KODE 
Тендеры и лиды
Информация
Автор статьи: Владимир Белозеров, заместитель коммерческого директора в ИТ-компании KODE.
Цифровизация должна помогать бизнесу сокращать издержки и работать быстрее. Но иногда получается наоборот: новая система требует дополнительных интеграций, доработок, миграции данных, инфраструктуры и постоянной поддержки. Разбираемся, где компании чаще всего ошибаются и что стоит проверить еще до старта проекта.
Российский бизнес продолжает увеличивать вложения в цифровизацию. По предварительной оценке ИСИЭЗ НИУ ВШЭ, затраты на развитие цифровой экономики в России в 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 млрд рублей. В выборку вошли предприятия промышленности, ритейла, ИТ и телекома, логистики. Почти в каждом втором случае компании обращались за повторным проектом или доработкой после предыдущего неудачного внедрения. Среди наиболее частых причин оказались недооценка стоимости владения, проблемы с интеграцией и неправильный выбор решения.
Разберем основные ошибки, из-за которых цифровизация может обойтись бизнесу значительно дороже, чем планировалось.
Сначала у компании появляется CRM. Потом ERP. Отдельно развивается мобильное приложение. Маркетинг внедряет систему лояльности, HR работает в своей системе, финансы — в своей. Следом появляются BI и AI-сервисы.
Каждый проект по отдельности выглядит вполне логично. У него есть заказчик, задача, бюджет и ожидаемый результат. Иногда все эти системы даже хорошо работают каждая сама по себе.
Проблема обнаруживается через несколько лет, когда становится понятно, что вместе они не складываются в единую систему.
Одни и те же данные хранятся в нескольких местах. У одного клиента появляются разные ID. Часть информации передается автоматически, другую сотрудники переносят руками. Чтобы добавить новую функцию в мобильное приложение, приходится менять сразу три внутренних сервиса. А замена CRM внезапно затрагивает продажи, приложение, аналитику и программу лояльности.
Так постепенно возникает тот самый зоопарк ИТ-систем.
В III Всероссийском опросе по цифровой трансформации Comindware, Artezio и РУССОФТ 60% участников сообщили, что реализуют отдельные проекты цифровизации, но не имеют общей стратегии. Еще 18% заявили, что такой стратегии у них нет вообще. 80% компаний используют разрозненные интеграции между информационными системами, и лишь 12% работают в единой цифровой среде.
У такого подхода вполне измеримые последствия.
К2Тех опросил более 300 руководителей и ИТ-специалистов средних и крупных российских компаний. 68% респондентов сообщили, что из-за зоопарка решений не могут получить целостную картину данных. 47% сталкиваются с высокими скрытыми расходами на поддержку разрозненных систем, еще 33% говорят о техническом долге, который мешает дальнейшему развитию.
Проблема не в самом количестве программ. У крупного бизнеса их в любом случае будут десятки или сотни. Важно другое: как они связаны между собой и понимает ли компания, каким должен стать ее ИТ-ландшафт через несколько лет.
Допустим, отделу продаж действительно нужна новая система. Но кроме вопроса «решает ли она нашу текущую задачу?» стоит задать еще один: «что произойдет с остальной инфраструктурой после ее появления?»
Новая система может дать заметный локальный эффект сегодня, но одновременно сильно увеличить стоимость любых изменений завтра.
Еще до выбора решения стоит хотя бы на верхнем уровне понимать:
какие существующие системы новый продукт заменит, а какие дополнит;
какие данные он будет получать и куда передавать;
где будет храниться мастер-версия данных;
сколько дополнительных интеграций понадобится;
не появится ли еще одна копия уже существующей информации;
от каких систем и подрядчиков будет зависеть продукт;
можно ли будет заменить его через несколько лет без перестройки половины ИТ-ландшафта.
Здесь полезно иметь архитектурную схему не только текущего состояния, но и целевого. Иначе цифровой контур компании формируется не по заранее продуманному плану, а просто потому, что новые проекты запускались один за другим.
«Запустить CRM до декабря» звучит как цель. «Разработать мобильное приложение» тоже.
Как и «автоматизировать оформление заказа», «внедрить AI» или «перевести сотрудников в новую систему».
Но все это цели проекта, а не бизнеса.
Русская школа управления в 2025 году опросила руководителей и HR-специалистов российских компаний. 55% назвали одним из основных барьеров цифровизации высокую стоимость внедрения. На втором месте оказался более показательный ответ: 35% не понимают эффекта от цифровых решений. Еще 29% указали на сопротивление сотрудников, 27% — на недостаток компетенций руководителей, 26% — на сложности ИТ-инфраструктуры.
Проблема обычно становится очевидна после релиза. Проект закончили. Систему запустили. Но как понять, что несколько миллионов рублей были потрачены не зря? Если до начала проекта компания не измерила текущий процесс, ответить на этот вопрос бывает сложно.
Например, смысл нового личного кабинета может заключаться вовсе не в том, что у компании появился еще один цифровой канал. Его задача может быть в том, чтобы больше клиентов самостоятельно решали свои вопросы и реже обращались в поддержку.
Цель автоматизации документооборота может состоять в том, чтобы сократить согласование с пяти дней до одного.
Новый внутренний сервис может быть нужен для того, чтобы операция, на которую сотрудник тратил 20 минут, занимала пять.
А для мобильного приложения главным показателем может быть вовсе не количество установок, а доля пользователей, дошедших до покупки, или снижение нагрузки на офлайн-каналы.
Поэтому еще до начала разработки полезно зафиксировать три вещи:
Что происходит сейчас. Например, обработка одной заявки занимает 40 минут.
Какой результат хотим получить. Например, сократить это время до 15 минут.
Как и когда будем измерять результат.
Без исходной точки сравнения можно получить красивый продукт, хорошие отзывы команды и при этом не иметь ни одного доказательства, что бизнес действительно стал работать лучше. /
Еще хуже, если в качестве KPI цифровизации используются исключительно технические показатели.
Количество функций, число релизов или процент готовности проекта почти ничего не говорят о результате для бизнеса. Система может быть разработана без критичных ошибок, запущена вовремя и полностью соответствовать техническому заданию, но при этом остаться неудачным бизнес-проектом.
Это одна из наиболее понятных ошибок, потому что ее легко увидеть в деньгах.
В исследовании ОБИТ 61% проблемных проектов были связаны с тем, что компании недооценили стоимость владения ИТ-решением. В бюджет не полностью закладывали интеграции, дальнейшую поддержку и обучение сотрудников. В 48% случаев возникали проблемы с интеграцией в существующую инфраструктуру, а в 35% выбранное решение не соответствовало реальным требованиям бизнеса.
По оценке ОБИТ, доработка и исправление ошибок после неудачного внедрения могут потребовать еще 10–30% первоначального бюджета. В отдельных случаях перезапуск проекта требует сопоставимых с первоначальными затрат или даже вдвое больших вложений.
Поэтому если компания говорит, что внедрение стоит 15 млн рублей, полезно уточнить: что именно входит в эту сумму?
Только разработка?
Разработка и лицензии?
А интеграции?
Миграция данных?
Доработка существующих систем?
Инфраструктура?
Информационная безопасность?
Переходный период, когда старая и новая системы работают одновременно?
Обучение сотрудников?
Поддержка?
Развитие продукта через год?
Рабочее время сотрудников заказчика, которые будут участвовать во внедрении?
Цифровой продукт редко перестает потреблять деньги в день релиза. Поэтому сравнивать варианты только по стоимости разработки малоэффективно.
Условный проект может выглядеть так:
15 млн рублей — разработка и внедрение;
еще 2 млн — доработка интеграций;
1,5 млн — подготовка и миграция данных из смежных информационных систем;
1 млн — переход и обучение сотрудников;
2,5 млн — поддержка и развитие в первый год.
В результате получается уже 22 млн вместо первоначальных 15 млн. Это не среднерыночный расчет и не прогноз для любого проекта. Это лишь пример того, насколько могут отличаться «стоимость разработки» и «сколько бизнес в итоге потратил на изменение».
Поэтому разумнее заранее считать совокупную стоимость владения — TCO — хотя бы на несколько лет вперед.
Иногда продукт, который дороже купить и внедрить, оказывается дешевле в дальнейшей эксплуатации.
А недорогое коробочное решение через пару лет может обрасти таким количеством доработок, что его поддержка превращается в отдельную заметную статью расходов.
Несколько лет назад бизнес массово хотел блокчейн. Сейчас хочет AI. Между ними были супераппы, low-code, микросервисы и другие технологические тренды. Но фраза «нам нужно внедрить AI» сама по себе ничего не говорит о задаче компании. То же самое касается CRM, ERP, мобильного приложения или отечественной замены зарубежного продукта.
В анализе ОБИТ 35% проблемных внедрений были связаны с тем, что выбранное решение не соответствовало фактическим требованиям бизнеса. Среди причин компания отмечает недостаточное тестирование до внедрения и незрелость самого продукта.
Особенно ярко эта проблема проявилась в период импортозамещения.
Т1 и РУССОФТ исследовали 78 российских компаний с фокусом на крупный бизнес. Среди серьезных препятствий при переходе на отечественные продукты участники называли высокую стоимость новых решений, проблемы совместимости с текущей инфраструктурой и недостаточную функциональную зрелость некоторых российских аналогов.
При этом 54% респондентов уже включают миграцию на российские технологии в стратегию развития собственных информационных систем. Только 14% считают импортозамещение исключительно вынужденной реакцией на внешние обстоятельства.
В исследовании РБК и Ростелекома среди 308 руководителей российских компаний 36,7% назвали одной из проблем импортозамещения интеграцию отечественных решений с существующими системами, еще 32,5% — длительные сроки внедрения.
Поэтому даже задача «заменим зарубежную систему российской» может быть сформулирована слишком узко. Если компания все равно меняет критичную часть ИТ-ландшафта, стоит сначала проверить, нужен ли ей точный цифровой аналог старой системы и старого процесса.
За годы работы мог измениться сам бизнес. Некоторые этапы стали лишними. Часть функций старой системы могла перестать быть нужна. Поэтому последовательность лучше выстраивать так:
проблема → целевой процесс → требования → ограничения текущей архитектуры → возможные варианты решения → выбор между готовым продуктом, доработкой и собственной разработкой.
Не обязательно каждый раз создавать новую систему с нуля. И не обязательно сразу распространять выбранное решение на всю компанию. Если технология новая, интеграций много, а процессы критичны для бизнеса, пилот часто обходится гораздо дешевле полноценного запуска.
На небольшой группе пользователей можно проверить реальные сценарии, производительность, интеграции и ограничения продукта. Это намного безопаснее, чем обнаружить проблемы после миграции нескольких тысяч сотрудников.
После анализа проблемных проектов ОБИТ также рекомендует предварительное тестирование и пилотирование, а миграцию критичных систем — проводить поэтапно.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13752 тендера
проведено за восемь лет работы нашего сайта.
Когда компания готовит требования к новой системе, проще всего взять текущий процесс и просто перенести его в цифру.
Есть пять этапов согласования? Значит, в новой системе будет пять этапов.
Сотрудник четыре раза вводит одинаковые данные? Сделаем для него четыре удобные формы.
Раньше документ отправляли руководителю по почте? Теперь появится кнопка «Отправить руководителю».
Технически это цифровизация. Но сам процесс практически не изменился.
Показательный пример есть в финансовом секторе.
В исследовании Ассоциации ФинТех при участии К2Тех 70% компаний сообщили, что во время трансформации ИТ-архитектуры провели аудит и пересмотр значительной части бизнес-процессов. Более 80% организаций отметили положительные результаты такой перестройки: повышение эффективности, рост гибкости, создание базы для дальнейшего развития и работу с накопившимся техническим долгом.
Конечно, опыт финансовой отрасли нельзя автоматически переносить на весь российский бизнес. Но сам принцип важен: смена технологии становится поводом пересмотреть процесс, а не просто скопировать его в новую систему.
До начала автоматизации полезно буквально нарисовать текущий процесс: что делает клиент, что делает сотрудник и что делает система.
Затем нарисовать целевой процесс.
И для каждого действия задать вопрос: зачем оно вообще существует?
Почему заявка должна пройти три согласования?
Почему данные снова вводятся вручную?
Почему менеджер переносит информацию из одной системы в другую?
Почему человек принимает решение, которое полностью определяется набором формальных правил?
Почему клиент заполняет данные, которые компания уже о нем знает?
Какие этапы после цифровизации должны не просто ускориться, а исчезнуть совсем?
Если раньше сотрудник заполнял Excel, а теперь вносит те же данные в новую корпоративную систему и на всякий случай продолжает вести прежнюю таблицу, эффект от такой цифровизации довольно ограничен.
На презентации новый цифровой продукт обычно выглядит автономно. Красивые экраны мобильного приложения. Новый личный кабинет. CRM. Внутренняя платформа. В настоящей ИТ-инфраструктуре почти ничего не существует отдельно.
Мобильному приложению нужно получить данные пользователя из одной системы, остатки — из другой, цены — из третьей, историю заказов — из четвертой, провести платеж через внешнего провайдера, а затем вернуть результат операции в ERP. И здесь начинается та часть проекта, которую бизнес не всегда видит на старте.
У ОБИТ проблемы с интеграцией стали причиной сложностей в 48% проанализированных проектов. Компания отмечает, что последствиями становились не только дополнительные расходы, но и риск остановки бизнес-процессов.
У Comindware 80% участников исследования используют разрозненные интеграции.
У К2Тех 74% опрошенных считают решением проблемы несогласованных данных сквозную интеграцию систем и создание единого контура управления данными. При этом бизнес не обязательно хочет полностью менять существующий ИТ-ландшафт: 46% компаний считают приоритетом оптимизацию текущих систем без масштабных инвестиций.
Поэтому еще до проектирования интерфейсов полезно нарисовать карту интеграций и данных.
Откуда приходит каждый тип информации?
Какая система является источником истины?
Кто может изменять данные?
Как часто происходит синхронизация?
Что будет, если в двух системах окажутся разные значения?
Что произойдет, если внешнее API не отвечает?
Что случится, если запрос случайно отправлен дважды?
Как система восстановит операцию после сбоя?
Кто заметит ошибку и кто будет ее расследовать?
Эти вопросы могут влиять на стоимость проекта значительно сильнее, чем количество экранов в интерфейсе.
Цифровизация ускоряет бизнес, но одновременно делает его сильнее зависимым от технологий. Если раньше недоступность одного сервиса мешала работе отдельного подразделения, после глубокой автоматизации тот же сбой может остановить всю цепочку операций.
КРОК в исследовании 70 ИТ-руководителей крупных и крупнейших российских компаний отметил, что в 2025 году заметно выросло внимание к резервированию и отказоустойчивости. Среди инфраструктурных проблем 36% респондентов называли отсутствие резервного ЦОДа, необходимость зеркалирования резервных копий, дублирования сетей и сервисов.
Поэтому тестировать нужно не только happy path, в котором все системы работают как задумано.
Что случится, если платежный сервис будет недоступен два часа?
Если упадет CRM?
Если внешняя система вместо одной секунды отвечает десять?
Если в Black Friday нагрузка увеличится в несколько раз?
Если мобильное приложение доступно, а один из внутренних сервисов — нет?
Хорошая архитектура предусматривает не только нормальную работу, но и управляемую деградацию. Пользователь по возможности должен сохранить хотя бы часть сценариев, а бизнес — понимать, как система вернется в штатное состояние после устранения проблемы.
Исследования показывают, что крупные российские компании называют соответствие высоким требованиям информационной безопасности одним из главных критериев при выборе ИТ-партнера, а кибербезопасность остается важным направлением ИТ-инвестиций.
Но безопасность влияет не только на выбор подрядчика.
Требования ИБ могут значительно менять:
архитектуру;
способы хранения данных;
авторизацию;
интеграции;
инфраструктуру;
стоимость разработки.
Если специалисты по безопасности подключаются только тогда, когда продукт почти готов, часть решений приходится переделывать.
Старой системе легко назначить роль главного виновника всех проблем. Релизы идут медленно, разработчики жалуются на монолит, документации мало, а за годы накопилось множество странных технических решений. Возникает логичное желание: давайте перепишем все с нуля и нормально. Иногда это действительно лучший вариант. Но возраст системы сам по себе еще не является бизнес-проблемой.
Опираясь на данные вышеупомянутых исследований, 78% российских компаний, которые используют облачные технологии, продолжают работать с legacy-системами. У 14% legacy составляет более половины ИТ-портфеля. 46% участников называют одним из приоритетов оптимизацию существующих систем без масштабных инвестиций. В исследовании КРОК более 30% респондентов говорили о необходимости обновления оборудования и работы с legacy.
Здесь нет противоречия. Потому что модернизировать старую систему можно по-разному.
Допустим, старое ядро работает стабильно, содержит критичную бизнес-логику и выдерживает необходимую нагрузку. Но интегрироваться с ним неудобно. В такой ситуации иногда дешевле и безопаснее сохранить ядро и построить вокруг него нормальный API-слой.
Если проблема находится в одном модуле — можно вынести только его.
Если система мешает независимым релизам — разделить наиболее проблемные компоненты.
Если стоимость поддержки высока из-за конкретной части кода — провести рефакторинг там, где это даст наибольший эффект.
Полная замена тоже возможна. Но тогда бизнесу стоит заранее понимать, что именно он получит за стоимость переписывания.
Будут ли быстрее выходить новые функции?
Снизится ли стоимость поддержки?
Исчезнут ли ограничения по нагрузке?
Станет ли проще находить разработчиков?
Снизятся ли риски безопасности?
Можно ли будет проще подключать новые продукты?
Если четкого ответа нет, проект «перепишем все с нуля» легко превращается в очень дорогой способ получить почти то же самое.
Особенно рискован подход big bang, когда старая система выключается, а новая должна одномоментно заменить абсолютно все ее функции.
Чем критичнее продукт для бизнеса, тем разумнее рассматривать поэтапную миграцию. Часть функций или пользователей переводится постепенно, а у команды остается возможность проверить новую систему на реальной нагрузке.
Иногда хороший результат технического аудита звучит не как «вам понадобится 30 млн рублей на новый продукт», а как «эту часть лучше вообще не трогать».
С распространением AI проблема качества данных стала еще заметнее. Можно купить хорошую систему прогнозирования, внедрить BI, подключить AI-ассистента или модель автоматического принятия решений.
Но если один клиент хранится сразу в трех системах под разными идентификаторами, справочники не совпадают, часть данных сотрудники вводят вручную, а происхождение показателя в отчете никто не может объяснить, новая технология проблему не исправит. Она просто будет работать с теми данными, которые получила.
51% компаний сохраняют внедрение AI среди ключевых приоритетов. При этом 68% респондентов говорят, что не могут получить целостную картину данных из-за разрозненного ИТ-ландшафта.
В исследовании КРОК качество исходных данных и отсутствие формальных регламентов названы среди факторов, которые мешают масштабировать технологические инициативы.
Отдельно Strategy Partners исследовала работу с данными на российских промышленных предприятиях.
В 56% компаний ручной ввод остается распространенным способом сбора данных. Только у четверти есть отдельное подразделение, которое занимается данными, еще в 36% выделен отдельный специалист по аналитике. Среди основных барьеров компании называют нехватку сотрудников, компетенций и технических ресурсов.
Для AI-проектов это особенно важно, потому что качество результата напрямую зависит от качества входной информации.
Поэтому до запуска стоит разобраться:
где хранится мастер-версия данных;
кто является их владельцем;
кто отвечает за качество;
есть ли дубли;
насколько данные полные и актуальные;
как обновляются справочники;
можно ли определить происхождение конкретного значения;
какую информацию нельзя использовать в выбранном AI-сценарии;
кто будет отвечать за ошибку, если автоматическая система примет неправильное решение.
Если сегодня компания имеет три разных значения одного показателя в трех системах, AI не сможет магически определить правильное. Скорее есть риск, что появится четвертый вариант.
Команда несколько месяцев или даже лет разрабатывает систему. Проходит приемка. Проект закрывается. В отчете появляется зеленый статус «внедрено».
Но сотрудники продолжают работать в Excel. Или часть информации переносят вручную. Или находят способы обходить новый процесс, потому что старый быстрее. Или системой пользуются, но время выполнения операций не изменилось.
Технический запуск еще не означает, что бизнес действительно изменился.
В исследовании Т1 и РУССОФТ сопротивление сотрудников новым системам отметили 79,5% представителей крупных компаний. В исследовании Русской школы управления об этой проблеме сообщили 29% респондентов.
Разница в цифрах значительная, потому что исследования охватывали разные аудитории и сценарии. Т1 и РУССОФТ изучали крупный бизнес и переход на отечественные продукты, РШУ шире рассматривала цифровизацию управленческих процессов.
Но оба исследования показывают одно: сама по себе новая технология не заставляет людей изменить привычный способ работы.
Здесь легко прийти к простому выводу: «значит, сотрудников нужно лучше обучать». Обучение действительно необходимо. Но сначала стоит проверить сам продукт.
Если раньше сотрудник выполнял пять действий, а после внедрения делает восемь, сопротивление может быть связано не с консерватизмом, а с неудобством новой системы.
Если новая программа работает медленнее прежней, сотрудник начнет искать обходной путь.
Если информацию нужно вводить и в старую, и в новую систему, Excel никуда не исчезнет.
Если продукт не учитывает реальные исключения из бизнес-процесса, сотрудники быстро построят вокруг него параллельную систему из почты, таблиц и мессенджеров.
Поэтому после релиза важно измерять не только технические показатели. Конечно, нужны uptime, число ошибок и SLA.
Но одновременно стоит следить:
какая доля сотрудников действительно работает в новой системе;
какую часть процесса они проходят в ней от начала до конца;
сколько ручных операций сохранилось;
сколько времени теперь занимает задача;
изменилась ли частота ошибок;
не ведут ли сотрудники параллельные таблицы;
как часто приходится обходить систему;
изменился ли бизнес-показатель, ради которого запускался проект.
Цифровизация заканчивается тогда, когда изменился сам процесс и бизнес получил измеримый результат.
Поэтому сложный цифровой продукт почти невозможно разработать один раз и забыть о нем.
Меняется бизнес. Возникают новые требования. Появляются интеграции, регуляторные ограничения и новая нагрузка.
Продукт должен развиваться вместе с ними.
Ошибки из этой статьи выглядят по-разному, но многие из них можно обнаружить еще до большой разработки. Перед запуском проекта стоит честно ответить хотя бы на несколько групп вопросов.
Какую проблему мы решаем?
Во сколько она обходится компании сейчас?
Какой бизнес-показатель должен измениться после запуска?
Знаем ли мы его текущее значение?
Как поймем через полгода, что проект действительно сработал?
Нужно ли вообще автоматизировать текущий процесс в его нынешнем виде?
Какие этапы можно удалить?
Какие действия после внедрения должен перестать выполнять человек?
Не создаем ли мы просто цифровую копию существующей бюрократии?
Какие существующие системы затронет новый продукт?
Сколько интеграций понадобится?
Где находится источник истины для каждого типа данных?
Что потребуется изменить в текущих системах?
Что произойдет, если одна из интеграций перестанет работать?
Мы посчитали только стоимость разработки или полную стоимость владения?
Учтены ли миграция данных, инфраструктура, интеграции и обучение?
Как будет финансироваться поддержка?
Кто продолжит развивать систему после первого релиза?
Во сколько решение обойдется компании через три года?
Почему выбрали именно этот класс решений?
Рассматривали ли альтернативы?
Действительно ли нужна собственная разработка?
Можно ли доработать уже существующий продукт?
Нужно ли полностью переписывать legacy?
Можно ли сначала проверить гипотезу с помощью пилота?
Что произойдет при пиковой нагрузке?
Как система поведет себя, если часть сервисов станет недоступна?
Есть ли план постепенной миграции и возможность отката?
Учтены ли требования информационной безопасности непосредственно в архитектуре, а не только перед релизом?
Какие данные получает система и можно ли им доверять?
Участвовали ли реальные сотрудники или клиенты в проверке сценариев?
Станет ли им действительно проще выполнять свою задачу?
Не придется ли одновременно пользоваться старой и новой системой?
Как будем измерять фактическое использование продукта после запуска?
Если на значительную часть этих вопросов пока нет ответа, возможно, компании еще рано проводить тендер на разработку.
Первым этапом может стать не дизайн интерфейса и не оценка количества часов разработки, а обследование: анализ процессов, архитектуры, интеграций, данных, технического долга, требований безопасности и экономики будущего решения.
Этот этап тоже требует денег. Но его задача именно в том, чтобы не обнаруживать самые дорогие особенности проекта тогда, когда договор уже подписан, команда работает, а половина бюджета потрачена.
Цифровизация дорого обходится бизнесу не только тогда, когда разработчики ошибаются в коде. Значительно больше денег можно потерять еще раньше: выбрать не ту задачу, не посчитать стоимость владения, добавить новую систему в и без того сложный ИТ-ландшафт или автоматизировать процесс, который сначала стоило пересмотреть.
И чем крупнее проект, тем дороже в итоге обходится вопрос, который бизнес не задал себе на старте.
