Сравнение As-Is и To-Be решает проблему улучшений «в пустоту»: без явно зафиксированной текущей картины процесса и явно спроектированной целевой картины команда обсуждает изменения абстрактно, каждый представляет себе другое «сейчас» и другое «после», а реальный разрыв между ними остаётся неявным. Визуализация двух состояний рядом делает разрыв видимым и превращает расплывчатое желание «улучшить процесс» в конкретный список того, что должно измениться.
Невозможно спланировать путь из точки А в точку Б, если никто в команде не может нарисовать ни точку А, ни точку Б одинаково.
Происхождение и исследовательская база
Сравнение состояний «как есть» (As-Is) и «как должно быть» (To-Be) — базовая практика управления изменениями и процессного консалтинга, применяемая при реинжиниринге бизнес-процессов и в проектах организационных преобразований для структурированного перехода от текущего к желаемому состоянию.
Ключевые идеи и принципы
Принцип: As-Is описывает реальность, а не то, как процесс должен работать по регламенту
Модель As-Is должна фиксировать процесс таким, каким он реально выполняется сотрудниками, включая обходные пути и неформальные практики, а не то, что написано в устаревшем регламенте — иначе сравнение теряет смысл.
Принцип: To-Be проектируется исходя из целей, а не косметически улучшает As-Is
Целевое состояние должно быть спроектировано от целей и требований, а не получено путём мелких косметических правок текущего процесса — иначе результат остаётся близким к исходному состоянию с минимальным эффектом.
Принцип: Разрыв (gap) между As-Is и To-Be — основа плана изменений
Явное сопоставление двух состояний рядом друг с другом показывает конкретные точки разрыва — что нужно добавить, убрать или изменить, — которые затем становятся основой плана внедрения изменений.
Принцип: Обе модели строятся в одной нотации для сопоставимости
As-Is и To-Be описываются в одной и той же нотации (блок-схема, SIPOC, дорожки) — разные форматы описания делают прямое визуальное сравнение затруднительным.
Ограничения, слепые зоны и критика
Детальное описание As-Is отнимает значительное время, и если организация меняется быстро, зафиксированная модель может устареть ещё до завершения проектирования To-Be. Излишний фокус на подробном As-Is иногда заставляет команду проектировать To-Be как инкрементальное улучшение текущего процесса, вместо того чтобы подумать шире о принципиально иной архитектуре процесса. Наконец, сравнение двух статичных состояний не отражает сам путь перехода — для этого нужен отдельный план внедрения с промежуточными этапами.
Типовые ошибки
Ошибка 1: As-Is описывается по регламенту, а не по тому, как процесс реально выполняется.
Модель не отражает реальность, и разрыв с To-Be рассчитывается от неверной точки отсчёта.
Как избежать: Фиксировать As-Is через прямое наблюдение и интервью с исполнителями, а не по устаревшим документам.
Ошибка 2: To-Be проектируется как незначительная косметическая правка As-Is.
Эффект от изменений минимален, реальные проблемы процесса не устраняются.
Как избежать: Проектировать To-Be исходя из целей и требований, допуская принципиально иную архитектуру процесса.
Ошибка 3: As-Is и To-Be описаны в разных нотациях или разной степени детализации.
Прямое визуальное сравнение затруднено, разрыв неочевиден.
Как избежать: Использовать единую нотацию и уровень детализации для обеих моделей.
Ошибка 4: Сравнение заканчивается диаграммами без явного списка конкретных различий и плана перехода.
Наглядная картина разрыва не превращается в исполняемый план действий.
Как избежать: Формировать явный список различий (gap-анализ) и план перехода с этапами и ответственными.
Ошибка 5: Модель As-Is составляется слишком детально и долго, теряя актуальность к моменту завершения.
Затраченное время на детализацию не оправдывается, если реальность процесса уже изменилась.
Как избежать: Ограничивать глубину детализации As-Is уровнем, достаточным для выявления ключевых разрывов, не более.
Главное, что нужно знать
Сравнение As-Is и To-Be делает разрыв между текущим и целевым состоянием процесса явным и визуальным, превращая абстрактное желание «улучшить процесс» в конкретный список различий. To-Be должен проектироваться от целей, а не как косметическая правка As-Is, а обе модели должны использовать единую нотацию для прямой сопоставимости.
План внедрения
Неделя 1: зафиксировать модель As-Is через наблюдение и интервью с реальными исполнителями процесса.
Неделя 2: спроектировать модель To-Be исходя из целей, не ограничиваясь косметическими правками.
Неделя 3: провести gap-анализ и составить явный список конкретных различий.
Неделя 4: сформировать план перехода от As-Is к To-Be с этапами и ответственными.
Далее: использовать модель To-Be как ориентир при контроле хода изменений.
Книги по теме
Hammer M., Champy J. — «Reengineering the Corporation» (1993). Основополагающая работа по реинжинирингу бизнес-процессов, где сравнение текущего и целевого состояния — центральный элемент подхода.