Модель бизнес процесса возможно описать в следующем формате

Форматы описания бизнес-процессов

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

Таблица
3

Преимущества и недостатки
форматов описания бизнес-процессов

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

Текстовый формат описания

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

Табличный формат описания

Для
описания процесса в таблицах можно
использовать следующий формат (см. Табл.
4).

Таблица
4

Табличный формат описания
процесса

№	Наименование функции	Исполнитель	Ресурсы (в т.ч. документы, программы)
Входящие	Исходящие

Графа
«№»
— показывает порядковый номер функции.
Для описания декомпозиции
процесса
можно использовать разряды номера
функции. Например, у функции №7 есть
три
подфункции, их номера начинаются с
номера декомпозируемой функции: 7.1; 7.2;
7.3.
Графа «Наименование функции» —
включает название работы/ операции.

Графа
«Исполнитель»
— обозначает сотрудника (должность)
выполняющего
соответствующую работу.

Графы
«Ресурсы»
— включают всю совокупность используемых
в процессе предметов и
средств труда,
а также документов.

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

Графические форматы
описания

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

IDEF
(Integration
Definition for Function Modeling
— методология функционального
моделирования)
— семейство совместно используемых
методов для процесса
моделирования.
Первоначально разработаны в военных
ведомствах США. На сегодня эта
техника
описания бизнес-процессов получила
наибольшее распространение в мире
и
принята как стандарт во многих
странах. В России на момент написания
Методики это
зафиксировано в
Р50.1.028-2001 «Информационные технологии
поддержки жизненного цикла изделия.
Методология функционального моделирования»,
а также в проекте
стандарта: ГОСТ Р
ИСО 10303-203 «Системы автоматизации
производства и их
интеграция.
Представление данных об изделии и обмен
данными. Протокол применения
203 —
Проектирование изделия управляемой
конфигурации». Концепция реализована
во
многих программных продуктах,
наиболее популярным из которых на
сегодняшний день
является пакет
ВРWIN/ERWIN.

UML
(Unified
Modeling Language
— унифицированный язык моделирования)
— наиболее
систематизированный подход
к описанию любых систем, в т.ч. и
бизнес-процессов.
Позволяет перейти
от описаний системы непосредственно к
написанию компьютерных
программ и —
в значительной степени — сформировать
основу будущего средства
автоматизации.
UML принят как стандарт для проектирования
информационных систем
более чем 60-ю
ведущими разработчиками программного
обеспечения, в т. ч и Microsoft.
Разработчик
языка — некоммерческий консорциум Object
Managment Group (ОМС).
Наиболее популярным
инструментом, поддерживающими язык
UML, является Rational

АRIS
(ARchetecture
of Information Systems
— проектирование интегрированных
информационных
систем) — германская технология описания
предприятий. Разработана
профессором
Августом Вильгельмом Шеером (компания
IDE Scheer АС). Используется
как встроенное
средство в одну из крупнейших на
сегодняшний день систем
автоматизации
предприятий — SAP R/3.
Пока имеет меньшее распространение,
чем
вышеперечисленные системы. При
этом единственная методология, где
фирма-
разработчик является и
производителем одноименного программного
продукта,
поддерживающего данную
методологию. Этим обеспечивается
практически
единовременное
совершенствование методологии и
программной поддержки.

IDEF

Рассмотрим
концепцию IDEF как более простой и
доступной в виде большого числа
программных продуктов, поддерживающих
эту концепцию (BPWIN, БИГ-Мастер, МS Visio и
др.).

IDEF
технология используется, начиная с
конца 1980-х годов. Department of Defence USA
(Министерство обороны США) является
основным пользователем данной технологии.
Ею пользуются также некоторые крупные
корпорации в США.

Графически
формат IDEFO представляет собой следующую
структуру (рис. 10).
Функции (работы,
операции) изображаются прямоугольниками.
Названия функций по
стандарту
формируются в глагольном наклонении:
оформить заказ, обработать заготовку.

Каждая
из сторон прямоугольника имеет свое
назначение:

• Верхняя
сторона — управление;

• Нижняя
сторона — механизмы (ресурсы);

• Левая
сторона — входы;

• Правая
сторона — выходы.

Все
ресурсы, участвующие в процессе,
изображаются стрелками (потоками).
Значение
стрелок различно в зависимости
от того, с какой стороны процесса они
расположены.
Названия стрелок уникальны
и формируются по правилам стандарта
ЮЕР как обороты
существительного.

Рис. 10. Графическое
представление процесса в IDEFO (сделано
в МS Visio ХР)

Стрелками
управления могут быть документы,
регламентирующие деятельность
(стандарты,
технические условия и т.п.) Входами,
выходами и механизмами могут быть
различные
ресурсы: люди, станки, материалы, сырье,
документы, базы данных и т. п. (см.
Рис.
11).

Рис. 11. Пример блока IDEF
диаграммы

Функции
IDEF могут детализироваться в отдельных
схемах, это называется
декомпозиция.
На самом верхнем уровне это может быть
все предприятие, отраженное как один
блок, а далее — в отдельной схеме — будут
раскрыты различные процессы.
Декомпозиция
обозначается под блоком процесса с
правой стороны в виде номера
схемы
детализации. В отличие от номера
блока, расположенного внутри прямоугольного
блока
функции, номер схемы детализации
находится снаружи прямоугольника (рис.
12). На
рисунке номер схемы декомпозиции
«АО». Уровень вложенности процессов
не
ограничивается.

Рис. 12. Декомпозиция
процесса в IDEF

Пример
процесса в формате IDEF (см. Рис. 13). Надписи
на стрелках сделаны выносками в форме
молний.

Рис. 13 Пример процесса в
формате IDEF

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

От текстового описания до систем Business Process Analysis

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

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

Текстовый формат описания бизнес-процесса

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

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

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

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

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

Табличный формат описания бизнес-процесса

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

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

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

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

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

Графическая модель бизнес-процесса

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

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

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

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

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

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

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

Система моделирования бизнес-процессов

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

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

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

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

От моделирования к автоматизации

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

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

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

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

Что же выбрать?

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

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

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

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

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

Андрей Коптелов, опубликовано на c-news.ru

Источник

Роман Исаев

Партнёр ГК «Современные технологии управления»

Руководитель проектов, бизнес-тренер, сертифицированный специалист Business Studio

Автор 11 книг и более 60 публикаций в научно-практических журналах

Автор и разработчик моделей и модулей для системы Business Studio, которые на протяжении многих лет активно используются в ведущих российских и международных организациях

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

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

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 основных формата.

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

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

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

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

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

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

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

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

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

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

Январь 2018 г.

Введение

В этой статье мы рассмотрим, что представляет собой нотация бизнес-моделирования BPMN и как её использовать для описания бизнес-процессов.

Главное назначение и практическое применение

Нотация BPMN (Business Process Modeling Notation) нужна для подробного описания логики выполнения бизнес-процесса, в том числе для отражения деталей процессов, таких как: события, исполнители каждого из действий, используемые и создаваемые документы и другие объекты, использующиеся в качестве входных данных для тех или иных действий или создающиеся в результате их выполнения.

BPMN позволяет описать бизнес-логику выполнения действий в виде наглядной диаграммы, а также запустить отрисованный бизнес-процесс на исполнение. Для этого используются специализированные системы BPMS (Business Process Management System), поддерживающие эту нотацию.

BPMS-системы могут автоматически перевести схему бизнес-процесса в исполняемый код и создать веб-приложение, которое будет обрабатывать данные, введённые пользователями и сторонними сервисами. Это соответствует концепции Low Code/No Code (создание программного обеспечения без разработки кода) и отлично подходит для автоматизации офисных процессов.

Технически такая возможность реализуется за счёт перевода BPMN-диаграмм в документы формата BPEL (Business Process Execution Language). BPEL-документы представляют собой инструкции исполнения бизнес-процессов для веб-сервисов.

Таким образом, BPMN используется в следующих случаях:

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

Краткая история появления нотации

BPMN считается довольно молодой нотацией: её 1-я версия вышла в 2009 году под эгидой профессионального консорциума OMG. Сегодня эта нотация является стандартом де-факто в ИТ-сфере и используется для описания бизнес-процессов. Текущая версия BPMN 2.0 вышла в 2011 году и используется до сих пор. В 2014 году в дополнение к BPMN группа OMG выпустила нотацию описания бизнес-правил и принятия решений (Decision Model and Notation, DMN).

DMN упрощает построение BPMN-диаграмм в случаях сложной бизнес-логики и многоуровневых её ветвлениях.

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

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

Уровни моделирования

В зависимости от целей построения BPMN-диаграмм, различают 3 уровня моделирования:

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

Алфавит нотации

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

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

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

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

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

События

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

Триггер определяет тип и смысл события. Например, триггер в виде конверта означает, что пришли какие-то данные, причём совсем не обязательно в виде сообщения электронной почты. Триггер в виде часов связан со временем. Если событие имеет триггер, значит, поток управления двинется дальше только тогда, когда сработает триггер этого события. Например, получены данные, наступил определённый временной интервал и так далее.

Таблица базовых элементов BPMN

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

Поток управления

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

Эфемерной сущностью BPMN, которая показывает смысл концепции потока, называют токен. Подобно потоку воды токен «бежит» от стартового события диаграммы к финишному, разделяясь на несколько экземпляров с помощью логических операторов. Последовательность и вариативность выполнения действий называется бизнес-логикой и показывается с помощью логических операторов или развилок, шлюзов. Например, на диаграмме ниже представлено 2 логических оператора: исключающее ИЛИ (XOR) и включающее ИЛИ (OR).

Процесс утреннего пробуждения

Пример процесса утреннего пробуждения

Как можно видеть на диаграмме, после стартового события выполняется первое действие («Проверить время звонка»). Следующий за ним логический оператор исключающего ИЛИ, подобно шлюзу, пропускает дальше поток управления только по одной ветке: «да» или «нет». Причём ветка «нет» здесь помечена как поток по умолчанию, который выполнится, если все остальные условия не будут верны.

После выполнения действия оператор включающего ИЛИ (OR) пропускает поток на действие «Выпить кофе» или на действие «Узнать новости» или по обоим веткам. Исключения здесь нет, ручеёк потока управления распараллеливается на две ветки, чтобы потом объединиться снова в одну и один раз выполнить действие «приготовиться к делам». После выполнения этого действия процесс заканчивается конечным событием.

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

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

Диаграмма BPMN может содержать один или несколько пулов, каждый из которых может содержать одну или несколько дорожек.

Процесс утоления голода

В следующем примере процесс «утоления голода» состоит из двух дорожек («Ребёнок» и «Мама»), общение между которыми выполняется через поток управления.

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

Стартовым событием является простое событие «Возникло чувство голода» на дорожке Ребёнок, а конечным — простое событие «Чувство голода удовлетворено» на этой же самой дорожке.

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

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

Типы событий

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

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

Также некоторые события могут быть прерывающими и не прерывающими.

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

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

Прерывающие события с разным типом

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

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

Граничные прерывающие и непрерывающие события

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

Примеры прерывающих и непрерывающих граничных событий с типом «сообщение»

Типы действий

Подобно событиям, действия в BPMN также могут быть разных типов:

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

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

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

Логические операторы

Поскольку BPMN показывает логику выполнения бизнес-процесса, в диаграммах используются логические операторы, которые также называются развилками или шлюзами. Изначально их всего три: OR, XOR и AND.

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

Пример исключающего ИЛИ

В отличие от исключающего или, простое ИЛИ (OR) допускает возможность активации как нескольких веток, так и одной из них. В математическом смысле этот оператор реализует дизъюнкцию или логическое сложение переменных, что показано в таблице истинности на слайде.

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

Пример логического И

Поскольку алфавит BPMN является избыточным, помимо базовых операторов булевой алгебры (то есть ранее рассмотренных И, ИЛИ и исключающего ИЛИ) в нотации также присутствуют усложнённые вариации этих операторов.

Например, исключающее ИЛИ по событиям, событийное И, а также сложный оператор, который объединяет несколько из упомянутых и моделирует сложную бизнес-логику. Его не рекомендуется использовать на диаграммах, т.к. не очевидно, что именно он показывает.

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

Пример использования эксклюзивного шлюза по событиям

Все остальные шлюзы, которые есть в BPMN, приведены в Приложении В.

Артефакты

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

Вы можете найти полный перечень артефактов в Приложении Г.

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

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

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

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

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

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

