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

Введение

В этой статье мы рассмотрим, что представляет собой нотация бизнес-моделирования 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 используется в следующих случаях:

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

2. Когда требуется запустить схему бизнес-процесса на исполнение в 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 уровня моделирования:

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

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

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

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

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, следует отметить небольшое различие между событиями-сообщениями и задачами-сообщениями. По сути это одно и тоже, но к задачам-сообщениям можно прикреплять обработчики событий (например, таймер) и модификаторы (например, цикл по объектам), а к самим событиям — нет.

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

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

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

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

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

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

• Использовать только пользовательские и ручные задачи — без сценариев, сервисов и бизнес-правил, отправки и получения сообщений.

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

• Использовать только XOR и AND, без событийных шлюзов и OR, так как разница между исключающим и не исключающим ИЛИ понятна не всем пользователям.

• Использовать события с типом простое, таймер, сообщение и останов.

Для упрощения восприятия диаграммы стоит придерживаться правил наименования:

• Внешних контрагентов показывать как закрытые, они же — свёрнутые пулы (пулы, в которых нет действий).

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

• Называть дорожки также, как роль, должность или структурное подразделение.

• Называть действия (задачи) в стиле Глагол-Существительное, например, «‎Проверить счёт», «Подтвердить заявку», «Оформить договор».

• Называть события как свершившийся факт в прошедшем времени, к примеру, «Поступила заявка», «Прошло 3 дня».

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

Также рекомендуется:

• Показывать успешное и неуспешное завершение процесса разными финишными событиями.

• Не выводить поток управления за пределы подпроцесса.

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

Наконец, при разработке любой диаграммы нужно помнить о главном правиле аналитика: независимо от нотации, ваша схема должна быть МАКСИМАЛЬНО простой и понятной читателю БЕЗ знания тонкостей процессного моделирования!

В целом алгоритм разработки BPMN-диаграммы можно представить как набор следующих 7 шагов:

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

2. Описать «счастливый» путь (happy path), который ведёт к созданию полезного результата (продукта).

3. Добавить условия и альтернативные потоки.

4. Добавить неуспешные завершения.

5. Добавить артефакты (объекты и хранилища данных).

6. Раскрыть на новых связанных диаграммах свёрнутые подпроцессы.

7. Добавить промежуточные событийные потоки к внешним пулам.

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

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

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

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

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

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

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

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

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

• ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;

• Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;

• Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию

• простые веб-«рисовалки‎» Lucidchart, Draw.io, Visual Paradigm

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

Заключение

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

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

---

• Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)

• Сертифицированный бизнес-аналитик (IIBA CBAP, 2020)

• Сертифицированный специалист Business Studio и СЭД Directum

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

Иллюстрация: Andrea Piacquadio / Pexels / Colowgee для Skillbox Media

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

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

---

Фото: личный архив Александра Завьялова

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

О базовых терминах и идеях в области бизнес-процессов мы рассказали в большом гайде. В этой статье разберём подробнее:

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

---

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

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

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

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

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

Специалисты придумали много вариантов нотаций. Их делят на две основные категории:

• Структурные. Они показывают элементы процесса и взаимосвязи между ними. Это нотации стандарта IDEF: IDEF0, IDEF1x, IDEF4, IDEF5.
• Динамические. Они показывают логику выполнения процессов, последовательность и варианты их использования. Это нотации DFD, EPC, BPMN.

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

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

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

Иногда можно встретить и другие подходы, но обычно это гибридные решения, собранные из основных. Каждый из трёх подходов предполагает, что процессы нужно визуализировать — рисовать их в виде схем. Различия подходов — в принципах визуализации.

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

У модели есть точки входа и выхода: то, что имеем на старте, и то, что хотим получить. Внутри — промежуточные результаты, ресурсы и факторы, которые влияют на процесс.

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

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

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

Разберём на примере. Пусть это будет изготовление рекламного ролика.

Процесс изготовления рекламного ролика — основной блок с процессами. Я называю его «чёрный ящик». У него есть три входа и один выход:

1. Сверху — вход для информации о контроле и ограничениях. Это данные, которые определяют условия для реализации процесса. Например, при разработке ролика нас будет ограничивать законодательство и стайлбук заказчика. А ещё мы будем опираться на перечень услуг клиента — чтобы в рекламе были корректные данные.

2. Слева — вход для основной информации. На её основе будет создан результат. В примере с роликом, чтобы получить эту информацию, для заказчика проводят брифинг.

О том, как составить бриф для клиента в рекламе и digital, писали в статье.

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

4. Справа — выходы. Это результаты, которые мы получим: заключим договор, снимем ролик и предложим сотрудничать на постоянной основе.

Вот как функция будет выглядеть в виде диаграммы.

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

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

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

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

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

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

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

Для примера нарисовали блок-схему обработки заявки в учебном центре. Она не соответствует канонам BPMN, но всё равно наглядна и понятна.

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

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

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

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

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

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

Рассмотрим, кто может заниматься моделированием процессов.

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

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

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

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

Моделирование как отдельную услугу заказывают редко. Чаще это один из этапов внедрения систем автоматизации — CRM, ECM или ERP. Это работает по такой схеме:

• Команда внедрения — подрядчик — приходит на территорию заказчика.
• Она описывает процессы, проводит аудит и составляет аналитический отчёт с вариантами оптимизации.
• Заказчик утверждает отчёт.
• Подрядчик внедряет систему автоматизации с уже оптимизированными процессами.

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

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

В специальных программах. Это способ для профессионалов в моделировании.

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

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

• Microsoft Visio 2010 — векторный графический редактор для создания разных видов схем: блок-схем, схем технологических процессов, моделей бизнес-процессов, планов зданий и этажей, трёхмерных карт и так далее. Платный.
• Bizagi Process Modeler — программа для моделирования процессов по нотации BPMN с возможностью совместной работы. Бесплатная.
• ARIS Express — программа для моделирования бизнес-процессов и оргструктуры с нотациями eEPC или BPMN. Бесплатная.
• Business Studio — система, в которой можно описать, оптимизировать и регламентировать бизнес-процессы предприятия. Платная.

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

В графических редакторах. Этот способ подойдёт для новичков, которые только знакомятся с моделированием бизнес-процессов. Проще всего взять обычный графический редактор — например, Microsoft Paint, Figma или Adobe Photoshop — и самостоятельно нарисовать интуитивно понятную схему процесса.

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

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

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

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

• Когда начинается процесс. В нашем примере это момент получения заявки от клиента. Если компания использует CRM, точкой входа будет попадание заявки в систему.
• Когда процесс закончится. Это момент успешной реализации сделки: клиент оплатил счёт, а продавец и логист организовали доставку.

Можно придумать несколько вариантов точек входа и выхода — для разных вариантов развития события.

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

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

Здесь лежит шаблон текстового описания процесса.

3. Выделяем основные этапы процесса. На основе описанного в предыдущем пункте процесса составляем блок-схему. В графическом редакторе рисуем каркас — основные этапы в пределах границ входа и выхода.

4. Добавляем детали. Наполняем каркас «мясом» — основными событиями по процессу и действиями исполнителя по алгоритму.

5. Задаём роли. В процессе может быть несколько исполнительских ролей. Их может выполнять один или несколько сотрудников. Обычно роли обезличены, без уточнения фамилий, — только должности.

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

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

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

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

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

Другие материалы Skillbox Media для менеджеров

Эффективный руководитель

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

Узнать про курс

1.

Пошаговое
моделирование
бизнес-процесса
Лозовицкий Игорь Борисович

2.

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

3.

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

4. Определение процесса

ПРОЦЕСС –
совокупность взаимосвязанных и взаимодействующих видов
деятельности, преобразующих входы в выходы
Ограничения
Выход
Вход
Поставщик
ПРОЦЕСС
Ресурсы
Потребитель

5.

Модель процесса

6. Последовательность моделирования бизнес-процесса (БП)

Последовательность моделирования бизнеспроцесса (БП)
I.
Определение точки зрения и целей описания БП
II.
Определение назначения и типа БП
III.
Описание окружения БП
IV.
Построение функциональной структуры БП
V.
Описание структуры потоков объектов БП
VI.
Построение диаграмм потоков БП
VII.
Построение алгоритма БП
VIII.
Построение оргструктуры БП

7. Выбор фокуса определяется позицией инженера

