Графический метод описания бизнес процессов

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

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

• CFFC (Cross Functional Flow Chart. Кросс-функциональная модель, или «диаграмма дорожек») — см.  Рис. 1. По мнению многих экспертов, она наиболее проста для разработки и чтения. Данная нотация интуитивно понятна сотрудникам и имеет очень широкое распространение. Но есть два недостатка: ограничение по количеству «дорожек» (субъектов — исполнителей бизнес-процесса) на листе А4, недостаточный набор фигур для отображения всех необходимых сущностей и атрибутов (например, отсутствие фигур «базы данных» и «программный продукт»).

Рис. 1. Нотация «Cross Functional Flow Chart» — модель процедуры «Оформление и выдача кредита»

• EPC (Event driven Process Chain. Цепочка процесса, управляемая событиями) — см. Рис. 2. Содержит большой набор фигур для отображения всех основных сущностей и атрибутов на моделях бизнес-процессов. Имеет хорошую визуализацию и цветовое оформление.

Рис. 2. Нотация «EPC» — модель процедуры «Разработка / модификация продукта банка»

• BPMN (Business Process Model Notation. Модель и нотация бизнес-процесса) — см. Рис. 3. Является наиболее сложной и многофункциональной нотацией. Есть организации, которые полностью описывают все свои бизнес-процессы в BPMN и имеют более 200 моделей в формате А4 с постоянной актуализацией.

Рис. 3. Нотация «BPMN» — модель процедуры «Прием сотрудников на работу»

• Basic Flow Chart и IDEF0. Оисание этих двух нотаций не входит в задачу данной статьи.

Разработку графических моделей необходимо выполнять с помощью программных продуктов бизнес-моделирования (например, Business Studio или Microsoft Visio). Каждый программный продукт поддерживает разный набор нотаций. Подробное описание всех нотаций утверждается в документе «Соглашение по бизнес-моделированию». Для бизнес-аналитиков (методологов) это единые договорённости по разработке, а для сотрудников организации — памятка по правильному чтению (интерпретации) графических моделей.

Форматы описания бизнес-процессов по их оформлению (формализации)

Рассмотрим 3 основных формата.

1. Текстовый формат. Для сложных бизнес-процессов это обычно несколько текстовых регламентов с общим объёмом более 100 страниц А4. У этого формата есть немало минусов и недостатков, тем не менее, он является самым распространённым на сегодняшний день.
2. Табличный формат  — более формализованный (структурированный) и компактный. Бизнес-процесс представляется в виде таблицы со следующими столбцами: функции (действия), вход, источник входа, выход, потребитель выхода, требования к срокам, комментарии и др.
3. Графический формат. В России уже известны организации (в первую очередь банки — см.  [1]), которые имеют все свои процессные регламенты в графическом формате (т. е. они состоят только из моделей). Такая практика с каждым годом получает всё более широкое распространение. На наш взгляд, все организации, которые ориентированы на долгосрочное и эффективное ведение бизнеса в условиях конкурентной среды, перейдут к графическому описанию бизнес-процессов.
   Однако следует отметить, что специализированные методики и правила (например, методику анализа финансового состояния клиента, правила юридической проверки клиента) не нужно описывать в виде моделей. Это технически сделать очень сложно и нецелесообразно. Поэтому подобные методики следует применять в качестве текстовых приложений к графическим моделям бизнес-процессов.

Есть ещё и четвёртый формат, редко встречающийся в организациях, но запоминающийся. Это описание бизнес-процесса в формате презентационных слайдов (например, MS Power Point), состоящих из «живых» картинок (Clipart), фотографий и текстовых пояснений. Данному формату нельзя придать юридическую силу (официально утвердить), но, как это ни странно, бизнес-процессы в течение многих лет работают на основе этого формата описания. Работают с ошибками, операционными рисками и проблемами, но руководители не понимают этого или не хотят менять подход.