После действия «Направить клиенту коммерческое предложение (КП)» на диаграмме используется логический оператор ИЛИ (событийный XOR), после которого возможен один из двух вариантов:

1. Если прошло 5 дней, что показано событием с триггером таймер, и ответа от клиента нет, заявке присваивается статус «Отказ» в CRM-системе и наступает финишное событие «Заявка закрыта».

2. Если же ответ от клиента получен и 5 дней ещё не прошло, процесс движется дальше в зависимости от данных в этом ответе.

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

В результате этой задачи создаётся документ «Проект договора» и наступает финишное событие «Заявка успешно обработана».

Поток по умолчанию

Если в диаграмме используются операторы обычного XOR, проверяющего условия по данным, и OR (неисключающего ИЛИ) рекомендуется помечать поток по умолчанию, который активируется, если другие условия не сработали. Поток по умолчанию допустимо не подписывать, если подписаны остальные потоки и диаграмма остаётся понятной. В примере ниже «‎Нецелевой» — поток по умолчанию.

Пример обозначения потока по умолчанию

Альтернативный способ показать условия

Поскольку алфавит нотации BPMN чрезмерно широкий, даже избыточный, то некоторые элементы по сути эквивалентны друг другу. В частности, вместо шлюза XOR по данным можно зашить условие в сам поток управления. Он обозначается маленьким ромбом в начале стрелки и содержит условие, которое определяет, будет активирован данный поток или нет. Этот поток нельзя использовать со шлюзами. В случае визуально нагруженной диаграммы с большим количеством блоков такой приём может чуть облегчить её и упростить восприятие.

Пример условия зашитого в поток управления

Задачи и события

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

Ниже показан пример диаграммы с задачами по отправке и получению сообщения:

Пример этой же диаграммы с событиями получения и отправки сообщений:

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

Пример построения диаграммы по текстовому описанию

Рассмотрим пример процессов работы с клиентской заявкой, представленной двумя пулами: «Обработка заявки» и «Заключение договора».

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

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

Узнав подробности коммерческого предложения, клиент принимает решение о продолжении сотрудничества или отказе от него. Если клиент не согласился на условия КП, на этом процесс работы с ним заканчивается, а заявке присваивается статус «Отказ».

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

При наличии возражений к проекту договора клиент вносит в него изменения и снова направляет менеджеру. Менеджер формирует новый проект договора и снова отправляет клиенту на согласование, то есть идёт возврат к ранее выполняемой задаче.

Пример построения диаграммы по текстовому описанию

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

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

ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;
Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;
Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию
простые веб-«рисовалки‎» Lucidchart, Draw.io, Visual Paradigm

Также алфавит нотации BPMN поддерживается и в MS Visio, ARIS Express и других редакторах диаграмм общего назначения.

Заключение

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

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

Анна Вичугова

Бизнес-аналитик, CBAP, к.т.н., тренер Systems.Education,
основатель и тренер Школы прикладного бизнес-анализа

Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)
Сертифицированный бизнес-аналитик (IIBA CBAP, 2020)
Сертифицированный специалист Business Studio и СЭД Directum

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19, 34, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

Источник

Просмотров 27.5к. Опубликовано 21.03.2022
Обновлено 31.10.2022

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

Содержание

Что такое основной бизнес процесс простыми словами
История появления термина
Зачем нужны бизнес процессы
Отличие бизнес процессов от функций и стандартных процессов
Кто описывает бизнес процессы
Характеристики описания основных бизнес процессов
Уровни основных бизнес процессов
Классификация бизнес процессов
Описание бизнес процесса
Основные виды бизнес процессов
Правила описания основных бизнес процессов
Уровни анализа
Этапы описания
Форматы описания бизнес процессов
Схема описания бизнес процессов
Создание и оптимизация бизнес процессов на предприятии
Анализирование
Пошаговое описание
Управление бизнес процессами
Зарождение BPM
Модель зрелости BPM
Моделирование бизнес процессов
Нотации моделирования
В чем разница между нотациями
Платное и бесплатное программное обеспечение и сервисы для создания и описания модели бизнес процесса
Как рассчитать стоимость бизнес процесса
Внедрение бизнес процессов
Оптимизация бизнес процессов
Автоматизация бизнес процессов
Плюсы внедрения процессного управления
Реинжиниринг и постоянное совершенствование
Пример удачного анализа и оптимизации бизнес процессов
Ошибки при внедрении систем управления
Ситуации, когда бизнес процессы нужно описывать
Как бизнес процессы могут быть оптимизированы и усовершенствованы
Где можно обучиться управлению бизнес процессами
Заключение
Отзывы о бизнес процессах
Полезные книги
Литература о принципах и идеологии бизнес-процессов:
Книги про оптимизацию:
Книги о системном мышлении:
Книги о применении процессов:

Что такое основной бизнес процесс простыми словами

Business Process (в переводе «Бизнес процесс») – это постоянно повторяющаяся в определенное время последовательность (цепочка) действий сотрудников, которая выстроена, в соответствии с политикой компании, и направлена на достижение поставленных целей.

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

Понятие процесса управления и качества его описания – это индикатор профессионализма организации.

История появления термина

Впервые термин «бизнес процессы» появился давно — в 70-х г. г. XX века. Именно тогда предприятия стали переходить к информационным системам и информатизации производственного процесса. Возникла потребность в четкой организации управления предпринимательством и трудовыми ресурсами.

Инструктирование работников стало осуществляться по схеме «человек – человек» и «человек – машина». Все нормы были стандартизированы. Так, нужны были команды, которые бы распознал и человек, и машина.

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

Зачем нужны бизнес процессы

Если компания стремится к качественной системе менеджмента, основанной на стандарте ISO 9001, разработка, описание, внедрение и оптимизация процесса – обязательное условие. В этом случае у предприятия появляется сильное преимущество на конкурентном рынке.

С помощью описания процессов достигают и иные задачи:

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

Отличие бизнес процессов от функций и стандартных процессов

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

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

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

Кто описывает бизнес процессы

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

Специалист должен уметь описывать процессы и:

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

Характеристики описания основных бизнес процессов

Описание процессов характеризуется такими параметрами:

