Как описать бизнес-процесс: обзор и сравнение методологий

В этой статье рассказываем о вариантах популярных нотаций описания бизнес-процессов и их преимуществах. Детально рассматриваем элементы нотаций IDEF, EPC, VAD, UML, ДРАКОН, BPMN. После прочтения вы сможете сформировать общее представления и понять какую нотацию лучше выбрать под ваши задачи и цели описания процессов.

А надо ли описывать процессы?

Развивающийся бизнес рано или поздно приходит к пониманию необходимости описания системы управления, протекающих бизнес-процессов, так как без этого:

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

В практике, лица принимающие решения, говоря о целях описания бизнес-процессов, как правило, упоминают следующий набор потребностей:

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

В зависимости от цели формируется соответствующий подход, фиксируется точка зрения для моделирования, определяется кто целевая аудитория:

• непосредственно сотрудники, исполнители, участники;
• высокие руководители, которые должны в целом принимать решение об изменениях\трансформациях и иных проектах по улучшениям системы управления;
• внешние участники: аудиторы, консультанты, юристы, представители службы безопасности, иные лица;
• ИТ команда, которая должна использовать описания в качестве технического задания на автоматизацию/роботизацию;
• службы HR для последующего оргпроектирования, ведения модели расчёта численности;
• или все вместе

Исходя из целей, определяют требования к качеству описания и моделирования бизнес-процессов:

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

Когда мы зафиксировали цель и целевую аудиторию можно приступать непосредственно к описанию

Хрестоматийно деятельность по описанию процессов тоже можно представить как процесс, а при желании даже «описать процесс по описанию процессов» 😊, то есть:

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

Более подробно данная деятельность представлена в статьях:

Разработка и создание бизнес-процессов: пошаговое руководство с примерами, которые можно применить на практике и Описание бизнес-процессов: как структурировать работу по правилам

Когда мы знаем зачем описывать процессы и что такое описание, самое время ответить на вопрос “как описывать?” - какую нотацию и методологию описания бизнес-процессов использовать, тут есть варианты

Варианты, нотации, методологии описания процессов

Текстовый документ и простая блок-схема

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

С данными описаниями можно знакомить сотрудников, использовать в качестве основы технического задания на автоматизацию. Но текстовые описания и описания в виде таблицы (например, в варианте SIPOC = табличное представление, состоящее из столбцов: Поставщик – Вход – Действие – Выход - Потребитель) имеют существенные ограничения. Когда речь идёт о сложном, многовариантном процессе текстовое описание может занимать десятки страниц с множеством перекрестных ссылок.

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

Ответим на этот вопрос и для начала пойдём с самого, на первый взгляд, простого варианта – блок-схема. Как правило общий вид подобного описания выглядит следующим образом:

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

При кажущейся простоте использование простой блок-схемы имеет ряд ограничений, особенно когда речь заходит о цикличных или нелинейных процессах. Существенным ограничением является отсутствие единых общепринятых правил использования подобных схем, что влечёт за собой необходимость разработки и фиксации правил моделирования для конкретной организации. В противном случае есть существенный риск получить множество описаний на разных «наречиях», с разными «акцентами». В итоге обнулить все преимущества наличия схем как таковых.

В целом использование простой блок-схемы для разовых и проектных задач вполне себе применимо. Если же речь о выстраивании архитектуры и системы процессов как управленческой основы бизнеса обратите внимание на стандартизованные нотации и методологии описания бизнес-процессов. Их достаточно много, поговорим о некоторых из них: IDEF, EPC, UML, ДРАКОН, BPMN.

Системные нотации описания процессов

IDEF

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

IDEF является семейством нотаций, включающим в себя порядка 15 вариантов, в контексте текущей статьи основной интерес представляют 2:

• IDEF0 – для описания взаимосвязей на верхнем уровне;
• IDEF3 – для описания выполнения конкретного процесса

Общие правила, используемые в IDEF – моделируем «слева направо», «сверху вниз»

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

Общий вид нотации IDEF3 представлен на следующем рисунке:

Посредством IDEF3 могут быть предоставлены достаточно детальные описания, в том числе используемые в качестве инструкций для сотрудников

IDEF3, равно как и IDEF0 можно довольно легко использовать в распечатанном виде.