Во многих организациях (особенно среднего и небольшого размера) бизнес-процессы, к сожалению, вообще не описаны. Нет ни моделей, ни регламентов, ни каких-либо официальных материалов. Есть только виртуальные знания и договорённости, которые находятся «в головах» сотрудников и руководителей организации. Подробные рекомендации и примеры того, как описать бизнес-процессы с минимальными инвестициями и рисками, рассмотрены в [2].

Почему важно именно графическое описание бизнес-процессов

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

• Визуализировать (представить наглядно) логику бизнес-процесса. Например, для коллективного обсуждения и анализа.
• Быстро и точно выявить ошибки и операционные риски в бизнес-процессах. Также очень удобно на моделях отметить те места, в которых могут реализоваться операционные риски, и заранее принять необходимые меры.
• Найти «узкие места» и причины неэффективности в бизнес-процессе.
• Полноценно применить методы оптимизации, разработать модели «как надо» («TO-BE» или версию 2.0). Большое количество методов оптимизации основано на использовании графических моделей.
• Провести имитационное моделирование (Simulation) и функционально-стоимостный анализ (ФСА) бизнес-процесса с помощью программных продуктов бизнес-моделирования.
• Объяснить порядок выполнения бизнес-процесса сотрудникам, быстро вспомнить или понять основные моменты и детали. В некоторых организациях графические модели наиболее важных и сложных процедур постоянно находятся на рабочих столах сотрудников.
• Отследить все взаимосвязи с другими бизнес-процессами и объектами в компании, что особенно актуально для крупных и территориально разделённых организаций.
• Организовать качественный контроль бизнес-процесса (в том числе процедуры внутреннего аудита). Отметим, что в банках инициатором описания бизнес-процессов иногда выступает служба внутреннего контроля.
• Построить комплексную электронную бизнес-модель организации (например, основанную на бизнес-процессах [3]). Именно системный подход, т. е. разработка системы взаимосвязанных моделей по всем областям работы и управления в организации, позволяет добиться максимальных результатов.
• Обеспечить синхронизацию одинаковых объектов в разных бизнес-процессах. Например, если бизнес-аналитик изменил название должности (субъекта) в организационной структуре, то на моделях всех бизнес-процессов, в которых участвует данная должность (как исполнитель), должны автоматически измениться названия соответствующих фигур. При текстовом описании бизнес-процессов синхронизацию и актуализацию регламентов приходится выполнять вручную, поэтому при больших объёмах информации часто возникают неточности и даже противоречия.
• Автоматически сгенерировать текстовые и табличные регламенты с помощью программных продуктов бизнес-моделирования (например, Business Studio).

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

Источники информации

1. Исаев Р.А. Секреты успешных банков. Бизнес-процессы и технологии. — М.: Инфра-М, 2017.
2. Исаев Р. А. Описание и оптимизация бизнес-процессов с минимальными инвестициями и рисками.
3. Комплексная типовая бизнес-модель банка (финансовой организации).

Опубликовано по материалам:
Журнал «Банковское дело» № 12/2017

Январь 2018 г.

Рекомендуемые материалы по тематике

Комплексная бизнес-модель банка: новые решения и практика

Инструменты бизнес-моделирования и особенности его применения

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

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

Методология IDEF0 берет своё начало в 60-х годах. Разработана известным американским ученым Дуглас России в США. В настоящее время методология IDEF0 является фундаментальной, занимает ведущую позицию. Рассмотрим более подробно ее назначение и особенности.

Несколько слов о преимуществах графики

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

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

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

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

Что такое нотация описания бизнес-процессов

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

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

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

По аналогии с языками программирования, нотации называют языками моделирования бизнес-процессов, являются общепризнанными и понятными для всех.
Сегодня в мире наиболее популярны 3 нотации:

• IDEF0;
• EPC;
• BPMN.

Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT.

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

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

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

Таким образом, IDEF0 на сегодняшний день, является универсальной методологией описания бизнес-процессов.

Назначение и состав методологии

Методология IDEF0 получила свою популярность и широкое применение благодаря простому графическому исполнению и простоте восприятия.

Методология IDEF0 описания бизнес-процессов заключается в описании действий с помощью диаграмм.

