Сегодня поговорим о том, когда содержание важнее формы и в каких случаях можно (и даже нужно) нарушать строгие правила формальных нотаций моделирования бизнес-процессов. В этой статье я поделюсь практическим опытом описания корпоративной деятельности и отвечу на один из самых частых вопросов начинающих бизнес-аналитиков: насколько важно соблюдать однозначные рекомендации по описанию процессов в 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-аналитик.
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
MODP
Ближайшая дата курса
13 июня, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Случай из личной практики: упрощаем нотации моделирования бизнес-процессов в угоду клиенту
Чтобы подтвердить вышесказанные тезисы, приведу недавний случай из своей практики. Передо мной стояла задача проанализировать сквозной бизнес-процесс, в который вовлечено множество участников на разных иерархических уровнях крупного предприятия с филиальной структурой и функциональной организацией деятельности. В первой итерации разработанная модель бизнес-процесса «как есть» в нотации EPC включала около 70 блоков и для наглядного представления размещалась на листе формата А3. Едва взглянув на эту схему, представитель Заказчика сразу отметил ее сложность и попросил «что-то попроще».
Закрыв глаза на строгие правила, я отрисовала модель в нотации BPMN, отбросив рекомендации по объединению потоков через логические шлюзы. Разделение по иерархическим уровням предприятия показала через дорожки, а исполнителей функций отметила в скобках названия процессного блока. Различный характер профильной деятельности отразила с помощью цвета процессного блока, чтобы показать их преемственность на разных уровнях организационной иерархии. В результате этих нехитрых приемов размер модели сократился более чем в 2 раза, а сама схема стала сразу понятной экспертам предметной области со стороны Заказчика.
Поскольку в данном конкретном случае вопрос разработки автоматизированных workflow-схем на основе процессных диаграмм не входил в текущий проект, то нарушение некоторых правил бизнес-моделирования не привело к негативным эффектам. А, наоборот, позволило быстрее прийти к взаимопониманию с клиентом и решить его проблемы, выявив организационные и технические возможности оптимизации анализируемого бизнес-процесса.
Основы бизнес-анализа: вход в профессию для начинающих
Код курса
INTRO
Ближайшая дата курса
28 июня, 2024
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Подробнее разобраться с популярными нотациями моделирования бизнес-процессов и особенностями их практического использования в реальных проектах вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы бизнес-анализа: вход в профессию для начинающих
- Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
