Если десять лет назад спросить у генерального директора крупной российской компании, как техническая архитектура влияет на прибыль бизнеса, ответ, скорее всего, был бы довольно расплывчатым. Технологии воспринимались как обслуживающая функция. Есть бухгалтерия, есть производство, есть продажи, а где-то рядом существует IT-департамент, который "поддерживает серверы" и иногда пишет новые системы.
Сегодня эта модель больше не работает.
После массовой цифровизации бизнеса, импортозамещения, ухода иностранных вендоров и постоянного роста требований к скорости вывода новых продуктов технологии перестали быть вспомогательным подразделением. Они стали частью финансовой модели компании. Решения, которые принимает CTO, всё чаще напрямую отражаются в отчёте о прибылях и убытках.
И это касается не только продуктовых компаний вроде банков, маркетплейсов или экосистем.
Промышленность, энергетика, логистика, строительство, ритейл — практически любая крупная организация сегодня зависит от программного обеспечения настолько сильно, что одна архитектурная ошибка способна повлиять на годовой финансовый результат.
Именно поэтому в российских компаниях постепенно меняется сама роль технического директора. Если раньше CTO отвечал преимущественно за стабильность инфраструктуры и качество разработки, то теперь он всё чаще становится полноценным участником обсуждения финансовой стратегии бизнеса.
В инженерной среде любят обсуждать микросервисы, Kubernetes, event-driven архитектуру, очереди сообщений, CI/CD, DevOps, контейнеризацию и десятки других технических тем.
Проблема заключается в том, что подобные обсуждения часто ведутся в полном отрыве от экономики компании. Между тем любое техническое решение обладает своей стоимостью владения.
Допустим, команда принимает решение перейти на микросервисную архитектуру. С инженерной точки зрения всё выглядит убедительно: независимые сервисы, масштабируемость, отказоустойчивость. Однако одновременно увеличивается количество инфраструктуры, возрастает стоимость сопровождения, появляются новые требования к мониторингу, логированию, DevOps-компетенциям и поддержке.
С точки зрения P&L это означает рост операционных расходов.
Другой пример.
Компания принимает решение написать собственный сервис вместо покупки готового решения. Первоначально инвестиции оказываются выше, зато спустя несколько лет появляется экономия на лицензиях, большая независимость от поставщиков и возможность быстрее развивать продукт.
Снова речь идёт уже не о программировании, а идёт о капитальных вложениях, операционных расходах, сроках окупаемости инвестиций и будущей прибыльности бизнеса.
Именно поэтому Gartner всё чаще рекомендует рассматривать архитектурные инициативы через призму создаваемой бизнес-ценности, а не исключительно технологического совершенства. Для руководства важнее понимать, как изменится финансовый результат компании, чем узнать, какой стек использовала команда. Аналогичную позицию сегодня занимают McKinsey и Deloitte, связывая зрелость технологических решений с ростом EBITDA, производительности и скоростью вывода продуктов на рынок.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
Интересно наблюдать, как компании продолжают считать стоимость разработки исключительно через зарплаты инженеров. На практике основные потери возникают совершенно в других местах.
Система, которую сложно сопровождать, постепенно начинает требовать всё больше ресурсов. Каждый новый релиз становится дороже предыдущего. Любое изменение сопровождается риском регрессии. Команда начинает больше времени тратить на поддержку существующего функционала, чем на развитие продукта.
В финансовой отчётности эти процессы не отображаются отдельной строкой, но они прекрасно видны в динамике расходов:
Стоимость одного релиза увеличивается.
Производительность инженерной команды снижается.
Появляется технический долг.
Увеличивается текучесть разработчиков.
Растут расходы на найм новых специалистов.
Отложенные архитектурные проблемы постепенно превращаются в реальные финансовые обязательства.
На российском рынке эта ситуация особенно заметна после 2022 года. Многие компании были вынуждены ускоренно переходить на отечественные решения, перестраивать инфраструктуру и заменять зарубежные сервисы. Там, где архитектура изначально проектировалась с учётом независимости компонентов, миграция проходила относительно спокойно. Там же, где система представляла собой набор тесно связанных решений, стоимость изменений оказалась кратно выше ожидаемой.
Получается любопытный парадокс.: технический долг редко появляется в бухгалтерском балансе, но именно он способен незаметно ухудшать P&L на протяжении нескольких лет.
В IT-компании GreenCore подход к архитектурным решениям постепенно изменился по мере роста сложности проектов. Если раньше обсуждение строилось вокруг производительности, отказоустойчивости или выбора технологий, то сегодня CTO предлагает смотреть значительно шире.
Перед стартом проекта команда задаёт вопрос не только "как реализовать систему", но и "какое влияние выбранная архитектура окажет на экономику заказчика через два-три года".
Этот подход особенно хорошо проявился в проектах для крупных корпоративных клиентов.
Например, при реализации системы автоматизации согласования товарных позиций для «Газпром недра» задача заключалась не просто в ускорении внутренних процессов. Архитектурные решения принимались с расчётом на снижение операционных затрат, уменьшение времени согласования и сокращение стоимости каждой последующей доработки системы. Итогом стало ускорение бизнес-процессов на 43%, но не менее важным результатом стало снижение стоимости владения системой в долгосрочной перспективе.
Похожая логика применялась и при реализации проекта КОНКОРД, где итерационная архитектура внедрения позволила отказаться от масштабного единовременного запуска. Вместо этого заказчик начал получать экономический эффект значительно раньше, а финансовые риски распределились между несколькими этапами проекта.
Если новый сервис уменьшает стоимость эксплуатации — это инвестиция.
Если интеграция сокращает ручной труд — это инвестиция.
Если изменение архитектуры уменьшает вероятность дорогостоящих простоев — это тоже инвестиция.
Именно поэтому в GreenCore технические решения постепенно начинают обсуждаться на языке финансовых показателей, понятных собственникам бизнеса.
Российский рынок постепенно движется к модели, в которой технический директор перестаёт быть исключительно руководителем инженерной функции.
Он становится человеком, который способен объяснить совету директоров, почему одно архитектурное решение принесёт компании дополнительные десятки миллионов рублей, а другое, наоборот, создаст постоянный источник расходов.
Чем сложнее становятся цифровые продукты, тем теснее переплетаются технологии и экономика. Невозможно эффективно управлять разработкой, если не понимаешь структуру затрат бизнеса. Точно так же невозможно строить долгосрочную финансовую стратегию компании, игнорируя архитектурные ограничения информационных систем.
В ближайшие годы эта связь станет ещё сильнее. Искусственный интеллект, автоматизация, импортонезависимые платформы, распределённые архитектуры и новые требования к информационной безопасности будут увеличивать стоимость технических решений. Вместе с этим будет расти и цена ошибок.