Описание бизнеса-процессов происходит быстро и очень понятно. Главные составляющие — диаграммы.

Выделяют четыре типа диаграмм:

• контекстная;
• диаграмма декомпозиции;
• диаграмма дерева узлов;
• диаграмма только для экспозиции.

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

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

Диаграмма дерева узлов — выражает зависимость функций между собой.

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

Элементы графической нотации

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

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

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

• Деятельность;
• Процесс;
• Операция;
• Действие.

Стрелочка в диаграмме обозначает взаимосвязь функций между собой и внешним миром. Подразделяются на:

• Вход;
• Управление;
• Механизм;
• Выход;
• Вызов.

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

Типы связей между функциями

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

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

Выделяют несколько типов связей:

• Иерархическая
• Регламентирующая связь
• Функциональная
• Потребительская
• Логическая
• Коллегиальная
• Ресурсная
• Информационная
• Временная
• Случайная.

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

Плюсы и минусы

Преимущества IDEF0:

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

Недостатки IDEF0:

• К недостаткам можно отнести сложность восприятия такого бизнес-процесса, поскольку множество стрелочек рассеивают внимание и переключают его с основной функции и взаимосвязи на второстепенные.
• Сложность прочтения, как для сотрудников организации, так и для руководителей. Однако, в этом случае следует отметить, что перед внедрением в деятельность любой методологии, сотрудники организации должны пройти обучение. В противном случае бизнес-процессы не будут эффективными.

Правила и рекомендации построения диаграмм

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

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

Облегчить чтение модели возможно, если придерживаться определенны правил создания диаграмм IDEF0. Вот некоторые из них:

• Первостепенно определить для себя цель бизнес-процесса. Необходимо определить тип формируемой модели, а также позицию, с точки зрения которой будет строиться модель.
• При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы).
• На контекстной диаграмме отображается один блок, показывающий назначение системы. Для него рекомендуется отображать по 2–4 стрелки, входящие и выходящие с каждой стороны.
• Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6.
• Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз.
• Отсутствие у функции одновременно стрелок управления и входа не допускается.
• Обеспечить каждому блоку свой вход.
• Постараться как можно меньше допустить поворотов в диаграмме и петель.
• Используйте обратные дуги для изображения обратных связей.
• Поименуйте каждый элемент диаграммы.
• Использовать туннелирование стрелок.
• Объединить стрелки, проходящие параллельно и дать им единое имя.
• Нумерация блоков.

Типичные ошибки

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

Рассмотрим типичные ошибки:

1. Использование различных цветов — не стоит пытать выделить отдельные элементы цветами, чтобы повысить наглядность. Все элементы одинаково важны.
2. Слишком большое количество блоков — нельзя изобразить все нюансы процесса на одном листе. Для конкретизации деятельности необходимо применить детализацию каждого блока.
3. Нарушение структуры при внесении корректировок — при внесении каких-либо изменений, например смены точки зрения, следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов.
4. Правила названия управляющих элементов и блоков — называйте стрелки именами, а блоки глаголами.

Программное обеспечение для построения диаграмм IDEF0

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

К сегодняшнему дню создано не мало программ для создания диаграмм IDEF0. Вот некоторые из них:

• ERWin 3.5.2;
• Design/ IDEF;
• Dia;
• IDEF0/EMTool;
• BPwin.

Пример создания функциональной модели IDEF0

Рассмотрим процесс написания статьи для наглядного описания создания функциональной модели IDEF0

Основной блок называется «Написать статью».

Взаимодействие с внешней средой обозначены на схеме входящими стрелками – «Знания в области написания статьи», «Опыт», «Информация из сторонних источников». Основы, которые необходимы для описания.

Управляющие в данном случае – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение.

Таким образом, созданы основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса. Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом.

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

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

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



Содержание:

1.      Простая блок-схема бизнес-процесса

2.      Моделирование IDEF0

3.      Моделирование BPMN

4.      Моделирование BPMN

5.      Графические нотации бизнес-процессов. Выводы.

Добрый день, коллеги.

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

·         Простая блок-схема;

