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

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

Зачем описывать процесс до того, как что-то автоматизировать

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

Описание процесса нужно сразу для нескольких целей:

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

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

Шаг за шагом: как собрать описание процесса

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

1. Назовите процесс одной фразой с началом и концом: «от обращения клиента до выставленного счёта». Без границ описание расползается.
2. Определите триггер. Что запускает процесс: звонок, письмо, заявка с сайта, наступление даты, поступление оплаты.
3. Перечислите участников и роли. Не фамилии, а роли: менеджер, склад, бухгалтер, руководитель. Потому что люди меняются, а роли остаются.
4. Запишите шаги в порядке выполнения. Каждый шаг в формате «кто, что делает, с чем, какой получается результат».
5. Отметьте точки принятия решений. «Если сумма больше порога, то требуется согласование руководителя». Условия формулируйте явно.
6. Зафиксируйте входы и выходы: документы, файлы, поля, письма, сообщения.
7. Опишите исключения. Что происходит, когда клиент отказался, товара нет, документ не пришёл, оплата частичная.
8. Укажите результат и критерий завершения. Как понять, что процесс закончен успешно.

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

Процесс: от заявки на сайте до счёта клиенту
Триггер: клиент отправил форму на сайте
1. Менеджер видит заявку в течение рабочего дня (роль: менеджер)
2. Менеджер звонит клиенту, уточняет объём (результат: заполнены поля заявки)
3. Если объём выше согласованного порога, менеджер запрашивает цену у руководителя
4. Менеджер формирует коммерческое предложение (документ: КП)
5. Клиент соглашается, бухгалтер выставляет счёт
Исключения: клиент не отвечает (напоминание через заданное число дней), отказ (причина фиксируется)
Результат: счёт выставлен, заявка закрыта

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

Как выяснить, как процесс работает на самом деле

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

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

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

Типичные ошибки при описании процессов

Ошибки повторяются от проекта к проекту:

• Слишком общий уровень. «Менеджер обрабатывает заказ» ничего не говорит. Нужны конкретные действия и поля.
• Слишком подробный. Описание каждого клика в интерфейсе делает документ нечитаемым. Держите уровень, на котором понятно, кто что передаёт кому.
• Только счастливый путь. Исключения описывать утомительно, но именно на них проекты ломаются.
• Автоматизация хаоса. Если процесс сам по себе запутан, сначала упростите его, потом автоматизируйте.
• Описание вместо участников. Документ составлен в одиночку и не показан тем, кто работает в процессе. Дайте им прочитать и поправить.
• Нет владельца. У процесса должен быть человек, который отвечает за результат и может принимать решения об изменениях.

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

От описания процесса к заданию на разработку

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

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

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

Пример: как один шаг раскрывается на исключения

Возьмём из описания выше шаг «менеджер звонит клиенту». На бумаге это одна строка, но при разборе появляются вопросы. Что, если клиент не берёт трубку? Через сколько повторять звонок и сколько раз? Кто видит, что звонок не состоялся? Когда заявка считается потерянной, и фиксируется ли причина? Куда попадает заявка, если менеджер в отпуске?

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

Как проверить описание на готовность к автоматизации

Пройдите по короткому списку:

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

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

Частые вопросы

Нужно ли использовать BPMN или другие нотации?

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

Сколько времени занимает описание одного процесса?

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

Кто должен описывать процесс: сотрудник или внешний аналитик?

Лучше вместе. Сотрудник знает детали, аналитик задаёт вопросы, которые сотрудник уже не задаёт сам себе, потому что привык. Окончательно описание подтверждает владелец процесса.

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

Это нормальная находка, а не проблема описания. Зафиксируйте варианты, выясните, какой из них даёт лучший результат, и договоритесь о едином. Автоматизировать два разных способа делать одно и то же дороже и труднее поддерживать.

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