Дмитрий Важенин

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

С одной стороны баррикад находится финансовый департамент, который видит раздувающиеся счета и требует жесткой экономии. С другой — инженерные команды, которым для стабильной работы и запуска новых фич постоянно требуются новые мощности. А между ними — глухая стена взаимного непонимания.

Корневой конфликт: два разных языка

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

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

В результате такой размытой ответственности до 20-30% ИТ-бюджета компании буквально испаряются в никуда: круглосуточно работают серверы с 15%-й загрузкой, годами висят забытые тестовые среды и неиспользуемые диски. Классические методы финансового контроля бессильны: попытки «срезать косты» постфактум приводят лишь к сбоям в продукте и оттоку клиентов.

Принцип совместной ответственности

Чтобы остановить бессмысленное сжигание денег без заморозки развития, бизнесу нужны не перестановки в команде и штрафы, а новая культура управления ИТ-затратами — FinOps (Financial Operations).

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

Преодоление сопротивления: золотое правило FinOps

Инженерные команды чаще всего сопротивляются FinOps, потому что видят в нем очередную попытку ограничить их свободу. Чтобы успешно «продать» эту идею техническому департаменту, ИТ-директорам важно руководствоваться «золотым правилом» методологии.

Вместе с финансовой ответственностью давайте командам реальную свободу управлять своими бюджетами и лимитами.

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

Что в итоге получает каждая из сторон?

  • ИТ-команда уходит от рутины ручного сбора отчетов (который может занимать до одной рабочей недели) и получает инструмент осознанного самоконтроля.

  • Финансовый отдел избавляется от необходимости «выбивать» данные из технарей и видит абсолютную прозрачность расходов по всем подразделениям в режиме реального времени.

  • Руководство компании получает инструмент для точного долгосрочного планирования, полноценную юнит-экономику и уверенность в маржинальности бизнеса при масштабировании.

Три главные ошибки при изменении культуры

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

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

Анти-пример № 2: чрезмерный контроль, убивающий инновации. Попытка заставить разработчиков согласовывать покупку каждой виртуальной машины через сложную цепочку бюрократических одобрений уничтожает главное преимущество облаков — их гибкость и скорость (time-to-market). Зарегулированная команда просто перестанет создавать новые инновационные продукты. Поэтому фокусироваться надо не на контроле, а на прозрачности последствий от приобретения каждого ИТ-ресурса.

Анти-пример № 3: внедрение FinOps-платформы без изменения мышления. Купить специализированное ПО для FinOps-практик, настроить красивые дашборды и выгрузить отчеты — это лишь 10% дела. Если команды разработки не понимают своей финансовой ответственности и продолжают бросать включенными тестовые серверы, любая автоматизация останется лишь дорогой игрушкой.

Вместо вывода

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

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

Источник: