8 мин

515

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

Большинство компаний на эти вопросы отвечают приблизительно. В лучшем случае — оценкой в Excel, где кто-то умножил количество сотрудников на среднюю зарплату и поделил на число проектов. В худшем — интуитивным ощущением руководителя, которое потом попадает в презентацию для инвесторов как «мы оптимизировали операционные расходы на 15%».

Проблема не в том, что никто не пытался посчитать, а в том, что получившаяся цифра не имеет отношения к реальности. McKinsey в исследовании Global Survey on AI фиксирует типичную ситуацию: около 60% организаций не видят EBIT-импакта от AI-проектов не потому, что технология не работает, а потому что никто не договорился, как именно измерять результат. Нет так называемого evidence pack — пакета подтверждённых данных, на который можно опереться при принятии решений. Без него пилот выглядит успешным на демо, но при масштабировании выясняется, что атрибуция была некорректной, а стоимость посчитана по-разному на разных этапах.

Это касается не только AI. Любой проект автоматизации страдает от той же проблемы: вы запускаете систему, тратите бюджет, получаете отчёт о выполнении — и не можете сказать, сколько всё это стоило в пересчёте на единицу работы, сравнить два процесса по стоимости владения или оценить, окупилась ли автоматизация. Вы управляете процессом, но не знаете его реальную цену.

Ранее я уже рассказывал об Organization as Code, или OaC, а также о нашем подходе к картографированию корпоративного ландшафта. В этой статье я покажу, как применить эти сущности к оценке окупаемости — и попытаюсь дать инструмент, которого не хватает компаниям по мнению McKinsey. 

Откуда берутся «сферические» цифры

Типичный расчёт стоимости процесса выглядит так: руководитель оценивает, какой процент времени сотрудники тратят на задачу, HR даёт среднюю зарплату по отделу, кто-то перемножает в Excel. Результат — приблизительная цифра, которая выглядит убедительно в презентации и полностью бесполезна для принятия решений.

При таком подходе теряются:

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

• Косвенные процессы: в регламенте написано «согласование договора — 2 дня», но реально туда входят обучение менеджеров новым шаблонам, разбор конфликтных случаев юристом, сверка данных в учётной системе. Эти активности не попадают в оценку, потому что они не описаны как отдельные задачи. 

• Зависимость от объёма: стоимость процесса не линейна, она растёт непропорционально при увеличении нагрузки, потому что появляются очереди, простоя и ручные обходные сценарии. 

• Стоимость ошибок: каждый сбой в процессе — это не только время на исправление, но и потенциальные потери от нарушенных сроков, испорченных отношений, штрафных санкций.

Приведу пример из практики: процесс согласования договора. В плане проекта автоматизации значится: разработка — 200 часов, внедрение — 50 часов, обучение — 30 часов. Итого 280 часов. При ставке 2000 рублей в час — 560 000 рублей. Звучит понятно. Но через полгода после запуска выясняется, что юрист тратит на сопровождение процесса 5 часов в месяц, менеджер по закупкам — 3 часа, ИТ-специалист — 15 часов на поддержку, а каждый десятый договор требует дополнительного согласования, которое не было учтено. 

Итого — не 560 000 рублей разово, а примерно 2,3 миллиона рублей в год. И это без учёта того, что в будущем объём может вырасти.

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

Как Organization as Code решает эту проблему

Когда индустрия столкнулась с аналогичной проблемой в управлении серверной инфраструктурой, ответом стала парадигма Infrastructure as Code. Вместо того чтобы описывать желаемое состояние серверов вручную и потом пытаться его достичь, инженеры стали описывать инфраструктуру в виде кода — декларативно, с версионированием, с возможностью автоматического применения и проверки. Terraform стал стандартом, потому что он дал ответ на вопрос: как описать инфраструктуру так, чтобы система сама показала стоимость и последствия изменений до того, как они будут применены?

OaC по своей сути предполагает тот же подход. Он позволяет описать ресурсы декларативно — в формате, который позволяет системе автоматически вычислять стоимость на основе актуальных данных из уже существующих источников: справочников должностей, учёта сотрудников, данных о фактической загрузке. Не раз в квартал по запросу, а постоянно, в реальном времени.

Ключевое отличие от Excel: это не инструмент расчёта, а машиночитаемый источник данных о ресурсах. Описание ресурса — это не отчёт, а код, который можно применять, проверять и автоматически пересчитывать при изменении условий.

В нашей реализации OaC состоит из трёх карточек-артефактов:

• ServiceCard описывает входящие сервисы: какие запросы подразделение принимает, какой входной пакет данных нужен, какие SLA установлены. 

• ObligationCard описывает обязательства подразделения в виде проверяемых инвариантов — утверждений, которые всегда должны быть истинными. 

• ResourceCard описывает ресурсное обеспечение: штатную численность, зависимости от других подразделений, нормы загрузки.

Первые две сущности подробно описаны в другой статье. Для CFO главная ценность — ResourceCard. Это карточка ресурса, где собраны все данные, необходимые для расчёта стоимости владения процессом. Роль, норма загрузки, фактическая утилизация, стоимость часа — всё в одном месте, всё связано между собой. Рассмотрим её подробнее.

Где живут данные для ResourceCard

Типичное возражение: это звучит как ещё одна система, которую нужно заполнять вручную. Где взять время на описание всех ресурсов?

Ответ: ничего заполнять не нужно. Данные уже есть в вашей платформе. Вопрос не в том, чтобы создать новую сущность, а в том, чтобы правильно соединить то, что уже существует.

В нашей платформе, «Первой Форме», ResourceCard этот принцип уже полностью применяется. Справочник должностей содержит нормативы загрузки по каждой роли. Табличный дополнительный параметр с колонкой утилизации фиксирует, какой процент времени сотрудник тратит на данный тип задач. Данные о сотрудниках связывают абстрактную роль с конкретными людьми. Хранимая процедура портальной отчётности агрегирует плановые нормо-часы по команде проекта.

Всё это уже работает непосредственно в рабочей среде. Данные используются для формирования HR-отчётов, для порталов планирования, для расчёта загрузки. Никто не вводит их дважды. Единственное, что нужно сделать, — описать соответствие между тем, как данные хранятся в системе, и тем, как они должны быть представлены в ResourceCard. Это техническая задача, которая решается один раз.

Формула живого TCO

Когда маппинг готов, расчёт стоимости становится автоматическим. Формула простая: 

TCO = Σ (Количество исполнителей роли × Утилизация роли × Ставка часа роли) × Объём работ за период + Стоимость токенов AI

Разница между этим расчётом и Excel-таблицей — в динамике. ResourceCard — это живой расчёт, который пересчитывается автоматически при изменении любого параметра: повышении зарплаты, росте объёма заказов, уменьшении времени на выполнение процесса. Соответствующий портал всегда будет отражать актуальную картину.

Вернёмся к примеру с согласованием договоров. Дано:

Excel-подход покажет только «разработку» или «прямые затраты»:

280 часов × 2000 рублей = 560 000 рублей. 

При этом не учитываются:

• Другие участники процесса;

• Утилизация (посчитали 100% времени);

• Стоимость юристов и финдиректоров;

• Повтор процесса;

• Стоимость сопровождения.

Теперь посмотрим на расчёт TC) при помощи ResourceCard:

Шаг 1: Считаем стоимость часа каждой роли с учётом утилизации

Менеджер: 3 чел × 0,85 × 2 000 ₽ = 5 100 ₽/час

Юрист: 2 чел × 0,60 × 3 000 ₽ = 3 600 ₽/час

Финдиректор: 1 чел × 0,40 × 5 000 ₽ = 2 000 ₽/час

Шаг 2: Суммарная стоимость часа процесса

5 100 + 3 600 + 2 000 = 10 700 ₽/час

Шаг 3: Стоимость одного цикла согласования

10 700 ₽/час × 2 часа = 21 400 ₽ за договор

Шаг 4: Годовой TCO

21 400 ₽ × 500 договоров = 10 700 000 ₽/год

Теперь посмотрим, как будет выглядеть этот расчёт после автоматизации. Предположим, что изменилось следующее:

• AI-ассистент берёт первичную проверку документов

• Менеджер тратит не 2 часа, а 40 минут (0,67 часа)

• Юрист проверяет только проблемные кейсы — допустим, 20% от объёма