EPC (Event-driven Process Chain)

«Ну, во-первых это красиво...»

По сравнению с нотацией IDEF нотация и методология EPC содержит много разноцветных геометрических фигур, посредством которых можно проводить как верхнеуровневое описание, так и детальное моделирование

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

В общем виде модель EPC представлена на рисунке ниже:

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

EPC позволяет использовать довольно много элементов поэтому вопрос наличия Соглашения о правилах моделирования в рамках компании является достаточно важным.

VAD (Value-Added Chain Diagram)

Моделирование в нотации VAD (цепочка добавленной ценности) предусматривает описание верхнеуровневых процессов и их взаимосвязей

В общем виде диаграмма VAD представляет из себя:

Визуально данная диаграмма может дополняться иными элементами, в случае необходимости визуальных акцентов

В целом данная нотация служит для формирования общего представления о процессах в компании и\или создания презентационных материалов для руководителей

Фактически VAD является аналогом IDEF0, а EPC заменяет IDEF3

UML (Unified Modeling Language)

UML – универсальный язык моделирования, который в первую очередь используется при описании программных продуктов и процессов, происходящих в информационных системах. UML является стандартизованным языком, содержит 14 видов диаграмм:

- составной структуры;

- развертывания;

- пакетов;

- профилей;

- классов;

- объектов;

- компонентов;

- деятельности;

- прецедентов;

- состояний;

- последовательности;

- коммуникаций;

- обзора взаимодействия;

- времени)

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

Одной из основных схем, которая может рассматриваться в контексте данной статьи является Диаграмма деятельности, она довольно схожа с кросс-функциональными дорожками. В общем виде диаграмма деятельности может выглядеть следующим образом:

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

В целом подход к моделированию процессов при системной и программной инженерии отражён в ГОСТ Р 57098-2023 «Управление жизненным циклом. Руководство для описания процесса»

«ДРАКОН»

ДРАКОН, является аббревиатурой, раскрывается как «Дружелюбный русский алгоритмический язык, который обеспечивает наглядность»

Импортозамещение в среде нотаций и методов описания бизнес-процессов, имеющее отношение к космической отрасли, получившее развитие в здравоохранении :)

В общем виде схема ДРАКОН является линейной, математически строгой и запрещает пересечение сценариев, схематично представляет собой следующий вид

Данный язык моделирования не так широко распространён, но вполне может использоваться для формирования схем – инструкций

BPMN 2.0 (Business Process Model and Notation)

BPMN – в настоящее время, пожалуй, самый популярный, универсальный и стандартизованный язык моделирования бизнес-процессов. Он позволяет использовать результат моделирования в большом числе сценариев и целях моделирования.

В рамках использования нотации BPMN есть возможность провести детальное моделирование для использования результатов в качестве:

- регламента работы;

- презентационных материалов для руководства;

- основы для проекта по повышению качества процесса;

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

В общем виде BPMN диаграмма выглядит следующим образом

 Детально о нотации BPMN в статье “BPMN: полное руководство на примерах”.

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

В рамках таблицы представлено общее сравнение нотация моделирования, а также возможности их использования

Инструменты описания процессов

Когда вопрос и «муки выбора» нотации завершён, то появляется следующий не менее важный вопрос – вопрос инструментария описания.

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

Отдельно стоит отметить следующие:

• разгон от начала регистрации в системе до первой удобоваримой модели порядка 5 минут, в т.ч. с помощью AI– помощника + интуитивно понятного интерфейса системы;

• помощь, подсказки по ошибкам моделирования согласно нотации, с учётом строгости и сравнительной сложности самой нотации существенное подспорье;

• оценка модели по десятибалльной шкале, что позволяет выстраивать диалог и правила с сотрудниками без перехода в оценки: нравится\не нравится.

Заключение

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

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

В рамках выбора нотаций важно также сразу ответить на вопросы связанные с:

• хранением общей базы моделей бизнес-процессов;
• управлением версионностью описаний;
• вариантами и способами предоставления доступа к моделям на этапах разработки\согласования;
• механизмами ознакомления участников с итоговыми вариантами описаний;
• способом фиксации и контроля правил моделирования процессов.

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

Ну и напоследок

Готовьте процессы с удовольствием, используя только качественные ингредиенты.

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