Описание и моделирование бизнес-процессов: подходы и примеры

Процесс начинается с обещанного результата

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

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

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

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

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

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

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

Передача между ролями важнее списка отделов

Для шага определяют исполнителя, входные сведения и понятный признак завершения, потому что название отдела не объясняет, кому достанется задача после передачи и какие данные позволят человеку приступить к работе. «Передать в производство» оставляет открытым вопрос, кто именно принимает задачу и как отправитель узнаёт о приёме.

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

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

Особого внимания заслуживает момент приёма. Менеджер отправил сведения, расчётчик обнаружил, что не хватает адреса объекта: задача уже у расчётчика или вернулась менеджеру?

Ответ нужен до внедрения уведомлений. Иначе система начнёт быстрее сообщать о работе, которую никто не считает своей.

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

Стрелка «далее» скрывает правило. Чтобы оно стало проверяемым, рядом с развилкой нужен вопрос, на который можно ответить по данным заявки. «Клиент важный?» обычно не годится: два менеджера оценят важность по-разному.

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

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

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

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

Дорожки удобны, когда проблема возникает при передаче между ролями. Более формальное описание в BPMN уместно, если важны события, ожидание ответа, развилки и взаимодействие нескольких участников, а схема пойдёт аналитикам или в систему управления процессами. При этом освоение значков не заменяет разговора с исполнителями: можно безупречно обозначить событие, которое в реальной работе никто не фиксирует. События в руководстве ELMA365 обозначают запуск, завершение либо ожидание определённого действия. Это хороший повод спросить команду, какое именно событие подтверждает переход, но ещё не основание превращать каждый звонок в отдельный элемент. Для сотрудника, которому нужно отправить расчёт, слишком подробная техническая диаграмма может быть менее понятна, чем короткий маршрут с ясной ответственностью.

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

Возвраты раскрывают настоящую сложность

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

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

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

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

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

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

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

Схема готова, когда её можно исполнить без автора

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

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

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

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