Статья: Моделирование бизнес процессов управления: IDEF (Integration definition for function modeling)
В результате такого моделирования строятся управляющие процессы, являющиеся ортогональными к процессам оперативной деятельности. То есть переход от уровня к уровню понимается именно как процесс, а на графической схеме получается два ортогональных направления процессов: одно (горизонтальное) оперативное, второе (вертикальное) управления. Причем информацией для вертикального процесса, кроме внешней информации, является результат процессов последующих уровней, в то время как результат процесса предыдущего уровня является управляющей информацией для процессов последующего уровня, следовательно, реализуется управляющая обратная связь. Таким образом, при описании в виде схемы любой бизнес-процесс не должен пониматься плоским и однонаправленным, каждый процесс должен быть связан с другим ортогональным управляющим процессом. Именно такой управляющий процесс, решающий перспективные, стратегические проблемы организации и является в принципе приоритетным для руководителя, а не операционные процессы, решающие текущие вопросы. Хотя, как подчеркивалось выше, к такому пониманию в первую очередь необходимо придти самому руководителю.
Теперь вернемся ко второй проблеме. Допустим, что аналитик (разработчик, проектировщик бизнес-процессов) изобразил все описанные выше процессы, используя методологию IDEF, где отобразил руководителей, плановиков и т.д. Практически неизбежным вопросом будет представление данных схем самим участникам процессов, что особенно актуально при внесении изменений в процесс и необходимости их согласований в нескольких подразделениях компании.
Для решения данной проблемы, связанной с недостатком выразительности методологии IDEF, предлагается разработать правила переноса схем процессов в другое представление, называемое "SWIM-LINE". Фактически внутри компании разрабатывается внутренний стандарт презентации процессов, который описывает, в том числе, и данные правила конвертирования из одного представления, удобного для разработчиков, в другое, удобное для менеджера.
|
Пример. 1. "Дорожка" может представлять собой однородные объекты: сотрудника, отдел, службу, внешнего контрагента и т.д. 2. Каждая функция обязательно размещается на "дорожке". 3. Для каждой функции обязательны три дуги: вход, выход, управление. 4. "Дорожки" определяется из множества IDEF-дуг "Механизм". 5. IDEF-дуга "Механизм" заменяется на дополнительную исходящую дугу функции. 6. Группировка функций в фазы процесса производится по основным функциям менеджмента, и являются отражением уровней вложения IDEF-схемы. 7. На схему обязательно переносятся "Внешние источники данных". 8. Процесс изображается в естественном его направлении сверху вниз, при этом всегда имеет начало и конец, и т.д. |
На первый взгляд конвертирование из одного представления в другое может занять много времени аналитика. Во-первых, перевод IDEF в SWIM-LINE выполняется только лишь для проведения презентации процесса менеджерам, то есть выполняется не так часто, как может показаться. Во-вторых, как показывает практика, данные затраты времени аналитика окупаются при проведении самой презентации, что выражается не только многократным сокращением времени ознакомления менеджеров с материалом и времени его обсуждения, но и значительным повышением качества принимаемых решений, что в конечном счете и является целью всех проводимых мероприятий.
| Пример. На рис. 3 приводится упрощенная схема процесса продажи с участием руководителя службы (отдела) продаж. Для изображения схем может использоваться, например, MS-Visio с шаблоном Cross-functional Flowchart. Таким образом, основная логика, понятная аналитику и применимая для построения любой алгоритмической модели процесса, остается та же, что используется в IDEF, а меняется лишь внешний вид представления на более удобный для руководителя и менеджера. |
Рис. 3. Модель бизнес-процесса "Продажа".
Предложенный подход ориентирован на раскрытие целостности организации и обеспечивающих ее механизмов, на выявление многообразных управляющих связей, и реализует представление организации в виде иерархической модели, отражающей не только текущую деятельность сотрудников компании, но также руководителей и их процессы управления.
Стоит отметить, что, с одной стороны, для отражения изменяющейся и адаптируемой к внешней среде сущности организации схемы бизнес-процессов постоянно должны актуализироваться аналитиком (проектировщиком) параллельно с изменениями, происходящими в процессе управления, а с другой стороны, полученная схема не должна быть жестким правилом выполнения процесса. Одним из вариантов, используемым автором на практике, является создание так называемых "сценариев" процессов или динамически вызываемых вариантов выполнения процесса, реализующих характерное при процессном управлении смещение принятия текущих управленческих решений "вниз по иерархии", которое в рамках текущей деятельности заключается в частности в выборе сценария процесса, но это тема следующей отдельной статьи.
Список литературы
1. Садовский В.Н. Системные исследования: некоторые принципиальные проблемы построения общей теории систем, М.: Наука, 1971.
2. Месарович М. Теория иерархических многоуровневых систем, М.: Мир, 1973.
3. Мильнер .З. Системный подход к организации управления, М.: Экономика, 1983.
4. Авилов А.В. Рефлексивное управление. Методологические основания. М., 2003.
5. Котлер Ф. Основы маркетинга, СПб.: КОРУНА, 1994.
6. Друкер П.Ф. Задачи менеджмента в XXI веке, М., 2001.