В прошлой статье я писала про то, что значит быть Internal PO, когда у продукта нет клиента с улицы. Естественный следующий вопрос: а как в таком случае доказывать ценность в цифрах? Вот с этим и разберёмся.

Все цифры в примерах ниже — условные, для иллюстрации метода.

Почему классический ROI не работает

Классическая формула ROI строится на выручке: внедрили фичу, выросла конверсия, посчитали деньги. У внутреннего продукта выручки нет вообще. Оркестратор не продаёт ничего напрямую, он просто должен работать. А когда работает хорошо, это, как назло, никто не замечает.

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

Вместо того чтобы искать одну универсальную формулу, я считаю ценность по трём разным основаниям — смотря, что конкретно продукт даёт бизнесу. У каждого основания своя логика и своя точность.

Три типа ценности

Сэкономленное время. Люди тратили N часов на ручную операцию или разбор инцидентов, а потом стали тратить меньше. Переводится в деньги без всяких допущений: время × стоимость часа специалиста. Из всех трёх — самое благодарное, считается быстрее всего.

Предотвращённые потери. Клиент мог уйти из-за сбоя, задержки, ошибки, но не ушёл, потому что система отработала штатно. Тут уже сложнее: чёткого «до» и «после» нет, есть только гипотеза «что было бы, если бы система не справилась».

Снятый риск. Регуляторный, репутационный, технический — риск, который просто не реализовался. Самый неблагодарный тип: считается через вероятность инцидента × потенциальный ущерб и чаще служит аргументом, а не точной цифрой. Точности здесь и не может быть.

Кейс 1: сэкономленное время на примере статуса заявки

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

Было (в день): 40 обращений × 300 ₽ на обработку = 12 000 ₽
Стало (в день): 20 обращений × 300 ₽ = 6 000 ₽
Экономия: (40 − 20) × 300 ₽ × 20 рабочих дней = 120 000 ₽/месяц

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

Что важно: тут считается не активность («мы сделали доработку»), а разница до и после в реальных деньгах. Именно она в итоге убеждает бизнес, а не сам факт работы.

Кейс 2: предотвращённые потери на примере деградации сервиса

Тут история сложнее. Оркестратор работает медленнее обычного — не падает совсем, а именно «работает чуть хуже», и клиент в дилерском центре ждёт решение по заявке дольше. Формально всё работает, но по ощущениям — не очень. Это уже другой класс задачи.

Дополнительное время ожидания: 5 минут
Конверсия без задержки: 70%, с задержкой: 65%
Средний чек по автокредиту: 1 500 000 ₽
Заявок в день: 100
Потери: 100 заявок × 5% (падение конверсии) × 1 500 000 ₽ = 7 500 000 ₽ в день

Это не прогноз и не расчёт до копейки, а порядок величины. Нужна она не для красивой точности, а чтобы показать руководителю масштаб: пять минут задержки по деньгам сопоставимы с потерей в сотни тысяч, а то и миллионы в день.

Но тут есть важный нюанс: связку «время ожидания → падение конверсии» нужно либо подтвердить реальными данными из аналитики, либо честно сказать, что это иллюстративное допущение, а не установленный факт. Выдать гипотезу за измеренную зависимость — самый быстрый способ потерять доверие к расчёту.

Кейс 3: снятый риск на примере требования по раскрытию ПСК

353-ФЗ обязывает банк раскрывать клиенту полную стоимость кредита (ПСК) и график платежей в определённом формате при оформлении. Наша система собирает эти данные из смежного сервиса расчёта и передаёт во фронтальные каналы для формирования печатных форм. Не реализуй мы эту интеграцию или посчитай она ПСК с ошибкой, банк рисковал бы получить от регулятора предписание и штраф за нарушение закона о потребительском кредите.

Расчёт (условный):

Вероятность выявления нарушения при проверке регулятором: 30%
Потенциальный штраф по 353-ФЗ за эпизод: 700 000 ₽
Снятый риск: 30% × 700 000 ₽ = 210 000 ₽ в расчёте на проверку

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

Шаблон, который я использую

Было

Стало

Метрика

Формула

Период

Итог, ₽




(было − стало) × стоимость единицы



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

Что не оцифровывается

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

Заключение

В начале квартала легко столкнуться с вопросом: «Почему в бэклог попала именно эта задача, а не вот эта?» — имея в виду ту, что на первый взгляд выглядит важнее. И тогда лучше, чтобы расчёт уже лежал под рукой.

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

Если у вас есть свой метод считать ценность внутреннего продукта, было бы интересно узнать про него в комментариях.