Бизнес-процессы. Моделирование, внедрение, управление - Владимир Репин

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

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

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

Для формирования структурных моделей используются соответствующие нотации: IDEF0, ARIS Value Added Chain, Value Stream Map (информационные потоки) компании Toyota, модель цепочек создания ценности и др. Информация о них содержится во многих публикациях, поэтому в своей книге я не стану касаться этого вопроса.

Структурные модели процессов, как правило, применяются для:

• описания, анализа бизнес-модели организации и определения возможных направлений ее реорганизации;

• разработки системы бизнес-процессов организации по принципу «сверху вниз»;

• системного описания процессов, которые необходимо автоматизировать (например, в ERP-системе);

• описания состава процессов, декомпозированных на следующий уровень (несистемное, фрагментарное использование).

Рассмотрим деятельность торговой компании (розничная торговля продуктами питания). На рис. 4.5.1 показан пример структурной модели процессов, выполненной без использования специализированной нотации на основе анализа цепочек создания ценности, осуществляемых компанией.

Рис. 4.5.1. Пример структурной модели торговой компании[89]

На рис. 4.5.1 видно, что в модели выделено семь групп процессов. Цель ее построения – демонстрация возможного варианта определения и группировки процессов торговой компании. Такая модель может быть представлена руководителям верхнего уровня для согласования. В дальнейшем модель используется при построении системы процессов организации.

На рис. 4.5.2 та же модель, что и на рис. 4.5.1, только выполненная в стандарте IDEF0.

Анализируя рис. 4.5.2, отмечу, что многочисленные стрелки, которые обычно представлены на схемах IDEF0, не так уж важны руководителям бизнеса для понимания и использования модели. Менеджеры крупной торговой компании, проработавшие в бизнесе много лет, хорошо представляют себе основные результаты работы каждого структурного подразделения (ассортиментная матрица, план продаж и закупок и т. п.). Поэтому загромождение структурной схемы стрелками скорее развлечение, а не деятельность бизнес-аналитика, полезная для управления. Нужно стремиться минимизировать количество стрелок, сохраняя при этом информативность схемы.

Рис. 4.5.2. Пример структурной модели процессов торговой компании[90]. Стандарт IDEF0

Однако в случае проектирования компании с нуля проработка основных связей на структурной схеме очень полезна. Но такие случаи на практике встречаются редко.

Вопрос пользы структурных моделей для решения задач бизнес-моделирования спорный. С моей точки зрения, построение сложной, многоуровневой системы процессов организации в одной модели IDEF0 (или в другой нотации) излишне. Если соблюдать все формальные правила, то в такой модели может получиться семь-восемь уровней декомпозиции. Реальную же ценность для последующего описания и регламентации имеют один-два нижних уровня, где выполняются конкретные операции и осуществляется реальный документооборот. Именно на этих уровнях процессы можно описать в формате Work Flow и при помощи этих описаний сформировать регламенты работы сотрудников («регламент процесса», «инструкция по выполнению процесса» и т. п.). Вопрос в том, как разработать адекватный реальному бизнесу иерархический справочник процессов[91]. Если можно обойтись без сложной (понятной только бизнес-аналитику) структурной модели процессов, то и не нужно ее создавать.

Примечание. В крупной, давно работающей компании построение сложной структурной модели может не принести ожидаемого результата. Дело в том, что топ-менеджмент вряд ли решится перекраивать весь бизнес по модели в IDEF0. А с точки зрения регламентации на операционном уровне все верхние уровни (3–5-й) в модели IDEF0 бесполезны.

Другое дело, если нужно спроектировать новый бизнес. Эта работа выполняется по принципу «сверху вниз», так как действующих процессов и самой компании пока нет. Анализ структуры и связей процессов на верхнем и среднем уровнях полезен для принятия решений о структуре будущей организации и закреплении групп процессов за подразделениями.

Итак, структурная модель процессов нужна:

• бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь для корректного перехода к процессам уровня Work Flow – регламентируемым или автоматически исполняемым в BPMS процессам);

• руководителям организации для:

– уточнения зон ответственности, целей и задач их деятельности;

– анализа и совершенствования архитектуры бизнеса;

• руководителям и бизнес-аналитикам при проектировании нового бизнеса.

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

4.6. Модели процессов на операционном уровне

В этом параграфе мы рассмотрим модели процессов на операционном уровне. Они отображают последовательность выполнения операций процесса (подпроцессов) во времени. Их обычно называют «модели Work Flow»[92].

Сейчас существует множество нотаций типа Work Flow, при помощи которых можно описывать процессы операционного уровня. Рассмотрим основу формирования моделей и некоторые важные аспекты их применения.

4.6.1. Нотации типа Work Flow

На рис. 4.6.1 показаны основные элементы, которые используются практически во всех современных нотациях Work Flow. Можно выделить пять основных:

1. События.

2. Операторы логики (по-другому их называют: блоки решения, ветвления/развилки, шлюзы/гейтвеи[93]).