Бизнес – консалтинг = организационные разрывы
Работа 1
Подразделение 1
Работа 2
Работа 3
Подразделение 3
Подразделение 2
IT – консалтинг = информационные разрывы
Работа 1
Информационная
система 1
Работа 2
Информационная
система 2
Работа 3
Информационная
система 3

8. Модели процессов помогают

Понять
Понять
Управлять
Управлять
Регламентировать
Регламентировать
Автоматизировать
Автоматизировать
Модель
Модель––представление
представлениебизнес-процесса
бизнес-процессана
наспециализированном
специализированномязыке
языке
(с
(спомощью
помощьюспециализированной
специализированнойнотации
нотации––текстовой,
текстовой,табличной,
табличной,
графической),
графической),используемое
используемоепри
приорганизации
организациидеятельности
деятельностикомпании
компании

9. 1. Пошаговое моделирование бизнес-процесса. Какие работы необходимо выполнять?

Работа
Работа 22
Работа
Работа 11
Работа
Работа 33

10. 2. Пошаговое моделирование бизнес-процесса. Каков порядок (последовательность) выполнения?

?
Работа
Работа 11
?
Работа 2
Работа 3

11. 3. Пошаговое моделирование бизнес-процесса. Что является результатом каждой из работ? Какие ресурсы для этого необходимы?

Вход /
Ресурсы
Р
Е
С
У
Р
С
ы
Работа
1
Результат /
Ресурсы
Работа
Работа
2
Выход /
Результат
Результат /
Ресурсы
Работа
3
Р
Е
З
У
Л
Ь
Т
А
т

12. 4. Пошаговое моделирование бизнес-процесса. Кто как и какие работы выполняет? Кто за что отвечает?

Подразделение 1
Результат /
Ресурсы
Работа
2
Подразделение 2
Результат /
Ресурсы
Работа
3
Подразделение 3
Результат
Ресурсы
Работа
1
Регламент
Регламент
Регламент

13. Декомпозиция. Вложенные бизнес-процессы и алгоритмы

Работа 1
Работа 2
Работа 3
Работа 4
Декомпозиция работы 3
Работа
3.2
Работа
3.1
Декомпозиция
работы 3.1
Работа
3.1.2
Работа
3.3
Вложенные процесс –
подпроцесс
Работа
3.4
Декомпозиция
работы 3.4
Работа
3.4.1
Работа
3.1.1
Вложенные процесс –
подпроцесс / алгоритм
Работа
3.4.3
Работа
3.1.3
Работа
3.4.2

14. Пример. Алгоритм процесса

Начало
Процесс В
Действие 1
да
Условие,
решение
нет
Действие 3
Действие 2
да
Действие 4
Окончание
нет

15. Описание потоков

Потоки объектов
Материальные
Продукция
Услуги
Материалы
Комплектующие
Оборудование
Информационные
Управление и экономика
Административное воздействие
Документооборот о
материальных и финансовых
потоках
Финансовые
Поступления за
продукцию и услуги
Расчеты по закупкам
Кредиты и займы
Налоги

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

Функциональные сферы
управления
Управление процессом
Исполнение процесса
Б
Е
З
О
П
А
С
Н
О
С
Т
Ь
Б
У
Х
У
Ч
Е
Т
Н
А
Л
О
Г
У
Ч
Е
Т
П
Е
Р
С
О
Н
А
л
.
.
.

17. Оргструктура бизнес-процесса

Функции (стадия процесса)
А1
Структурные
звенья
А2
А3
А4
Х
Х
Х
Х
Распределение
ответственности
Отдел 1
Отдел 2
Отдел 3

18. Варианты представления организационной структуры

2
1
Подразделение
3
Процессы
управления
Основные
процессы
Процессы
поддержки
4
Руководитель

19. Факторы, влияющие на формирование организационной структуры

Как есть
Стратегия
Диагностика
Бенчмаркинг
Как будет

20. Примеры типологий структуризации оргструктуры

Архитектоника (число уровней,
показания подчинения, ветвление)
Высокие
Плоские
Модель организации деятельности
…
Линейная
Линейно — штабная
Органическая
Проектная
Бригадная (кросс функциональная) структура
Матричная (программноцелевая)
Модель ответственности
Линейно-функциональная
Дивизиональная
Матричная

