Сравнение As-Is и To-Be процессов

Сравнение As-Is и To-Be решает проблему улучшений «в пустоту»: без явно зафиксированной текущей картины процесса и явно спроектированной целевой картины команда обсуждает изменения абстрактно, каждый представляет себе другое «сейчас» и другое «после», а реальный разрыв между ними остаётся неявным. Визуализация двух состояний рядом делает разрыв видимым и превращает расплывчатое желание «улучшить процесс» в конкретный список того, что должно измениться.

Невозможно спланировать путь из точки А в точку Б, если никто в команде не может нарисовать ни точку А, ни точку Б одинаково.

Происхождение и исследовательская база

Сравнение состояний «как есть» (As-Is) и «как должно быть» (To-Be) — базовая практика управления изменениями и процессного консалтинга, применяемая при реинжиниринге бизнес-процессов и в проектах организационных преобразований для структурированного перехода от текущего к желаемому состоянию.

Практика реинжиниринга (Hammer, Champy, 1993) — не единственный и не самый ранний теоретический корень идеи «текущее состояние → целевое состояние». На 46 лет раньше Курт Левин в статье «Frontiers in Group Dynamics» (Human Relations, 1947, том 1, номер 1, статья, открывшая первый выпуск журнала) описал изменение как переход между двумя устойчивыми социальными равновесиями — по сути, той же логике, что стоит за парой As-Is/To-Be: пока текущее равновесие (As-Is) не «расшатано», предложение о новом равновесии (To-Be) воспринимается как абстракция, а не конкретная цель. Важное уточнение об этой линии происхождения: широко известная «трёхшаговая модель» Левина (unfreeze — change — refreeze) в реальности изложена в 24-м из 25 подразделов 37-страничной статьи, без единого графика или количественного примера, — а сам термин «refreeze» Левин никогда не использовал: его придумал в 1950 году его бывший студент Леон Фестингер уже после смерти Левина (1947). Это подтверждено историко-методологическим анализом Каммингса, Бриджмана и Брауна (Cummings, Bridgman, Brown, «Unfreezing change as three steps», Human Relations, 2016) — популярная версия модели заметно проще и «глаже», чем реальный, куда более осторожный текст первоисточника.

Ключевые идеи и принципы

1. Принцип: As-Is описывает реальность, а не то, как процесс должен работать по регламенту

   Модель As-Is должна фиксировать процесс таким, каким он реально выполняется сотрудниками, включая обходные пути и неформальные практики, а не то, что написано в устаревшем регламенте — иначе сравнение теряет смысл.

2. Принцип: To-Be проектируется исходя из целей, а не косметически улучшает As-Is

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

3. Принцип: Разрыв (gap) между As-Is и To-Be — основа плана изменений

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

   Тот же Курт Левин предложил и практический инструмент для объяснения того, почему разрыв не закрывается сам собой, — анализ силового поля (force field analysis): текущее состояние (As-Is) устойчиво не случайно, а потому что удерживается балансом движущих сил (driving forces), толкающих к To-Be, и сдерживающих сил (restraining forces) — привычек, страхов, недостатка ресурсов, — которые это движение гасят. Практический вывод для gap-анализа: список различий между As-Is и To-Be — это ЧТО нужно изменить, но план перехода становится реалистичным только тогда, когда для каждого значимого различия отдельно проанализировано, какая сдерживающая сила мешает этому измениться само по себе, — иначе план перехода рискует раз за разом упираться в одно и то же невидимое препятствие.

4. Принцип: Обе модели строятся в одной нотации для сопоставимости

   As-Is и To-Be описываются в одной и той же нотации (блок-схема, SIPOC, дорожки) — разные форматы описания делают прямое визуальное сравнение затруднительным.

   Формализованный, промышленный масштаб этой же логики — методология TOGAF (The Open Group Architecture Framework), где сравнение As-Is/To-Be выделено в отдельные, официально определённые фазы жизненного цикла архитектуры (Architecture Development Method, ADM): Baseline Architecture — документированное текущее состояние — фиксируется отдельно для бизнес-архитектуры (Фаза B), архитектуры информационных систем (Фаза C) и технологической архитектуры (Фаза D); для каждой из них параллельно формулируется Target Architecture, и на этой же фазе выполняется формальный gap-анализ; Фаза E сводит все выявленные разрывы из фаз B-D в единый список инициатив для последующего планирования миграции. TOGAF не изобретает новый принцип по сравнению с BPR-практикой Хаммера или полем Левина — но показывает, что на масштабе целой организации (не одного процесса) простое «нарисовать было/будет» требует именно такой институционализированной, многоуровневой структуры, а не одной диаграммы.

   Фаза E того же ADM («Opportunities and Solutions») предлагает и практическое правило приоритизации выявленных разрывов: делить их на быстрые победы (quick wins), реализуемые почти немедленно и с малыми затратами, и структурные изменения, требующие отдельных программ и годового горизонта, — прямое противоядие от Ошибки 4 выше: план перехода без такого деления рискует одинаково растягивать и мелкие, и крупные различия во времени, не давая команде быстрого видимого результата на старте.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: As-Is описывается по регламенту, а не по тому, как процесс реально выполняется.

   Модель не отражает реальность, и разрыв с To-Be рассчитывается от неверной точки отсчёта.

   Как избежать

   Фиксировать As-Is через прямое наблюдение и интервью с исполнителями, а не по устаревшим документам.

2. Ошибка 2: To-Be проектируется как незначительная косметическая правка As-Is.

   Эффект от изменений минимален, реальные проблемы процесса не устраняются.

   Как избежать

   Проектировать To-Be исходя из целей и требований, допуская принципиально иную архитектуру процесса.

3. Ошибка 3: As-Is и To-Be описаны в разных нотациях или разной степени детализации.

   Прямое визуальное сравнение затруднено, разрыв неочевиден.

   Как избежать

   Использовать единую нотацию и уровень детализации для обеих моделей.

4. Ошибка 4: Сравнение заканчивается диаграммами без явного списка конкретных различий и плана перехода.

   Наглядная картина разрыва не превращается в исполняемый план действий.

   Как избежать

   Формировать явный список различий (gap-анализ) и план перехода с этапами и ответственными.

5. Ошибка 5: Модель As-Is составляется слишком детально и долго, теряя актуальность к моменту завершения.

   Затраченное время на детализацию не оправдывается, если реальность процесса уже изменилась.

   Как избежать

   Ограничивать глубину детализации As-Is уровнем, достаточным для выявления ключевых разрывов, не более.

6. Ошибка 6: gap-анализ фиксирует ЧТО должно измениться, но не то, ПОЧЕМУ это не происходит само.

   Список различий превращается в план из благих намерений («автоматизировать согласование», «убрать лишний шаг»), который снова и снова откладывается, потому что никто явно не назвал реальное препятствие — например, отдел, теряющий влияние при устранении шага, или отсутствие бюджета на автоматизацию.

   Как избежать

   для каждого значимого различия из gap-анализа явно проводить анализ силового поля (force field analysis) — называть конкретные сдерживающие силы, а не оставлять переход абстрактным пунктом плана.

План внедрения

1. Неделя 1: зафиксировать модель As-Is через наблюдение и интервью с реальными исполнителями процесса.

2. Неделя 2: спроектировать модель To-Be исходя из целей, не ограничиваясь косметическими правками.

3. Неделя 3: провести gap-анализ и составить явный список конкретных различий.

4. Неделя 4: сформировать план перехода от As-Is к To-Be с этапами и ответственными.

   Далее: использовать модель To-Be как ориентир при контроле хода изменений.

Как реализовать этот план с помощью фрейма «Сравнение As-Is и To-Be» в OrgDevTools

Фрейм на вкладке «Сравнение» показывает две колонки шагов рядом — красную «As-Is — как есть сейчас» и зелёную «To-Be — как должно быть», каждый шаг пронумерован для прямого визуального сопоставления (реализация Принципа 4 — единая нотация). Под колонками — отдельная таблица gap-анализа: для каждого различия указывается сам факт изменения, тип («Добавлено», «Удалено», «Изменено», «Автоматизировано» — цветовое кодирование) и обязательное текстовое поле обоснования от цели.

Неделя 1 плана внедрения — колонка «As-Is»: сюда заносятся реальные шаги процесса по итогам наблюдения и интервью (защита от Ошибки 1). Неделя 2 — колонка «To-Be»: шаги целевого процесса.

Неделя 3 — таблица gap-анализа: каждая строка — конкретное различие с типом и обоснованием. Вердикт вкладки «Итоги» реализован как настоящая приоритетная (не равновесная) проверка по цепочке: сначала проверяется, что As-Is не пуст; затем — что To-Be не пуст; затем — что gap-анализ (хотя бы одна именованная строка различия) проведён вообще, а не просто нарисованы две колонки без выводов (прямая защита от Ошибки 4); и только на последнем шаге — что у КАЖДОГО названного различия заполнено поле обоснования, а не только его тип (защита от ситуации, когда изменения перечислены, но не привязаны к цели). Это осмысленная последовательная логика, а не констатация факта заполненности всех полей.

Неделя 4 — план перехода формируется кнопкой создания задачи на вкладке «Итоги», которая по умолчанию берёт первое необоснованное различие как заголовок задачи «Обосновать изменение из gap-анализа» — то есть фрейм явно подталкивает закрыть именно самый слабый из выявленных пробелов первым.

Книги по теме

Hammer M., Champy J. — «Reengineering the Corporation» (1993). Основополагающая работа по реинжинирингу бизнес-процессов, где сравнение текущего и целевого состояния — центральный элемент подхода.