·         IDEF0;

·         BPMN;

·         EPC.

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

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

1. Простая блок-схема бизнес-процесса

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

Упрощенная схема заваривания чая в нотации простой блок-схемы приведена Рисунке 1.

Преимущества данной схемы:

·         Простота элементов, наглядность;

Недостатки данной схемы:

·         Необходимость указания участника непосредственно внутри блока, что затрудняет восприятие. Данный недостаток может быть нивелирован при помощи вынесения операций, выполняемых разными участниками в отдельные подпроцессы, для примера на схеме приведен «Подпроцесс восполнения компонентов».

·         Сложность в описании временных задержек, ожиданий.

Рисунок 1. Схема заваривания чая в формате простой блок-схемы

2. Моделирование IDEF0

Нотация является федеральным стандартом обработки информации в США с 1993 года. К особенностям данного формата можно отнести следующие особенности:

·         Использование контекстной диаграммы:

Бизнес-процессы idef0 обязательно подразумевают использование диаграммы верхнего уровня, так называемой «диаграммы А-0», которая устанавливает область моделирования, ее границу и связи объекта моделирования с окружающей средой.

·         Поддержку декомпозиции:

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

·         Доминирование:

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

·         Выделение 4 типов стрелок:

В нотации выделяются такие типы стрелок: «Вход», «Выход», «Механизм», «Управление». Тип стрелки определяется стороной функционального блока, к которой она присоединена. «Входы» преобразуются или потребляются процессом. «Выходы» — данные или материальные объекты, производимые процессом. «Механизмы» описывают средства поддержания процесса. «Управления» показывают условия, необходимые процессу для производства правильного выхода.

Описание основных графических элементов:

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

Упрощенная схема заваривания чая в нотации IDEF0 приведена на Рисунке 2 (Контекстная диаграмма) и Рисунке 3 (Диаграмма первого уровня декомпозиции).

Преимущества данной схемы:

·         Неограниченная глубина детализации;

·         Жесткое регламентирование описания ресурсов процесса.

Недостатки данной схемы:

·         Сложность при глубоком уровне детализации;

·         В связи со сложностью хорошо подходит для верхнеуровневого и малоприменима для детального описания бизнес-процессов

Рисунок 2. Контекстная диаграмма 

Рисунок 3 Диаграмма первого уровня декомпозиции

3. Моделирование BPMN

Нотация используется для описания процессов нижнего уровня. Как и простая блок-схема, диаграмма BPMN отражает алгоритм выполнения процесса. Отображаются события, участники процесса, потоки данных и потоки ресурсов. По аналогии с нотацией IDEF0 каждый процесс может быть декомпозирован, при этом может использоваться как нотация BPMN, так и нотация EPC.

В нотации BPMN выделяют пять основных категорий элементов:

·         элементы потока (события, процессы и шлюзы);

·         данные (объекты данных и базы данных);

·         соединяющие элементы (потоки управления, потоки сообщений и ассоциации);

·         зоны ответственности (пулы и дорожки);

·         артефакты (сноски).

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

Описание основных графических элементов:

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

 Упрощенное BPMN описание заваривания чая приведено на Рисунке 4. 

Рисунок 4. Упрощенный процесс в нотации BPMN

Преимущества данной нотации:

·         Неограниченная глубина детализации;

·         Жесткое регламентирование использования элементов;

·         Автоматизация процессов моделирования и исполнения;

·         Гибкость и наглядность отображения сложных процессов.

Недостатки данной схемы:

·         Сложные регламенты моделирования.

4. Нотация EPC

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

Описание основных графических элементов:

Преимущества нотации EPC

·         При формировании схемы выдерживается строгая, формальная логика процесса.

·         Четко определены все события, возникающие по ходу процесса.

Недостатки нотации EPC

·         Сложность восприятия.

·         Значительная трудоемкость формирования схемы.

·         Информационная избыточность.

·         Занимает слишком много места, что неудобно для документирования.

Упрощенная схема заваривания чая в нотации EPC приведена на Рисунке 5.

Рисунок 5. Упрощенная схема заваривания чая в нотации EPC

5. Графические нотации бизнес-процессов. Выводы.

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

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

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

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

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

Эксперт-консультант по производственному учету

Виктор Малиновский.

В статье Владимира Репина раскрываются методы визуального анализа графической схемы бизнес-процесса в нотации BPMN в Business Studio 5. Они могут быть использованы для выявления проблем, связанных с выполнением процесса, и разработки мероприятий по его оптимизации. Материал может быть полезен руководителям и специалистам, вовлеченным в проект описания и оптимизации бизнес-процессов компании.

Введение

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

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

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

Требования к графической схеме бизнес-процесса

Прежде всего определимся с контекстом, точкой зрения и целью анализа.

Контекст – в компании создан Процессный офис, который использует программный продукт Business Studio для моделирования и анализа бизнес-процессов в нотации BPMN. Разработан и используется внутренний стандарт по описанию процессов («Соглашение по моделированию»).

Точка зрения – взгляд на выполняемую деятельность со стороны владельца бизнес-процесса.

Цель – выполнить описание и анализ бизнес-процесса «Как есть» для выявления возникающих проблем и разработки мероприятий по оптимизации/цифровизации бизнес-процесса, создания модели процесса «Как должно быть».

Важно отметить, что возможность визуального анализа определяется качеством и аналитической полнотой графической схемы. Логически некорректная модель с отсутствием какой-либо аналитики («Голый поток Work Flow») вряд ли подойдет для решения указанной выше задачи.

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

1. Отсутствие нотационных и логических ошибок.
2. Наличие на схеме потоков документов (информации), статусов документов, хранилищ данных (ресурсов), используемых информационных систем.
3. Содержательное соответствие реальному процессу (Модель «Как есть», адекватная семантика).
4. Визуальная наглядность и красота схемы (стиль).

Кратко пройдемся по этим критериям. Отсутствие нотационных и логических ошибок является базовым требованием. Схема, содержащая ошибки, тем более, логические, — непригодна для анализа. Для формального контроля качества схемы можно использовать чек-лист, который может содержать, например, следующие разделы:
• корректность формулировок названий объектов на схеме;
• корректность описания входов/выходов;
• корректность описания событий (стартовых, промежуточных, завершающих);
• логические ошибки;
• адекватное описание множества обрабатываемых в рамках процесса объектов;
• архитектурные ошибки (дублирование группы задач вместо использования «Типового процесса» и проч.);
• неоднородность по масштабу выполняемых задач;
• аккуратность исполнения схемы, наглядность.

Наличие на схеме потоков документов (информации), статусов документов, хранилищ данных (ресурсов), используемых информационных систем является ключевым для возможности выполнять анализ. Подробно о создании таких схем я написал в статье «Моделирование информационных потоков в нотации BPMN в Business Studio 5». Рекомендую обратить внимание на представленные там требования.

Содержательное соответствие реальному процессу (Модель «Как есть», адекватная семантика). Речь идет о том, что модель действительно соответствует процессу «Как есть», то есть содержит все реально выполняемые задачи без пропусков, упрощений и т.п.

На рис. 1 показан фрагмент схемы процесса. Слева – то, что было в созданной модели «Как есть». Справа – реальный процесс, в рамках которого осуществляется ручная передача документа от сотрудника к сотруднику. Такого рода ситуации, когда документ (информация) мгновенно и непонятно каким образом перемещаются от задачи к задачи, скорее могут служить иллюстрацией к фантастическому роману, чем для целей практического анализа бизнес-процесса.

Адекватная реальности семантика. Нотация BPMN является весьма сложной. Важно понимать, что она была разработана для проектирования исполняемых в BPM-системе процессов. Движок такой BPM-системы, если объяснять не уходят в технические детали, интерпретирует значки нотации BPMN определенным образом и генерирует исполняемый код без участия человека. При исполнении бизнес-процесса в BPM-системе семантика графической схемы реализуется через соответствующий функционал. Например, могут быть использованы такие решения, как: межпроцессное взаимодействие путем отправки/получения сообщений, граничные события различного типа, завершение процесса типа «Terminate», триггеры, сигналы, компенсации и прочее.