21. Архитектоника – высокие и плоские структуры

«Высокая» структура
«Плоская» структура
Наблюдение: структурные звенья стремятся к размножению

22. Функционально-ориентированная организационная структура (подразделения отвечают за исполнение функций)

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

23. Процессно-ориентированная организационная структура (подразделения отвечают за исполнение процессов)

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

24. Проектно-ориентированная организационная структура (подразделения отвечают за исполнение проектов)

Органы
управления
Центр
проектов
развития
Центр
проектов
строительства

25. Смешанная организационная структура

Органы
управления
Отдел
сервисов
Департамент бизнеспроцессов
Департамент бизнеспроцессов
Департамент
проектов
Центр проектов
развития
Отдел
сервисов
Отдел
сервисов

26. Обобщенная организационная структура

Органы
управления
Департаменты
сервисов
Департаменты
бизнес-процессов
Департаменты
бизнес-проектов
Департаменты
развития

27. Матричная схема взаимодействия бизнесов и сервисов

Департаменты сервисов
Матрицы
взаимодействия
Структурные схемы
Департаментов
Функции
Департаментов
Департаменты
процессов
Порядок
взаимодействия
Порядок
взаимодействия
Департаменты
проектов
Порядок
взаимодействия
Порядок
взаимодействия
П
О
Т
Р
Е
Б
И
Т
Е
Л
и

28. Другие виды структур. Финансовая структура

Компания / Центр прибыли
Отдел закупок /
Отдел хранения /
Отдел сбыта /
Центр затрат
Центр затрат
Центр дохода

29. Окружение организационной модели

Показатели
Стратегия
Поставки
Услуги
Организационная
модель
Процессы
Функции
Проекты

30. Условия, влияющие на выбор структуры

Динамика
внешней среды
Тип структуры
Процессная
Постоянно действующая команда
специалистов под руководством
владельца процесса
Проектная
Подразделение из специалистов,
созданное на время проекта,
отвечающее за его выполнение
Изменчивость
технологий
конкурентов
Изменчивость
потребностей
клиентов
Матричная
Специалисты функциональных
подразделений объединены в
виртуальную команду
Функциональная
Постоянно действующие
подразделения специализируются на
выполнении функции
Свойства
структуры
Модульность,
выживаемость
Усиление
горизонтальных
связей
Адаптивность,
реактивность

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

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

32.

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

33.

Алгоритм процесса
Подготовить нож,
доску для резки, ложку
и емкость для салата
Достать из холодильника
помидоры, огурцы и
сметану
Вымыть овощи
1. Начало процесса
Согласовать с потребителем решение
2. Подготовить рабочее место
3. Достать ингредиенты
4. Доставить ингредиенты к рабочему
месту (транспортировка)
5. Вымыть овощи
Нарезать овощи
6. Контролировать качество компонентов
7. Подготовить овощи к резке
Перемешать
компоненты салата
Добавить специи,
сметану, перемешать
8. Нарезать овощи
9. Контролировать качество
10. Перемешать компоненты салата
11. Добавить специи, сметану, перемешать
12. Окончательно проконтролировать качество
Подать салат
13. Окончание процесса Подать салат

34.

Три варианта описания процесса
1. Как процесс должен был бы идти по документам,
его описывающим
2. Как процесс протекает по представлениям
руководства
3. Как процесс протекает на самом деле
Одна из задач моделирования — добиться, чтобы процесс, представляемый в
голове, документах и реальный был один и тот же. Поэтому необходимо
включить в схему все детали, существенные для качества, включая и те
мелочи, какие мы неявно подразумеваем

35. Построение алгоритмов «как есть»

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

36.

Пояснение алгоритма процесса
1. Начало процесса
Согласовать с потребителем решение
2. Подготовить рабочее место
3. Достать ингредиенты
4. Доставить ингредиенты к рабочему
месту (транспортировка)
5. Вымыть овощи
6. Контролировать качество компонентов
7. Подготовить овощи к резке
8. Нарезать овощи
9. Контролировать качество
10. Перемешать компоненты салата
По классификации, принятой в
системах бережливого
производства, транспортировка
— операция второго рода, т.е.
бесполезные затраты,
необходимые для
осуществления процесса,
которые должны быть
минимизированы
Подготовка к резке (7) — хорошо
ли заточен нож, готовим доску
для резки — выполняем
совокупность операций по
подготовке оборудования к
оптимальному выполнению
данного процесса
11. Добавить специи, сметану, перемешать
12. Окончательно проконтролировать качество
13. Окончание процесса Подать салат
Окончательный контроль
качества (12) – упрощение
схемы

