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