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

Суть нотации BPMN

BPMN, или Business Process Model and Notation, является стандартом для описания бизнес-процессов с помощью графических символов. Эта нотация позволяет представлять процессы в графическом виде, что значительно облегчает их анализ, выявление узких мест и оптимизацию. BPMN 2.0 – самая распространенная нотация для описания бизнес-процессов.

Обобщенный пример модели бизнес-процесса в BPMN 2.0

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

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

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

Элементы нотации BPMN: События

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

События в нотации BPMN

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

Элементы нотации BPMN: Действия

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

Действия в нотации BPMN

У действий обязательно должен быть хотя бы один входящий поток и хотя бы один исходящий. Несколько входящих потоков отрабатывается по логике «ИЛИ», а несколько исходящих – по логике «И», то есть все одновременно.

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

Элементы нотации BPMN: Логические операторы (шлюзы)

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

Логические операторы в нотации BPMN

Логические операторы (или шлюзы) задают условия. Они используются как для разветвления одного потока управления на несколько, так и для объединения нескольких потоков в один.

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

Элементы нотации BPMN: Роли

Роли определяют, кто (или какая команда) будет выполнять определенные последовательности действий.

Роли в нотации BPMN

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

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

Другие элементы нотации BPMN

Есть и иные элементы в нотации BPMN 2.0.

Элемент «данные» говорит о том, какие данные нужно сохранить, а какие – считать. Например, когда нужно задокументировать результат действий в бумажном документе или в автоматизированной системе.

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

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

Документация, транзакции и данные в нотации BPMN

Почему так популярна нотация BPMN

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

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

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

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

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

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

Пример 1. Обработка заказа клиента

Возьмем пример описания бизнес-процесса обработки заказа клиента в нотации BPMN 2.0. Тут и далее приводим примеры работ учеников CORS Academy: сможете найти, что можно дополнительно оптимизировать в этих процессах?

Бизнес-процесс обработки заказа клиента, полученного с сайта

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

Рассмотрим действие: проверка наличия товара на складе.

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

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

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

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

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

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

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

Пример 2. Оплата счета поставщика

Рассмотрим еще один пример бизнес-процесса, описанного в нотации BPMN 2.0.

Бизнес-процесс оплаты счета поставщика

В этом простом бизнес-процессе присутствует только одна роль – бухгалтер-операционист.

Стартовое событие запускает процесс, и бухгалтер сразу проверяет, согласована ли оплата. Если нет – процесс завершается.

Если оплата согласована, бухгалтер по определенным правилам устанавливает дату оплаты и сообщает её менеджеру.

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

Если денег достаточно, бухгалтер оформляет платежку, отправляет её в банк и оформляет списание с расчетного счета.

Можно ли этот бизнес-процесс оптимизировать? Конечно. Но об этом будем говорить дальше.

Пример 3. Набор персонала

И еще один пример: набор персонала.

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

При возникновении потребности в персонале руководитель готовит требования к кандидату и отправляет запрос в службу персонала.

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

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

Если кандидат подходит, он оформляется на работу. Если не подходит, возвращаемся к поиску.

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

Но об этом поговорим далее.

Случай из практики

До запуска CORS Academy я успел проработать в крупных 1С: Франчайзи топ-менеджером. Приобрёл опыт распределения большого объёма задач на ограниченное количество специалистов с разной квалификацией.

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

Встречаемся мы как-то с другом в баре, выпить по кружечке пенного. А друг руководит сервисной IT-компанией. И он говорит:

– Слушай, у меня довольно большой объём заявок на Service Desk. Конечно же, есть автоматизация: всё как положено. Но всё равно проблемы присутствуют. И с качеством, и со скоростью исполнения. У тебя же есть опыт распределения заявок? Поделись.

Я всегда с удовольствием делюсь опытом:

– Да, были ситуации, когда на 50–70 специалистов надо было распределять заявки. При этом в пиковый период казалось, мы не справимся – их могло быть больше 100. А «удалёнки» тогда не было, к клиентам надо было выезжать. Но всё же справляться удавалось. И качеством клиенты были довольны.

– А как так удавалось? Какие факторы учитывали?

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

Он настаивал:

– Да ты своими словами объясни, «на пальцах», я пойму! Нарисуй вот тут…

И даёт мне лист бумаги и ручку.

Ну что ж… Заказываю ещё кружечку пенного, раз такое дело, и начинаю рисовать.

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

Но друг этот листок бумаги забрал.

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

– Господи, ты ЭТО вставил в рамку? Ты нормальный вообще? Там же ничего не понятно!

– Илья, кому-то может и не понятно, а мне понятно всё!

Мораль: иному и «мазня» – нотация.

Задание из курса аналитика 1С от CORS Academy

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

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

2. Опишите этот бизнес-процесс, используя нотацию BPMN 2.0.

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

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

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

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

• Повышение скорости работы с данными

• Сокращение ручных операций

• Обеспечение прозрачности компании для руководства

• Упорядочение и закрепление правил в системе

• Сокращение издержек на выполнение работ

• Повышение качества принятия решений

• Снижение ненужных затрат

• Увеличение рентабельности

Эти цели объединяют в себе как бизнес-цели, так и цели оптимизации и автоматизации бизнес-процессов.

Отличия оптимизации от реинжиниринга бизнес-процессов

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

Реинжиниринг бизнес-процессов

Цель реинжиниринга бизнес-процессов – улучшение показателей компании.

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

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

• Компания проигрывает конкурентам

• Экономический кризис в целом и спад какой-то части рынка в частности

• Компания хочет выйти на новый уровень прибыли

• Реинжиниринг в рамках импортозамещения, когда компания стремится занять нишу, освободившуюся после ухода иностранных конкурентов

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

Отличия реинжиниринга от оптимизации:

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

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

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

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

• Оптимизация характеризуется узким охватом, тогда как реинжиниринг – широким.

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

Проблемы, требующие оптимизации бизнес-процессов

Вот какие проблемы, требующие оптимизации бизнес-процессов, мы рассмотрим:

• Нехватка элементов

• Лишние элементы

• Зацикливания

• Неверная последовательность

• Лишние повторы действий

• Непредусмотренные ситуации

• Перепутанные роли

• Неуниверсальность

• Бесцельные действия

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

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

Как обычно, все примеры бизнес-процессов составлены учениками CORS Academy. Пользовались ученики разными инструментами, поэтому само начертание несколько отличается.

Пример 1. Нужны события – оповещения

Оптимизация: добавляем события – оповещения.

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

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

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