AS IS и TO BE: как сравнить текущий и будущий процесс

Чтобы сравнить AS IS и TO BE, построй две схемы одного процесса с одинаковыми границами: как работа идёт сейчас и как должна идти после изменений. Сопоставь действия, роли, проверки и возвраты. Итог - две схемы и список изменений с ответственными и критериями проверки.

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

Задай общую рамку сравнения

AS IS описывает фактическую работу, включая ожидание, переписку и повторные согласования. TO BE показывает выбранный будущий порядок с учётом доступных людей и ограничений.

Перед сравнением зафиксируй:

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

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

Построй AS IS по завершённым заявкам

Возьми обычную заявку, заявку с возвратом и случай с исключением. Это материал для восстановления маршрута, а не статистическая выборка. Сверь переписку и документы с участниками. Спрашивай «что произошло с этой заявкой», а не «как положено работать».

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

Условная схема AS IS:

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

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

Хочешь навести порядок в задачах и процессах команды? Начни с одного маршрута в Legend BMS. Зарегистрироваться →

Построй TO BE вокруг выявленных проблем

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

Условная схема TO BE с теми же границами:

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

Контроль координатора сохранён: предварительная проверка менеджера не гарантирует полноту данных. Пока допустимые условия не утверждены, сохрани согласование каждого предложения руководителем.

Составь список изменений

Сопоставляй действия по назначению: номера шагов после перестройки могут различаться. Для каждого изменения заполни связку «было - станет - кто внедряет - как проверить».

• Исходные данные. Было: комплектность впервые проверяет координатор. Станет: сначала проверяет менеджер, контроль координатора сохраняется. Ответственный за внедрение: руководитель продаж, который определяет состав данных. Проверка: координатор начинает расчёт либо возвращает заявку с конкретной причиной.
• Согласование. Было: руководитель согласует каждое предложение. Станет: рассматривает отклонения. Ответственный: собственник, который утверждает допустимые условия. Проверка: стандартный случай проходит без руководителя, отклонение поступает на согласование.
• Передача заказа. Было: отдельная сверка не описана. Станет: координатор сверяет заказ с подтверждёнными условиями. Ответственный: операционный директор, который утверждает критерии приёмки. Проверка: заказ принят либо возвращён с указанием расхождения.

К каждому пункту добавь срок и статус внедрения. Не путай исполнителя действия с ответственным за изменение: данные проверяет менеджер, правило готовит руководитель продаж.

Возврат к расчёту при изменении объёма сохранён в обеих схемах. В TO BE после пересчёта заново определяется необходимость согласования. Это следствие нового правила, которое тоже нужно проверить на пилоте.

Ожидаемый эффект запиши как гипотезу: например, «ранняя проверка уменьшит число возвратов от координатора». Само наличие новой схемы этого не доказывает.

Проверь маршрут до перехода

Пройди TO BE на случаях, разобранных для AS IS. Проверь обычную заявку, нехватку данных, изменение объёма, отклонение от условий и отказ. У каждой развилки должно быть продолжение, у возврата - получатель, у проверки - понятный критерий.

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

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

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

Перенеси будущий маршрут в Legend BMS

Сохрани обе схемы, список изменений и результаты пилота. После перехода сверяй фактическую работу с TO BE: обход маршрута может указывать на неудобное или неполное правило.

В конструкторе бизнес-процессов Legend BMS можно задать шаги, роли и условия перехода. Условия контролируют переход по введённому результату, но не гарантируют фактическое качество работы. Критерии приёмки и содержательную проверку определи отдельно.

Если различия между AS IS и TO BE уже согласованы, но будущий маршрут ещё не закреплён в работе команды, перенеси его шаги, роли и условия перехода в Legend BMS. Зарегистрируйся и первым шагом создай в конструкторе процесс обработки заявки с этапом проверки исходных данных и ролью менеджера.