Цифровизация должна сокращать издержки и ускорять бизнес, но иногда происходит наоборот: новая система требует дорогих интеграций, доработок, миграции данных и поддержки. Разбираем, где компании чаще всего ошибаются и что стоит проверить до старта проекта.
Российский бизнес продолжает вкладывать в цифровизацию все больше денег. По предварительной оценке ИСИЭЗ НИУ ВШЭ, затраты на развитие цифровой экономики в России в 2025 году составили 7,1 трлн. рублей, это на 6,5% больше, чем годом ранее. Только внутренние затраты организаций на создание, распространение и использование цифровых технологий оцениваются в 4,5 трлн. рублей. За пять лет эта сумма выросла примерно вдвое. Причем 87,5% расходов крупных и средних организаций на цифровые технологии в 2024 году финансировались из собственных средств.
В 2026 году расходы продолжают расти. В исследовании Apple Hills Digital, Selectel, Cloud.ru и VK Tech 65% опрошенных российских компаний сообщили, что увеличили ИТ-бюджеты: 48% подняли их в пределах 15%, еще 17% более чем на 15%. Исследование охватило 419 компаний из разных отраслей и 27 глубинных интервью с ИТ-руководителями.
То есть вопрос уже не столько в том, готов ли российский бизнес тратить деньги на цифровизацию. Готов. Другой вопрос: сколько из этих денег действительно должно было быть потрачено.
Компания может согласовать систему за 20 млн. рублей, успешно провести тендер и даже уложиться в смету. А потом обнаружить, что отдельно нужны интеграции, миграция данных, переделка нескольких внутренних сервисов, обучение сотрудников, дополнительная инфраструктура и команда, которая будет развивать продукт после запуска.
Иногда проблема обнаруживается еще позже: система работает, но не дает эффекта, ради которого ее создавали.
Это не редкий сценарий. Оператор ИТ-решений ОБИТ в 2025 году проанализировал более 100 входящих запросов от компаний среднего и крупного бизнеса с оборотом от 2 млрд. рублей. В выборку вошли промышленность, ритейл, ИТ и телеком, логистика. Почти в каждом втором случае компании приходили с запросом на повторный проект или доработку после предыдущего неудачного внедрения. Самыми частыми причинами стали недооценка стоимости владения, проблемы интеграции и неправильный выбор решения.
Разберем ошибки, из-за которых цифровизация становится дороже, чем могла бы быть.
Ошибка 1. Цифровизировать компанию отдельными проектами
У компании появляется CRM. Потом ERP. Отдельно развивается мобильное приложение. Маркетинг подключает систему лояльности, HR работает в своей системе, финансы в своей. Где-то появляется BI, затем AI-сервис. Каждый проект можно защитить отдельно. У каждого есть заказчик, задача, бюджет. Иногда все они даже работают нормально.
Через несколько лет обнаруживается другая проблема: весь этот набор плохо работает как единая система. Одни и те же данные хранятся в нескольких местах. У одного клиента разные ID. Часть информации синхронизируется автоматически, часть переносится вручную. Новая функция в мобильном приложении требует изменений в трех внутренних системах. Замена CRM неожиданно затрагивает продажи, приложение, аналитику и программу лояльности. Так появляется тот самый зоопарк ИТ-систем.
В III Всероссийском опросе по цифровой трансформации Comindware, Artezio и РУССОФТ 60% участников сообщили, что проводят отдельные проекты цифровизации, но не имеют общей стратегии. Еще 18% сказали, что такой стратегии нет вообще. 80% компаний используют разрозненные интеграции между информационными системами, а в единой цифровой среде работают только 12%.
У этой проблемы уже вполне материальные последствия. К2Тех опросил более 300 руководителей и ИТ-специалистов средних и крупных российских компаний. 68% респондентов сообщили, что из-за зоопарка решений не могут получить целостную картину данных. 47% сталкиваются с высокими скрытыми затратами на поддержку разрозненных систем, еще 33% говорят о техническом долге, который мешает развитию.
Проблема тут не в количестве программ. У крупной компании их и не может быть две или три. Вопрос в том, как устроены связи между ними и понимает ли компания, каким должен быть ее ИТ-ландшафт через несколько лет.
Допустим, отделу продаж действительно нужна новая система. Помимо вопроса «Решает ли она нашу задачу?» стоит задать еще один: «Что произойдет со всей инфраструктурой после ее появления?». Новая система может дать локальный эффект сейчас, но заметно увеличить стоимость любых изменений потом.
Что проверить до следующего внедрения? Нужно хотя бы на верхнем уровне понимать:
- какие системы новый продукт заменяет, а какие дополняет;
- какие данные он будет получать и передавать;
- где будет храниться мастер-версия данных;
- сколько новых интеграций появится;
- не придется ли хранить еще одну копию уже существующей информации;
- от каких систем и подрядчиков новый продукт будет зависеть;
- можно ли будет заменить его через несколько лет без перестройки половины ИТ-ландшафта.
Здесь полезна архитектурная схема не только текущего состояния, но и целевого. Иначе цифровой контур формируется не потому, что его кто-то таким спроектировал, а потому что проекты запускались один за другим.
Ошибка 2. Не решить заранее, какой результат должен дать проект
«Запустить CRM до декабря» звучит как цель. «Разработать приложение» тоже. Как и «автоматизировать оформление заказа», «внедрить AI» или «перевести сотрудников в новую систему». Только все это цели проекта, а не бизнеса.
Русская школа управления в 2025 году опросила руководителей и HR-специалистов российских компаний. 55% назвали одним из главных барьеров цифровизации высокую стоимость внедрения. Но на втором месте оказался гораздо более интересный ответ: 35% не понимают эффекта от цифровых решений. Еще 29% назвали сопротивление сотрудников, 27% недостаток компетенций у руководителей, 26% сложности ИТ-инфраструктуры.
Проблема становится заметна после релиза. Проект завершили. Система работает. Как понять, что несколько миллионов были потрачены не зря?
Если до начала работы компания не измеряла текущий процесс, ответа может и не быть.
Например, смысл нового личного кабинета может быть не в самом факте его появления, а в том, чтобы больше клиентов решали свои вопросы без обращения в поддержку.
У автоматизации документооборота задача может состоять в сокращении срока согласования с пяти дней до одного. У нового внутреннего сервиса — в том, чтобы операция, которая занимала у сотрудника 20 минут, выполнялась за пять. А у мобильного приложения — не обязательно в росте установок. Возможно, важнее доля пользователей, дошедших до покупки или снижение нагрузки на офлайн-канал.
Поэтому еще до разработки хорошо зафиксировать три вещи: что происходит сейчас. Например, обработка одной заявки занимает 40 минут. Что хотим получить. Например, 15 минут. Как и когда будем это измерять.
Без первой точки сравнения можно получить красивый продукт, хорошие отзывы внутри команды и ни одного доказательства, что бизнес стал работать лучше. Еще хуже, когда KPI цифровизации выбирается из технических показателей. Количество функций, число релизов или процент готовности проекта мало говорят о результате для компании. Система может быть написана без критических ошибок, запущена в срок и полностью соответствовать техническому заданию. И одновременно быть неудачным бизнес-проектом.
Ошибка 3. Считать бюджет внедрения, а не реальную стоимость владения
Это одна из самых приземленных ошибок, потому что ее легко увидеть в деньгах. В исследовании ОБИТ 61% проблемных проектов были связаны с недооценкой стоимости владения ИТ-решением. Компании не полностью учитывали стоимость интеграции, дальнейшего обслуживания и обучения сотрудников. В 48% случаев возникали сложности интеграции с существующей инфраструктурой, в 35% выбранное решение не соответствовало фактическим требованиям бизнеса.
По оценке ОБИТ, доработки и исправления после неудачного внедрения могут потребовать еще
Если компания говорит, что внедрение стоит 15 млн. рублей, стоит уточнить, что именно входит в эти 15 млн.:
- Только разработка?
- Разработка и лицензии?
- А интеграции?
- Миграция данных?
- Изменения в действующих системах?
- Инфраструктура?
- Информационная безопасность?
- Переходный период, когда старое и новое решение работают параллельно?
- Обучение?
- Поддержка?
- Развитие продукта через год?
- Стоимость сотрудников заказчика, которые будут участвовать в проекте?
Цифровой продукт редко заканчивает потреблять деньги в день релиза. Поэтому сравнивать варианты только по стоимости разработки не очень полезно.
Условный проект может выглядеть так:
- 15 млн. рублей стоит разработка и внедрение;
- еще 2 млн. потребовали доработки интеграций;
- 1,5 млн. ушли на подготовку и миграцию данных из смежных ИС;
- 1 млн. на переход и обучение;
- 2,5 млн. на поддержку и доработки первого года.
Мы получили уже 22 млн. вместо 15 млн. Это не среднерыночный расчет и не прогноз для любого проекта, а просто иллюстрация того, насколько по-разному могут выглядеть «стоимость разработки» и «сколько бизнес реально потратил на изменение». Поэтому разумнее считать совокупную стоимость владения (ТСО) хотя бы на несколько лет.
Иногда более дорогой продукт на этапе покупки оказывается дешевле в эксплуатации. А иногда дешевое коробочное решение через два года обрастает таким количеством доработок, что стоимость его поддержки становится отдельной строкой бюджета.
Ошибка 4. Сначала выбрать технологию, а потом искать ей задачу
Еще несколько лет назад бизнес хотел блокчейн. Сейчас хочет AI. Между ними были супераппы, low-code, микросервисы и много чего еще. Фраза «нам нужно внедрить AI» сама по себе ничего не говорит о том, что компании нужно сделать. То же относится к CRM, ERP, мобильному приложению или отечественной замене зарубежной системы.
В анализе ОБИТ 35% проблемных внедрений были связаны с тем, что выбранное решение не соответствовало фактическим бизнес-требованиям. В числе причин компания называет недостаточное тестирование продукта до внедрения и незрелость самого решения. Отдельно эта проблема проявилась во время импортозамещения.
Т1 и РУССОФТ исследовали 78 российских компаний с фокусом на крупный бизнес. Среди серьезных препятствий при переходе на отечественные системы компании называли высокую стоимость новых продуктов, проблемы совместимости с текущей инфраструктурой и недостаточную функциональную зрелость части российских аналогов.
Одновременно 54% респондентов уже включают миграцию на российские технологии в стратегию развития собственных информационных систем. Только 14% рассматривают импортозамещение исключительно как вынужденную реакцию на внешние обстоятельства.
В исследовании РБК и Ростелекома среди 308 руководителей российских компаний 36,7% назвали одной из проблем импортозамещения интеграцию отечественных решений с существующими системами, 32,5% долгие сроки внедрения.
То есть задача «заменим зарубежную систему на российскую» сама по себе тоже может оказаться слишком узкой. Если компания все равно вынуждена менять критичный кусок ИТ-ландшафта, логично сначала посмотреть, нужен ли ей точный цифровой аналог старого процесса. Возможно, за годы работы изменился сам бизнес, появились лишние этапы, а некоторые функции старого продукта уже никому не нужны.
Поэтому порядок лучше разворачивать следующим образом: сначала проблема → затем целевой процесс → требования → ограничения текущей архитектуры → возможные решения → выбор между готовым продуктом, доработкой и собственной разработкой
Не обязательно каждый раз писать новую систему. И не обязательно сразу раскатывать выбранное решение на всю компанию. Если технология новая, интеграций много, а процессы критичные, пилот часто дешевле большого запуска. На ограниченной группе пользователей можно проверить реальные сценарии, производительность, интеграции и ограничения продукта. Это намного лучше, чем обнаружить их после миграции нескольких тысяч сотрудников.
После анализа проблемных проектов ОБИТ тоже рекомендует предварительное тестирование и пилотирование, а миграцию критичных систем проводить поэтапно.
Ошибка 5. Автоматизировать старый процесс, не задаваясь вопросом, нужен ли он таким вообще
Когда компания готовит требования к новой системе, самый простой способ их получить — описать текущую работу. Есть пять этапов согласования? Переносим пять этапов в систему. Сотрудник четыре раза вводит одни и те же данные? Сделаем ему четыре красивые формы. Раньше документ отправляли на почту руководителю? Теперь будет кнопка «Отправить руководителю». Формально это цифровизация. Но процесс остался прежним.
Здесь есть показательный пример из финансового сектора. В исследовании Ассоциации ФинТех при участии К2Тех 70% компаний сообщили, что в ходе трансформации ИТ-архитектуры провели аудит и пересмотр значимой части бизнес-процессов. Более 80% организаций отметили положительные эффекты такой перестройки: повышение эффективности, большую гибкость, создание задела для развития и работу с накопленным техническим долгом.
Конечно, финансовый сектор нельзя автоматически переносить на весь российский бизнес. Но сам подход показателен: смена технологий становится поводом пересмотреть процесс, а не просто перенести его в новую систему.
· До автоматизации полезно буквально нарисовать процесс как есть: что сейчас делает клиент, сотрудник и система. Затем нарисовать должно быть. И к каждому действию задать неприятный вопрос:
- А зачем оно вообще существует?
- Почему заявка должна пройти три согласования?
- Почему данные повторно вводятся руками?
- Почему менеджер переносит информацию из одной программы в другую?
- Почему человек принимает решение, которое полностью определяется набором формальных правил?
- Почему клиент должен заполнять то, что компания уже о нем знает?
- Какие этапы после цифровизации должны не ускориться, а исчезнуть?
- Если раньше сотрудник заполнял Excel, а теперь заполняет новую корпоративную систему и на всякий случай продолжает вести тот же Excel, то бизнес не очень много выиграл.
Ошибка 6. Недооценить интеграции, данные, безопасность и аварийные сценарии
На презентации новый продукт обычно выглядит отдельно. Есть красивые экраны приложения, новый личный кабинет, CRM или внутренняя платформа. В реальной ИТ-инфраструктуре ничего отдельно не существует.
Мобильному приложению нужно получить пользователя из одной системы, остаток из другой, цены из третьей, историю заказов из четвертой, принять платеж через внешнего провайдера и вернуть результат в ERP.
И здесь начинается та часть проекта, которую бизнес не всегда видит на старте.
У ОБИТ сложности интеграции были причиной проблем в 48% проанализированных проектов. Компания отмечает, что они приводили не только к дополнительным затратам, но и к рискам простоев бизнес-процессов.
У Comindware 80% участников исследования работают с разрозненными интеграциями.
У К2Тех 74% опрошенных видят решение проблемы несогласованных данных в сквозной интеграции систем и создании единого контура управления данными. Интересно, что бизнес не обязательно хочет выбрасывать существующий ИТ-ландшафт: 46% компаний называют приоритетом оптимизацию текущих систем без масштабных инвестиций.
То есть еще до интерфейсов полезно нарисовать карту интеграций и данных:
- Откуда приходит каждый тип информации?
- Какая система считается источником истины?
- Кому разрешено менять данные?
- Как часто они синхронизируются?
- Что происходит, если две системы содержат разные значения?
- Что будет, если внешнее API не отвечает?
- А если запрос был отправлен дважды?
- Как система восстановит операцию после сбоя?
- Кто увидит ошибку и кто будет ее разбирать?
- Вот эти вопросы часто влияют на стоимость проекта сильнее, чем количество экранов.
Цифровизация делает бизнес быстрее, но заодно сильнее связывает операции с технологиями. Если раньше недоступность одного сервиса мешала части сотрудников, после автоматизации сбой может остановить всю цепочку.
КРОК в исследовании 70 ИТ-руководителей крупных и крупнейших российских компаний отметил, что в 2025 году заметно вырос фокус на резервировании и отказоустойчивости. Среди инфраструктурных проблем 36% респондентов называли отсутствие резервного ЦОДа, необходимость зеркалировать резервные копии, дублировать сети и сервисы. Поэтому до запуска стоит проверять не только happy path, где все работает как задумано.
- Что произойдет, если платежный сервис недоступен два часа?
- Если упала CRM?
- Если внешняя система отвечает десять секунд вместо одной?
- Если в Black Friday нагрузка выросла в несколько раз?
- Если мобильное приложение работает, а один из внутренних сервисов нет?
Хорошая архитектура предусматривает не только полную работоспособность, но и управляемую деградацию. Пользователь по возможности должен сохранить хотя бы часть сценариев, а бизнес понимать, как система вернется в штатный режим.
И безопасность нельзя добавлять последним пунктом перед релизом.
Исследования показали, что крупные российские компании назвали соответствие высоким требованиям информационной безопасности главным критерием выбора ИТ-партнера, а кибербезопасность остается одним из основных направлений ИТ-инвестиций российского бизнеса.
Но безопасность влияет не только на выбор подрядчика. Она может заметно поменять архитектуру, способ хранения данных, процессы авторизации, интеграции, инфраструктуру и стоимость разработки. Если требования ИБ появляются после того, как продукт уже почти готов, часть работы иногда приходится делать заново.
Ошибка 7. Решить, что legacy обязательно нужно переписать
Старому коду легко назначить виноватого. Если релизы идут медленно, разработчики жалуются на монолит, документации мало и вокруг системы накопилось много странных решений, появляется естественное желание: давайте перепишем все нормально. Иногда это правда правильный вариант. Но возраст системы сам по себе еще не бизнес-проблема.
Опираясь на данные вышеуказанных исследований, 78% российских компаний, использующих облачные технологии, сохраняют legacy-системы. У 14% legacy составляет больше половины ИТ-портфеля. 46% участников называют одним из главных приоритетов оптимизацию существующих систем без масштабных инвестиций. В исследовании КРОК более 30% респондентов говорили о необходимости обновления оборудования и работы с legacy. Тут нет противоречия. Потому что legacy можно модернизировать по-разному.
Допустим, старое ядро работает стабильно, содержит критическую бизнес-логику и справляется с нагрузкой. Но у него плохие интеграции. Тогда иногда разумнее оставить ядро и построить нормальный API-слой.
Если тормозит один модуль, можно вынести его. Если система мешает независимым релизам, разделить наиболее проблемные компоненты. Если высокая стоимость поддержки связана с конкретной частью кода, провести рефакторинг именно там.
Полная замена тоже возможна, но тогда бизнесу стоит понимать, что именно он покупает за стоимость переписывания:
- Будут быстрее запускаться функции?
- Снизится стоимость поддержки?
- Уйдут ограничения по нагрузке?
- Станет проще находить разработчиков?
- Исчезнут риски безопасности?
- Можно будет подключать новые продукты?
- Если на эти вопросы нет ответа, то проект под названием «перепишем все с нуля» легко превращается в очень дорогой способ получить почти то же самое.
Особенно рискован big bang, когда старая система выключается, а новая должна одномоментно заменить все функции. Чем критичнее продукт, тем разумнее рассматривать поэтапную миграцию, когда часть функций или пользователей переводится последовательно и у команды остается возможность проверить систему на реальной работе.
Иногда хороший результат технического аудита звучит не как «вам нужно 30 млн. рублей на новый продукт», а как «эту часть вообще не трогаем».
Ошибка 8. Сначала внедрить AI, а потом разбираться с данными
С AI проблема качества данных стала гораздо заметнее. Можно купить хороший инструмент прогнозирования, подключить BI, внедрить AI-ассистента или модель для автоматического принятия решений. Но если клиент хранится в трех системах под разными идентификаторами, справочники не совпадают, часть данных вводится вручную, а происхождение цифры в отчете никто не может объяснить, новая технология это не исправит. Она будет работать с тем, что ей дали.
51% компаний сохраняют внедрение AI среди ключевых приоритетов. Одновременно 68% респондентов говорят, что не получают целостной картины данных из-за разрозненного ИТ-ландшафта.
В исследовании КРОК качество входных данных и отсутствие формальных регламентов названы среди факторов, которые мешают масштабированию технологических инициатив.
Отдельно Strategy Partners исследовала работу с данными на российских промышленных предприятиях. В 56% компаний ручной ввод остается распространенным способом сбора данных. Только у четверти есть отдельное подразделение для работы с данными, еще у 36% выделен специалист по аналитике. Среди основных барьеров компании называют нехватку людей, компетенций и технических ресурсов.
Это особенно важный момент для AI-проектов, потому что там качество исходной информации напрямую связано с качеством результата.
До запуска стоит разобраться:
- где хранится мастер-версия данных;
- кто является их владельцем;
- кто отвечает за качество;
- есть ли дубли;
- насколько информация полная и свежая;
- как изменяются справочники;
- можно ли понять происхождение конкретного значения;
- какие данные вообще нельзя использовать в выбранном сценарии;
- кто отвечает за ошибку, если автоматическая система приняла неправильное решение.
Если у компании три разных значения одного показателя в трех системах, AI не создаст магическим образом правильное. Есть риск, что появится просто четвертый вариант.
Ошибка 9. Считать, что цифровизация закончилась в день релиза
Команда несколько месяцев или лет делает систему. Проходит приемка. Проект закрывают. На презентации появляется зеленый статус «внедрено». А сотрудники продолжают пользоваться Excel. Или переносят часть данных вручную. Или нашли способ обходить новый процесс, потому что старый быстрее. Или система используется, но время выполнения операции не уменьшилось.
Технический запуск еще не означает, что произошло изменение бизнеса.
В исследовании Т1 и РУССОФТ сопротивление сотрудников новым системам отметили 79,5% представителей крупных компаний. В исследовании Русской школы управления эту проблему отметили 29% респондентов.
Разница в цифрах большая, потому что исследования изучали разные выборки и сценарии. Т1 и РУССОФТ рассматривали крупный бизнес и переход на отечественные системы, РШУ шире спрашивала о цифровизации управленческих процессов. Но обе работы показывают, что технология сама по себе не заставляет людей изменить способ работы.
И здесь легко дать неправильный совет: «нужно лучше обучать сотрудников». Обучение нужно, но сначала стоит проверить сам продукт. Если раньше сотрудник выполнял пять действий, а после внедрения системы делает восемь, сопротивление не обязательно связано с консерватизмом. Если новая программа работает медленнее старой, человек будет искать обходной путь. Если данные нужно вводить и в старую, и в новую систему, он продолжит вести Excel. Если продукт не учитывает реальные исключения из процесса, сотрудники быстро построят вокруг него собственный параллельный процесс в почте и мессенджерах.
Поэтому после релиза важно измерять не только технические показатели. Да, нужны uptime, количество ошибок и SLA. Но параллельно стоит смотреть:
- какая доля сотрудников действительно работает в новой системе;
- какую часть процесса они проходят в ней полностью;
- сколько ручных операций осталось;
- сколько времени занимает задача;
- изменилась ли частота ошибок;
- не продолжают ли сотрудники вести параллельные таблицы;
- как часто им приходится обходить систему;
- изменился ли бизнес-показатель, ради которого все начиналось.
Цифровизация заканчивается тогда, когда изменился процесс и появился измеримый результат для бизнеса.
Именно поэтому сложный цифровой продукт почти никогда нельзя воспринимать как объект, который один раз разработали и забыли. Меняется бизнес, появляются новые требования, интеграции, регуляторика, нагрузка. Продукту приходится меняться вместе с ними.
Что проверить до того, как утвердить бюджет
Ошибки из этой статьи могут выглядеть очень разными, но большинство можно обнаружить до начала большой разработки. Перед запуском проекта полезно честно ответить хотя бы на несколько групп вопросов.
Бизнес:
- Какую проблему мы решаем?
- Сколько она стоит компании сейчас?
- Какой показатель должен измениться после запуска?
- Знаем ли мы его текущее значение?
- Как поймем через полгода, что проект сработал?
Процесс:
- Нужно ли вообще автоматизировать процесс в его нынешнем виде?
- Какие этапы можно убрать?
- Какие действия должен перестать делать человек?
- Не создаем ли мы цифровую копию старой бюрократии?
ИТ-ландшафт:
- Какие системы затронет новый продукт?
- Сколько интеграций потребуется?
- Где находится источник истины для каждого типа данных?
- Что придется доработать в существующих системах?
- Что будет, если одна из интеграций перестанет работать?
Деньги:
- Посчитана стоимость разработки или полная стоимость владения?
- Учтены ли миграция данных, инфраструктура, интеграции и обучение?
- Как будет финансироваться поддержка?
- Кто будет развивать систему после первого релиза?
- Сколько решение будет стоить компании через три года?
Технология:
- Почему выбран именно этот класс решений?
- Смотрели ли мы альтернативы?
- Нужна ли собственная разработка?
- Можно ли доработать существующий продукт?
- Нужно ли действительно полностью переписывать legacy?
- Можно ли сначала проверить гипотезу на пилоте?
Риски:
- Что произойдет при пиковой нагрузке?
- Как работает система при частичной недоступности сервисов?
- Есть ли план поэтапной миграции и возможность отката?
- Учтены ли требования информационной безопасности в архитектуре, а не только перед релизом?
- Какие данные система получает и можно ли им доверять?
Пользователи:
- Участвовали ли реальные сотрудники или клиенты в проверке сценариев?
- Станет ли им проще выполнять задачу?
- Не придется ли пользоваться старой и новой системой одновременно?
- Как мы измерим реальное использование продукта после запуска?
Если на значительную часть этих вопросов пока нет ответа, возможно, компании еще рано проводить тендер на разработку.
Иногда первым этапом должен стать не дизайн приложения и не оценка программистами количества часов, а обследование: разбор процессов, архитектуры, интеграций, данных, технического долга, требований безопасности и экономики будущего решения.
Такой этап тоже стоит денег. Но его задача как раз в том, чтобы не выяснять самые дорогие особенности проекта тогда, когда контракт уже подписан, команда работает, а половина бюджета потрачена.
Цифровизация обходится дорого не только тогда, когда разработчики ошибаются в коде. Гораздо больше денег можно потерять раньше: выбрать не ту задачу, не посчитать владение, добавить еще одну систему в уже сложный ландшафт или автоматизировать процесс, который стоило сначала переделать.
И чем крупнее проект, тем дороже становится вопрос, который бизнес не задал себе на старте.
