Скрытые ИТ-риски, о которых СЕО узнает слишком поздно

За последние годы ИТ перестал быть просто поддерживающей функцией и превратился в главную движущую силу. Реальная жизнеспособность компании начинает полностью зависеть от изнанки ИТ-производства — процессов и скрытой архитектуры. Настоящая ценность на рынке создается вокруг здорового ландшафта, который сможет выдержать масштабирование, интеграционную нагрузку и внедрение ИТ-решений без постоянных сбоев и колоссальных переплат за инфраструктуру. О том, как руководителю контролировать эту невидимую часть технологий и скрытые риски, рассказывает директор Nord Clan Алексей Артамонов.

Риск 1: Увлечение технологиями без понимания бизнес-эффекта 

Один из самых распространенных рисков последних лет связан с ИИ. Иногда компании внедряют универсальных ИИ-ассистентов и автономных ИИ-агентов, запускают пилотные решения  еще до того, как появляется понимание, какую конкретную задачу они должны решать и как будет измеряться результат. Если ИИ-решение не встроено в процесс, нет понятных метрик эффективности и структурированных данных, четкой архитектуры и контроля, проект может легко превратиться в демонстрацию возможностей ИИ, а не в рабочий инструмент. 

В нашей практике самый рабочий тренд сейчас — прикладные сценарии ИИ: контроль качества, обработка обращений, интеллектуальный поиск по базе знаний, автоматизация HR и сервисных процессов, а также прогнозирование отклонений. Именно такие проекты проще масштабируются и быстрее начинают приносить измеримый результат. Чтобы минимизировать этот риск, при запуске ИИ-проектов важно заранее определять, с какими операционными процессами они связаны и по каким метрикам будет оцениваться их результат. 

Риск 2: Запуск разработки без выстроенных базовых процессов

Запуск разработки без выстроенных базовых процессов — одна из самых распространенных скрытых ошибок. Любая инициатива должна сначала дойти до понятного состояния: что именно меняется в процессе, где это происходит и за счет чего должен появиться эффект. Если этого нет, разработка неизбежно превращается в уточнение требований по ходу, а результат может не соответствовать ожиданиям. Дальше важно определить, как вообще появляются и отбираются задачи. Если нет понятного порядка приоритизации, команда начинает работать в режиме постоянных переключений. 

Проекты конкурируют друг с другом за ресурсы без связи с бизнес-целями. 

Отдельно стоит вопрос данных. До старта должно быть понятно, откуда они берутся, кто за них отвечает и можно ли на них опираться. В противном случае система быстро начинает использовать разные версии информации, и любые решения становятся спорными. Параллельно задаются базовые ограничения по архитектуре — рамки, которые не дают системе разрастаться хаотично. Наконец, важно заранее определить, как будет приниматься результат. Минимизировать этот риск позволит внедрение жесткого регламента, запрещающего выделять бюджет на разработку до тех пор, пока проект не пройдет стадии описания целевого процесса, проверки источников данных и фиксации рамок архитектуры.

Риск 3: Использование архитектуры, не приспособленной к изменениям

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

В российском контексте к этому добавляется импортозамещение. Если архитектура была построена вокруг одного зарубежного вендора и закрытых связей, переход на отечественные решения превращается не в замену продукта, а в полноценную пересборку процессов. На практике даже относительно стандартный корпоративный контур — ERP, CRM, внутренние сервисы, аналитика, системы управления доступом и кибербезопасности — со временем может стать негибким, если архитектура изначально не учитывает масштабирование и развитие интеграций. Основная проблема таких архитектур заключается в низкой гибкости: любое изменение требует больших усилий и запуска отдельного проекта, а не точечной доработки. В результате компания теряет способность быстро адаптировать ИТ-ландшафт под новые задачи и ограничения.

Для минимизации этого риска руководителю следует провести аудит текущих систем и при формировании ИТ-стратегии учитывать требования к совместимости, возможностям доработки и открытости API там, где это действительно критично для бизнеса. 

Риск 4: Резкое увеличение сложности эксплуатации ИТ-систем

При внедрении новых систем компании чаще всего недооценивают не саму технологию, а то, как она будет встраиваться в существующий контур. Бизнес обычно смотрит на интерфейс и функциональность, но ключевой вопрос — как решение будет обмениваться данными с ERP, CRM, производственными, складскими и финансовыми системами. Когда таких связей становится много, резко растет сложность эксплуатации. Увеличивается количество точек доступа, зависимостей и сценариев отказа, а вместе с этим требования к кибербезопасности, управлению доступами, мониторингу и устойчивости системы. Накопление таких связей постепенно выходит за рамки проектной логики и начинает негативно влиять на ежедневную работу ИТ-ландшафта в целом. Управление системой становится сложнее не на уровне отдельных компонентов, а на уровне всей архитектуры. 

Чтобы снизить нагрузку на эксплуатацию и избежать роста сложности, при внедрении нового ПО рекомендуем заранее оценивать, как оно будет интегрироваться в существующий IT-ландшафт, а также какие ресурсы потребуются для его дальнейшей поддержки и мониторинга. 

Риск 5: Ориентация на текущий объем вместо масштабирования 

Одна из самых частых проблем цифровых проектов — ориентация на текущий объем вместо сценария дальнейшего роста. Если архитектура изначально не рассчитана на рост пользователей, данных или функциональности, она начинает ломаться при масштабировании и требует переработки. В результате, появляются простои, сбои в операциях и дополнительные финансовые траты. 

Особенно часто это проявляется в проектах, которые стартуют через MVP или пилот. На этапе тестирования решение может работать стабильно: с ограниченным объемом данных, ручными операциями и упрощенными интеграциями. Такой подход позволяет быстро проверить гипотезу и показать первый результат бизнесу. Однако при переходе к полноценной эксплуатации именно эти допущения начинают превращаться в узкие места.

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

Отдельная проблема — экономика масштабирования. Решение может показывать хороший результат на небольшом объеме, но при росте пользователей, транзакций или данных резко увеличивает стоимость инфраструктуры и поддержки. В этот момент проект начинает постепенно снижать тот эффект, ради которого запускался.

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

На практике снизить этот риск помогает предварительная оценка сценария промышленной эксплуатации еще до запуска проекта: предполагаемой нагрузки, требований к интеграциям, роста объема данных и стоимости дальнейшей поддержки системы. Так мы можем заранее понять, насколько решение готово к масштабированию без серьезной пересборки отдельных компонентов.

Риск 6: Привлечение внешнего подрядчика без специфического корпоративного опыта

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

Отдельно рекомендуем смотреть на скорость входа в проект. Если команда долго подбирается и погружается в контекст, проект начинает тормозить уже на старте. Рабочий формат когда подрядчик подключается через архитектора и тимлида, быстро собирает команду и берет на себя управление. Еще один важный момент — опыт работы с проблемными проектами. В реальности значительная часть задач — это не разработка с нуля, а ситуации, где уже есть наработки, срывы сроков или неработающие решения. Подрядчик должен уметь быстро провести аудит, понять причины и перезапустить процесс, а не просто продолжить разработку. Минимизировать риск найма неподходящей команды можно путем включения в тендерную документацию обязательных требований к подрядчику по наличию кейсов в вашей отрасли, опыта прохождения корпоративных ИБ-проверок и готовности предоставить команду архитекторов для экспресс-аудита в течение первой недели.