Field CTO по региону EMEA в Apptio, компании IBM, подчеркивает: для успешного расширения интеллектуальной автоматизации необходима финансовая дисциплина.
Подход "создай, и пользователи придут" часто приводит к бюджетным провалам при внедрении автоматизации. Руководители обнаруживают, что удачные пилотные проекты не переходят в полноценные корпоративные развертывания, поскольку начальное финансовое моделирование не учитывает реалии производства в масштабе.
Интеграция возможностей FinOps с автоматизацией меняет подход к управлению расходами: от реактивных мер к проактивной оптимизации ценности, отмечает эксперт.
Это меняет критерии оценки для технических руководителей. Вместо ожидания месяцев или лет для проверки ценности, команды инженеров отслеживают потребление ресурсов — например, стоимость за транзакцию или вызов API — с самого начала.
Экономика единичных затрат при масштабировании интеллектуальной автоматизации
Инновационные проекты имеют высокий уровень неудач. Около 80 процентов новых инициатив терпят крах, часто из-за отсутствия финансовой прозрачности на пилотной стадии, что скрывает будущие обязательства.
Если пилот показывает экономию, скажем, 100 часов в месяц за счет автоматизации процесса, руководство считает это успехом, поясняет эксперт. Однако при этом игнорируется тот факт, что пилот может работать на избыточно выделенной инфраструктуре, из-за чего результаты выглядят впечатляюще. В реальном производственном развертывании такую переполноценность не применяют.
Перевод нагрузки в продакшн меняет картину. Требования к вычислениям, хранилищам и передаче данных растут. Вызовы API умножаются, появляются исключения и граничные случаи в объемах, выходящих за рамки пилота, а затраты на поддержку тоже увеличиваются.
Чтобы избежать проблем, компании обязаны отслеживать предельные затраты в масштабе. Это значит мониторить экономику единичных затрат, такую как стоимость обслуживания клиента или транзакции. Если затраты на клиента растут с расширением базы, модель бизнеса ненадежна.
При эффективном масштабировании эти единичные затраты должны падать. Эксперт приводит пример Liberty Mutual: страховая компания сэкономила около 2,5 миллиона долларов, внедрив метрики потребления, а не ограничившись учетом только сэкономленных трудочасов.
Финансовая ответственность не может лежать только на плечах финансового отдела. Нужно вернуть управление разработчикам прямо в их инструменты и рабочие нагрузки.
Интеграция с инструментами инфраструктуры как кода, такими как HashiCorp Terraform и GitHub, позволяет внедрять политики на этапе развертывания. Команды создают ресурсы программно с мгновенной оценкой затрат.
Вместо развертывания и последующего исправления, что приводит к бесконечной борьбе с проблемами, компании проверяют правильность решений заранее, подчеркивает эксперт.
При масштабировании интеллектуальной автоматизации часто возникает конфликт между CFO, ориентированным на отдачу от инвестиций, и главой автоматизации, фокусирующимся на операционных метриках вроде сэкономленных часов.
TBM (Technology Business Management) и Apptio как раз решают эту проблему перевода, создавая общий язык между технологиями, финансами и бизнесом.
Таксономия TBM предлагает стандартизированную схему для согласования взглядов. Она отображает технические ресурсы (вычисления, хранилища, труд) в IT-башни и дальше в бизнес-функции, переводя техвходы в бизнес-выходы.
Пользователь бизнеса не вникает в IT-слои, но благодаря таксономии получает детальный счет за потребление сервисов и видит, какие именно затраты растут при увеличении нагрузки.
Работа с legacy-долгами и долгосрочное планирование бюджета
Компании с устаревшими ERP-системами стоят перед выбором: использовать автоматизацию как заплату или как мост к модернизации. Если просто маскировать неэффективные процессы без переработки, это только наращивает технический долг, предупреждает эксперт.
Подход с полным учетом стоимости владения (TCO) помогает выбрать стратегию. Commonwealth Bank of Australia применила TCO-модель к 2000 приложениям разной зрелости, оценив полные жизненные циклы, включая скрытые расходы на инфраструктуру, труд и инженерные усилия по поддержке автоматизации.
Устаревшее не всегда стоит выводить из эксплуатации, если ценность высока.
В других случаях подсчет TCO с учетом оберток автоматизации вокруг старой системы раскрывает истинную картину. Суммируя все, понимаешь: реальная цена поддержания legacy — это не только сама система, но и дополнительные слои вокруг нее.
Чтобы избежать шока от расходов, нужен бюджетный план, балансирующий переменные затраты с долгосрочными обязательствами. Переменные расходы (OPEX) дают гибкость, но сильно колеблются от спроса и эффективности инженерии.
Долгосрочная видимость позволяет принимать лучшие инвестиционные решения. Фиксация на технологиях или платформах на несколько лет вперед дает возможность торговаться за масштабы и стандартизировать архитектуру.
Такие обязательства упрощают создание правильных решений на перспективу.
Жесткий контроль переменных затрат в сочетании со стратегическими фиксациями помогает компаниям расширять интеллектуальную автоматизацию без той волатильности, которая часто срывает трансформацию.