Что мешает автоматизации идти по плану и как сократить разрыв в сроках
17.09.2026
На старте проект автоматизации почти всегда выглядит управляемым: есть цель, команда, подрядчик, бюджет и план. Кажется, что нужно только описать процесс, разработать систему, подключить интеграции и запустить пользователей. Но по последним данным The Standish Group (обновление CHAOS Report за 2020–2025 гг.), в срок, бюджет и полный объем укладываются лишь 31% ИТ-проектов, еще половина попадает в категорию «с проблемами», то есть выходит за рамки сроков, бюджета или объема, а по данным PMI, 43% проектов превышают плановый бюджет.
Для российского рынка к этой общей картине добавляется свой контур сложности. Поданным опроса, который приводит vc.ru, 44% компаний говорят об остром дефиците квалифицированных экспертов, кто умеет работать с архитектурой, интеграциями и импортозамещением одновременно. А часть проектов автоматизации в 2026 году, понаблюдениям CNews Analytics, являются повторными: некоторые заказчики уже отказываются от одних отечественных продуктов в пользу более зрелых и заново проходят путь внедрения. То есть удлинение сроков – это системная характеристика отрасли, которую сегодня стоит закладывать в план конкретного проекта заранее.Решения накапливаются быстрее, чем их успевают оцениватьИзменение требований – нормальная часть любого проекта: бизнес развивается, появляются новые вводные, руководители видят первые прототипы и предлагают доработки. Каждое изменение по отдельности выглядит разумным решением, а вместе они незаметно меняют объем проекта, если никто не оценивает их влияние на сроки, бюджет и архитектуру как управленческое решение, а не как мелкую правку.Ситуация усугубляется, если на стороне заказчика нет владельца продукта – человека, который не обязан быть техническим специалистом, но должен понимать бизнес-цель, расставлять приоритеты между сценариями и быстро отвечать на вопросы команды. Без этой роли десятки мелких решений зависают между подразделениями: команда разработки ждёт согласований, подразделения спорят между собой, а подрядчик вынужден либо останавливать работу, либо принимать решения самостоятельно. И оба варианта увеличивают срок.Интеграции и данные – отдельный проект внутри проектаНа презентации интеграция обычно выглядит как стрелка между двумя системами. В реальности за ней стоят форматы данных, права доступа, справочники, очереди сообщений, обработка ошибок и ответственность за поддержку. Особенно сложно работать со старыми системами без актуальной документации или понятного владельца. Иногда данные в системе есть, но они не подходят для автоматизации: неполные, противоречивые или заведены в свободном формате.В российских условиях это осложняется отдельно тем, что миграция на отечественное ПО нередко означает интеграцию с системами, для которых еще не сложилась зрелая экосистема совместимых решений. А дефицит экспертизы, о котором говорят 44% опрошенных компаний, чаще всего упирается именно в эту зону.То же касается данных. Если у компании нет актуальной карты систем, списка ролей и владельцев справочников, разработка стартует параллельно с выяснением базовых вопросов, что почти всегда добавляет месяцы к сроку, даже если команда работает быстро.Наконец, если служба безопасности, владельцы смежных систем и пользователи подключаются к проекту не с самого начала, а по факту обнаружения проблем, каждое такое обнаружение отбрасывает проект на несколько шагов назад. Например, интерфейс, спроектированный без участия пользователей, почти гарантированно потребует переделки на приёмке.Как сократить разрыв в срокахРаз срыв сроков – статистическая норма, а не редкое стечение обстоятельств, разумная цель не «избежать любых отклонений», а сократить самый управляемый источник задержек: неопределенность, которую можно было закрыть до старта разработки.Практически это означает три проверки до подписания договора на разработку:— Назначен ли владелец продукта со стороны бизнеса – конкретный человек, с полномочием приоритизировать сценарии без долгих согласований.— Проведён ли аудит данных и интеграций – понятно, в каком состоянии находятся справочники, какие системы придётся подключать и есть ли документация, прежде чем архитектура будет зафиксирована в договоре.— Подключены ли ИТ-безопасность, владельцы смежных систем и ключевые пользователи на этапе проектирования, а не тестирования, чтобы ограничения всплывали до разработки функции, а не после.Автоматизация – это не перенос ручного процесса в систему, а изменение того, как компания работает. Если управлять ею как обычной закупкой разработки, отклонение от плана почти неизбежно попадет в ту же половину «проблемных» проектов, о которой говорит статистика. Если управлять как организационным изменением – с владельцем, обследованием и ранним подключением всех сторон – разрыв в сроках сокращается до управляемой величины.