Документ, который выдерживает вопросы финансового блока

Документ состоит из шести обязательных разделов. Первый — описание процесса и его текущих показателей: объём операций за период, трудозатраты на единицу, стоимость часа работы, доля ошибок. Второй — целевое состояние: что именно изменится и за счёт чего. Третий — расчёт эффекта в консервативном сценарии. Четвёртый — полная стоимость владения, включая эксплуатацию. Пятый — риски и допущения. Шестой — критерии остановки проекта.

Особое внимание стоит уделить первому разделу. Именно baseline становится предметом спора: если до внедрения не зафиксировано время обработки одной заявки, после внедрения невозможно доказать, что оно сократилось. Мы настаиваем на измерении до старта, даже если это займёт неделю — иначе весь документ теряет доказательную силу.

Раздел рисков не следует делать формальным. Он показывает, что автор расчёта понимает ограничения: качество данных, готовность пользователей, зависимость от внешнего поставщика модели, изменение процесса. Грамотно описанный риск с планом проверки воспринимается как признак профессионализма, а не как слабость проекта.

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

Дальше добавляются остальные составляющие: стоимость эмбеддингов при обновлении индекса и при поиске, вызовы внешних сервисов, машинное время при собственном контуре. Сумма даёт себестоимость обработки одной операции в технической части. К ней добавляется человеческая: доля случаев, уходящих на ручной разбор, умноженная на время проверки одного случая и стоимость часа.

Сравнение себестоимости до и после даёт маржинальный эффект на операцию. Именно эта величина, умноженная на реальный объём с учётом пиков, определяет срок окупаемости. Если маржинальный эффект отрицательный или близок к нулю, проект не имеет смысла ни при каком объёме — и лучше узнать об этом до начала работ.

Мы всегда считаем три сценария из одних входных данных, меняя допущения. Консервативный предполагает, что автоматически обрабатывается меньшая доля операций, ручная проверка занимает больше времени, а стоимость инференса выше. Базовый отражает ожидаемые значения. Оптимистичный показывает потенциал, если качество модели окажется выше расчётного.

Инвестиционное решение принимается по консервативному сценарию. Это принципиальный момент: если проект окупается только в оптимистичном варианте, он несёт слишком много риска. Оптимистичный сценарий полезен для другого — он показывает верхнюю границу эффекта и позволяет понять, стоит ли вкладываться в улучшение качества модели.

Критерии остановки формулируются вместе с заказчиком до старта. Пример: если по итогам пилота доля автоматической обработки ниже 60% или время ручной проверки превышает четыре минуты на операцию, проект закрывается без дополнительных вложений. Наличие такого условия защищает и бюджет, и репутацию — решение об остановке принимается по заранее согласованному правилу, а не в эмоциональном споре.