3.3.2. Требования к описанию процесса базового уровня в простейшей кросс-функциональной нотации

Простейшая нотация должна решить несколько задач. Во-первых, должна быть совершенно понятной любому новичку в этой области. Во-вторых, сохранять жесткость описания на базовом уровне бизнес-процесса. В-третьих, представлять собой этакий синтез схемы и таблицы, т.е. когда каждый существенный элемент либо стоит на своем месте, либо это место пустое. Очень дисциплинирует исполнителей и облегчает жизнь проверяющим специалистам. После долгих проб мы выбрали формат о котором кратко уже говорили в разделе 3.1.6.

Этот формат, в отличии от общепринятого кросс-функционального, представляет собой четырех колоночную таблицу в каждой строке которой описывается одна процедура. Помните, процедура – часть процесса, которую выполняет один исполнитель. Соответственно, в каждой строчке на первом месте идет овал с исполнителем, затем – прямоугольник с именем процедуры и основными действиями, потом – ромб с условием разветвления (если важен) и заканчивается строка – результатом.

На такой нотации видно и процедуру и её исполнителя. Причем сразу снимается чуть ли не главный парадокс традиционного мышления. Напомним, для большинства людей нормально не процессное, а субъектное мышление. Т.е. когда человек мыслит не частями процесса, а отношениями субъектов. Помните А передает Б, Б – С, С обратно А и т.п.

Обратите внимание, на приведенном выше упрощенном примере, после каждой проверки могут появиться замечания. Кому они передаются? Менеджеру (заказа), но не в процедуру, где он разрабатывает проект договора (он уже давно разработан), а в дополнительную процедуру по исправлению замечаний или доработки! Это описание процесса в рамках процессного мышления. Каждый раз когда исполнитель появляется в процессе – он выполняет новую процедуру…

Кажется, что это правило банально и понятно каждому здравомыслящему работнику. Когда он смотрит на схему – да, а вот когда рисует схему увы не всегда, особенно на первых двух-трех схемах. Парадокс в том, что большинство менеджеров и специалистов компании, привлекаемые к разработке схем как эксперты в предметной области – рисуют не более 5 схем, а потом идут работать.

Очень важно в нашей версии кросс-функциональной нотации не терять стрелки-соединители. Причем между исполнителем, процедурой, условием и результатом – они могут идти только одним образом: слева направо, показывая чья процедура, условие и результат. А вот между результатом и следующим исполнителем – стрелка может быть и короткой и длинной, но должна показывать: кому придет результат для продолжения работы.

Чтобы отслеживать, как передается результат мы настоятельно рекомендуем использовать разные способы обозначения для материалов, бумажных и электронных документов и устных сообщений. При использовании других нотаций про это как правило забывают и теряется очень важная информация: в какой форме передан результат… С материалами то все понятно, а вот с информацией или командами есть громадная разница как она передается: устно, на бумажке, по электронной почте или через запись в Базе данных. Кроме того, после описания процесса в виде схемы всегда можно спросить: вот вы тут передаете замечания в какой форме? – Эээ, по почте – Покажите пример – Ну вообще-то должны по почте, но как правило, устно… А любая устная передача информации или управленческих воздействий – это потенциальная угроза для процесса… Хотя иногда без устных команд обойтись невозможно – иначе работа превращается в бессмысленный труд по написанию бумажек

Ну и как мы уже говорили в разделе 3.1.6. мы настоятельно не рекомендуем использовать обозначения типа "База данных" или "Событие". В силу их недостаточной конкретности. Вместо "База данных" лучше использовать более точное "электронный документ", например "запись в CRM о новом клиенте…"

Событие же использовать только в случае крайней необходимости, т.е. когда никаких других носителей информации не возникает. Например: "Наступило 5 число месяца"… и то при условии, что в процессе исполнителю никто про это наступление даты Х не напоминает. Ну и при описании события следует использовать такое определение события (из соглашения по терминологии ARIS): событие – это точное описание состояния в которое пришла система.

После краткой характеристики используемых приемов описания, давайте перейдем к самому описанию. Обучение описанию процессов мы делим на два этапа: первичное описание и проверка/верификация.

Предыдущая страница || Следующая страница >>