Вредные советы опытного бизнес-аналитика. Часть 1: не топите за нотации

автор
Вредные советы опытного бизнес-аналитика. Часть 1: не топите за нотации

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

Правила моделирования соблюдать нельзя нарушить

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

Когда я преподавала в ВУЗе, мои студенты могли запросто получить «неуд», отправив 2 потока управления в один функциональный блок EPC напрямую, вместо того, чтобы объединить их с помощью соответствующего логического оператора (AND, OR, XOR). Однако, жизнь гораздо интереснее учебных примеров. Чаще всего разработанная по всем правилам схема бизнес-процесса в нотации EPC или BPMN, покажется представителю Заказчика или эксперту предметной области слишком громоздкой и сложной для понимания. А разработчик ПО может посчитать разработанную аналитиком диаграмму последовательностей UML слишком примитивной и не отражающей технических особенностей, связанных с синхронными и асинхронными вызовами.

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

Разумеется, подобные вольности с нотациями допустимы, если речь не идет об автоматизации ваших процессных схем, как это бывает в случае BPMN-диаграмм, отправляемых на исполнение в BPMS-систему. Некорректно нарисованная диаграмма, точнее, ее отображение в виде XPDL или BPEL-файлов просто не будет понято потребителем – исполняющим движком прикладной системы, будь то BPMS, СЭД, ERP, CRM и пр. Аналогичные ошибки могут возникнуть при имитационном моделировании бизнес-процессов, например, в Business Studio. Поэтому, когда аналитик разрабатывает диаграмму бизнес-процесса для его последующей автоматизации в виде workflow-схемы потока действий, правила нотаций BPMN и EPC нарушать нельзя.

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

 

Случай из личной практики: упрощаем нотации моделирования бизнес-процессов в угоду клиенту

Чтобы подтвердить вышесказанные тезисы, приведу недавний случай из своей практики. Передо мной стояла задача проанализировать сквозной бизнес-процесс, в который вовлечено множество участников на разных иерархических уровнях крупного предприятия с филиальной структурой и функциональной организацией деятельности. В первой итерации разработанная модель бизнес-процесса «как есть» в нотации EPC включала около 70 блоков и для наглядного представления размещалась на листе формата А3. Едва взглянув на эту схему, представитель Заказчика сразу отметил ее сложность и попросил «что-то попроще».

Закрыв глаза на строгие правила, я отрисовала модель в нотации BPMN, отбросив рекомендации по объединению потоков через логические шлюзы. Разделение по иерархическим уровням предприятия показала через дорожки, а исполнителей функций отметила в скобках названия процессного блока. Различный характер профильной деятельности отразила с помощью цвета процессного блока, чтобы показать их преемственность на разных уровнях организационной иерархии. В результате этих нехитрых приемов размер модели сократился более чем в 2 раза, а сама схема стала сразу понятной экспертам предметной области со стороны Заказчика.

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

Подробнее разобраться с популярными нотациями моделирования бизнес-процессов и особенностями их практического использования в реальных проектах вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Комментировать