AS-IS и TO-BE: как описать текущий и будущий процесс без смешивания фактов

• Бизнес-процессы

К вопросам по статье

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

Как собрать AS-IS

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

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

Как перейти к TO-BE

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

1. Зафиксируйте проблему с конкретным примером.
2. Определите желаемое изменение результата.
3. Подготовьте будущий маршрут с ролями и исключениями.
4. Для каждого изменения укажите зависимость и владельца решения.
5. Проверьте достижимость на ограниченном сценарии.
6. Согласуйте порядок перехода для команды.

Какие материалы относятся к текущей модели

AS-IS должен объяснять действующее поведение, включая отклонения от регламента. Разделяйте установленное наблюдение, рассказ участника и предположение аналитика. Их можно хранить рядом, но нельзя делать одинаковыми по доказательности. Иначе будущий проект будет решать проблему, которая существует только в удобном пересказе.

Для существенного вывода сохраняйте достаточное основание. Не требуется копировать все исходные данные в отчёт. Полезнее ссылка на разрешённый пример и короткое описание наблюдения. Лишние копии клиентской информации не делают модель достовернее и усложняют дальнейшую передачу материалов.

Рабочий процесс построения двух моделей

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

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

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

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

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

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

Реестр различий: что именно меняется

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

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

Как выбирать будущий вариант

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

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

Если несколько вариантов допустимы, покажите компромиссы. Один может быстрее запускаться, другой — лучше соответствовать дальнейшему развитию. Решение принимает уполномоченный владелец на основании понятных условий. Аналитик не должен скрывать выбор за единственным уверенно нарисованным TO-BE.

Что делать с полезными ручными действиями

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

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

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

Как планировать переходный период

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

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

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

Матрица проверки будущего процесса

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

Как измерять эффект без подмены определения

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

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

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

Границы готового результата

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

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

Граница подтверждённого результата в реальном анализе

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

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

Контрпример: быстрее стало только название этапа

Предположим, в текущей модели срок считают от поступления запроса, а в будущей — от получения полного комплекта. Вторая длительность может оказаться меньше, даже если клиент ждёт столько же. Сначала приведите начало и конец измерения к одной границе, затем сравнивайте изменения.

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

Разделю текущий процесс и будущие изменения

Покажите один действующий маршрут и опишите желаемое изменение. Я зафиксирую факты отдельно от предложений, подготовлю список различий и проверку перехода для команды. Бизнес-анализ перед автоматизацией. Написать в Telegram · Написать в MAX