GreenCore 
Тендеры и лиды
Информация
Когда компания задумывается о развитии IT, разговор довольно часто начинается одинаково: нужно перейти на микросервисы, внедрить Kubernetes, построить Data Lake, мигрировать в облако, заменить устаревшую ERP или добавить искусственный интеллект. У каждого такого решения есть аргументы в пользу внедрения, презентации вендоров и успешные примеры использования на рынке. Проблема в том, что наличие перспективной технологии ещё не означает, что именно она нужна конкретному бизнесу.
Можно построить современную инфраструктуру, перейти на актуальный стек, внедрить несколько платформ и при этом не решить ни одной из проблем, которые мешают компании развиваться. Согласования по-прежнему занимают недели, данные остаются разрозненными, сотрудники продолжают вручную переносить информацию между системами, а выпуск новых функций не становится быстрее. В результате бизнес получает дополнительные расходы на лицензии, интеграцию и поддержку, но не получает ожидаемого эффекта.
Мы в GreenCore считаем, что техническая стратегия должна начинаться не с вопроса «какие технологии нам внедрить?», а с другого: «какие возможности должен получить бизнес и что сегодня мешает их реализовать?». Только после ответа на этот вопрос можно выбирать архитектуру, платформы и инструменты. Технологии должны быть следствием стратегии, а не её отправной точкой.
За последние несколько лет российский IT-рынок прошёл через масштабную трансформацию. После 2022 года многие компании были вынуждены в короткие сроки пересматривать технологическую инфраструктуру, искать замену зарубежным продуктам и обеспечивать непрерывность критически важных процессов. В такой ситуации выбор технологий часто определялся доступностью, сроками миграции и возможностью сохранить работоспособность существующих систем. Это было вполне рационально: в первую очередь требовалось закрыть риски, а уже потом думать о долгосрочной оптимизации.
Однако сейчас рынок постепенно переходит к следующему этапу. По данным обзора РБК от мая 2026 года, после периода активного импортозамещения российские компании всё чаще сталкиваются с задачей построения устойчивой и управляемой IT-среды из отечественных решений. По оценкам T1, темпы роста российского IT-рынка в 2025 году заметно замедлились относительно предыдущего года. При этом дальнейшее развитие связывают не столько с экстренной заменой отдельных продуктов, сколько с переходом к тиражируемым архитектурным решениям и управляемым сервисам.
Это принципиально меняет логику принятия решений. Если раньше компания могла выбирать систему исходя из того, какую зарубежную платформу необходимо заменить, то теперь ей приходится оценивать, насколько новое решение совместимо с остальной инфраструктурой, какова стоимость его владения, какие компетенции потребуются для поддержки и сможет ли оно выдержать дальнейшее развитие бизнеса. Формально импортозамещение может быть завершено, но если в результате компания получила несколько слабо связанных систем, дублирующие функции и сложные интеграции, говорить о полноценной технологической трансформации рано.
Исследование ИТ-холдинга T1 и ассоциации РУССОФТ, опубликованное в июне 2025 года, показало, что 54% крупных российских компаний включают миграцию на отечественные технологии в стратегию развития собственных информационных систем. Только 14% рассматривают импортозамещение исключительно как вынужденную реакцию на геополитические изменения. При этом среди основных препятствий для перехода участники исследования называли высокую стоимость продуктов, несовместимость с существующей инфраструктурой и недостаточную функциональную зрелость отдельных аналогов. Исследование охватило 78 российских компаний из промышленности, финансового сектора, торговли, IT и нефтегазовой отрасли.
Ещё один показательный результат приводит исследование «Инфосистемы Джет», опубликованное в сентябре 2025 года. Только 47% опрошенных компаний имели актуальную IT-стратегию. При этом архитектурный комитет или специализированный архитектор были лишь у 30% организаций. Авторы исследования также отмечали, что более 70% компаний привлекают внешних подрядчиков из-за нехватки внутренних ресурсов, а систематически собирают и используют обратную связь от бизнеса только 27% респондентов.
Эти цифры позволяют увидеть более глубокую проблему. Компаниям часто не хватает не отдельных технологий, а механизма, который связывает бизнес-приоритеты, архитектурные решения и инвестиции в IT. Когда такого механизма нет, выбор платформы может определяться личными предпочтениями технического руководителя, популярностью конкретного инструмента или предложением поставщика. В результате технологический ландшафт развивается фрагментарно: каждое подразделение решает свою локальную задачу, но общая система становится всё сложнее.
Поэтому на российском рынке сегодня особенно важно переходить от логики «заменить продукт» к логике «спроектировать целевую IT-среду». И это уже задача не только CIO или CTO, но и руководства компании. Техническая стратегия должна учитывать направление развития бизнеса, его операционную модель, требования к безопасности, экономику владения системами и способность инфраструктуры меняться вместе с организацией.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13836 тендеров
проведено за восемь лет работы нашего сайта.
Представим компанию, которая решила перейти на микросервисную архитектуру. Причина звучит убедительно: монолитная система стала сложной, разработка замедлилась, изменения затрагивают сразу несколько функциональных блоков. Руководство утверждает план миграции, выделяет бюджет, привлекает архитекторов и начинает разделять приложение на сервисы. Через некоторое время компания получает новую архитектуру, но скорость выпуска изменений практически не меняется. Более того, появляются дополнительные расходы на инфраструктуру, мониторинг, сетевые взаимодействия и поддержку распределённых компонентов.
Проблема здесь не в микросервисах. Они могут быть правильным решением для систем с определёнными требованиями к масштабированию, независимому развитию компонентов и организации команд. Ошибка заключается в том, что компания выбрала архитектурный инструмент до того, как сформулировала конкретную проблему и проверила, действительно ли выбранный подход её решает. Если причиной медленной разработки были не ограничения монолита, а отсутствие автоматизированного тестирования, сложные согласования и неуправляемый бэклог, переход на микросервисы сам по себе ничего не исправит.
Похожая ситуация возникает с облачными платформами. Компания может решить, что миграция в облако автоматически повысит гибкость и снизит расходы. Но если не определить профиль нагрузок, требования к доступности, ограничения по данным, модель резервирования и стоимость эксплуатации, результат может оказаться противоположным. Облако не гарантирует экономии: при неправильной архитектуре и отсутствии FinOps-практик расходы на инфраструктуру способны расти быстрее, чем нагрузка на систему.
То же самое относится к искусственному интеллекту, low-code-платформам, контейнеризации и другим технологическим направлениям. Они решают определённые классы задач, но не являются универсальными ответами на проблемы бизнеса. AI не исправит некачественные данные и не заменит неописанный процесс. Low-code не устранит архитектурную сложность автоматически. Контейнеризация не сделает приложение отказоустойчивым, если изначально не продуманы механизмы восстановления и управления состоянием.
В исследовании LDM «Корпоративная разработка в России 2025», основанном на 50 интервью и ответах более 100 специалистов, включая CIO, CTO и архитекторов, отдельно подчёркивается запрос на управляемую скорость разработки. Среди направлений, влияющих на неё, рассматриваются архитектура, CI/CD, автоматизированное тестирование и использование AI. Важен сам подход: эти инструменты рассматриваются как элементы единой инженерной системы, а не как независимые технологии, которые можно внедрять по отдельности ради соответствия трендам.
По нашему мнению, главный критерий хорошей технической стратегии — способность объяснить, какую конкретную проблему решает каждое крупное технологическое решение и как будет измеряться его эффект. Если на вопрос «зачем нам эта технология?» можно ответить только тем, что она современная, популярная или используется конкурентами, значит, решение ещё не обосновано.
В подходе CTO GreenCore работа над технической стратегией начинается с изучения бизнеса, а не с выбора стека. Сначала необходимо понять, какие цели стоят перед компанией на ближайшие годы, какие процессы критичны для её деятельности, где возникают основные операционные потери и какие ограничения IT мешают реализовать планы руководства. Важно смотреть не только на текущие запросы подразделений, но и на ожидаемые изменения: рост нагрузки, выход на новые рынки, расширение продуктовой линейки, увеличение количества пользователей или появление новых требований к безопасности.
На первом этапе проводится оценка существующего IT-ландшафта. Нужно разобраться, какие системы используются, какие данные между ними передаются, где существуют дублирующие функции, какие интеграции критичны и насколько дорого обходится сопровождение. Отдельно оцениваются архитектурные ограничения, технический долг, кадровые зависимости и риски, связанные с устаревшими компонентами. Результатом должна стать не просто инвентаризация программного обеспечения, а понимание того, какие элементы инфраструктуры помогают бизнесу развиваться, а какие уже создают ограничения.
На втором этапе определяются целевые возможности. Здесь важно описывать не технологии, а изменения, которые компания хочет получить. Например, не «внедрить новую CRM», а обеспечить единую историю взаимодействия с клиентами и исключить дублирование данных между подразделениями. Не «перейти на микросервисы», а сократить время выпуска независимых функциональных изменений и снизить влияние доработок одного модуля на остальные. Не «внедрить AI», а сократить время обработки обращений, автоматизировать классификацию документов или ускорить поиск информации в корпоративных базах знаний.
После этого CTO может переходить к архитектурным принципам. На этом уровне определяются требования к интеграциям, управлению данными, безопасности, масштабируемости, отказоустойчивости и сопровождению. Только теперь появляется основание выбирать конкретные технологии. Причём выбор должен учитывать не только функциональность, но и совокупную стоимость владения, наличие специалистов на рынке, зрелость экосистемы, совместимость с существующими решениями, возможности миграции и зависимость от поставщика.
Следующий шаг — формирование дорожной карты. Техническую стратегию не стоит превращать в единый масштабный проект, который должен завершиться через несколько лет. Гораздо эффективнее разбить её на последовательные инициативы с понятным приоритетом и измеримым эффектом. Например, сначала устранить критические риски и наладить мониторинг, затем привести в порядок интеграции и качество данных, после этого модернизировать наиболее проблемные компоненты и только затем переходить к более масштабным архитектурным изменениям. Такой подход позволяет получать результат постепенно и корректировать план по мере изменения бизнес-приоритетов.
При этом CTO должен постоянно проверять, не превратилась ли сама дорожная карта в набор технических задач, оторванных от бизнеса. У каждой инициативы должны быть владелец, обоснование, ожидаемый эффект, оценка затрат и критерии успешности. Если проект перестал соответствовать текущим целям компании, его необходимо пересмотреть, даже если на него уже потрачены значительные ресурсы. Техническая стратегия не должна быть документом, который один раз утвердили и больше не открывают. Это рабочий механизм принятия решений.
Именно здесь проявляется роль CTO как связующего звена между бизнесом и инженерной командой. Он должен уметь объяснить руководству, почему определённое изменение необходимо, какие риски возникнут при его откладывании и как инвестиции в инфраструктуру повлияют на экономику компании. При этом важно не перегружать CEO техническими деталями. Для управленческого решения гораздо полезнее знать, что модернизация интеграционного контура сократит время подключения новых систем и уменьшит расходы на поддержку, чем разбираться в конкретных версиях брокеров сообщений или фреймворков.
Техническая стратегия имеет смысл только тогда, когда её результаты можно измерить. При этом не существует универсального набора метрик, который одинаково подходит банку, производственной компании, ритейлу и IT-продукту. Показатели должны отражать те изменения, ради которых принимались архитектурные решения.
Если задача заключалась в ускорении разработки, стоит отслеживать время от постановки задачи до выхода изменения в продуктивную среду, частоту релизов, долю неудачных изменений и время восстановления после инцидентов. Если целью было повышение надёжности, важны доступность критичных систем, количество повторяющихся сбоев и время восстановления. Если компания занималась интеграцией данных, необходимо оценивать полноту и корректность обмена, количество дублирующихся записей и объём ручных операций. Если речь шла об автоматизации, нужно измерять продолжительность процесса, количество ошибок, стоимость выполнения операции и нагрузку на сотрудников.
В проектах GreenCore мы также рассматриваем результат через изменение бизнес-процессов, а не через перечень реализованных функций. Например, в проекте для «Газпром недра» работа была направлена на улучшение процесса согласования продуктовых позиций. По итогам реализации среднее время согласования сократилось на 43% — с 5,6 до 3,2 рабочего дня, а количество возвратов на доработку уменьшилось на 38%. Эти показатели важны не потому, что демонстрируют использование определённой технологии, а потому, что показывают изменение конкретного процесса.
Другой пример — проект Nova Energy, в котором требовалось обеспечить более согласованную работу данных из шести HR-источников. Здесь ключевой задачей было не просто объединить базы, а добиться корректности данных и повысить устойчивость связанных процессов. В результате доля дублирующихся записей снизилась с 18% до менее 2%, количество ошибок в продуктивной среде сократилось на 37%, а цикл выпуска изменений — на 42%. Подобные результаты показывают, почему архитектурные и интеграционные решения необходимо оценивать через их влияние на работу компании.
Эти проекты не следует воспринимать как универсальный шаблон технической стратегии: у каждого бизнеса собственные ограничения, процессы и цели. Но они хорошо иллюстрируют принцип, которого мы придерживаемся в GreenCore: технология имеет ценность не сама по себе, а благодаря изменениям, которые она позволяет получить. Поэтому выбор инструментов должен быть связан с конкретными требованиями, а результат — проверяться на уровне процессов и показателей бизнеса.
В конечном счёте техническая стратегия не должна отвечать на вопрос, какой технологический стек будет использовать компания через три года. Она должна объяснять, какие возможности бизнесу понадобятся, какие ограничения необходимо устранить и каким образом IT поможет достичь поставленных целей. Технологии за это время могут измениться: появятся новые платформы, инструменты и архитектурные подходы. Если стратегия построена вокруг конкретного вендора или модного инструмента, компании придётся пересматривать её при каждом существенном изменении рынка. Если же она основана на бизнес-приоритетах, архитектурных принципах и измеримых результатах, выбор технологий можно адаптировать без потери общего направления.
Мы считаем, что зрелость CTO определяется не количеством внедрённых технологий и не сложностью архитектуры, которую удалось построить. Она определяется способностью выбрать минимально достаточное и устойчивое техническое решение для конкретной задачи бизнеса, предусмотреть его дальнейшее развитие и объяснить, зачем компании нужны именно такие инвестиции. Хорошая техническая стратегия начинается не с вопроса «на чём будем писать?», а с понимания того, что компания хочет изменить и почему без технологий этого не получится.
