Пример. 1. Дорожка может представлять собой однородные объекты: сотрудника, отдел, службу, внешнего контрагента и т.д.

1. " Дорожка" может представлять собой однородные объекты: сотрудника, отдел, службу, внешнего контрагента и т.д.

2. Каждая функция обязательно размещается на " дорожке".

3. Для каждой функции обязательны три дуги: вход, выход, управление.

4. " Дорожки" определяется из множества IDEF-дуг " Механизм".

5. IDEF-дуга " Механизм" заменяется на дополнительную исходящую дугу функции.

6. Группировка функций в фазы процесса производится по основным функциям менеджмента, и являются отражением уровней вложения IDEF-схемы.

7. На схему обязательно переносятся " Внешние источники данных".

8. Процесс изображается в естественном его направлении сверху вниз, при этом всегда имеет начало и конец, и т.д.

На первый взгляд конвертирование из одного представления в другое может занять много времени аналитика. Во-первых, перевод IDEF в SWIM-LINE выполняется только лишь для проведения презентации процесса менеджерам, то есть выполняется не так часто, как может показаться. Во-вторых, как показывает практика, данные затраты времени аналитика окупаются при проведении самой презентации, что выражается не только многократным сокращением времени ознакомления менеджеров с материалом и времени его обсуждения, но и значительным повышением качества принимаемых решений, что в конечном счете и является целью всех проводимых мероприятий.

Пример. На рис. 3 приводится упрощенная схема процесса продажи с участием руководителя службы (отдела) продаж.

Для изображения схем может использоваться, например, MS-Visio с шаблоном Cross-functional Flowchart. Таким образом, основная логика, понятная аналитику и применимая для построения любой алгоритмической модели процесса, остается та же, что используется в IDEF, а меняется лишь внешний вид представления на более удобный для руководителя и менеджера.

Рис. 3. Модель бизнес-процесса " Продажа".

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

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