Новые параметры:

Пройдём те же шаги:

Стоимость часа:

Менеджер: 3 × 0,85 × 2 000 × 0,67 × 500 = 1 708 500 ₽

Юрист: 2 × 0,60 × 3 000 × 0,67 × 100 (20% от 500) = 241 200 ₽

Финдиректор: 1 × 0,40 × 5 000 × 0,67 × 500 = 670 000 ₽

Итого без AI: 2 619 700 ₽

Стоимость токенов AI: 80 000 ₽/год

Итоговый TCO после автоматизации: 2 700 000 ₽/год

Экономия: 8 000 000 ₽

Чистый эффект (минус стоимость токенов): 7 920 000 ₽/год 

Почему важны именно машиночитаемые доказательства

McKinsey в том же отчёте описывает типичную ситуацию: компании запускают AI-пилоты, демонстрируют улучшения на ограниченном наборе метрик, получают одобрение на масштабирование — и на этапе масштабирования выясняется, что улучшения не воспроизводятся. 

Причина — так называемая «ловушка пилота»: на этом этапе собираются селективные метрики, атрибуция была некорректной, эффект хоккейной клюшки не сработал.

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

ResourceCard — это машиночитаемой пакета таких данных для стоимостной стороны. ObligationCard — ядро для операционных KPI и инвариантов. Вместе они дают CFO и руководителю проекта инструмент, который позволяет не просто декларировать эффект, а доказать его. Вот три варианта, как его можно применить:

1. Обоснование инвестиций в автоматизацию. Вы можете показать, что данный процесс стоит X рублей в год, автоматизация сократит стоимость на Y рублей, инвестиция окупится за Z месяцев. Все расчёты — на данных из системы, которые можно проверить и воспроизвести.

2. Приоритизация. Когда у вас есть TCO по нескольким процессам, вы можете расставить приоритеты: не «автоматизируем то, что проще», а «автоматизируем то, что дороже всего». Самая большая экономия — от автоматизации самого дорогого процесса, даже если он сложнее всего.

3. Сравнение вариантов. «Делать вручную» против «автоматизировать» против «передать на аутсорс». Вы видите стоимость каждого варианта и принимаете решение на основе цифр, а не интуиции.

Что это даёт на практике

Для CFO подход меняет полную картину по окупаемости инвестиций. Вместо «затраты на поддержку» в бюджете появляется строка с точной цифрой: стоимость владения процессом X составляет столько-то, она меняется при изменении объёма и ставок, мы видим её в реальном времени. Появляется возможность сравнивать процессы между собой, находить самые дорогие, оценивать эффект от изменений до их внедрения и общаться с инвесторами аргументированно.

Для руководителя проекта меняется разговор со стейкхолдерами. Вместо «это дорого» — конкретная цифра: данный процесс стоит 2,3 миллиона рублей в год, автоматизация сократит стоимость до 800 000, инвестиция окупится за 8 месяцев. Вместо «мы улучшили эффективность» — «мы сократили время на согласование с 2 часов до 40 минут, что даёт экономию X рублей в год».

Для владельца продукта появляется метрика успеха. Не «процесс автоматизирован», а «TCO снизился на 65%». Не «пользователи довольны», а «время отклика сократилось на 40%, стоимость операции — на 55%». Любое решение о развитии продукта принимается с оглядкой на его влияние на стоимость владения.

Заключение: от хаоса к управляемому коду

Мы не придумываем новые сущности, а наводим порядок в данных, которые уже существуют. 

Organization as Code — это не о том, чтобы «описать компанию кодом». Это о том, чтобы сделать ресурсы видимыми и измеримыми. Чтобы CFO мог ответить на вопрос «сколько стоит наш процесс» так же точно, как отвечает на вопрос «сколько стоит наш сервер». Чтобы любое решение об автоматизации принималось на основе расчёта, а не ощущения.

Если хотите посмотреть на свою организацию по-другому — начните с маппинга ресурсов. Возьмите один процесс, посчитайте его TCO через ResourceCard, посмотрите, какие данные уже есть в вашей платформе и как их можно связать. Скорее всего, окажется, что данные есть, их нужно только правильно соединить.

А дальше автоматизация становится не вопросом веры, а вопросом арифметики.