Но в реальном, неавтоматизированном бизнес-процессе (типичный пример: Outlook + функциональная система) ничего этого нет – передача информации, остановки, уведомления осуществляются вручную сотрудниками. Поэтому схема бизнес-процесса «Как есть», созданная бизнес-аналитиком с использованием сложной семантики BPMN, реализуемой только в BPM-системе, в действительности не соответствует реально выполняемому процессу. При чтении такой схемы совершенно непонятно, как выполняется процесс в действительности.

Некоторые бизнес-аналитики, «нахватавшись» красивых значков BPMN, начинают «лепить» их где и как попало, глубоко не анализируя процесс и не прописывая нюансы его практического выполнения.
Поэтому для описания неавтоматизированного бизнес-процесса «Как есть» настоятельно рекомендую использовать только самые простые конструкции нотации BPMN. Кроме того, важно подробно описать допустимые в моделях «Как есть» интерпретации значков BPMN в «Соглашении по моделированию».

Если цель – создание модели бизнес-процесса для исполнения в конкретной BPMS, то создавать эту модель «Как должно быть» нужно понимая, какой конкретно функционал имеет система, то есть какие возможности нотации BPMN она поддерживает.

Визуальная наглядность и красота схемы (стиль). Схемы могут сложными, но понятными, а могут быть содержательно простыми, но до крайности визуально запутанными (см. пример на рис. 2).
Например, в одной компании, в которой я проводил анализ качества схем в нотации BPMN, было жесткое требование размещать модели на листе формата А4. Это приводило к тому, что бизнес-аналитики делали на схеме «Змейку» и она становилась крайне сложной для восприятия. Это можно назвать плохим стилем моделирования.

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

Какие проблемы можно выявить, анализируя схему бизнес-процесса?

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

• Технология выполнения процесса: некорректный состав, последовательность выполнения задач процесса, дублирование, отсутствие бизнес-правил.
• Дезинтеграция процесса по информационным системам (ручной перенос информации (документов) из системы в систему).
• Потеря важной информации (документов) при выполнении процесса.
• Отсутствие необходимой интеграции между процессами.
• Возвраты, излишние согласования.
• Узкие места.
• Задачи, не добавляющие ценность, потери.

Ниже рассмотрим каждую из указанных видов проблем.

Технология выполнения бизнес-процесса

Пример. Коллеги из довольной крупной компании разработали схему процесса «Создание, согласование и закрытие заявки на подбор» — см. рис. 3.

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

Кроме того, процесс «Подбор персонала» включен в рассматриваемый процесс, как типовой. На мой взгляд, это несколько некорректно с точки зрения архитектуры бизнес-процессов HR в целом.

Анализ схемы может показать, например, что результат процесса не передается его инициатору, то есть «зависает». Инициатор вынужден сам как-то его добывать. Это означает, что границы процесса определены некорректно.

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

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

Еще один пример отсутствия бизнес-правила представлен на рис. 5. Менеджеры работают с заказчиками по-разному. Ряд заказчиков подписывает договор и присылает его скан, ряд – нет. Четко не определено, должны ли менеджеры требовать от заказчиков присылать подписанные сканы договоров или достаточно версии в формате MS Word и протокола разногласий и т.д.

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

Дезинтеграция процесса по информационным системам

На том же рис. 6 видно, что бизнес-процесс не интегрирован по информационным системам – наблюдается ручная передача информации в Outlook, ручная выгрузка из АСУ в MS Excel, потом в MS Word, сохранение в pdf-формат, звонки и e-mail-ы клиентам.

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

Потеря важной информации (документов) при выполнении процесса

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

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

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

Отсутствие необходимой интеграции между процессами

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

Но менеджер по закупку может: 1) случайно удалить письмо; 2) увидеть письмо со значительной задержкой; 3) отложить работу с поставщиков «на потом» без контроля сроков. Таким образом, проблема, возникшая в одном бизнес-процессе и нуждающаяся в решении, не связана с запуском на исполнение другого процесса. Кроме того, информации о проблеме не зафиксирована в системе и может быть потеряна.
Представленный выше пример весьма типичный. Очень часто можно увидеть на схемах ситуацию типа: «Уведомить менеджера…», «Переслать информацию в такой-то отдел» и т.п.

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

Возвраты, излишние согласования

При выполнении бизнес-процессов часто возникают возвраты. Например, на рис. 8 показан возврат на повторное согласование договора.

Чем плохи возвраты? Они: 1) многократно увеличивают длительность выполнения процесса; 2) увеличивают затраты; 3) могут негативно влиять на качество результата процесса; 4) негативно сказываются на отношении сотрудников к работе (бесконечные переделки и уточнения, повторное выполнение одних и тех же задач мало кому понравится).

В свое время Филипп Кросби, известный специалист в области менеджмента качества, сформулировал принцип «Делать всё правильно с первого раза». Почему же сотрудникам сложно его придерживаться? В чем причины возвратов? Думаю, в следующем. К ним приводят:
• нечетко поставленные задачи;
• недостаток информации у исполнителя;
• некачественные входы (информация);
• отсутствие методик/бизнес-правил у исполнителя;
• недостаточная квалификация исполнителя;
• ошибки («человеческий фактор»).

Исполнитель получил задачу и выполнил ее. Но оказалось, что руководитель имел в виду немного другое. Приходится переделывать.

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

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

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

Не стоит исключать и человеческий фактор: физическая усталость, моральное утомление (например, в случае выполнения рутинной, монотонной работы по разнесению УПД из «Контур.Диадок» в 1C-ERP при крайне медлительной работе программы), негативное отношение к выполняемой работе и, в целом, — к компании, отсутствие лояльности и т.д.

Но в чем коренные причины указанных выше проблем? Кто виноват? Сами сотрудники? Нет. Еще дедушка Эдвардс Деминг, специалист мирового масштаба и отец новой философии управления, говорил, что 95% проблем, возникающих у сотрудников при выполнении процессов, обусловлены не плохим отношением людей к работе, а теми бизнес-процессами, системой, которую создали сами менеджеры компании.

Поэтому наличие большого количество возвратов на схеме процесса красноречиво говорит о недостатках в работе руководителей.

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

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

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

Узкие места

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

На рис. 10 показ пример кадрового процесса одной из крупных компаний. По нему движется документ, который дополняют и согласуют множество руководителей. Несмотря на то, что процесс автоматизирован в СЭД, в нем возникло узкое место, обведенное овалом. Специалист подразделения кадров осуществляет ручной контроль после каждой задачи согласования и «проталкивание» процесса между его участниками.
Хотя все участники процесса используют СЭД, назвать этот процесс автоматизированным, а тем более цифровым, нельзя. Автоматизация, предполагающая постоянный ручной контроль и «проталкивание» документов, является неэффективной.

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

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

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

Задачи, не добавляющие ценность, потери

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

Приведу несколько примеров действий, которые не создают ценность, но влияют на увеличение потерь:
• ручной перенос информации из одной информационной системы в другую (например, из pdf-файла в 1С);
• ожидание отклика информационной системы сотрудником при выполнении загрузки данных, сохранении, проведении проводок; зависания и «вылеты» системы; ожидание начала совещания у руководителя;
• неудобный интерфейс программы и, как следствие, много лишних действий исполнителя (движения мышкой от одного места экрана к другому, сложные многоуровневые меню и т.д.);
• ручное перемещение документов от одного рабочего места к другому в рамках, например, процесса согласования;
• выполнение расчетов и подготовка документов (отчетов), которые потом не используются;
• частые перемещения внутри офисного помещения (рабочее место – принтер – рабочее место), перемещения между разными этажами офиса, пешие перемещения сотрудников по территории крупного производственного предприятия и проч.;
• переделка документов из-за выявленных ошибок.

Выводы

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

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

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.

Февраль 2023 г.

Вы можете посмотреть видео по данной теме: