Как описать бизнес-процессы: схема работы от заявки до результата
Описание процесса нужно там, где работу приходится каждый раз объяснять заново или искать причину задержки по перепискам. Для первого разбора достаточно одного повторяющегося пути: от заявки до согласованного результата. Схема должна отражать то, что действительно происходит в компании.
Содержание статьи
Выберите начало и конец
У процесса «обработка заказа» могут быть разные границы. Для отдела продаж он заканчивается оплатой, для клиента продолжается до получения покупки, для учета включает возвраты. Если это не оговорить, участники нарисуют разные процессы под одним названием.
Запишите событие начала, результат и получателя результата. Например: процесс запускает подтвержденная оплата; завершает передача заказа курьеру с зафиксированным номером доставки. Проверку получения покупателем можно выделить в связанный процесс. Границы выбираются под вопрос, который вы исследуете.
Начните с участка, где регулярно возникает потеря информации или ожидание. Попытка описать всю компанию за один подход обычно заканчивается слишком общей картинкой: «маркетинг, продажи, производство». На ней трудно найти конкретную ошибку.
Восстановите работу по реальным примерам
Попросите сотрудников показать последние заказы и действия в системах. Кто получил заявку, когда уточнил состав, где записал адрес, как передал информацию дальше. Сравните объяснение с отметками времени и сообщениями.
Возьмите также неудачный случай: перенос даты, отказ поставщика, ошибку в адресе. Если описать только прямой путь, схема развалится на первом исключении. При этом не стоит сразу рисовать все редкие ситуации; сначала отметьте, кто принимает решение и куда возвращается работа.
Интервью с руководителем дополните разговором с исполнителем. В регламенте может быть ежедневная сверка, а фактически сотрудник делает ее после жалобы. Для диагностики ценна именно эта разница. Желаемый порядок запишите отдельно, чтобы команда видела, какие шаги действительно меняются.
Заполните паспорт процесса
Ниже условный пример передачи оплаченного заказа на доставку. Таблицу можно скопировать и заменить сведения своими. В графе «результат» нужен признак, который способен проверить следующий участник.
| Поле | Пример заполнения |
|---|---|
| Начало | Оплата подтверждена в карточке заказа |
| Входные данные | Состав, адрес, контакт, интервал доставки |
| Исполнитель | Менеджер заказа |
| Проверка | Адрес и интервал подтверждены покупателем |
| Передача | Задание на сборку появилось у исполнителя |
| Завершение | Курьер принял заказ, статус сохранен |
| Исключение | При отказе курьера менеджер выбирает другой вариант |
| Контроль | Заказы без принятой доставки видны в отдельном списке |
Таблицу можно прокрутить вправо
К паспорту добавьте владельца всего процесса: человека, который разбирает повторяющиеся сбои между участниками. Исполнитель одного шага и владелец процесса могут быть разными людьми. В небольшой компании роли часто совмещаются, но это стоит написать явно.
Нарисуйте понятную схему
Для рабочей встречи хватает прямоугольников с действиями, стрелок и развилок с условиями. Подпись «проверить оплату» понятнее абстрактного «контроль». На выходах из развилки напишите, что произошло: «подтверждена», «не подтверждена», «нужна сверка».
Если схему будут передавать аналитикам или разработчикам, можно использовать BPMN. Материалы Camunda объясняют эту нотацию и ее элементы. Простую авторскую блок-схему не обязательно называть BPMN: полезность начинается с однозначных действий и переходов.
Разнесите участников по дорожкам или отдельным столбцам. Тогда станет видно, где работа пересекает границу роли. Рядом с передачей укажите систему и набор данных. Именно здесь часто обнаруживается, что один человек считает сообщение отправленным, а другой не видит новой задачи.
Измерьте ожидание отдельно от выполнения
В условном процессе менеджер тратит пять минут на оформление передачи, но заказ ждет подтверждения исполнителя четыре часа. Автоматическое заполнение карточки сократит несколько минут. Причину четырехчасового ожидания придется искать в очереди, расписании или правилах приема работы.
Поэтому фиксируйте время начала и завершения этапа, активную работу и ожидание, если его можно измерить. Проверьте несколько случаев разной сложности. Среднее без контекста скрывает заказы, которые стоят существенно дольше остальных.
В Why Not? Flowers статусы доставки возвращались из Telegram в CRM, а менеджерам и флористам назначили разные зоны ответственности. Для собственной схемы полезен этот принцип: передача должна оставлять проверяемое подтверждение. Точную схему клиента по кейсу восстановить нельзя; приведенный выше паспорт является учебным примером.
Проверьте схему до внедрения
Попросите сотрудника пройти по ней обычный заказ и два исключения. Уточните, какие сведения он должен угадывать. Проверьте, существует ли нужное поле, доступен ли ответственный и понятно ли, когда задача считается принятой.
После этого выберите одно изменение: убрать повторный ввод, определить полномочия или сделать очередь видимой. Обновите схему, укажите дату и владельца документа. Версия, которую никто не поддерживает, быстро начинает описывать прошлую компанию.
Матрица ответственности поможет распределить решения между ролями. Когда порядок работы согласован, можно выбирать процесс для автоматизации. До этого сохраните рядом со схемой хотя бы один реальный пример, на котором команда проверила все переходы.