Наименование и цель. Обычно это одно и то же. Все участники должны будут их знать и понимать. Например, название – «Продажа первой партии нового товара». Цель звучит так же.
Исполнитель или владелец инструмента. Это ответственное лицо, которое будет подробно составлять план, доносить его до сотрудников, вести и контролировать процесс его выполнения.
Ресурсы, которые используются для достижения поставленных целей.
Вход – это те ресурсы, которые поступают извне, сырье.
Выход – это произведенные товары или оказываемые услуги. Иногда может получиться не то, что было запланировано, тогда цель на этом этапе меняется.

Еще есть и другие параметры описания, но не обязательны:

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

Уровни основных бизнес процессов

Процессы имеют многоуровневое строение:

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

Классификация бизнес процессов

Классификация основных процессов осуществляется по разным признакам:

Специфика работы:

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

Сложность:

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

Структурное место на предприятии:

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

Функции отдела:

управления;
распределения финансов;
организации работы склада;
логистики;
производства.

Детализация или комплексность:

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

Исполняемость:

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

Описание бизнес процесса

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

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

Кстати! Зарегистрируйтесь в нашем сервисе голосовых рассылок Zvonobot и получите первые 20 звонков — бесплатно 😉

Основные виды бизнес процессов

Все процессы делятся на 6 групп:

Основная, представляющая полезную ценность для потребителей.
Вспомогательная, обеспечивающая существование основных процессов, но не имеющая ценности для потребителей.
Управляющая, предназначенная для контроля над основной и вспомогательной группой процессов и над процессом исполнения целей.
Сопутствующая – вспомогательный вид процессов, которые будут приносить дополнительный доход.
Группа развития, предназначенная для увеличения производительности и доходов предприятия.
Категория совершенствования, направленная на улучшение рабочего процесса, повышения его качества.

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

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

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

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

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

Уровни анализа

Менеджер самостоятельно определяет, насколько подробно будет описан основной бизнес-процесс. Его можно анализировать на 5 уровнях:

Операции. Это самый детализированный уровень, когда будет требоваться перечислять каждое действие.
Действия – это ряд операций, в котором должна быть соблюдена определенная последовательность.
Процедуры – несколько объединенных действий, выстроенных в определенном порядке для достижения поставленных целей.
Базовый уровень, на котором объединяется несколько взаимосвязанных процедур, которые будут служить достижению результатов. Обычно в них участвует несколько сотрудников.
Направление работы. Это самый обобщенный уровень, который включает в себя несколько процессов.

Этапы описания

Составление описания бизнес процесса будет осуществляться пошагово в 11 этапов:

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

Форматы описания бизнес процессов

Описание процессов может быть в 3 форматах:

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

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

простота реализации

отсутствие требований к навыкам оформителя

множество текста, который нужно полностью прочитать для выделения самого важного

сложности при структурировании и анализировании текста

отсутствие наглядности, что затрудняет восприятие бизнес-процесса

специфический, сложный язык для описания некоторых процессов

отсутствие необходимости в подготовке при наличии шаблона

простое заполнение таблиц без особых навыков

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

дает возможность сравнения и анализирования числовых показателей описания

необходимость в предварительной разработке шаблонов

отсутствие возможности изложить в таблице сложный бизнес-процесс с развернутым описанием

ограниченное место для данных

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

сложности при отображении ответвлений

наглядная демонстрация информации описания, что обеспечивает простоту восприятия

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

глубокая детализация элементов описания

возможность включения любого количества ответвлений

удобное использование графики при разработке программного обеспечения

потребность в специальных навыках

работа с графикой требует большого количества времени

Схема описания бизнес процессов

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

Для построения схемы по описанию процессов могут использоваться специальные программы. Это осуществляется поэтапно:

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

Схема описания отображается либо в виде карты (блок-схем), либо маршрута (движение данных и ресурсов в процессе). Для этого применяются стандартные международные формы документирования (нотации).

Создание и оптимизация бизнес процессов на предприятии

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

оценить те процессы, которые уже протекают на предприятии, и описать их модели по принципу «как есть»;
оставить и обновить существующие модели до формата «как быть должно»;
обеспечить контроль над процессами.

Анализирование

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

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

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

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

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

Пошаговое описание

Описание текущего бизнес процесса строится поэтапно:

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

Управление бизнес процессами

Для реализации потенциала предприятия в полном объеме нужно будет правильно выстроить управление бизнес процессами (BPM). Оно состоит из 4 ступеней:

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

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

Зарождение BPM

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

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

Модель зрелости BPM

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

Моделирование бизнес процессов

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

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

Нотации моделирования

В процессе моделирования используются специальные технические условные обозначения (нотации) – единые по всему миру:

ARIS	Его используют при создании, анализировании, внедрении и оптимизации процессов
DFD	Предназначен для использования в макропроцессах бизнеса
UML	Применяется при разработке программного обеспечения, демонстрирует ошибки в структуре
IDEF	Разделяет и объединяет блоки IDEF0, изображает процесс IDEF3
BPMN	Демонстрирует процесс в разных аудиториях
RAD	Предназначена для описания и анализирования функциональных элементов, а также демонстрации их взаимодействия
WFD	Отражает процессы на нижнем уровне, демонстрирует последовательность действий и время их выполнения
ANSI	Это блок-схемы, которые демонстрируют, как идет процесс
ERM	Позволяют сделать описание концепции процессов
SADT	Помогают создавать функциональные модели
FCD	Создан для описания действий, исполнителей, оборудования символами
EPC	В рамках сложного комплексного процесса позволяет определить его вход и выход
STD	Отражает поведение системы во время внешнего воздействия
Дорожки Брюса Силвера	Используется, как дополнение для демонстрации перехода ответственности от одного сотрудника к другому
Unified Modeling Language	Позволяет визуализировать, сконструировать, задокументировать системы и процессы, скачать сформированные документы
Карты потоков ценностей	Отражают потраченные ресурсы и время
Цветные сети Петри	Предназначены для демонстрации переходов, событий, действий

В чем разница между нотациями

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

BPMN имеет особенности:

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

Нотацию ARIS выбирают с учетом ее характеристик:

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

На практике использовать BPMN удобнее, так как она поддерживает больше инструментов. С ее помощью можно построить схему как отдельного процесса, так и целой серии.

Платное и бесплатное программное обеспечение и сервисы для создания и описания модели бизнес процесса

Моделирование процессов осуществляется в специальных программах. Самые популярные и удобные из них:

Bizagi Process Modeler	Бесплатный софт для небольших организаций, который можно скачать в интернете. Поддерживает построение диаграмм, позволяет распределить приоритеты. Имеет широкий функционал. Созданную схему можно проверить, изменить ее части, добавить свои элементы, скачать, распечатать. Все сопутствующие документы формируются автоматически и сохраняются в файл. Поддерживает русский язык и одновременную работу нескольких менеджеров.
Visual Paradigm	Платная программа, с помощью которой можно построить схему со всеми корпоративными процессами с взаимосвязанными элементами. Описания можно протестировать или задать их для отдельных составных частей. Для каждого объекта можно установить свои правила.
Elma BPM	Платное ПО, позволяющее следить за работой бизнес-схемы в онлайн-режиме. Задачи можно распределить между конкретными работниками. Поддерживается подключение 1C и загрузка документов.
Fox Manager	Софт, который позволяет создать карту процесса с планом. У поставленных задач можно контролировать степень выполнения и качество, их эффективность и всего рабочего процесса в целом.
ARIS Express	Бесплатная программа для построения моделей и карт. Есть поддержка инструмента Smart Design: после внесения данных схема выдается автоматически. Отдельно созданные модели не могут быть объединены в общий процесс.
Business Studio	Софт от российского разработчика для контролирования исполнения поставленных задач и автоматической генерации документов. Может применяться совместно с другими программами.

Как рассчитать стоимость бизнес процесса

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

Собрать первичные данные о процессе, сделать его описание, определить, какие операции, как часто и кем будут выполняться. Данные обычно заносятся в таблицу MS Excel с названием столбцов: «Наименование операции», «Коэффициент использования» (частота повторения данной операции), «Исполнитель».
Проанализировать, сколько времени будет требоваться на выполнение каждой операции. Для этого можно использовать методы фотографирования (фиксация процесса выполнения операции каждым сотрудником), экспертной оценки персонального бизнес-аналитика, анализа данных с помощью информационной системы (на основе прошлого опыта). На практике часто применяются комбинированные способы. Полученные данные заносятся в таблицу в графу «Время исполнения операции».
Подсчет стоимости ресурсов. Для этого рассчитывается, сколько стоит 1 минута работы данного сотрудника (исходя из размера его заработной платы). Затем это значение умножается на время исполнения операции. Полученное значение заносится в таблицу в графу «Стоимость ресурсов за 1 мин». Для получения полной картины стоимости процесса необходимо добавить все остальные статьи расходов: арендную плату, закупку расходных материалов и пр., но без излишней детализации, так как этот этап может затянуться.
Подсчет стоимости всего процесса с учетом полученных данных. Для этого необходимо рассчитать, во сколько обходится выполнение одной операции (стоимость минуты времени работника умножается на длительность выполнения задачи). Эти данные нужно занести в таблицу в графу «Стоимость 1 операции», а затем заполнить столбец «Стоимость операций за месяц». Путем сложения значений в последнем столбце можно получить стоимость всего процесса. При этом нужно учитывать, что подобный расчет может иметь большие погрешности.
Анализирование стоимости процесса. Когда цена каждой операции будет наглядно отображена в таблице, у руководства обычно появляется желание ее удешевить. Сделать это можно с помощью полного исключения данной операции из процесса (нужно проанализировать, насколько она необходима для получения результата), использования более дешевых ресурсов или менее квалифицированных кадров, ускорения выполнения операций, упрощения рабочего процесса.
Анализирование нагрузки на работников. Для этого учитываются не только операции данного процесса, но и все остальные функции сотрудников. Расчеты помогают понять, насколько та или иная операция трудозатратная, а также распределить нагрузку равномерно между участниками.

Внедрение бизнес процессов

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

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

Еще на этапе внедрения нужно, чтобы каждый сотрудник работал по новой схеме.

Оптимизация бизнес процессов

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

«Здравый смысл», когда:
- удаляются дублирующиеся операции;
- исключается лишний контроль;
- автоматизируются часто повторяющиеся операции;
- равномерно распределяются ресурсы;
- корректируются все составляющие процесса: материалы, технологии и пр.;
- процесс максимально упрощается;
- все операции стандартизируются;
- назначается параллельное выполнение задач, процесс ускоряется;
- продолжительность операций и расходов на них сокращаются.
«Бережливое производство», когда:
- минимизируются паузы в рабочем процессе (простой машин, согласование заказа и пр.);
- исключается производство излишков;
- нерациональные действия сотрудников сводятся к минимуму;
- сокращаются перемещения работников для сохранения времени;
- выпускаемая продукция страхуется на предмет появления возможных дефектов;
- обеспечивается достаточный объем ресурсов.

Оптимизация процесса происходит вскоре после его внедрения.

Автоматизация бизнес процессов

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

Автоматизация помогает при:

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

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

Плюсы внедрения процессного управления

Управление процессами и их автоматизация имеет преимущества:

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

Реинжиниринг и постоянное совершенствование

Реинжиниринг – это кардинальная перестройка бизнес процессов.

У каждой организации своя специфика и свой порядок этой процедуры, но есть 5 основных шагов:

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

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

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

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

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

Пример удачного анализа и оптимизации бизнес процессов

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

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

После этого были сформулированы задачи:

Уменьшить срок доставки товара до 5 ч.
Обеспечить своевременную доставку молока в цеха.

Оптимизация процесса позволила предпринять меры:

Сменить поставщика молока.
Приобрести дополнительные автомобили для оперативной отправки продукции и нанять водителей.

Ошибки при внедрении систем управления

При внедрении системы управления следует учитывать возможные ошибки:

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

Ситуации, когда бизнес процессы нужно описывать

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

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

Как бизнес процессы могут быть оптимизированы и усовершенствованы

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

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

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

Помимо этого оптимизация требуется, когда нужно:

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

Моделирование бизнес процессов: гайд от начала до конца: Видео

Где можно обучиться управлению бизнес процессами

Бизнес процессами занимается персональный бизнес-аналитик. Получить профильное образование можно различными способами:

Непрофильные вузы с направлениями «Экономика», «Менеджмент».
Профильные учебные заведения со специализацией «Предпринимательство».
Курсы с государственной поддержкой, т.е. бесплатные для слушателей. В каждом регионе есть свои представительства.
Курсы от «Сбера» и Google – лучший бесплатный вариант для получения образования по бизнесу в интернете. Бонусные уровни открываются после прохождения тестирования на сайте. А в блоге постоянно публикуются полезные статьи по теме.
Платные онлайн-курсы от «Синергия», Skillbox.ru, «Нетологии» и пр. с получением официального сертификата по e mail.

Заключение

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

Отзывы о бизнес процессах

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

Александр, 40 лет (Санкт-Петербург)

«5 лет назад я открыл свое кафе. Расположение удачное, хорошая проходимость потенциальных клиентов, продуманное меню, но особой прибыли дело не приносило. Решил попробовать описание и внедрение бизнес процессов. Так, была максимально автоматизирована работа персонала. Все функции были внесены в компьютер, тщательно продумано рабочее место официантов, поваров, кассиров, сделан упор на качество и свежесть продуктов. Увеличилась скорость обслуживания клиентов, что позволило нам привлечь большое количество посетителей во время бизнес-ланчей, трансляции спортивных мероприятий и т.д. Прибыль вышла на новую ступень»

Алексей, 35 лет, (Уфа)

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

Сергей, 32 года, (Москва)

Полезные книги

Свод знаний по управлению бизнес процессами. BPM CBOK 3.0
Бизнес процессы. Инструменты совершенствования (Б. Андерсен)
Управление бизнес процессами. Практическое руководство по реализации проектов (Д. Джестон, Й. Нелис)
Учитесь видеть бизнес процессы. Построение карт потоков создания ценности (М.Ротер, Д.Шук)

Литература о принципах и идеологии бизнес-процессов:

Критическая цепь (Э. Голдратт)
Серия «Цель» (Э. Голдратт)
Дао Тойота (Д. Лайкер)
Организация как система. Принципы построения устойчивого бизнеса Эдварда Деминга (Г. Нив)
Кайдзен. Ключ к успеху японских компаний (М. Имаи)

Книги про оптимизацию:

Быстрее, лучше, дешевле: девять методов реинжиниринга бизнес процессов (М. Хаммер)
Оптимизация бизнес процессов. Документирование, анализ, управление, оптимизация (Д. Харрингтон)
Практическое руководство по реинжинирингу бизнес процессов (М. Робсон, Ф. Уллах)
Реинжиниринг корпорации: манифест революции в бизнесе (М. Хаммер, Дж. Чампи)
Руководство по улучшению бизнес процессов. Harvard Business School.
Производство без потерь для рабочих. Институт комплексных стратегических исследований.

Книги о системном мышлении:

Системность во всем. Универсальная технология повышения эффективности (С. Карпентер)
Искусство системного мышления (Д. О. Коннор)
Системное мышление. Как управлять хаосом и сложными процессами. Платформа для моделирования архитектуры бизнеса (Дж. Гараедаги)
Ключевые показатели менеджмента (К. Уолш)
Азбука системного мышления (Д. Медоуз)

Книги о применении процессов:

Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию (У. Детмер)
Найти идею. Введение в ТРИЗ (Г. Альтшуллер)
Бережливое производство + шесть сигм в сфере услуг (Майкл Джордж)
Теория ограничений в действии (Э. Шрагенхайм)
Действенное видение. Как обратить текущий объем продаж в чистую прибыль (Д. Кендалл)

Источник

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

Cпоры о выборе нотации для моделирования бизнес-процессов по-прежнему не утихают. Анализу подвергаются возможности нотаций EPC (Event-driven Process Chains) и BPMN (Business Process Modeling Notation), синтаксис, набор примитивов языка описания и т. д. Однако сравнивать нотации и языки описания бизнес-процесса путем анализа их функциональности некорректно — является ли модель функциональной или процессной, определяет не только нотация, но и методология. Часто методология моделирования подменяется нотацией, что приводит к серьезным ошибкам в проектировании бизнес-процессов и появлению некачественных моделей.

Модели и перспективы

Модель — это материальное или мысленное представление объекта или явления, повторяющее одни свойства, существенные для целей конкретного моделирования, и опускающее другие, несущественные свойства, в которых модель может отличаться от прототипа. Сложный объект, например бизнес-процесс, описывается совокупностью моделей, каждая из которых отображает ограниченный набор свойств, а все вместе они описывают объект моделирования полностью. Каждая из частных моделей [1] связана с главным вопросом, на который должна давать ответ соответствующая модель. Выделяются четыре перспективы модели бизнес-процесса (см. рисунок).

Функциональная: «Что делают участники?». Описывает состав выполняемых работ.

Поведенческая: «Как работают участники?». Описывает очередность, расписание выполнения, бизнес-правила.

Информационная: «Что обрабатывают участники?». Описывает бизнес-сущности предметной области процесса.

Организационная: «Кто выполняет работу?». Описывает состав и структуру исполнителей.

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

Сравнительный анализ нотаций моделирования бизнес-процессов

Перспективы процесса

Функциональная перспектива

BPM со всех сторон

С чем связан повышенный интерес к BPM и какие решения в данной области предлагаются сегодня отечественному бизнесу?

Наталья Дубова

Функциональная модель описывает систему в статическом состоянии, помогает ответить на вопрос «что надо делать для достижения поставленной цели?». Ответом является перечень всех действий, которые необходимо выполнить, чтобы добиться запланированного результата. В управлении проектами широко применяется структурная декомпозиция работ (Work Breakdown Structure) — перечисленные в ней действия не связаны временной последовательностью. Аналогично, при моделировании процессов очень полезно создать структурную декомпозицию, которая поможет понять логику процесса и не забыть выполнить какую-либо важную функцию. Если две разные организации выполняют один и тот же процесс, то функциональная декомпозиция работ у них будет одинаковой, хотя очередность исполнения работ может меняться с учетом отличий их организационной структуры. Таким образом, функциональная модель слабо зависит от организационной структуры и может рассматриваться как справочная.

Часто функциональную модель ошибочно называют картой процессов; например, модели SCOR (The Supply-Chain Operations Reference-model) и ETOM (Enhanced Telecom Operations Map) содержат иерархии функций и цепочки создания ценности, но отнюдь не процессы [ 2 ]. Даже руководящие документы TeleManagement Forum призывают различать процесс как последовательность выполняемых действий и процесс как направление деятельности компании.

Аспекты поведенческой перспективы

Эталонная модель BPM

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

Александр Самарин

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

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

Бизнес-логика процесса

