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

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

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

1. Задайте границы процесса

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

2. Нарисуйте основные блоки процесса

Расположите основные блоки (подпроцессы, операции) бизнес-процесса в том порядке, в котором они выполняются.

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

3. Добавьте развилки и другие события

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

4. Обозначьте роли участников процесса

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

По необходимости добавляйте недостающие операции.

5. Разместите на схеме документы

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

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

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

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

7. Расположите инструменты и материалы

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

8. Определите показатели эффективности в бизнес процессе

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

9. Свяжите полученную схему с другими процессами

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

10. Проверьте полученную модель бизнес процесса

В принципе, схема готова. 

Схема бизнес процесса должна отвечать на следующие вопросы:

• С чего начинается и чем заканчивается бизнес процесс?
• С какими процессами он связан? Чем обменивается?
• Какие операции выполняются? В каком порядке?
• Кто выполняет операции в процессе?
• Какие документы используются и появляются в процессе? В каких операциях эти документы используются/появляются?
• Какие инструменты, материалы, ПО и базы данных используются в процессе и в каких операциях?
• Какие показатели эффективности и где именно фиксируются в бизнес процессе?

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

Качественно подготовленная схема должна быть проста для восприятия и достаточно информативна. 

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

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

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

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

Этап 1. Определение и ограничение бизнес-процесса

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

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

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

Этап 2. Задание точек начала и окончания, основных блоков

Любая схема бизнес-процесса имеет начало и конец. Например, за начало берётся поступившая от клиента заявка, за конечную точку – момент передачи ему готового продукта (доставки).

Далее вычленяются основные этапы обработки бизнес-процесса. Например:

• Регистрация входящей заявки.
• Презентация клиенту подходящего продукта.
• Оформление конкретной заявки.
• Производство продукта (или поиск его на складе) и отправка клиенту.

Этап 3. Детализация схемы бизнес-процесса

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

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

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

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

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

Заказать демо

Этап 4. Определение ролей участников процесса, документов, баз данных

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

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

Этап 5. Проверка схемы бизнес-процесса

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

Готовая схема бизнес-процесса может быть с лёгкостью автоматизирована с помощью систем BPM.

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

Введение

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

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

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

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

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

Шаг 1. Осознание информации

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

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

Шаг 2. Научитесь видеть самое важное

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

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

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

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

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

Шаг 3. Изучить условные обозначения 

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

Читайте также: Что такое x86-64 и откуда оно взялось?

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

Шаг 4. Выбор рабочего инструмента

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

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

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

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

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

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

Шаг 5. Знать основные правила построения блок-схем

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

• Обязательно в схеме должно присутствовать два блока – это «Начало» и «Конец». Очевидно, что у любого алгоритма или бизнес-процесса может быть только одно начало или только один конец.
• Начальный блок связывается с конечным посредством линий связи, которые могут быть дополнены различными промежуточными операциями. Из всех блоков, кроме конечного, должны выходить линии потока. 
• Все блоки удобно пронумеровывать. Так легче ориентироваться и вам при разборе схемы, и тому, кто пытается осмыслить полученный вами результат. 
• Не секрет, что линии делятся на входящие и выходящие. Если блоки не начальные или конечные, или концевые для конкретной ветки, то одна и та же линия является для одного блока выходящей, а для другого входящей. 
• Допускается наличие разрывов в линиях потока. Это обычное дело! Ведь у каждого ответвления рано или поздно происходит логическое завершение. 
• Логика процесса может быть линейная, разветвляющаяся или циклическая. Предположительно, тут вопрос появиться не должно 🙂 Если блоки на прямой линии – это линейный вариант. Если на схеме есть разветвления – то схема разветвляющаяся (всегда реальная схема такая). Циклическая – для программиста обычное дело, а вот для бизнес-аналитика более редкая. Скажем, заправка автомобиля перед каждым рейсом – это циклическая операция. 

Шаг 6. Проработка существующей схемы процесса “от” и “до”

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

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

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

Иллюстрация: 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 для менеджеров

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

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

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

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

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

Первый этап. Обозначаем и устанавливаем границы бизнес-процесса

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

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

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

Второй этап. Задаем точки начала, окончания, ключевых блоков

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

• Регистрация заявки.
• Знакомство заказчика с подходящим продуктом.
• Оформление заявки.
• Изготовление продукта (или доставка со склада).
• Отправка заказа клиенту.

Третий этап. Дополним сетку недостающими операциями

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

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

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

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

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

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

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

В остальном необходимо очень четко прописать все дополнительные детали и особенности. Речь, например, о методах коммуникации между отделами компании. Это может быть как электронная почта, так и конкретное ПО (следует прописать, какое именно).

Пятый этап. Проверим полученную модель

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

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

Ее можно легко автоматизировать с использованием систем BPM.