Четыре величины, без которых считать нечего
- Объём: сколько операций проходит через процесс за месяц. Заявок, документов, обращений, проверок.
- Стоимость операции сегодня: время сотрудника, умноженное на стоимость его часа, плюс стоимость ошибок и переделок.
- Доля, которую реально передать системе. Ста процентов не будет: сложные случаи останутся людям.
- Стоимость эксплуатации: вызовы моделей или инфраструктура, плюс сопровождение и контроль качества.
Месячная экономия равна объёму, умноженному на стоимость операции и на переданную долю, минус стоимость эксплуатации. Срок окупаемости равен бюджету проекта, делённому на эту экономию. Всё остальное в расчёте уточняет эти четыре числа.
Типичные ошибки в расчётах
Экономию времени приравнивают к экономии денег
Освободившиеся полчаса у десяти сотрудников сами в деньги не превращаются. Их нужно занять другой полезной работой или не нанимать следующего человека, когда объём вырастет. Если не происходит ни того, ни другого, экономия существует только в презентации.
Закладывают стопроцентную автоматизацию
Реалистичную долю передачи определяет пилот, и полной она почти не бывает. Считать надо по консервативной оценке. Отдельно закладывают долю случаев, где работу системы проверяет человек.
Забывают стоимость проверки
Пока автономность неполная, кто-то смотрит на результаты. Эта работа стоит денег и должна быть в расчёте. Иначе проект окупается на бумаге, а нагрузка просто переезжает от исполнителя к проверяющему.
Считают токены вместо процессов
Цена тысячи токенов ничего не говорит о себестоимости решённой задачи. Одна задача может стоить десятков вызовов, повторов после ошибок и обращений к внешним системам. Экономику меряют завершённым бизнес-процессом, а не запросом к модели.
Игнорируют стоимость данных
Если для задачи нужно привести в порядок документы или собрать историю, это часть бюджета проекта. Эта строка бюджета нередко оказывается больше разработки, и о ней чаще всего забывают.
Три источника эффекта, которые считаются по-разному
- Снижение затрат: меньше ручной работы на том же объёме. Считается прямо и проверяется легко. Для первого проекта это самый надёжный тип эффекта.
- Снижение потерь: меньше ошибок, штрафов, просрочек, переделок. Считается по исторической статистике инцидентов, поэтому эту статистику должны вести.
- Рост выручки: быстрее ответы клиентам, больше обработанных заявок, выше конверсия. Самый привлекательный и самый спорный источник: на него влияет слишком много факторов, и в обоснование первого проекта его лучше не класть.
Как считать до проекта, если данных нет
Без точных цифр тоже можно считать, если не фантазировать. Порядок такой:
- Замерьте вручную: возьмите 20–30 реальных операций и засеките, сколько занимает каждая. Это недорого и даёт основу для расчёта.
- Возьмите консервативную долю передачи и посчитайте по ней. Оптимистичный вариант держите отдельно, для сравнения.
- Заложите стоимость эксплуатации с запасом: на старте она известна хуже всего.
- Посчитайте, при каком объёме проект перестаёт окупаться. Эта граница полезнее самой цифры ROI.
Что должно быть в решении о проекте
- метрика успеха, зафиксированная до старта;
- её значение сегодня, иначе не с чем сравнивать;
- когда ожидается эффект и по какому признаку станет ясно, что гипотеза не подтвердилась;
- цена остановки: что теряем, если свернём проект после пилота;
- кто в компании отвечает за данные и доступы. Проекты чаще буксуют здесь, чем в разработке.
Когда проект не нужно начинать
Если окупаемость выходит больше года, причина обычно в слишком широком сценарии, а не в технологии. Сузьте задачу до участка с наибольшим объёмом и посчитайте заново. Если и после этого не сходится, процесс либо слишком редкий, либо его сначала нужно перепроектировать. Автоматизация плохого процесса делает его быстрым и по-прежнему плохим.