37.

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

38.

Появление блока принятия решений
При контроле качества всегда есть возможность появления несоответствующей
продукции, поэтому у нас должен появиться ромбик принятия решения
Протокол 1
Протокол 2
ПУНП и КД
6. Контролировать качество компонентов
ПД
Замена
несоответствующих
компонентов
Качество
компонентов
соответствует
ожиданием?
Нет
Да
В случае появления плохого продукта должна появиться процедура управления
несоответствующей продукцией (ПУНП) и петля устранения несоответствия, т.е.
процедура корректирующих действий (КД). Если возможны несоответствия,
надо принять меры по их предупреждению. Следовательно, должна появиться и
процедура предупреждающих действий (ПД).

39.

Отображение отдельных процедур
В реальной жизни процедура корректирующих действий
не так проста, как в рассматриваемом нами примере.
Поэтому справа после стрелочки «Нет» помещают
символ данной процедуры, а саму процедуру
отображают отдельно. Аналогично и ПУНП может быть
отделена от процедуры КД и описана отдельно

40.

Изображение процесса с указанием рождающихся документов
Требования
потребителей
высказанные
устно
Рабочая
инструкция
Запрос на
приготовление салата
Заполненная
форма-запись
1. Начало процесса
Согласовать с потребителем решение
2. Подготовить рабочее место
3. Достать ингредиенты
Записи по
транспортировке
4. Доставить ингредиенты к рабочему
месту (транспортировка)
ПУНП и КД
5. Вымыть овощи
Протокол 1
6. Контролировать качество компонентов
Протокол 2
ПД
Качество компонентов
соответствует ожиданием?
Нет
Замена
несоответствующих
компонентов
Да
Рабочая
инструкция
7. Подготовить овощи к резке
8. Нарезать овощи
9. Контролировать качество
Рабочая
инструкция
Протокол 3
10. Перемешать компоненты салата
11. Добавить специи, сметану, перемешать
12. Окончательно проконтролировать качество
13. Окончание процесса Подать салат
Протокол 4

41.

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

42.

Пример годового плана-графика

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

Выбор подхода к созданию модели бизнес-процессов

Выбор конфигурации модели бизнес-процессов

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

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

Моделирование бизнес-процессов — это подробное описание деятельности компании.

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

Цели

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

• установление взаимосвязей между процессами;
• разработка норм и правил выполнения отдельных операций для достижения требуемой результативности;
• оптимизация структуры управления.
• Основные этапы в развитии моделирования бизнес-процессов

Условно, моделирование всех бизнес-процессов можно подразделить на 3 основных этапа:

Первый начался в 20 году прошлого века с выходом в свет “Принципов научного управления” американского инженера Ф. Тейлора. Внедряется SADT – методология структурного анализа, объединяющая процесс моделирования с управлением конфигурацией проекта. Появляются наглядные блок-схемы и сети Петри. В 80-х гг. предпринимаются первые попытки автоматизации. Однако используемые методики несовершенны, так как допускают варианты интерпретации.

В 1990 М. Хаммер и Д. Чампи выпускают “Реинжиниринг корпорации: манифест революции в бизнесе”, которая до сих пор изучается во всех ведущих бизнес-школах мира. Рождается новый подход к моделированию. С этого момента строится две модели: одна описывает существующие процессы, вторая — оптимальные (как должно быть). Продолжаются работы по автоматизации. Основная задача — моделирование нестандартных бизнес-процессов, для чего требуется привлекать программистов и вкладывать средства. Если хотите подробнее узнать о реинжиниринге – читайте эту статью.

2000 гг. ознаменовались появлением работы Г. Смита и П. Фингара “Управление бизнес-процессами: третья волна”. Новый подход предполагает разработку инструментов, которые дадут возможность менеджерам предприятий не только вносить корректировки в схемы бизнес-процессов, но и самим их создавать.

