“Сверху” или “снизу”?

 

Хочу развенчать одну из крайностей в подходах к моделированию бизнес-процессов.

Очень часто перед началом формирования модели аналитики пытаются выбрать, а как правильно начать моделировать систему “сверху” или “снизу”? Т.е. правильно ли выстраивать процессы начиная с самого верхнего уровня, т.е. выстраивать структуру бизнеса в формате IDEF0 и затем декомпозировать спускаясь на более глубокие уровни, подгоняя результаты обследования бизнеса под жесткий каркас спускаемой сверху структуры? Или все таки правильным является подход при котором тотальный сбор информации (через анкетирование, интервью и т.д.) анализируется, формируются процедуры нижнего уровня, которые затем группируются и таким образом постепенно выстраивается структура верхнего уровня.

Правильными являются оба подхода одновременно. Т.е. структура приблизительно на два три уровня должна быть выстроена сверху. И только после того как структура согласована и принята высшим руководством, необходимо приступать к моделированию “снизу”. Объясню в чем суть такого компромиссного подхода на примере минусов и сложностей, подходов бескомпромиссных.

“Сверху”. Выбирая такой подход мы рискуем получить неадекватную модель по причине того, что структура и видение руководства, а именно это основная информация, на основании которой формируются укрупненные бизнес-процессы верхнего уровня, не всегда может на 100% соответствовать действительности. Вполне может сложится картина идеализированного представления о процессах, о разграничении сферы ответственности между владельцами бизнес-процессов и т.д. И пытаясь подогнать все под полученную структуру, т.е. создав структуру верхнего уровня глубиной 2 и 3 уровня,  и продолжая дальше декомпозировать, мы можем отсечь очень много ценной информации о реально существующей деятельности, взаимосвязях, а полученная картина процессов на нижних уровнях будет излишне разбита на мелкие подпроцессы и процедуры. Т.е. мы вместо сквозных процессов, которые главным образом и востребованы при процессном подходе, мы в итоге получим множество мелких операций, связанных между собой только структурно в нотации IDEF0.

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

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

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

Далее по результатам анкетирования (и/или интервьюирования) сотрудников начать описывать операции нижнего уровня, формировать процедуры и процессы, а затем группировать их подгоняя под полученный на первом этапе иерархию процессов верхнего уровня. Вот несколько рекомендаций:

• Даже перейдя с нотаций описания логики и взаимодействия (EPC, Cross-Functional Flowchart) на уровень структурного моделирования IDEF0 лучше придерживаться группировки процессов в более крупные по тому, в какой последовательности они выполняются. Т.е. нотация IDEF0 хоть и не призвана отображать логику взаимодействия и хронологическую последовательность, тем не менее при таком подходе читаемость диаграмм повышается, а связи взаимодействия процессов между собой ресурсами и информацией наиболее упрощаются и минимизируются междиаграмные переходы стрелок.
• Самым трудным может оказаться момент, когда необходимо будет сформировать слияние вершины айсберга с процессами нижнего уровня. На самом деле ничего сложно нет: просто в каждом случае рассогласования модели необходимо принять решение, корректировать структуру верхнего уровня или пересматривать группировку на нижнем уровне исходя из того, какой из подходов будет наименее трудоемким т.е., который повлечет наименьшую реструктуризацию сфер ответственности владельцев БП или перегруппировку процессов нижнего уровня для “подгонки” под процессы структуру верхнего уровня (именно перегруппировку т.к. реальные изменения бизнес-процессов на нижнем уровне инициированы не могут быть, т.к. если где в полученной информации и могут быть ошибки, так это ошибки при интерпретации сведений из анкет или ошибки в видении руководства на структуру процессов верхнего уровня, но никак не ошибки в самой деятельности компании)