Шрифт:
Рис. 4.5.2. Пример структурной модели процессов торговой компании [90] . Стандарт IDEF0
Однако в случае проектирования компании с нуля проработка основных связей на структурной схеме очень полезна. Но такие случаи на практике встречаются редко.
Вопрос пользы структурных моделей для решения задач бизнес-моделирования спорный. С моей точки зрения, построение сложной, многоуровневой системы процессов организации в одной модели IDEF0 (или в другой нотации) излишне. Если соблюдать все формальные правила, то в такой модели может получиться семь-восемь уровней декомпозиции. Реальную же ценность для последующего описания и регламентации имеют один-два нижних уровня, где выполняются конкретные операции и осуществляется реальный документооборот. Именно на этих уровнях процессы можно описать в формате Work Flow и при помощи этих описаний сформировать регламенты работы сотрудников («регламент процесса», «инструкция по выполнению процесса» и т. п.). Вопрос в том, как разработать адекватный реальному бизнесу иерархический справочник процессов [91] . Если можно обойтись без сложной (понятной только бизнес-аналитику) структурной модели процессов, то и не нужно ее создавать.
90
Модель учебная. Подразделения – исполнители процессов не показаны. Обратные связи тоже.
91
Этот вопрос подробно обсуждался в главе 3.
Примечание. В крупной, давно работающей компании построение сложной структурной модели может не принести ожидаемого результата. Дело в том, что топ-менеджмент вряд ли решится перекраивать весь бизнес по модели в IDEF0. А с точки зрения регламентации на операционном уровне все верхние уровни (3–5-й) в модели IDEF0 бесполезны.
Другое дело, если нужно спроектировать новый бизнес. Эта работа выполняется по принципу «сверху вниз», так как действующих процессов и самой компании пока нет. Анализ структуры и связей процессов на верхнем и среднем уровнях полезен для принятия решений о структуре будущей организации и закреплении групп процессов за подразделениями.
Итак, структурная модель процессов нужна:
• бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь для корректного перехода к процессам уровня Work Flow – регламентируемым или автоматически исполняемым в BPMS процессам);
• руководителям организации для:
– уточнения зон ответственности, целей и задач их деятельности;
– анализа и совершенствования архитектуры бизнеса;
• руководителям и бизнес-аналитикам при проектировании нового бизнеса.
Замечу, что среди руководителей компаний желающие работать со структурной графической моделью процессов верхнего уровня встречаются редко. Поэтому многоуровневая структурная модель (например, в IDEF0) – удел узкого круга бизнес-аналитиков. В лучшем случае руководители используют диаграмму первого уровня, которую размещают на стенде с нормативно-методической документацией.
4.6. Модели процессов на операционном уровне
В этом параграфе мы рассмотрим модели процессов на операционном уровне. Они отображают последовательность выполнения операций процесса (подпроцессов) во времени. Их обычно называют «модели Work Flow» [92] .
92
Work flow – «поток работ» (англ.).
Сейчас существует множество нотаций типа Work Flow, при помощи которых можно описывать процессы операционного уровня. Рассмотрим основу формирования моделей и некоторые важные аспекты их применения.
4.6.1. Нотации типа Work Flow
На рис. 4.6.1 показаны основные элементы, которые используются практически во всех современных нотациях Work Flow. Можно выделить пять основных:
1. События.
2. Операторы логики (по-другому их называют: блоки решения, ветвления/развилки, шлюзы/гейтвеи [93] ).
93
Gateway – «ворота, шлюз» (англ.).
3. Операции процесса.
4. Стрелки типа «Связь предшествования».
5. Стрелки типа «Поток объектов».
События служат для определения границ процесса. Они могут указывать на его начало и завершение. Кроме того, возможны промежуточные события, возникающие по ходу выполнения процесса. Примеры именования событий: «Поступила заявка клиента на отгрузку продукции», «Утвержден план проекта», «Подписана накладная», «8.00 понедельника» и т. п. Как видно на рис. 4.6.1, в различных нотациях события показаны при помощи разных условных обозначений. Особняком стоит BPMN 2.0 [94] (см., например, [9]). В рамках этой нотации внутри графического элемента «Событие» могут присутствовать различные маркеры: таймер, сообщение, триггер и т. д.
94
Business Process Model and Notation.
Рис. 4.6.1. Основные элементы нотации Work Flow
Операторы логики служат для описания ситуаций, связанных с ветвлением процесса. Оно может произойти по разным причинам (например, принятие решения, проверка условия). Операторы логики бывают трех типов [95] : логическое «И», логическое исключающее «ИЛИ», логическое неисключающее «ИЛИ».
На рис. 4.6.2 приведен пример использования операторов логики при построении схемы типа Work Flow (графические обозначения операторов логики на схеме условные).
95
За исключением BPMN.
Рис. 4.6.2. Использование операторов логики
При использовании логического оператора «И» (ситуация 1) после операции 1 выполняются операция 2 и операция 3.
При использовании логического оператора исключающее «ИЛИ» (ситуация 2) после операции 1 выполняется одна из двух операций – 2 или 3.
При использовании логического оператора неисключающее «ИЛИ» (ситуация 3) после операции 1 выполняется операция 2, либо операция 3, либо операции 2 и 3.