Модернизация ИТ: почему большой взрыв редко работает
Большие проекты по замене ИТ-систем часто заканчиваются неудачей или превышением бюджета в разы. Объясняю, почему инкрементальный подход работает лучше и как его применять.
Один из самых устойчивых паттернов в корпоративных ИТ - это большой проект по замене старой системы новой. Три года, два подрядчика и бюджет, который вырастает в процессе. В итоге либо запускается что-то работающее, но не то, что планировалось, либо проект замораживается на полпути.
Я называю этот подход "большим взрывом". И я вижу его последствия регулярно.
Почему большой взрыв привлекателен
С управленческой точки зрения подход логичен. Есть старая система с накопленными проблемами. Есть новая система с красивыми возможностями. Почему не заменить одно другим целиком?
Аргументы в пользу этого подхода реальны: интеграционная сложность двух параллельных систем неприятна, работа с двумя системами создаёт дополнительную нагрузку на команду, поэтапный переход затягивается.
Но эти аргументы не перевешивают риски.
Почему большой взрыв редко работает
Первая проблема - неполное понимание требований в начале. Сложная система накапливает неписаные правила, исключения и обходные пути. Выяснить их все заранее невозможно. В ходе проекта они всплывают и меняют объём работ.
Вторая проблема - обратная связь приходит поздно. При поэтапном внедрении проблемы видны рано и стоят дёшево. При "большом взрыве" проблемы видны перед запуском, когда откатиться назад трудно и дорого.
Третья проблема - изменение контекста. Проект длиной в два-три года заканчивается в другой реальности, чем начинался. Бизнес изменился, приоритеты изменились, иногда команда изменилась.
Что такое инкрементальный подход
Инкрементальный подход не означает делать всё медленно. Он означает разбивать изменение на части, каждая из которых создаёт ценность самостоятельно и может быть запущена в производство.
Практически это выглядит так. Вместо "заменить всю CRM" - "перевести процесс обработки входящих заявок на новую систему, оставив остальное в старой". Это требует временной интеграции двух систем, но даёт результат за месяц, а не за год, и позволяет проверить реальное поведение системы под нагрузкой.
Ключевой принцип: каждый шаг должен быть обратимым или иметь явный план отката.
Где это применимо
Инкрементальный подход применим не везде. Есть системы, где параллельное существование двух версий технически невозможно или создаёт неприемлемые риски. В таких случаях нужна особенно тщательная подготовка, а не отказ от планирования.
Но в большинстве типичных корпоративных ситуаций - замена ERP-модуля, переход на новую CRM, миграция с одного облака на другое - разбить проект на этапы возможно. Это требует больше архитектурного мышления в начале, но значительно снижает риск на протяжении всего проекта.
Вопросы для проверки
Прежде чем утверждать план крупного ИТ-проекта, стоит спросить:
- Есть ли версия этого проекта, которая даёт первый результат через 2-3 месяца?
- Как мы откатимся, если первый этап покажет неожиданные проблемы?
- Что является минимальной работающей версией нового решения?
- Кто из бизнеса будет тестировать и принимать систему на каждом этапе, а не только в конце?
Если на эти вопросы нет ответа - план требует доработки до его утверждения.