Как подготовка ИТ-проекта экономит миллионы на внедрении

Почему подготовка проекта важнее внедрения: как грамотный консалтинг экономит миллионы

Я последние годы руковожу проектами ИТ- и AI-трансформации в компании ВИАВЕЙ и почти всегда вижу одну и ту же картину: бизнес готов вкладываться в внедрение, но экономит на подготовке. В результате на рынок выходят красивые, но бесполезные системы, которые сотрудники обходят через Excel и чаты, а бюджеты и нервы уже потрачены.

За большинством таких историй стоит простая причина: подготовка проекта была слабее, чем само внедрение. Фактически компания инвестировала в решение, не проведя нормальный due diligence ни процессов, ни данных, ни управленческих задач.

Разберемся, почему предпроектный консалтинг — не «лишняя бюрократия», а главный способ сэкономить миллионы на ИТ-проекте, и что должно входить в качественную подготовку: от обследования до финансовой модели.

«Дорогая ошибка ТЗ»: когда решение придумано раньше проблемы

Классика: собственник формулирует задачу так — «Нам нужна новая CRM / платформа / AI-бот. Найдите подрядчика и сделайте».
Дальше появляются:

• краткий бриф на пару страниц;
• набор пожеланий от отделов (часто противоречивых);
• техническое задание, написанное «от интерфейса», то есть через список экранов и кнопок, а не через бизнес-цели и процессы.

Подрядчик честно делает то, что написано. Но в процессе всплывают вопросы:

• «А где отчет по марже в разрезе каналов?»
• «Почему система не тянет историю по клиенту за три года?»
• «Почему здесь нельзя согласовать нестандартную цену?»

Ответ неприятно прост: в ТЗ этого не было.

В моей практике был кейс крупного дистрибьютора, где на такой «недописанной» CRM сожгли почти год и десятки миллионов: доработки после запуска стоили дороже самого внедрения, а часть критичных задач так и не заработала. Все потому, что ТЗ описывало «что нажимать», а не «какой управленческий эффект мы хотим получить».

Это и есть «дорогая ошибка ТЗ»: компания цифровизирует то, что уже не работает, не задав базовый вопрос — правильно ли вообще устроен сам процесс.

Предпроектное обследование: диагноз до операции

Хороший ИТ-проект начинается не с выбора платформы, а с обследования бизнес-реальности.

Его задача — не «собрать хотелки», а:

1. Понять, где компания теряет деньги и управляемость: в просроченных отгрузках, ошибках в прайсах, потерянных заявках, ручном своде в Excel, непрозрачных скидках.
2. Увидеть, как реально живут процессы, а не как они выглядят в регламентах: кто и где «дотягивает руками» то, что системы не делают.
3. Разобраться, какие решения принимают руководители и каких данных им не хватает для осознанного выбора.
4. Зафиксировать ограничения: регуляторика, импортозамещение, текущие контракты, кадровый состав, существующий ИТ-ландшафт.

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

По сути, предпроектное обследование — это due diligence перед инвестициями. Если его не сделать, компания вкладывается в актив, который даже толком не описала.

Аналитический отчет: карта проблемы, а не рекламная презентация

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

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

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

Хороший аналитический отчет разрушает иллюзию «поставим систему — и все чудесным образом наладится», но дает руководству честную картину: где проблема в регламенте, где — в данных, а где — действительно в отсутствии инструмента.

План внедрения: не «сделать систему», а изменить управляемую реальность

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

Гораздо продуктивнее мыслить волнами и пилотами.

В грамотном плане внедрения обычно есть:

1. Приоритеты — какие процессы трогать первыми, потому что там максимальный эффект или риск.
2. MVP-контур — минимальный набор функций, который уже создает ценность и позволяет протестировать гипотезы на реальных пользователях.
3. Дорожная карта — порядок доработок, интеграций, миграции данных.
4. Роли и ответственность — кто внутри компании владеет результатом, а не только подрядчик и ИТ-отдел.
5. План отказа от старого — когда и как выключаются «костыли» и параллельные Excel-учеты.

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

Финансовая модель: считать эффект до строки кода

ИТ-проект без финансовой модели — это все еще гипотеза, а не инвестиция.

Модель не обязана быть сверхсложной, но она должна честно отвечать на несколько вопросов:

• Во что мы инвестируем? CAPEX: разработка, лицензии, внедрение, обучение.
• Что будем тратить регулярно? OPEX: поддержка, инфраструктура, сервис.
• Где прямой эффект? Экономия времени, снижение ошибок и штрафов, сокращение дублирующих систем.
• Где косвенный эффект? Ускорение оборота, рост конверсии, повышение качества сервиса, снижение рисков.

Мы в проектах всегда моделируем как минимум два сценария: базовый и консервативный. Жизнь показывает, что даже такой простой прием спасает от завышенных ожиданий и помогает сразу отсеять «золотые хотелки».

Финансовая модель дисциплинирует: любая новая идея по ходу внедрения проверяется на вопрос «как это влияет на окупаемость».

Как грамотная подготовка реально экономит миллионы

Предпроектный консалтинг обычно стоит 5–10% от бюджета внедрения. По привычке его легко записать в «переплату». Но если посмотреть на типовые провалы, становится понятно, где лежат настоящие деньги.

Характерные сценарии:

• Неверно сформулированная цель.
  Внедряют новую CRM «для роста продаж», но не меняют мотивацию и процессы.
  Получают дорогой регистр контактов вместо управляемой системы продаж.
• Игнорирование данных.
  В ТЗ не учитывают, что исторические данные грязные и разбросаны по десятку баз.
  Миграция превращается в отдельный проект, сроки и бюджет улетают в два раза.
• Отсутствие приоритетов.
  Попытка «запихнуть все и сразу» приводит к перегруженному интерфейсу,
  срыву сроков и отказу пользователей от системы.

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

Что делать руководителю, который не хочет учиться на своем бюджете

Если обобщить практику, рекомендации для собственников и топ-менеджеров выглядят так:

1. Не начинать с выбора технологии.
   Сначала — управленческий запрос и критерии успеха, потом платформа.
2. Закладывать предпроектное обследование как обязательный этап.
   С понятными артефактами: карта процессов и данных, аналитический отчет,
   варианты архитектуры, метрики.
3. Требовать финансовую модель до старта разработки.
   Даже базовая оценка лучше, чем движение вслепую.
4. Мыслить волнами, а не «большим взрывом».
   Пилот и MVP — это не слабость, а способ проверить гипотезы на малой крови.
5. Отделять технологии от управленческих иллюзий.
   Ни одна система сама по себе не исправит слабые регламенты
   и не заменит лидерские решения.

Подготовка проекта — это способ относиться к ИТ-инициативам
как к взвешенным инвестициям, а не к дорогостоящим экспериментам. И чем раньше в этот процесс приходит сильный консалтинг — внутренний или внешний, — тем выше шанс, что следующие миллионы будут потрачены не на «еще одну систему»,
а на реально работающий актив компании.