Хочу все знать: бизнес-анализ. Часть 2

→ Первая часть тут

Анализ и описание процессов

Следующим пунктом бизнес-анализа является описание бизнес процессов. На этом этапе, обычно, рисуют, так называемые диаграммы бизнес-процессов «As is». И вот тут-то всех и поджидают проблемы, что называется, на ровном месте. Самая большая проблема в том, что за деревьями не видно леса. Так же, как и при описании бизнес-целей, зачастую народ увлекается описанием того, как все работает прямо сейчас. При этом редко кто задается целью разобраться, а насколько текущие процессы вообще соответствуют тому, как все должно быть? Все наверняка знают одно из правил автоматизации: «автоматизируя бардак — мы получаем автоматизированный бардак, и ничего более». Так вот, чтобы не строить очередной «скайнет», который всех уничтожит, необходимо понять — «а как же все вообще должно функционировать?». И это очень интересная задача.

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

Так вот, не будет далеко уходить от нашего прекрасного примера с почтой, и рассмотрим «простейший» процесс — «услуга доставки бандеролей». Для тех, кто знает кухню почты, сразу предупреждаю, что дальше описывается упрощенный пример в «рафинированном виде», то, каким его может увидеть бизнес-аналитик, или даже менеджер. Подробностей в стиле «привязки к существующей инфраструктуре» и прочих «исторически сложившихся условий» тут не будет. По сути, все эти детали рассматриваться уже на третьем этапе работ бизнес-аналитика, который в данной статье не рассматривается. Более того, на данном этапе нам вообще не нужны технические детали и даже скажу больше, от них надо всячески уходить, иначе мы просто затрудним себе задачу. Подробности и детали, как и описание процессов «As Is» — нужны, важны и используются именно в части анализа процессов и последующих предложений, рекомендаций и прочего

Итак, у нас есть цель – доставка ценностей от заказчика – получателю. У нас есть вариант достижения этой цели:

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

Как уже говорил, мы берем упрощенный процесс, чтобы показать, на что надо обращать внимание, и что нужно делать. Как видим, все достаточно просто и можно хоть сейчас чего-нибудь рисовать. Но, не будет торопиться. Как говориться «Обязательно бахнем, и не раз. Весь мир в труху. Но потом» (ц). Так вот, вернувшись в сей бренный мир из тумана грез, перед нами стоит задача, описать, как мы (компания) может обеспечить исполнение потребности (доставка бандероли), и не только ее обеспечить, но и гарантировать, что заинтересованные стороны (заказчик и получатель) будут удовлетворены. И последнее замечание, является важным, я бы сказал, определяющим. Да, я знаю, что будет много возражений в стиле «целью бизнеса является зарабатывание денег», «компаниям наплевать на клиентов» и множество других, вполне резонных. Но, повторяю еще раз, целью бизнеса – является удовлетворение потребности. А уж насколько прибыльно это занятие, это уже другой, коммерческий вопрос.

Продолжаем. Нам необходимо гарантировать удовлетворение потребности. Просто потребности, без учета затрат, объемов и прочего. Можно сказать, что если заинтересованные лица воспользовались этой услугой и остались довольны результатом, значит — мы успешно достигли цели. То есть, нам надо просто понять, а почему эти самые лица могут быть недовольными? Вариантов немного: ожидаемые события не случились, или случились не так, как ожидалось. В нашем конкретном случае имеем куст вариантов с уточняющими вопросами:

1. Получатель не получил бандероль
   
   • Получатель утверждает/уверен, что именно данная, конкретная бандероль им не получена (Как мы может это проверить? Кто и как ее передает, и как это фиксирует?).
     
   • Бандероль не доставлена, когда ожидалась:
     
     • Нет согласованных требований к срокам доставки (Почему были другие ожидания? Фиксировалось ли это каким либо образом?).
       
     • Компания (или отдельные ее сотрудники, подрядчики) не имеют возможности выполнить работу: болеют, нет соответствующей квалификации, недоступны тех. средства (Кто за этим следит, и когда об этом стало известно?)
       
     • Компания (или отдельные ее сотрудники, подрядчики) ничего не знают о данной бандероли. (Как это проверить?)
2. Получатель не доволен тем, что и как получил. Например, вложение было повреждено. (В данном случае не понятно, проверялись ли вложения, или откуда эти «требования к бережному обращению» могли быть известны исполнителю/работнику. Более того, как исполнитель/работник может быть уверен, что требования, предъявляемые к вложению и/или обращению с отправлением, соответствует ожиданиям конкретного заказчика?)
3. Отправитель отказался от услуг:
   
   • заказчик не смог воспользоваться услугой, например, была очередь, или он не получил информации, что услуга доступна – например сотрудник не смог ее разъяснить, или же у него недостаточно квалификации чтобы ее оказать (Фиксируются ли обращения и результаты?).
     
   • предложенная услуга не соответствует пожеланиям заказчика, например по цене, или иным условиям (Как об этом мы можем узнать?).
   
   

Это похоже на «управление рисками», и нам необходимо отразить эти риски и поспособствовать их минимизации. Как видим, даже не вникая глубоко в фактические детали, мы уже получили общее представление о том, что должно делаться и что нам нужно контролировать. Безусловно, этого недостаточно чтобы получить полную картину происходящего или давать какие-либо советы. Тем не менее, на данном этапе этой информации достаточно, поскольку она уже раскрывает особенности, которые при описании «As Is» могут быть упущены. И ценность этой информации высока, поскольку любой, кто будет иметь наглядное представление о том, что делается, как и для чего – всегда сможет оценить, насколько текущие реализации процессов адекватны целям и условиям.

Итак, мы уже знаем о нашем процессе кое-что, но как все это сделать доступным и понятным для любого человека, без прочтения «… дцати» страниц текста? Ответ известен всем – надо просто нарисовать. И, как обычно, нас поджидает другой «сюрприз». Большинство используемых методологий графического отображения бизнес-процессов рекомендуют на диаграммах отображать именно технические детали (BPMN, UML, EPC и др.). В этом нет ничего плохого и на этапе анализа и подготовки рекомендаций диаграммы «As Is» и «To Be» именно такими и должны быть. Но когда мы описываем непосредственно сам процесс, его логику и правила, эти детали, как песок пустыни, покрывают любые сокровища. В результате, мало кто в состоянии сразу оценить корректность или ошибочность самих процессов или их понимание бизнес-аналитиком.

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

Мой вариант такой диаграммы я называю «Сафед-диаграмма», от таджикского/персидского «сафед»- ясный, чистый, белый. По сути, Сафед-диаграммы содержат консолидированную и обобщенную информацию о логике процессе, что упрощает понимание. Сами диаграммы я «рисовал» в Excel, так что никаких магических инструментов так же не требуется. И еще небольшое пояснение, я не привожу ни текстового описания процесса, но то, почему указаны те или иные особенности и детали, ни даже пояснений к используемой нотации. На данном этапе моя цель – показать, насколько диаграмма-схема может быть понятной даже без прочтения текстового описания и без приведения расшифровки к используемой нотации.

Итак, отображение логики процесса «указания услуги доставки бандероли» будет выглядеть примерно как на рисунках ниже (я разбил сам процесс на 3 части, чтобы было удобно его рассматривать):

Часть 1 (крупнее):


Часть 2 (крупнее):


Часть 3 (крупнее):


И дополнительные схемы — движение и источники данных для процесса (крупнее):


Как можете видеть, на диаграммах явно указано, кто и что делает, откуда берет или где фиксирует данные, кто отвечает за их (данных) актуальность и заполнение. Хоть сейчас составляй должностные инструкции. Более того, видно, какие должностные обязанности можно совместись. Одним словом, мы прозрели и явно видим, что должно происходить.

При этом у схемы процесса есть места вокруг самой диаграммы, где мы вольны добавлять произвольные пояснения и детали (в моем случае я добавил пару рассшифровок и коментарии к этапам). При необходимости, можно добавить и «второй слой» для замечаний, и дать возможность заинтересованным лицам вносить свои вопросы, комментарии и/или замечания к отдельным шагам процесса.

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

1. Если мы рассмотрим этап транспортироки, то видим, что мы никак не контролируем, что происходит с бандеролью после перадачи ее в транспортный отдел или компанию. Таким образом, надо или дополнительно требовать со смежников ведение мониторинга доставки, или же на нашей стороне контролировать «журнал транспортировки», на случай задержек или «пропаданий» отправлений. По-хорошему, этот нюанс должен быть отдельно описан и отражен на схеме процесса.
   
   
2. Для роли/должности «Комплектовщик» не указаны источники регламентирующих данных. С одной стороны, вся информация может быть в «наряде на доставку» и/или в «Журнале транспортировки», с другой же – это может быть результатом упущения бизнес-аналитика. В любом случае должны быть пояснения, поскольку появляется риск неверных действий сотрудника со всеми вытекающими.
   
   
3. Аналогично, как и в предыдущем замечании, при получении отправлений из транспортировки и далее, на финальных стадиях, ни для одного их сотрудников не указаны регламентирующие источники

Вероятно, будут также замечания на «избыточность» указания источников/наборов данных, которые присутствуют на последней схеме. Однако я их включил не просто так. В случае процессов, связанных с IT, да и вообще, для контроля над процессом и данными, это необходимая информация. Пользователь диаграммы получает возможность видеть и оперативно получить детали: кто, какую информацию и откуда ее вносит в тот или иной набор данных.


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

В принципе, нечто похожее можно изобразить и в рамках BPMN, EPC и UML. Однако рекомендации для этих нотаций больше ориентированы на описание конкретных реализаций процессов, а не на их логику. Я надеюсь, что все понимают, что идея в том и состоит, чтобы применять подобные Сафед-диаграммы как дополнение, как отправную точку для анализа процессов «As Is» и «To Be», а не как замену этих диаграмм.

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

У меня все. Надеюсь, кто-то найдет для себя что-нибудь полезное.

Всем удачи и успехов.


Источники изображений:

1. Песик и «бардак на почте» — отсюда и отсюда, соответственно.
2. Диаграмки — личное творчество.