Работа по усовершенствованию способов моделирования бизнес-процессов продолжается. Специалисты отмечают тенденцию к упорядочиванию и стандартизации.

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

Работа по моделированию бизнес-процессов включает в себя 5 этапов:

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

Виды

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

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

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

Основных принципов пять:

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

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

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

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

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Методы моделирования

Методов построения моделей довольно много, среди них:

IDEF — построенная на основе методологии SADT модель состоит из графических схем, облегчающих анализ системы.

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

Flow Chart Diagram — метод моделирования бизнес-процессов посредством символов. Отличается гибкостью.

Сети Петри – показывают динамику изменения процессов.

Инструменты

• AllFusion Process Modeler. Позволяет строить модели и производить анализ с использованием стандартных инструментов IDEF0, DFD и пр.
• ELMA BPM. Позволяет отслеживать выполнение процессов в реальном времени. Для построения моделей используется нотация BPMN 2.0.
• Draw io. Сервис позволяет строить огромное количество диаграмм и имеет большой набор элементов. Возможно связывать модели через гиперссылки. Кроме того, можно к элементам присоединять файлы из облачных хранилищ данных.

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

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

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

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

Если работа проведена правильно, на выходе компания получит:

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

Как видим, правильное и осознанное моделирование бизнес-процессов только упрощает работу руководства и персонала компании.

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Автор: Марина Ступакова, эксперт компании iTeam

Моделирование бизнес-процессов: цели, методы и результаты

Моделирование бизнес-процессов: цели, методы и результаты

Моделирование бизнес-процессов предприятия — важнейший инструмент грамотного и результативного управления.

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

Моделирование бизнес-процессов: основные понятия

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

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

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

Зачем моделировать бизнес-процессы

К чему приводит отсутствие формализованных бизнес-процессов?

• Нет распределения полномочий и зон ответственности — возникающие проблемы некому решать.

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

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

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

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

• Плохо работает документооборот — нужные документы сложно найти, нередки потери.

• Возникает избыток товарных запасов из-за недостаточного планирования.

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

• Не ведется контроль удовлетворенности клиентов — пробелы в этом направлении не выявляются и не устраняются. 

• Деятельность предприятия не прозрачна для инвесторов — снижается доверие.

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

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

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

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

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

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

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

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

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

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

Имитационное моделирование — в этом случае процессы представляют через примеры их поведения в разных условиях, анализируя свойства в динамике.

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

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

• Ориентация на эталонные и референтные модели как базу для описания бизнес-процессов.

• Моделирование «сверху вниз» — в каждой предметной области первыми создаются модели верхнего уровня: для основных процессов, процессов управления, развития, обеспечивающих процессов.

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

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

• Соизмеримость процессов по сложности (составу) и по значимости.

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

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

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

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

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

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

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

3. Построение модели «как должно быть» — формулирование состояния процесса, к которому необходимо стремиться. Эта модель отображает будущий процесс после проведения улучшений.

4. Тестирование построенной модели — внедрение ее в деятельность компании, оценка результатов, внесение изменений.

5. Улучшение построенной модели — в процессе использования модель необходимо продолжать анализировать и совершенствовать.

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

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

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

Количество методов достаточно велико. В числе основных можно назвать следующие.

• IDEF — класс методов (IDEF0, IDEF1 и т.д.), основанных на методологии SADT. Модель позволяет описывать в виде графических схем разные стороны процессов. Так, IDEF0 создает модель функций процесса, а IDEF3 —
  поведенческую модель.

• VAD — нотация дает общий взгляд на бизнес-процессы, которые непосредственно участвуют в создании ценности, т.е. продукта или услуги.

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

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

• Data Flow Diagram отображает передачу информации (не материалов) между операциями в рамках процесса. С помощью DFD можно разбить процесс на более мелкие подпроцессы, поэтому его применяют для структурного анализа. 

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

• Flow Chart Diagram строится с помощью набора символов, которые обозначают элементы процесса: процедуры, инструменты, данные и т.д. Метод отличается гибкостью, позволяя представить процесс как логическую последовательность
  действий множеством способов.

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

Существует ряд программных продуктов, которые могут быть использованы в качестве инструментов моделирования бизнес-процессов с применением описанных методов: ARIS, Business Studio, MS Visio, Bizagi Process Modeler и др.

Моделирование бизнес-процессов: проект из практики

Результаты бизнес-моделирования

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

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

Моделирование способно принести компании видимые преимущества:

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

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

• формируется четкое понимание потребности в персонале, процесс найма становится более простым и эффективным;

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

• улучшаются финансовые показатели.

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

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

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

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

Как изобретать что-то новое, мы рассказываем на нашей программе «ТРИЗ на практике: творческий подход на работе и в жизни». Кое-что про методы моделирования бизнес процессов вы можете узнать и сами, а разбираться с любой новой информацией вы научитесь на программе «Лучшие техники самообразования».

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

Моделирование бизнес-процессов: немного истории

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

Пионером в этой области стал польский инженер Карол Адамецки (1866-1933). В 1896 году он презентовал диаграммы-гармонограммы (harmonogram, от слова «гармония»), наглядно представлявшие все, что происходило в текущий момент времени на предприятии.

Работа была представлена на русском и польском языках и не получила широкого распространения в научных и производственных кругах, хотя наработки были однозначно интересными [A. Kosieradzka, 2018]. Уже тогда, в 19 столетии, языком науки и бизнеса был английский. Поэтому для того, чтобы работа получила широкую известность, ее нужно было как минимум выпустить на английском.

Намного больший резонанс вызвала разработка британского инженера Генри Ганта (1861-1919). В 1910 году он представил ленточную диаграмму, позволяющую отслеживать состояние всех процессов на предприятии в любой момент времени [H. Gant, 1910]. Разработка получила название по имени своего изобретателя – диаграмма Ганта. С тех пор прошло больше ста лет, однако диаграмма Ганта по-прежнему актуальна и позволяет решать многие организационные задачи:

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

По мере усложнения производства усложнялось и моделирование бизнес процессов предприятия. Так, появившийся в 50-е годы метод PERT (Project Evaluation and Review Technique) позволял работать с большим количеством значений, в том числе неопределенных и изменяющихся на протяжении времени проекта.

Желающие вникнуть в математическую часть могут прочитать книгу «Сетевые методы планирования и их применение» [А. Кофман, Г. Дебазей, 1968]. Мы же ограничимся представлением общей схемы сетевой диаграммы PERT, где обозначения от A до F – различные операции, t – время этих операций, а кружочки с цифрами – промежуточные этапы.

Схематично это выглядит так:

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

Собственно термин «моделирование бизнес-процессов» зародился в 1967 году. Впервые его употребил автор статьи, посвященной теме атомной энергетики [R. Walton, 1967].

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

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

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

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

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

• Нотация IDEF0.
• Нотация Basic Flowchart.
• Нотация Cross-Functional Flowchart.
• Нотация моделирования бизнес-процессов BPMN0 (Business Process Model and Notation).
• Нотация EPC (Event-Driven Process Chain).

Узнать подробнее можно из обзора «Нотации моделирования бизнес-процессов» [Business Studio, 2020]. В контексте нашей темы мы говорим об этом лишь для того, чтобы показать масштаб и многообразие разработок в данной области, что само по себе указывает на важность этой сферы. Почему эта сфера так важна? Давайте разбираться.

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

Конечная цель моделирования бизнес-процессов, как и всего, что происходит в бизнесе, – это увеличение прибыли. Анализ и моделирование бизнес-процессов позволяют выявить ресурсы для уменьшения себестоимости продукции, увеличения емкости рынка, повышения ценности продукта для потребителей и прочих важных для достижения конечной цели аспектов [enterchain, 2020]. Каким образом?

Зачем моделировать бизнес-процессы:

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

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

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

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

Определившись с подходами, будет проще понять, какие модели проектирования бизнес-процесса наилучшим образом отвечают поставленным целям [enterchain, 2020]. Итак, на каких же принципах должно строиться моделирование?

Топ-10 принципов моделирования бизнес-процессов:

1. Ориентация на эталонные и референтные модели как на основу описания бизнес-процесса.
2. Целостность описания процесса с целью получения исчерпывающей информации.
3. Моделирование «сверху вниз» от моделей верхнего уровня к моделям нижнего уровня.
4. Разумная достаточность в описании, детализации, количестве объектов и связей между ними.
5. Фокус на ключевых параметрах процесса без отвлечения на второстепенные детали.
6. Соизмеримость и соразмерность затрачиваемых ресурсов (материальных, временных, людских) и получаемого результата.
7. Множественность как понимание того, что модель должна отображать свойства объекта, влияющие на желаемые показатели.
8. Множественность как использование нескольких моделей для полного всестороннего представления объекта или процесса, если одной модели недостаточно.
9. Непротиворечивость как понимание того, что все элементы, входящие в модель, должны иметь четкое однозначное толкование и не противоречить друг другу.
10. Применимость моделей с учетом цели проекта.

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

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

Итак, какие стадии должно пройти моделирование бизнес-процессов, чтобы модель была эффективной?

5 основных стадий моделирования:

1. Создание модели в самом общем виде «как есть» с выявлением границ и основных составляющих процесса, сбором всей необходимой информации.
2. Анализ данных, включающий поиск ограничений, слабых мест, дублей функций и операций, возможностей для улучшения модели.
3. Построение желаемой модели «как должно быть» с описанием состояния процесса, к которому нужно стремиться.
4. Тестирование модели путем внедрения и оценки результатов.
5. Улучшение модели с учетом выявленных в ходе тестирования нюансов.

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

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

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

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

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

• BPMN – пошаговый метод проектирования процессов от начала до завершения, представленный в виде схемы. Применяется для презентации как последовательности операций, так и информационных потоков.
• VAD – метод предназначен для формирования общего вида процессов, необходимых для появления товара или услуги.
• Flow Chart Diagram, или диаграмма работ – это метод презентации процесса как логической последовательности действий.
• Data Flow Diagram, она же диаграмма данных – это метод отображения передачи информационных данных между этапами внутри процесса.
• Role Activity Diagram, она же диаграмма ролей – метод проектирования как единства и взаимодействия ролей, каждая из которых имеет свои функции.
• EPC – метод используется преимущественно для проектирования процессов нижнего уровня, где для каждой функции определены участники, материальные ресурсы, информационные потоки, стартовые и финишные точки.
• IDEF – класс методов, включающий семейство стандартов от IDEF0 до IDEF14. Каждый из стандартов заточен под разные задачи, а внутри класса методов используются разные подходы.

Относительно класса методов IDEF заметим, что, например, IDEF0 – это образец функционального подхода, а IDEF4 – это реализация объектно-ориентированного подхода, IDEF7 используется для аудита информационных систем, а IDEF14 – это метод проектирования компьютерных сетей.

Уточним также, что описанные методы реализуются с помощью специального программного обеспечения. Наиболее часто для этих целей используют такие программные продукты, как Business Studio, MS Visio, ARIS, Bizagi Process Modeler.

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

Для наглядности можно сказать, что по теме «Моделирование бизнес-процессов» курсовая работа, посвященная салону красоты, будет отличаться от курсовой, посвященной супермаркету. А работа по моделированию процессов для диспетчерской службы будет выглядеть иначе, чем такая же работа, выполненная для совместного предприятия [IT diplom, 2020].

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

Как избежать ошибок в моделировании бизнес-процессов?

Как известно, совсем не ошибается только тот, кто ничего не делает, однако тратить время на типовые ошибки, которые уже совершили до вас, было бы неразумно [Fox Manager, 2019]. В основе большинства ошибок лежит либо непонимание сути бизнес-процесса, за моделирование которого нужно взяться, либо плохое знание инструментов моделирования.

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

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

Однако если вы уверены, что лучше вас ваш бизнес все равно никто не знает, вполне можно попробовать взяться за создание модели самостоятельно. Тем более что уже накоплен определенный опыт, как избегать типовых ошибок при моделировании [Fox Manager, 2019].

Топ-5 рекомендаций, как избежать ошибок при моделировании:

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

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

Мы желаем, чтобы все процессы в вашем бизнесе и вашей жизни были упорядочены и приносили желаемый эффект. Мы ждем вас на наших программах «ТРИЗ на практике: творческий подход на работе и в жизни» и «Лучшие техники самообразования». И предлагаем ответить на вопрос по теме статьи: