«Зачем тратить время на описание бизнес-процессов, если всё и так хорошо работает?» — вопрос, который нам периодически задают наши клиенты. Мы решили разобраться, что такое бизнес-процессы, зачем их детально прописывать, и как за 11 шагов самостоятельно прописать бизнес-процесс для своей компании.
Что такое бизнес-процесс?
Бизнес-процесс – стандартная последовательность действий (алгоритм), которая помогает доставить ценность клиенту и получить прибыль. Поиск клиентов, наем новых сотрудников, съемка рекламного видео — примеры отдельных бизнес-процессов.
У бизнес-процесса есть две отличительные особенности:
- Бизнес-процессы повторяются. Например, в видеопродакшене работа с клиентом в основном проходит по одному и тому же пути: компания получает бриф, создает на его основе ТЗ, обсуждает с клиентом, подписывает договор, снимает и монтирует видео, презентует клиенту и получает оплату по договору.
- Бизнес-процессы проходят через несколько отделов (команд) и должностей. Например, к бизнес-процессу поиска сотрудников могут привлечь трех участников: отдел внешних коммуникаций рассылает анонсы о новых вакансиях, HR-отдел проводит собеседования, руководитель компании окончательно выбирает, кого взять в команду.
В бизнес-процессе есть подпроцессы, которые детализируют крупные шаги. Например, в процессе «Получение оплаты от клиента» подпроцессами могут быть:
- «Получение оплаты от клиента в рассрочку»;
- «Получение оплаты от клиента в рамках скидок и акций»;
- «Получение оплаты от постоянного клиента».
Количество бизнес-процессов зависит от сферы работы компании. Например, архитектурное бюро проектирует частное жилье и шоу-румы для ювелирных брендов. Стандартизировать такую работу не получится, потому что каждый проект уникален. Поэтому такой бизнес называется проектно-ориентированным, и бизнес-процессов в нем значительно меньше, чем в других компаниях.
Зачем нужен бизнес-процесс?
Бизнес-процесс описывает то, как вы работаете. С описанием работы легче добиться четкого выполнения процесса. Здесь действует правило: «Если это не написано — этого не существует». Когда бизнес-процесс прописан, его можно совершенствовать, а значит — повышать прибыль компании и удовлетворять потребности клиента. Также с бизнес-процессами вы снижаете зависимость от персонала, так как в бизнес-процессе участвуют не отдельные люди, а должности и отделы. Поэтому хорошо проработанный процесс понятен даже новичкам.
С помощью описанных и внедренных бизнес-процессов можно решать такие проблемы:
- конфликты между отделами и командами. Для решения каждого конфликта приходится привлекать топ-менеджеров.
- бизнес растет, но затраты растут намного быстрее.
- стало больше проблем, связанных с обслуживанием клиентов и производством: срыв сроков доставки, хамство сотрудников колл-центра, брак товара.
- сотрудникам, особенно новым, тяжело понять, кто и за что отвечает в компании;
- внедрение чего-то нового (оптимизация расходов, переход на Agile) встречает постоянное сопротивление сотрудников.
На первый взгляд, бизнес-процессы — не самое главное. Вначале нужно повысить продажи, разобраться с персоналом, проанализировать конкурентов. Потом, если будет свободное время, можно прописать бизнес-процессы. Это ошибка. Именно процессы определяют то, как компания работает: ищет сотрудников, решает задачи клиентов, масштабируется.
Как создать бизнес-процесс: пошаговое руководство
1. Определите цель процесса.
По критерию целей процессы делят на две крупные группы:
- Основные. Добавляют ценность клиенту и приносят прибыль компании (процесс «Продажи»).
- Вспомогательные. Помогают выполнять основные процессы (процесс «Введение нового работника в должность» в рамках основного бизнес-процесса «Управление персоналом»).
2. Определите границы процесса.
Границы процесса — это начало и конец, в рамках которых проходят все операции. Например, в процессе «Продажи» началом будет поступившая от клиента заявка, концом — доставка готового продукта.
3. Определите основные действия бизнес-процесса.
Основные действия — это этапы, из которых состоит процесс. Этапы удобно визуализировать с помощью канбан-таблиц, как мы это делаем в Worksection.
Михаил Рыбаков, автор книги «Бизнес-процессы. Как их описать, отладить и внедрить. Практикум» советует разбивать бизнес-процесс на 7 – 12 шагов.
4. Определите ответственных и исполнителей по каждому действию (этапу) бизнес-процесса.
В работе с бизнес-процессом не участвуют отдельные люди: человек может уволиться, а процесс нужно проводить дальше. Выделяют такие роли и должности:
- Архитектор. Отвечает за качественное проектирование и совершенствование схемы процесса. Он не отвечает за непосредственное выполнение процесса. Обычно архитектором становится руководитель управленческой команды (группы), которая работает с конкретным бизнес-процессом.
- Руководитель. Отвечает за четкое выполнение процесса, чтобы он достигал своих целей. У каждой единицы процесса — свой руководитель. Например, в бизнес-процессе найма сотрудников в студию видеопродакшена единица процесса — найм motion-дизайнера.
- Управленческая команда (группа). Команда (группа) вместе с архитектором проектирует и улучшает бизнес-процесс. Обычно в команду (группу) входят руководители подразделений и ведущие специалисты.
- Исполнители.
5. Определите результаты каждого действия (этапа) бизнес-процесса.
Обязательное качество результата — его можно проверить. Например, получение клиентом товара (результат) подтверждается подписанной товарно-транспортной накладной. У действия (этапа) может быть несколько результатов.
6. Добавьте альтернативные пути процесса.
Бизнес-процесс описывает идеальное развитие событий: например, в процессе «Получение оплаты от клиента» товар всегда есть на складе. Если товара на складе нет из-за ошибки поставщика, то путь выполнения процесса изменится — это альтернативный путь. Так, если в процессе «Получение оплаты от клиента» клиент отказывается от покупки, альтернативным путем будет «Привлечение специалистов для работы с возражениями».
7. Добавьте документы на схеме бизнес-процесса.
Наше любимое правило: «Если это не записано — этого не существует». К примеру, в колл-центр позвонил клиент и попросил отправить заказ на неделю позже. Менеджер не внес данные в CRM, а позвонил на склад и предупредил о переносе отправки. Если заказ придет клиенту через месяц, кто кто будет виноват: менеджер по продажам, склад или служба доставки? С записью о переносе доставки такого вопроса не возникнет.
Когда в следующий раз будете в McDonald’s, обратите внимание на график уборки в санузле, в котором работники расписываются после каждой уборки. Это — документ бизнес-процесса «Уборка помещений».
8. Добавьте инструменты и программы, которые вы используете в бизнес-процессе.
Для того, чтобы упростить работу с бизнес-процессом и быстро включать в работу новичков, можно использовать такие инструменты:
- чек-лист (что нужно сделать для того, чтобы передать ТЗ команде разработки программного обеспечения);
- технологическая карта (алгоритм приготовления конкретного блюда);
- фотографии (как выглядит сверстанный брендбук в студии дизайна);
- схема/блок-схема;
- видеоролик (демонстрация эффективной презентации финального продукта клиенту);
- скринкаст (видеоинструкция по работе с лидами в CRM для отдела продаж);
- скрипт (сценарий проведения переговоров с кандидатом на вакансию);
- блок-схема.
О программах для работы с бизнес-процессами мы написали в разделе «Инструменты по созданию бизнес-процессов». Сюда также вносятся все программы, которые так или иначе используются в работе: тайм-трекер, CRM, сервис по созданию ментальных карт, канбан-таблицы и так далее.
9. Определите KPI бизнес-процесса.
KPI (ключевые показатели эффективности) показывают, насколько хорошо работает бизнес-процесс и как его можно оптимизировать. Такими показателями могут стать:
- срок выполнения заказа клиента (в днях);
- стоимость привлечения клиента (в гривнах).
Каждый KPI — показатель, но не каждый показатель — KPI. Например, в студии 3D-печати срок выполнения заказа клиента может быть одним из KPI, а в архитектурном бюро — не будет.
Еще есть North Star Metric (метрика полярной звезды) — единый показатель, который отражает основную ценность продукта или услуги для клиентов. Например, в e‑commerce метрикой полярной звезды будет количество заказов.
10. Свяжите полученную схему с другими процессами.
Из бизнес-процессов формируется архитектура бизнеса — система бизнес-процессов, которые упорядочивают бизнесы и обеспечивают его результативность. Поэтому бизнес-процессы не могут противоречить или конфликтовать друг с другом.
11. Проверьте полученную модель бизнес процесса.
После тестирования вы поймете, насколько верно выполнены все предыдущие шаги. Уже на этом этапе можно думать, как усовершенствовать бизнес-процесс.
Инструменты по созданию бизнес-процессов
Существует множество программ, которые упрощают создание бизнес-процессов и помогают отслеживать их качество в реальном времени. Расскажем о трех из наиболее простых сервисов для создания бизнес-процессов. В этот раздел не попали отдельные инструменты типа диаграммы Ганта, канбан-таблиц, мнемосхем, ментальных карт.
Перед тем, как использовать любую программу или сервис для создания бизнес-процесса, советуем прописать несколько процессов на бумаге, чтобы понять логику построения.
Business Studio. ПО, с помощью которого можно не только описать бизнес-процессы, но и разработать систему KPI, бизнес-стратегию, внедрить систему менеджмента качества. Есть интеграция с пакетом MS Office.
Notion. Единое рабочее пространство для огромного количества инструментов: заметок, таблиц, баз знаний, ментальных карт, канбан-досок. Лайфхакер назвал его «гибридом Evernote, Google Docs, Trello и Todoist». Правда функций так много, что придется потратить пару вечеров для освоения программы.
Worksection. Система управления проектами со встроенными Agile-инструментами: диаграммой Ганта, канбан-досками. Для создания бизнес-процессов выделена функция Workflow, в которой процессы строятся на основе статусов и представлены в виде канбан-доски. Самое простое из перечисленных решений с бесплатными 14 днями для тестирования.
Как создать бизнес-процесс в Worksection
Бизнес-процесс в Worksection строится на основе статусов — действий, из которых состоит проект. Набор статусов (действий) всегда единый для конкретного проекта.
1. Выберите проект, в котором хотите прописать бизнес-процесс.
2. Создайте набор статусов.
3. Создайте новую канбан-доску.
4. Назначьте ответственного за бизнес-процесс и отдельные действия.
5. Выберите, как задача будет проходить бизнес-процессы с помощью функции «Следующий статус».
Этапы настраиваются исходя из специфики отдела. По аналогии их можно настраивать для любого бизнес-процесса.
Введение
В этой статье мы рассмотрим, что представляет собой нотация бизнес-моделирования BPMN и как её использовать для описания бизнес-процессов.
Главное назначение и практическое применение
Нотация BPMN (Business Process Modeling Notation) нужна для подробного описания логики выполнения бизнес-процесса, в том числе для отражения деталей процессов, таких как: события, исполнители каждого из действий, используемые и создаваемые документы и другие объекты, использующиеся в качестве входных данных для тех или иных действий или создающиеся в результате их выполнения.
BPMN позволяет описать бизнес-логику выполнения действий в виде наглядной диаграммы, а также запустить отрисованный бизнес-процесс на исполнение. Для этого используются специализированные системы BPMS (Business Process Management System), поддерживающие эту нотацию.
BPMS-системы могут автоматически перевести схему бизнес-процесса в исполняемый код и создать веб-приложение, которое будет обрабатывать данные, введённые пользователями и сторонними сервисами. Это соответствует концепции Low Code/No Code (создание программного обеспечения без разработки кода) и отлично подходит для автоматизации офисных процессов.
Технически такая возможность реализуется за счёт перевода BPMN-диаграмм в документы формата BPEL (Business Process Execution Language). BPEL-документы представляют собой инструкции исполнения бизнес-процессов для веб-сервисов.
Таким образом, BPMN используется в следующих случаях:
-
Когда нужно детально и наглядно показать последовательность и логику взаимосвязи действий, событий, исполнителей и объектов бизнес-процесса
-
Когда требуется запустить схему бизнес-процесса на исполнение в BPMS-системах
Краткая история появления нотации
BPMN считается довольно молодой нотацией: её 1-я версия вышла в 2009 году под эгидой профессионального консорциума OMG. Сегодня эта нотация является стандартом де-факто в ИТ-сфере и используется для описания бизнес-процессов. Текущая версия BPMN 2.0 вышла в 2011 году и используется до сих пор. В 2014 году в дополнение к BPMN группа OMG выпустила нотацию описания бизнес-правил и принятия решений (Decision Model and Notation, DMN).
DMN упрощает построение BPMN-диаграмм в случаях сложной бизнес-логики и многоуровневых её ветвлениях.
Несмотря на то, что BPMN носит универсальный характер и может использоваться в любом домене, как и любая другая нотация, BPMN имеет чётко ограниченную область применения.
BPMN не заменяет IDEF0 и других нотаций структурного моделирования бизнес-процессов, организационных структур и информационных систем. Для этих задач есть соответствующие иерархические диаграммы, а также ER, DFD и UML-нотации.
Уровни моделирования
В зависимости от целей построения BPMN-диаграмм, различают 3 уровня моделирования:
-
Описательное моделирование, когда нужно показать успешный путь выполнения бизнес-процесса, например, чтобы согласовать его с бизнес-пользователем. Здесь применяются самые простые элементы нотации, а сама диаграмма намеренно максимально упрощается.
-
Аналитическое моделирование используется, когда нужно полностью показать все варианты выполнения бизнес-процесса, включая логические ветвления и альтернативы. Такая диаграмма обычно создаётся для опытных пользователей и бизнес-аналитиков с помощью расширенного алфавита нотации, включая не только её базовые самые простые элементы, но и более сложные.
-
Исполняемое моделирование предназначено для запуска на исполнение в BPMS-движке, чтобы создать веб-приложение. Здесь может использоваться всё многообразие алфавита этой нотации, включая добавление специальных параметров и скриптов, создаваемых разработчиками.
Алфавит нотации
BPMN-диаграмма отражает детальное описание бизнес-процессов в наглядном графическом виде. Главными объектами на диаграмме являются события и действия (задачи), которые соединяются потоком управления.
Поток управления — это последовательность шагов бизнес-процесса, в которой он исполняется.
Событие — это некий свершившийся факт, что-то, что возникает по ходу процесса или происходит в результате выполнения тех или иных действий. Например, «от клиента поступила заявка», «прошла неделя с момента подачи заявления» и т. д. Процесс в BPMN-диаграмме всегда начинается с события и должен заканчиваться событием.
Кроме того, на диаграмме могут отражаться исполнители бизнес-процесса, документы, используемые или создаваемые в рамках процесса и другие артефакты.
При разработке BPMN-диаграмм «для людей» (описательный и аналитическое моделирование), используются базовые элементы нотации, самые простые для понимания.
События
В нижеприведённой таблице вы можете увидеть базовый набор элементов BPMN, использующийся для отображения событий. Если внутрь круга, изображающего события, вписан какой-то элемент, он называется триггер.
Триггер определяет тип и смысл события. Например, триггер в виде конверта означает, что пришли какие-то данные, причём совсем не обязательно в виде сообщения электронной почты. Триггер в виде часов связан со временем. Если событие имеет триггер, значит, поток управления двинется дальше только тогда, когда сработает триггер этого события. Например, получены данные, наступил определённый временной интервал и так далее.
Подробнее весь набор событий, их визуализация и смысл приведены в Приложении А.
Поток управления
Поток действий в бизнес-процессах от стартового события до конечного может идти не только последовательно, но и параллельно и даже взаимно исключать друг друга. BPMN позволяет это продемонстрировать.
Эфемерной сущностью BPMN, которая показывает смысл концепции потока, называют токен. Подобно потоку воды токен «бежит» от стартового события диаграммы к финишному, разделяясь на несколько экземпляров с помощью логических операторов. Последовательность и вариативность выполнения действий называется бизнес-логикой и показывается с помощью логических операторов или развилок, шлюзов. Например, на диаграмме ниже представлено 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 шагов:
-
Определить границы процесса, т. е. стартовое и конечное события, участников и полезный результат.
-
Описать «счастливый» путь (happy path), который ведёт к созданию полезного результата (продукта).
-
Добавить условия и альтернативные потоки.
-
Добавить неуспешные завершения.
-
Добавить артефакты (объекты и хранилища данных).
-
Раскрыть на новых связанных диаграммах свёрнутые подпроцессы.
-
Добавить промежуточные событийные потоки к внешним пулам.
Пример построения диаграммы по текстовому описанию
Рассмотрим пример процессов работы с клиентской заявкой, представленной двумя пулами: «Обработка заявки» и «Заключение договора».
Клиент является внешним участником этих бизнес-процессов, то есть чёрным ящиком, поэтому он показан свёрнутым пулом. Общение между пулами реализовано через потоки сообщений.
Процесс начинается с момента, когда клиент оставил заявку на сайте (то есть поступление заявки является триггером процесса, его стартовым событием). На основании заявки, в которой указаны подробности заказа, менеджер формирует коммерческое предложение (КП). Далее менеджер озвучивает КП по телефону или направляет на email, или же делает и то, и другое — в зависимости от пожеланий клиента и указанных в заявке контактных данных.
Узнав подробности коммерческого предложения, клиент принимает решение о продолжении сотрудничества или отказе от него. Если клиент не согласился на условия КП, на этом процесс работы с ним заканчивается, а заявке присваивается статус «Отказ».
Если же клиента устраивают все условия, он сообщает менеджеру о намерении заключить договор и передаёт нужные для этого данные. Менеджер формирует новую версию проекта договора и отправляет его на согласование клиенту. При отсутствии возражений клиент подписывает договор. После этого договор считается заключённым, и на этом бизнес-процесс заканчивается, и запускается процесс оплаты, описанный на отдельной диаграмме.
При наличии возражений к проекту договора клиент вносит в него изменения и снова направляет менеджеру. Менеджер формирует новый проект договора и снова отправляет клиенту на согласование, то есть идёт возврат к ранее выполняемой задаче.
Инструменты для разработки бизнес-процессов в нотации BPMN
BPMN-диаграммы для людей, то есть без запуска на исполнение, можно разработать, например, в следующих онлайн-редакторах:
-
ШТОРМ — веб-редактор от команды Дениса Котова, пожалуй, главного евангелиста BPMN в России, с автопроверкой диаграмм и возможностями командной работы в одном пространстве;
-
Online BPMN — простой и удобный веб-редактор, поддерживает интеграцию с BPMS-системой;
-
Cavemo — веб-редактор, аналогичный предыдущему, имеет офлайн-версию
-
простые веб-«рисовалки» Lucidchart, Draw.io, Visual Paradigm
Также алфавит нотации BPMN поддерживается и в MS Visio, ARIS Express и других редакторах диаграмм общего назначения.
Заключение
BPMN-диаграмма имеет массу достоинств. Она позволяет графически показать детальную логику выполнения процесса с помощью логических операторов, событий, документов и прочих объектов. BPMN-диаграмма может быть очень простой, наглядной и понятной для бизнес-пользователей, а также может быть запущена на исполнение в BPMS-движках. Сегодня именно эта нотация считается стандартом де-факто в ИТ-отрасли для описания бизнес-процессов.
Однако, избыточный алфавит нотации, особенно слишком большой набор событий и шлюзов, затрудняют разработку и чтение диаграмм. Это приводит к тому, что у разных аналитиков могут получиться разные диаграммы описания одного и того же процесса. Такая вариативность не всегда хороша, поскольку повышает семантическую нагрузку на читателя. Поэтому при использовании BPMN в качестве корпоративного стандарта визуального описания бизнес-процессов (без запуска на исполнение в BPMS) следует определить, какие элементы вы с коллегами будете использовать, и что именно каждый из них означает, чтобы исключить риски возможных семантических расхождений и снизить смысловую нагрузку на читателей диаграммы.
Анна Вичугова
Бизнес-аналитик, CBAP, к.т.н., тренер Systems.Education,
основатель и тренер Школы прикладного бизнес-анализа
-
Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)
-
Сертифицированный бизнес-аналитик (IIBA CBAP, 2020)
-
Сертифицированный специалист Business Studio и СЭД Directum
Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19, 34, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.
Эта статья может быть полезна тем, кто хочет научиться создавать бизнес-процессы (БП) на портале Битрикс24. В ней будет подробно и занудно описан каждый шаг при разработке бизнес-процесса в CRM на примере несложной автоматизации сделки.
Этапы разработки бизнес-процесса
- Видео инструкция
- Постановка задачи
- Создание шаблона БП
- Тестирование
- Сдача в эксплуатацию
Краткий видеогайд
Очень рекомендуем дочитать статью до конца, а наше видео поможет разобраться в материале еще быстрее.
Постановка задачи и описание алгоритма
В нашем случае задача выглядит так: «Необходимо назначить руководителя Наблюдателем сделки, если сумма сделки 100 000 руб. или больше».
Теперь, когда у нас сформулирована задача, можно приступить к описанию алгоритма. Этот этап нужен для того, чтобы представить решение задачи в структурированном виде, состоящем из отдельных действий и их взаимосвязей. Вы можете разрабатывать алгоритм с помощью любых удобных вам инструментов, например, нарисовать схему на листе, или описать последовательность шагов, или воспользоваться каким-либо сервисом для визуализации блок-схем.
Для нашей задачи достаточно простого описания алгоритма:
Если сумма сделки равна или больше 100 000 руб., то назначаем руководителя Наблюдателем этой сделки.
Создание шаблона по шагам
Шаблон бизнес-процесса – это инструмент Битрикс24, посредством которого можно реализовать ваш алгоритм.
В Битрикс24 можно разрабатывать бизнес-процессы для разных объектов (лидов, компаний, элементов Списков…) и для каждого из них надо выбирать соответствующий шаблон. Мы будем создавать шаблон БП для сделок, поскольку наша задача касается автоматизации сделки.
Перед началом работ убедитесь, что у вас достаточно прав. Для работы с бизнес-процессами в CRM вы должны быть или администратором портала, или иметь включенную опцию «Разрешить изменять настройки» в настройках роли в правах доступа CRM.
Шаг 1. Добавляем шаблон БП для сделок
Переходим в раздел CRM – Настройки – Настройки CRM.
Если вы не можете найти раздел «Настройки» среди пунктов меню, то поищите его под пунктом «Еще» (крайний правый), может быть он прячется там.
Если и это не помогло, то обратитесь к администратору портала, может быть, у вас недостаточно прав для создания БП.
В Настройках выбираем Роботы и бизнес-процессы – Бизнес-процессы.
Добавляем шаблон для сделок. По умолчанию добавляется шаблон для последовательного бизнес-процесса, что нам и требуется в данном случае (и вообще требуется в 99,99% случаев).
Шаг 2. Настройка шаблона
В появившемся окне изменяем Название и добавляем Описание (это не обязательно, но хороший тон).
Обратите внимание на настройки автоматического запуска – «Автоматически запускать».
По умолчанию там указано «При добавлении». Убираем ее! Не стоит, чтобы при добавлении новых сделок запускался наш недоделанный бизнес-процесс (а недоделанным он будет всегда, пока не проведено тестирование).
В окне настроек шаблона мы видим несколько вкладок:
- Основное (которую мы только что заполнили)
- Параметры
- Переменные
- Константы
Параметры служат для добавления информации при запуске процесса и для передачи данных между разными БП.
Переменные нужны для временного хранения данных в ходе бизнес-процесса, и они очищаются после его завершения.
Практическое применение параметров и переменных будет описано в следующих статьях.
Константы нужны для хранения постоянной информации, которая не меняется в ходе БП.
Именно их мы будем использовать в нашем примере для хранения значения 100 000 руб. (минимальной суммы, достойной внимания руководителя) и самого руководителя.
Давайте добавим их на вкладку «Константы».
Для добавления суммы заполните поля:
- Идентификатор – можно использовать только латинские символы, цифры и знак подчеркивания (не волнуйтесь, если вы ошибетесь, то система вам подскажет).
- Название – здесь пишите, что и как вам угодно, но лучше, чтобы это было информативное название.
- Описание – поле не обязательно заполнять, в данном примере и так все понятно, но давайте опишем для наглядности.
- Тип – здесь выберите тип «Целое число»
При добавлении Руководителя заполните те же поля.
Для Типа выберите «Привязка к пользователю».
При заполнении поля «Значение константы» вам сейчас надо выбрать не реального руководителя, а себя или, еще лучше, предварительно созданного тестового пользователя.
Для выбора пользователя нажмите кнопку для вставки значения (запомните ее вид, она будет часто использоваться во время работы над шаблоном):
Выберите пользователя из списка (в данном примере выбран «Тестовый Cотрудник»). Если вы не видите в списке нужного вам пользователя, то поищите его в разделе «Категории пользователей».
Теперь вкладка «Константы» будет выглядеть так:
Не забудьте нажать кнопку «Сохранить» для сохранения параметров шаблона!
Если вы немного утомились и хотите сделать перерыв, то давайте сохраним все что мы сделали с помощью кнопки «Применить»:
Советую вам не забывать периодически нажимать на эту кнопку, чтобы не потерять промежуточные результаты своей работы.
Шаг 3. Добавление блок-схемы
Блок-схема формируется с помощью действий, сгруппированных по разделам.
Вначале вам будет непонятно, какие действия в каких разделах искать и в каких случаях их применять. Но со временем вы увидите, что действий не так уж и много и в процессе работы вы познакомитесь с ними досконально.
Вспомним наш алгоритм: «Если сумма сделки равна или больше 100 000 руб., то назначаем руководителя Наблюдателем этой сделки.»
Нам потребуется действие «Условие» из раздела «Конструкции».
Раскроем раздел и перетащим «Условие» к серому треугольнику, как показано на скриншоте.
Есть еще один способ добавить действие.
Кликнув на треугольник, вы получите список с разделами и здесь уже из раздела «Конструкции» выберите действие «Условие».
Перейдем к настройке Условия.
Вначале давайте изменим название действия. В нашем простом примере с одним условием это кажется лишним, но если вы будете разрабатывать более сложные бизнес-процессы с несколькими условиями, то увидите, насколько удобно, когда блок-схема легко читается.
Для изменения названия нажмите на шестеренку и введите свое название в поле «Заголовок».
Теперь разберемся с ветками условия. По умолчанию их 2, как нам и надо для нашей задачи. Но в принципе можно добавить сколько угодно веток с помощью значка «+» справа от названия.
Настроим левую ветку.
Назовем ее «ДА».
Для «Типа условия» выберем «Поле документа», поскольку мы будем проверять поле сделки («документ» – это общее название элемента, на котором запускается БП).
В появившемся поле документа выберем «Сумма».
В качестве условия выберем «не меньше», поскольку «равна или больше» означает «не меньше».
Для установки Значения нажмите кнопку для вставки значения:
В окне «Вставка значения» раскройте «Константы» и выберите константу «Минимальная сумма».
Настройки левой ветки теперь выглядят так:
Сохраните их.
Таким образом мы добавили в блок-схему проверку условия:
Если сумма сделки (то есть поле сделки «Сумма») равна или больше (то есть «не меньше») 100 000 руб. (значение нашей константы summa_min).
Теперь перейдем к условию в правой ветке.
Здесь достаточно ввести «НЕТ» в поле «Заголовок» и то, это надо только для наглядности нашего условия.
Сейчас, когда у нас готовы 2 ветки, давайте добавим в них действия для логирования.
Это надо для того, чтобы потом по записям в Журнале бизнес-процесса мы могли проверить, как он работает.
За добавление в лог отвечает действие «Запись в отчет» из раздела «Прочее».
Добавьте текст. В текст можно добавить поля, константы, переменные… В нашем примере в текст вставлены поле сделки «Сумма» и константа для минимальной суммы. Добавьте их с помощью кнопки для вставки значения, подобно тому, как мы это делали при добавлении условия в левой ветке.
Для добавления действия «Запись в отчет» в правую ветку условия скопируйте действие, перетаскивая его как показано на скриншоте при нажатой Ctrl. Если будете перетаскивать без Ctrl, то действие будет перемещено, а не скопировано.
Отредактируйте текст в новом действии, изменив «ДА» на «НЕТ».
Вы можете написать свои тексты в этих действиях, главное, чтобы потом из записей Журнала вам было ясно, что происходит с вашим БП.
Теперь в левую ветку добавим наблюдателя к сделке.
Для этого выберем действие «Изменение наблюдателей» из раздела «CRM».
Здесь оставьте действие «добавить» и нажмите на кнопку «…» для выбора наблюдателя.
Поскольку наблюдатель у нас находится в константе «Руководитель», то ее и выберем.
Теперь действие выглядит так:
Итак, наш шаблон готов. Не забудьте его сохранить!
Запуск и Тестирование
Для тестирования создайте сделку c суммой больше 100 000 руб., например, 200 000 руб.
Перейдите в карточку сделки и запустите БП вручную, выбрав его из списка.
Теперь давайте посмотрим Журнал на вкладке «Бизнес-процессы».
Из журнала видно, что БП пошел по левой ветке, как и ожидалось.
Также мы видим, что в карточке сделки «Тестовый сотрудник» установлен как наблюдатель.
Также надо провести тесты, когда сумма сделки < 100 000 руб. и когда сумма сделки = 100 000 руб.
Для этого можно создать новые тестовые сделки с этими суммами или менять сумму в нашей тестовой сделке, при этом не забывая очищать поле «Наблюдатели».
Если все тесты прошли успешно, то можно переходить к последнему этапу.
Сдача в эксплуатацию
Перед запуском БП в работу нам надо сделать 2 вещи.
Первое, это установить реального руководителя вместо Тестового сотрудника в константе «Руководитель».
Для этого выберите наш шаблон в Списке шаблонов для сделок
и измените значение константы «Руководитель» на реального пользователя.
И второе, это установить автозапуск процесса.
Поскольку сумма сделки может быть указана и при добавлении сделки, и при ее изменении, то для автоматического запуска отмечаем 2 чекбокса «При добавлении» и «При изменении».
Теперь наш бизнес-процесс в работе!
#статьи
-
0
Моделирование бизнес-процессов: для чего оно нужно и как его провести
Продолжаем погружаться в управление бизнес-процессами. Рассказываем, как смоделировать процессы компании и описать их самостоятельно.
Иллюстрация: 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. Справа — выходы. Это результаты, которые мы получим: заключим договор, снимем ролик и предложим сотрудничать на постоянной основе.
Вот как функция будет выглядеть в виде диаграммы.
Инфографика: Майя Мальгина для Skillbox Media
В итоге из нескольких таких диаграмм можно собрать одну большую. Важно соблюдать правила расположения данных — сверху, слева и снизу, — чтобы связи между ними сохранялись.
Для неподготовленного управленца это самый понятный подход. Его используют, когда уже определены границы процесса — начало и конец события.
При процессном подходе описывают не результат, а действия, которые необходимо совершить для достижения результата. Процесс можно детализировать сколько угодно — вплоть до операций каждого сотрудника. Получается блок-схема.
Я сторонник процессного подхода. В результате него получаются более прикладные модели, которые понятны и руководителю компании, и исполнителям. Функциональный же подход больше полезен для общего проектирования процессов — и далёк от их практической реализации.
Например, в функциональном подходе «Обработка заявки» — только один из элементов входа. В центре внимания — результат, то есть заключение сделки. В процессном подходе «Обработка заявки» — большой алгоритм. Он подробно описывает действия всей команды.
У процессного подхода есть свои нотации. Стандартом считается BPMN — базовый набор условных обозначений. Его используют для изображения бизнес-процесса в виде блок-схемы.
Нотация BPMN есть в каждом конструкторе для моделирования, но пользоваться ей не обязательно. Гораздо важнее, чтобы схема процесса была читаемой и понятной для руководителя и исполнителей.
Для примера нарисовали блок-схему обработки заявки в учебном центре. Она не соответствует канонам BPMN, но всё равно наглядна и понятна.
Инфографика: Майя Мальгина для Skillbox Media
Это вариант моделирования «для себя». Его используют, чтобы структурировать общие представления о бизнес-процессе, но не раскладывать его на этапы и не составлять алгоритмов.
При ментальном подходе на процесс смотрят не как на последовательность результатов или действий, а как на набор связанных друг с другом понятий. Обычно их собирают на интеллект-карте: в центре «чёрный ящик» с процессом, на орбите — связанные с ним идеи и элементы. Жёстких рамок и нотаций нет — карты рисуют в произвольной форме.
Такая визуализация помогает найти решение, как сделать процесс эффективнее. Дальше это решение воплощают на основе процессного подхода: забирают в основную модель главные элементы, а ненужные отбрасывают.
Ниже дан пример ментальной карты процесса снабжения предприятия. На карте собраны понятия, которые связаны между собой внутри процесса. Но по этапам они не распределены.
Инфографика: Майя Мальгина для Skillbox Media
Обычно моделированием бизнес-процессов занимаются внутренние сотрудники компании или подрядчики. Выбор исполнителя зависит от размеров бизнеса и целей моделирования.
Например, если нужно построить воронку продаж для 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, точкой входа будет попадание заявки в систему.
- Когда процесс закончится. Это момент успешной реализации сделки: клиент оплатил счёт, а продавец и логист организовали доставку.
Можно придумать несколько вариантов точек входа и выхода — для разных вариантов развития события.
Инфографика: Майя Мальгина для Skillbox Media
2. Описываем элементы. При составлении схемы перед глазами нужно держать основную информацию о процессе, чтобы ничего не забыть. Для этого в любом файле подробно описываем:
- зачем нужен процесс;
- из каких шагов и действий он состоит;
- кто исполнители;
- есть ли ограничения по срокам — сколько времени должен занимать весь процесс и его отдельные шаги;
- какие события сопровождают действия исполнителей — например, обмен документами, информацией, денежные переводы;
- какого результата нужно достичь — например, нужны подготовленные документы или оплата по счёту;
- перечень ресурсов — что исполнителю нужно для реализации процесса;
- показатели эффективности — по каким параметрам отслеживать, достигнута цель процесса или нет;
- детали и особенности отдельных этапов.
Здесь лежит шаблон текстового описания процесса.
3. Выделяем основные этапы процесса. На основе описанного в предыдущем пункте процесса составляем блок-схему. В графическом редакторе рисуем каркас — основные этапы в пределах границ входа и выхода.
Инфографика: Майя Мальгина для Skillbox Media
4. Добавляем детали. Наполняем каркас «мясом» — основными событиями по процессу и действиями исполнителя по алгоритму.
Инфографика: Майя Мальгина для Skillbox Media
5. Задаём роли. В процессе может быть несколько исполнительских ролей. Их может выполнять один или несколько сотрудников. Обычно роли обезличены, без уточнения фамилий, — только должности.
6. Наполняем схему ресурсами. Отмечаем на схеме источники ресурсов, которые будут использовать в бизнес-процессе. Например, какие документы кто кому и на каком этапе отправит, какие базы и системы для этого будет использовать.
В нашей «ручной» схеме — это просто дополнительные элементы в алгоритме. Если для моделирования используется специальный софт, к схеме можно прикрепить ссылки.
Инфографика: Майя Мальгина для Skillbox Media
Блок-схема готова. Если таких схем несколько, их процессы можно связать друг с другом на одной карте.
Схемы и алгоритмы нужны, чтобы сделать процессы эффективнее и полезнее для бизнеса. Кроме этого, с готовыми моделями бизнес-процессов проще проводить автоматизацию. Об автоматизации бизнес-процессов расскажем в следующей статье.
- Бизнес-процессы — любые операции внутри компании, которые помогают решать бизнес-задачи и зарабатывать. Моделирование бизнес-процессов — описание существующих в компании процессов и документирование требований к ним.
- В моделировании бизнес-процессов есть три основных подхода: функциональный, процессный и ментальный. Самый понятный подход для неподготовленного человека — процессный. Он даёт подробный алгоритм действий для сотрудников и глубокую детализацию операций.
- Моделировать процессы можно своими силами — если бизнес небольшой и несложный. Если в дальнейшем нужно оптимизировать процессы, лучше привлечь консультантов.
- Бизнес-процессы обычно описывают графически — в виде карт и интуитивно понятных схем. Так с ними проще работать.
- Смоделировать процесс можно самому: разобрать внутреннюю кухню компании, описать в тексте все алгоритмы и на основе этого построить схему в графическом редакторе.
Другие материалы Skillbox Media для менеджеров
Профессия Бизнес-аналитик
Изучите всё, что нужно для бизнес-анализа, — от нотаций до IT-инструментов. Учитесь онлайн, в удобном вам темпе.
Узнать больше →
Бесплатный доступ к курсу: «Профессия Бизнес-аналитик»
Начать учиться
Всем привет! Продолжаем работу с бизнес-процессами: сегодня будем разбираться, как их описывать, для чего, какими способами. Применение каждого из способов описания я буду разбирать отдельно на примерах (как было с кейсом про анализ бизнес-процесса, так будет и про описание).
Описание у нас затрагивает две важные штуки:
- фиксацию всех элементов бизнес-процесса (вход, шаги, ресурсы, ограничения, владелец, исполнитель, потребитель, выход)
- оформление в однозначно понятном, доступном для последующего хранения, изменения, обучения и масштабирования виде
При этом, по моему мнению, важно отметить, что фиксируем мы бизнес-процесс либо в состоянии «как работает сейчас» (AS IS), либо в состоянии «каким бизнес-процесс должен быть» (TO BE), при этом когда мы говорим про то, каким процесс должен быть, мы либо предполагаем изменения, улучшения текущих процессов, либо занимаемся моделированием бизнес-процессов еще не запущенного бизнеса, то есть заранее устанавливаем правила, по которым собираемся начать работать.
А вот вариантов оформления у нас есть три: текст, таблица, графика. И именно про эти варианты, конкретные инструменты реализации этих форматов я и буду сегодня рассказывать. Так что дети, встаем в круг и слушаем, что говорит старый жук))
Про то, как мы получаем информацию о бизнес-процессе я писала в статье Как анализировать бизнес-процесс? Там смотрим в пункт про сбор информации, собираем как написано и потом формируем ручками описание. Собрать можно с помощью интервью (вопросы могут быть открытыми и закрытыми, «опишите важи ежедневные действия» и «оцените от 1 до 10 эффективность действий и почему вы дали такую оценку»), наблюдения (посидеть в углу и посмотреть, что происходит в рамках бизнес-процесса, кто из сотрудников что делает, как быстро оформляется та или иная документация внутри процесса), изучения документации (посидеть, почитать уже существующее старое описание процесса, документы, которые появляются в ходе выполнения процесса и сформулировать представление о состоянии процесса).
Это самый базовый способ — написать словами, как все устроено.
Обычно такой формат используется в регламентах, должностных инструкциях, методичках, и он удобен для линейных, простых процессов, но неудобен для кросс-функциональных процессов.
Пример текстового описания:
При поступлении заявки с сайта менеджер по продажам в течение одного рабочего дня связывается с клиентом по телефону, уточняет потребности. По уточненным потребностям готовит коммерческое предложение. После этого он направляет его клиенту и делает пометку в CRM (переводит на соответствующий этап воронки). Если клиент заинтересован, проводится встреча, обсуждаются условия, и после согласования документов менеджер передает счет на оплату. После оплаты счета клиентом менеджер делает пометку в CRM (переводит на соответствующий этап воронки) и переводит информацию в отдел внедрения.
Этот формат быстрый, простой в реализации, но бывает сложным к восприятию, запоминанию и исполнению, а также в таком виде сложно поддерживать актуальность описания бизнес-процессов (или это становится очень дорого).
Что еще? Так часто бывает, что бизнес-процессы, описанные текстом, «расползаются» по разным документам. Например, частично фиксируются и описываются в трех разных должностных инструкциях трех разных исполнителей одного и того же процесса, а общего описания всех элементов нет.
Для контроля за текстовым описанием нужно обязательно соблюдать наличие описания всех элементов процесса (вход, шаги, ресурсы, ограничения, владелец, исполнитель, потребитель, выход) и ссылки на связанные документы (регламенты, инструкции).
Как писать? Лучше всего по формуле стараться раскладывать каждый шаг описываемого процесса:
Кто? + В каком случае? + В каких ограничениях? + Что делает? + С какими ресурсами? + Что получает в результате?
То есть давайте вернемся к нашему примеру выше и разложим предложение из текста:
Менеджер по продажам (кто?) при поступлении заявки с сайта (в каком случае?) в течение одного рабочего дня (в каких ограничениях?) связывается с клиентом по телефону, уточняет потребности (что делает?).
Тут у нас нет фиксации результата (что он получает какое-то описание потребностей клиента, зафиксированное где-то), и нет описания ресурсов четкого, например, мы знаем, что есть сайт и телефон, но ничего нет про то, где он видит поступление-то, мы догадываемся, что это CRM. Поэтому наше текстовое представление бизнес-процесса было бы лучше, если бы звучало как-то так:
Менеджер по продажам (кто?) при поступлении заявки с сайта и отображении ее в CRM в этапе воронки «Новая заявка» (в каком случае?) в течение одного рабочего дня (в каких ограничениях?) связывается с клиентом по телефону, уточняет потребности (что делает?) и фиксирует выявленные потребности в поле «Потребность клиента» (что получает в результате?).
Детали, последовательность, однозначность, понятность, — писать надо стараться с соблюдением этих принципов.
Вариант чуточку более организованный и наглядный. Почти все элементы бизнес-процесса мы можем зафиксировать как столбцы, а строками будут выступать шаги процесса, в таком случае у нас есть вход и выход для каждого шага, исполнитель каждого шага и (при необходимости) ограничения, потребители и ресурсы каждого шага, что позволяет чуть глубже смотреть на бизнес-процесс.
Давайте на том же примере с обработкой заявки в продажах посмотрим:
Тут я остановлюсь на двух шагах, главное, чтобы вы уяснили суть.
Смотрите на важные штуки, на которые нужно обратить внимание в таблице:
- есть внешний исполнитель, тот, кто за пределами нашей организации (это клиент), но в таблице мы это никак не показываем, не отмечаем, мы просто знаем это, когда смотрим в нужную ячейку
- выход одного шага является входом для следующего шага (иногда в прямой последовательности, иногда через несколько шагов)
- появление потребителей, не связанных с функциональным линейным процессом (речь шла о продажах, а появился продукт), но в требованиях, которые сообщил клиент, может быть заинтересован Владелец продукта, и он будет использовать это как фидбэк или основание для ресерча, то есть точка появления нового потребителя выхода какого-то шага может быть входом для связанного процесса, например, обработки обратной связи, например, есть процесс, когда менеджеры регулярно собирают фидбэк от потенциальных клиентов, систематизируют его и передают в продуктовый отдел (важно: в текстовом описании тоже нужно делать ссылки по тексту на связанные процессы)
То есть какой мы вывод должны сделать по этому способу описания бизнес-процессов? Такой:
Чтобы было полное, детальное, однозначное описание, нужно чтобы у такой таблицы обязательно была шапка:
Название процесса: Продажи по заявкам с сайта
Владелец процесса: Руководитель отдела продаж
Потребители: Продажи, Маркетинг, Продукт, Финансы, Юристы
Связанные процессы: Маркетинг (реклама и трафик на сайт), Продукт (обработка обратной связи от клиентов)
И только потом уже сама таблица с заполненными данными.
Плюс подхода в том, что довольно наглядно и структурно, минус в том, что довольно громоздко. Мой любимый плюс в том, что очень удобно делать сводные таблицы с общим перечислением всех бизнес-процессов, и таким образом видеть общую картину покрытия процессами и правилами внутри компании.
И наконец, схемы, которые многие и считают правильным «описанием процесса», а все остальное так, для тех, кто ненастоящий аналитик.
Для представления бизнес-процесса в виде диаграммы или схемы существуют определенные «языки» написания — нотации, где для каждого элемента есть свое визуальное представление (то есть особый символ / графическое изображение действия, условий, ресурсов, исполнителей и т. д.). Например, для блок-схемы ромб означает выбор / условие, а прямоугольник означает действие, и люди, которые знают значение элементов легко считывают их с общего полотна, и так на описание тратится намного меньше условных текстовых символов и пояснений, потому что остальное шифруется графическими элементами.
Самые распространенные нотации: блок-схема, BPMN, EPC, IDEF0, UML, а строить эти схемы процессов можно в Miro, Lucidchart, Draw.io, Bizagi и т. д. В профессиональном стандарте для профессии бизнес-аналитика это относится к знанию и умению использовать языки и инструменты визуального моделирования.
(я в этой статье не буду делать графическое представление процесса, но в последующих с разбором конкретных нотаций, их правил и требований, буду, так что проявите терпение, драгоценные)
Из плюсов — наглядно, понятно, красиво, из минусов — не все умеют читать схемы и знают обозначение графических элементов, актуализировать сложно без специальных инструментов / людей, которые умеют работать с этими нотациями.
Описание бизнес-процесса должно быть полным, однозначно понятным, масштабируемым, и оно должно быть удобным для вас и вашего бизнеса, поэтому подбирать нужно под цели и задачи ваши:
- если вам важно быстро зафиксировать, как работает или как должно работать — начните с текстового описания,
- если важно учесть все детали каждого процесса и потом свести воедино представление о всех бизнес-процессах — делайте таблицу,
- если работаете над автоматизацией, внедрением новых инструментов и у вас работают высококвалифицированные специалисты — графическое описание в наиболее подходящей нотации,
- если работаете над аудитом всех бизнес-процессов компании для поиска узких мест, проблем и будущих улучшений — используйте комбинированный подход (текст + графика, графика + сводная таблица и т. д.).
Учитывать при подборе способа описания бизнес-процессов нужно не только свой опыт, но и опыт ваших коллег: у всех разное восприятие информации и коммуникационный бэкграунд. В описании лучше всего описывать не как для себя, а так, как если бы вы хотели описать действия, результаты, участников и суть для другого человека, который никогда не видел, как это все работает.
Чем проще, понятнее и честнее вы его опишете — тем эффективнее потом будет работа с этим процессом.
Что у нас дальше по плану? Возьмем пример какого-нибудь бизнес-процесса, из небольшого количества шагов и условий, и сделаем его в разных нотациях для сравнения + сформулируем основные элементы нотаций. И в паре моментов уточним, где граница описания бизнес-процесса и простого процесса, именно с точки зрения нотаций и графики.
Следить за выходом статей и хихикать над мемами, общаться в комментариях можно в канале: