АВТОМАТИЗАЦИЯ · ПРОЦЕСС · 13 МИНУТ
Как спроектировать статусы процесса
У каждого состояния должны быть смысл, ответственный и понятное следующее действие.
Короткий ответ: статус — это управляемое состояние, а не комментарий
Хороший статус изменяет правила работы: назначает ответственного, запускает срок, открывает допустимые действия или завершает процесс. Формулировки «думаем», «в процессе» и «занимаемся» бесполезны, если команда понимает их по-разному.
Статус = понятное состояние + один ответственный + ожидаемый следующий шаг + правило выхода.
РАБОЧИЙ ОБРАЗЕЦ / ДЕМОНСТРАЦИОННЫЕ ДАННЫЕ
Статусы без тупиков и скрытых решений
На небольшом экране таблицу можно прокрутить в сторону →
| Из состояния | Действие / владелец | В состояние |
|---|---|---|
| Новое | Диспетчер назначил ответственного | В работе |
| В работе | Нужны данные от клиента | Ожидает уточнения |
| Ожидает уточнения | Данные получены и проверены | В работе |
| В работе | Результат подтверждён владельцем | Завершено |
| Новое / в работе | Уполномоченный отменил с причиной | Отменено |
| Новое | Попытка закрыть без результата | Переход запрещён |
У ожидания есть владелец и условие возврата. Названия состояний и допустимые действия важнее цвета.
Как проверить переходы между статусами
- Назовите, что изменилось в работе при каждом статусе.
- Для перехода задайте действие, условие и ответственного.
- Проверьте возврат, отмену и запрещённый переход до переноса в систему.
Что учесть
Не заменяйте модель набором цветных меток. У ожидающего состояния должен оставаться владелец и следующий шаг; исключение не всегда требует нового статуса.
Подробный разбор, подготовка и вопросы
Пять правил устойчивой модели
- Статусы взаимоисключающие. Одна запись находится только в одном основном состоянии.
- Название описывает состояние. «Ожидает данных», а не «Запросить данные»; действие хранится отдельно.
- У каждого статуса есть владелец. Не отдел в целом, а роль, отвечающая за следующий шаг.
- Переход требует события. Получен документ, проведена проверка, подтверждена оплата — а не просто желание передвинуть карточку.
- Конечные статусы различают результат. Успешно завершено, отменено клиентом, не подходит, дубль — это разные основания для анализа.
Рабочая таблица переходов
| Статус | Что уже верно | Ответственный | Следующий шаг | Условие перехода |
|---|---|---|---|---|
| Новая | Запись создана, контакт доступен | Координатор | Проверить и назначить | Ответственный назначен |
| Нужны данные | Для решения не хватает конкретных сведений | Менеджер | Запросить список данных | Получен полный комплект |
| Готово к решению | Данные проверены | Руководитель роли | Принять решение | Решение зафиксировано |
| Выполняется | Решение принято, работа начата | Исполнитель | Завершить результат | Результат принят |
| Завершено | Результат передан и принят | Владелец процесса | Нет | Конечный статус |
Это не универсальная воронка. Названия и переходы должны следовать конкретному объекту: обращению, заказу, документу, задаче или заявке на обслуживание.
Не превращайте каждое исключение в новый основной статус
Причина
Например, «неверный телефон» или «нет обязательного документа». Хранится отдельно от этапа.
Признак блокировки
Показывает, что обычное движение остановлено, и запускает отдельное правило реакции.
Очередь исключений
Собирает записи, требующие ручного решения, без разрушения основной модели.
Возврат
Должен иметь разрешённую точку возврата, причину и ответственного за повторную проверку.
Если для исключения меняется вся ответственность и набор действий, отдельный статус оправдан. Если нужно только уточнить причину задержки, достаточно дополнительного признака.
Как согласовать статусы с командой за одну рабочую сессию
- Выберите один объект и точку начала процесса.
- Разложите 5–10 недавних реальных примеров, включая проблемные.
- Запишите состояния, в которых менялись ответственный или правило следующего шага.
- Объедините дубли и разговорные синонимы.
- Для каждого перехода укажите событие, инициатора и обязательные данные.
- Проверьте завершение, отмену, возврат и просрочку.
- Назначьте владельца словаря статусов и дату следующего пересмотра.
Проверка модели перед переносом в CRM или внутреннюю систему
- Каждый сотрудник одинаково объясняет смысл статуса.
- Для записи всегда можно определить одного текущего ответственного.
- Понятно, какое событие разрешает каждый переход.
- Нельзя случайно перескочить обязательную проверку.
- Просрочка видна отдельно от статуса.
- Причина отмены не записывается свободным текстом без необходимости.
- Возврат не уничтожает историю предыдущих действий.
- По конечным статусам можно посчитать результат без ручной расшифровки.
Частые вопросы
Сколько статусов должно быть в процессе?
Столько, сколько нужно для разных правил работы и управленческих решений. Если два статуса имеют одинакового ответственного, срок и следующий шаг, их стоит попробовать объединить.
Можно ли использовать статус «В работе»?
Можно, если он однозначно определяет ответственного, ожидаемое действие и срок. Если под ним скрываются разные этапы, статус не помогает управлять процессом.
Нужно ли делать отдельный статус для ошибки?
Критичная ошибка должна быть видимой, но не всегда как основной статус. Часто лучше использовать признак исключения, причину и отдельную очередь, сохранив основной этап процесса.
Кто должен менять статус?
Правило зависит от перехода: сотрудник после действия, система после подтверждённого события или руководитель для исключения. Для каждого перехода должен быть один понятный инициатор.
Как проверить модель до настройки системы?
Возьмите реальные недавние примеры и вручную проведите их по таблице переходов. Отдельно проверьте возврат, отмену, дубль, отсутствие данных и просрочку.
ПРИМЕНИТЬ К ПРОЦЕССУ
Зафиксировать статусы и переходы до автоматизации.
Если модель уже набросана, можно обсудить её границы и первый рабочий поток.