Очередность операций, образующих процесс, принято называть бизнес-логикой, и для ее описания применяются диаграммы потоков работ (UML, EPC, ABC Flowchart — описания на базе блок-схем). Бизнес-логика содержит явные, предписывающие сведения о маршруте исполнения процесса, но лишь косвенно учитывает критерии принятия соответствующих решений.

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

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

Бизнес-правила

Под бизнес-правилом принято понимать утверждение, определяющее или ограничивающее некоторые аспекты бизнеса. В отличие от процедурного описания, правила постулируют ограничения на исполнение процесса, но не определяют, как именно предполагается достичь результата. Специалист в области бизнес-правил Рональд Росс дает следующую классификацию бизнес-правил [3]:

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

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

Расписание исполнения

Открытая BPM-платформа

С увеличением сложности программных систем повышается роль моделирования, позволяющего интегрировать бизнес-процессы, но почему бы не построить инструмент моделирования на принципах Web 2.0?

Геро Декер, Матиас Веске, Сергей Смирнов, Хаген Овердик

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

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

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

Степень детализации бизнес-логики

Чтобы ответить на вопрос «как?», диаграмма управления должна содержать максимально подробное описание действий, образующих процесс. Многие аналитики ограничиваются перечислением функций, без указания деталей их исполнения, предполагая, что исполнитель знает, как следует выполнить работу. Однако на практике сотрудники склонны выполнять работу с учетом своего индивидуального опыта, что приводит к высокой вариативности исполнения процесса. Нотации моделирования не определяют степени детализации описания, отдавая этот вопрос на откуп аналитику. Определим критерии детализации.

Руководящий документ Госстандарта России, «Методология функционального моделирования IDEF0» [5] вводит понятия «действие» и «операция». Действие определяется как «преобразование какого-либо свойства материального или информационного объекта в другое свойство», а операция — как «совокупность последовательно или/и параллельно выполняемых действий».

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

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

Степень полноты бизнес-логики процесса

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

Сравнительный анализ нотаций EPC и BPMN

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

Нотация EPC является средством описания бизнес-логики процесса. Как показывает сравнение [6], нотация позволяет реализовывать основные паттерны бизнес-логики, не уступая остальным нотациям описания процессов. Диаграммы EPC часто не включают бизнес-правила, однако этот недостаток следует отнести не к нотации, как таковой, а к методологии применения. Что касается расписания исполнения, то тут надо отметить отсутствие средств моделирования временных характеристик исполнения. В нотации EPC присутствует конструкция «событие», однако она применяется для описания состояния объекта управления, а не для синхронизации исполнения. Методология EPC не акцентирует внимание на степени детальности и полноты получаемых диаграмм, оставляя этот вопрос на откуп аналитику. В отсутствие жесткой регламентации аналитики стремятся обеспечить простоту и читабельность диаграмм, поэтому ограничиваются описанием уровня операций и не стремятся выявить все маршруты исполнения. Нотация EPC часто используется для автоматизации с применением функционально-ориентированных систем, где человек играет ведущую, направляющую роль, так что отсутствие какого-либо сценария исполнения не является опасным. Все это позволяет классифицировать модели EPC как диаграмму потоков работ.

Нотации, включенные в ARIS, обладают чрезвычайно широкими возможностями по моделированию процессов, но не подкреплены открытыми и доступными для пользователей методологиями. Документ «Методология ARIS» [7] описывает не методологию, а правила применения нотации, что допускает широкие возможности «интерпретации» способов моделирования.

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

Нотация BPMN описывает логику процесса. Немного лучшая поддержка паттернов бизнес-логики, по сравнению с EPC [6], не является решающим преимуществом. Нотация оперирует понятиями «событие» и «интервал времени», содержит средства синхронизации веток процесса между собой и процессов друг с другом. Сама нотация не содержит рекомендаций разделять логику и правила, но руководства по правильному стилю моделирования включают такую рекомендацию [8]. Нотация BPMN применяется для создания процессно-ориентированных систем, где человек играет подчиненную, а система — ведущую роль, поэтому пропуск одного, даже самого редкого сценария не позволит выполнить работу и, следовательно, недопустим, соответственно модели BPMN покрывают все сценарии исполнения. Модели BPMN являются исполняемыми моделями, поэтому описывают все детали, вплоть до элементарных действий. Все вышесказанное позволяет классифицировать диаграмму BPMN как модель потоков управления.

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

Проблемы трансляции диаграммы EPC в исполняемый формат

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

Перечислим типовые ошибки моделирования.

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

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

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

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

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

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

***

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

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

Литература

B. Curtis, M. Kellner, J. Over. Process Modeling, 1992.
eTOM, Representative process flows. ITU. s.l.: Telecommunication Standardization Sector Of ITU, 2004.
R. Ross. Principles of the Business Rule Approach. Addison-Wesley Professional (2003).
C. Pedrinaci, Domingue, A. Alves de Medeiros. A Core Ontology for Business Process Analysis, Proceedings of the 5th European semantic web conference on The semantic web: research and applications, Springer-Verlag Berlin, Heidelberg, 2008.
Методология функционального моделирования IDEF0. Москва: Госстандарт России, 2000.
N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Workflow control-flow patterns.
Methods ARIS 7.0. Saarbrucken: IDS Scheer AG, 2005.
B. Silver, BPMN Method & Style. Cody-Cassidy Press, 2009.

Игорь Федоров (Igor.Fiodorov@bpexpert.ru) – директор, «Центр компетенции процессного управления», МЭСИ (Москва).

Источник

Я уже рассказывал об основных типах описания бизнес процессов и обозначил своё отношение к самому продвинутому из них — графическому описанию. Все методологии моделирования бизнес-процессов состоят из определённых элементов и правил. Пришла пора пого…

Семейство IDEF

Ну всё-таки небольшое вступление будет. IDEF — это не одна нотация, а целое семейство. Различаются они по порядковым номерам — IDEF0, IDEF1, IDEF2 и т.д. Каждая нотация имеет свои особенности и используется для описания разных элементов бизнес-системы. Рассматривать будем семейство в целом.
Итак, IDEF. Первое что надо знать, IDEF является самой «старой» нотацией. Второе, она уже очень давно (десятилетия!) не развивается. Отсюда первый камень в огород. Семейство IDEF безнадёжно, морально, функционально устарело.
Дальше. Использовать модели бизнес процессов, выполненных в IDEF, крайне сложно. Как для изучения, так и для анализа. Ниже представлен пример схемы бизнес процесса. Судите сами.

Нотация имеет ограничения по количеству отображаемых на схеме процессов — не больше 7. Отсюда возникает необходимость подстраивать описания под эти правила. Кроме того, существуют правила, которые сильно усложняют жизнь как «писателям» бизнес процессов, так и «читателям».
В совокупности это влечёт за собой огромное количество тяжёлых для восприятия, крайне запутанных схем. Но есть и плюс — вне зависимости от того, в какой программе вы составляете модель процесса в нотации IDEF, блок-схема будет ориентирована на лист формата А4 в альбомной ориентации. То есть распечатывать такие схемы удобно. На этом плюсы закончились)
О программном обеспечении. Да, существует огромное количество ПО, поддерживающего моделирование в этой нотации. В том числе и бесплатное. Но в большинстве своём оно тоже устарело и не позволяет решать актуальные на сегодняшний день задачи. В конце концов, нарисовать модель бизнес процесса можно в любом графическом редакторе. Начиная от элементарного Paint и заканчивая профессиональными инструментами, например, Microsoft Visio. Даже от руки на листе бумаги можно создать схему.
К слову, именно из потребности в автоматизации, т.е. в переводе моделей бизнес процессов в программу, и родились современные нотации. В том числе IDEF. Именно этим обусловлена строгость соблюдения правил моделирования. Машина может понять строгий графический язык, но не в состоянии понять текстовое описание.

Резюме — если вы встали перед выбором нотации для описания и моделирования бизнес-процессов, ни в коем случае не останавливайтесь на IDEF.

Нотация eEPC

А вот это уже интересно. Само название нотации Событийная цепочка процессов (event driven process chain, «e» вначале означает extended, расширенное) говорит о том, что моделирование в данной нотации сосредоточено вокруг событий. А именно события и определяют развитие процесса.
В основе этой нотации лежит… Одна из нотаций семейства IDEF. А конкретно IDEF3. Впрочем, eEPC намного функциональнее и нагляднее.

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

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

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

Резюме — нотация eEPC является не самым плохим решением для описания и моделирования бизнес процессов.

Нотация BPMN 2.0

Скажу сразу, на мой взгляд, это лучшая нотация для описания и моделирования любых бизнес процессов.
BPMN (Business Process Model and Notation) — нотация управления бизнес-процессами. Вот так скромно и без прикрас назвал своё детище Институт управления бизнес процессами (BPI). Да, созданием и развитием BPMN занимается целый институт. Одно это говорит о том, что нотация является результатом серьёзной, научно обоснованной работы. Более того, работа эта происходит постоянно, а в настоящее время нет ничего важнее постоянного развития инструментов управления. Впрочем, перейдём к сути.
BPMN — самая удобная, гибкая, наглядная, функциональная и вместе с тем простая нотация.
Существенным отличием является наличие понятия «дорожка». Дорожка — это область в модели процесса, которая отображает все, что выполняет конкретный человек в данном процессе. Естественно, если процесс затрагивает разных людей, то посредством дорожек отображается их взаимодействие. И это крайне важно.

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

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

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

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

Есть ещё возможности связки моделей BPMN и 1С. В итоге получается эффективная система управления процессами с возможностью отслеживания онлайн. Но об этом я буду рассказывать в другой раз в обзоре программ для моделирования и управления бизнес-процессами.

Правила и примеры моделирования в нотации BPMN

Резюме — нотацию BPMN выбирает большинство профессионалов в управлении бизнес-процессами. Она наиболее современная и активно развивающаяся. Я рекомендую работать именно с ней.

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

Выбирайте ту нотацию, с которой у вас уже принято работать.
Если не принято, выбирайте BPMN.
Выбирайте ПО и соответственно ту нотацию, с которой оно работает.
Не знаете с чего начать? Начинайте с BPMN.
В конце концов, выбирайте ту нотацию, которая вам понятна и симпатична:)

Источник

Форматы описания бизнес-процессов

От текстового описания до систем Business Process Analysis

Текстовый формат описания бизнес-процесса

Табличный формат описания бизнес-процесса

Графическая модель бизнес-процесса

Система моделирования бизнес-процессов

От моделирования к автоматизации

Что же выбрать?

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

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

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

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

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

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

Введение

Главное назначение и практическое применение

Краткая история появления нотации

Уровни моделирования

Алфавит нотации

События

Поток управления

Процесс утреннего пробуждения

Процесс утоления голода

Типы событий

Типы действий

Логические операторы

Артефакты

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

Поток по умолчанию

Альтернативный способ показать условия

Задачи и события

Рекомендации по использованию BPMN

Пример построения диаграммы по текстовому описанию

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

Заключение

Анна Вичугова

Что такое основной бизнес процесс простыми словами

История появления термина

Зачем нужны бизнес процессы

Отличие бизнес процессов от функций и стандартных процессов

Кто описывает бизнес процессы

Характеристики описания основных бизнес процессов

Уровни основных бизнес процессов

Классификация бизнес процессов

Описание бизнес процесса

Основные виды бизнес процессов

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

Уровни анализа

Этапы описания

Форматы описания бизнес процессов

Схема описания бизнес процессов

Создание и оптимизация бизнес процессов на предприятии

Анализирование

Пошаговое описание

Управление бизнес процессами

Зарождение BPM

Модель зрелости BPM

Моделирование бизнес процессов

Нотации моделирования

В чем разница между нотациями

Платное и бесплатное программное обеспечение и сервисы для создания и описания модели бизнес процесса

Как рассчитать стоимость бизнес процесса

Внедрение бизнес процессов

Оптимизация бизнес процессов

Автоматизация бизнес процессов

Плюсы внедрения процессного управления

Реинжиниринг и постоянное совершенствование

Пример удачного анализа и оптимизации бизнес процессов

Ошибки при внедрении систем управления

Ситуации, когда бизнес процессы нужно описывать

Как бизнес процессы могут быть оптимизированы и усовершенствованы

Где можно обучиться управлению бизнес процессами

Заключение

Отзывы о бизнес процессах

Полезные книги

Литература о принципах и идеологии бизнес-процессов:

Книги про оптимизацию:

Книги о системном мышлении:

Книги о применении процессов:

Модели и перспективы