Расчёт окупаемости ИТ-проекта: как считать и где ошибаются

Зачем считать до старта

ИТ-проект почти всегда продают через удобство: клиентам проще заказывать, менеджерам меньше рутины. Финансовый директор на это отвечает одним вопросом — когда вернутся деньги.

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

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

Три базовые формулы

Для ИТ-проектов обычно хватает трёх показателей. Каждый отвечает на свой вопрос, и смотреть на один без других опасно.

Как считать срок окупаемости проекта

Простой срок считают так: делят разовые вложения на ежемесячный чистый эффект. Если портал стоит 3 млн рублей, а экономия и дополнительная маржа дают 250 тысяч в месяц за вычетом поддержки, деньги вернутся через 12 месяцев. Это условный пример, а не цифры конкретного клиента.

Дисконтированный срок всегда длиннее. Каждый будущий месяц делят на (1 + r) в степени номера периода, где r — ставка дисконтирования. При высокой ключевой ставке разница между PP и DPP заметна уже на горизонте двух-трёх лет.

Когда нужен NPV

Если проект длинный и потоки неравномерные, полезно посчитать чистую приведённую стоимость, NPV. Это сумма всех дисконтированных потоков минус инвестиции. Положительный NPV значит, что проект выгоднее, чем держать деньги под ставку дисконтирования.

Из чего складывается модель для B2B-портала

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

• Разовые затраты: разработка, интеграция с 1С и складом, перенос данных, обучение.
• Ежегодные затраты: хостинг, поддержка, лицензии, доработки.
• Экономия: часы менеджеров на приём заказов, сверку остатков и выставление счетов.
• Дополнительная выручка: рост среднего чека и частоты заказов, новые клиенты из регионов.
• Снижение ошибок: меньше пересортов и возвратов из-за неверно набранного заказа.

Как рассчитать окупаемость экономии на менеджерах

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

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

Пошаговый пример на условных цифрах

Покажу ход мысли на выдуманной оптовой компании. Цифры круглые и нужны только для иллюстрации, у реального бизнеса они будут другими.

Допустим, у компании 400 активных оптовых клиентов и 6 менеджеров, которые принимают заказы по телефону и почте. Каждый менеджер с налогами обходится в 150 тысяч рублей в месяц, а половину времени тратит на ручной набор заказов и сверку остатков.

• Шаг 1. Считаем время: 6 менеджеров × 50% времени = 3 полные ставки уходят на рутину.
• Шаг 2. Оцениваем долю, которая уйдёт в портал за первый год: например, 60% заказов.
• Шаг 3. Переводим в деньги: 3 ставки × 60% × 150 тысяч = 270 тысяч рублей в месяц.
• Шаг 4. Вычитаем поддержку и хостинг, скажем 70 тысяч в месяц. Остаётся 200 тысяч чистого эффекта.
• Шаг 5. Делим вложения на эффект: 3 млн ÷ 200 тысяч = 15 месяцев простого срока.
• Шаг 6. Повторяем с пессимистичной долей онлайн-заказов, например 30%, и смотрим, как растягивается срок.

Что делать с результатом

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

Где модели ошибаются

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

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

Окупаемость проекта и чувствительность

Полезно посмотреть, что будет, если ключевые допущения ошибочны на 20–30%. Если срок при этом растягивается с года до трёх, проект рискованный. Если почти не меняется, решение можно принимать спокойнее.

В таблице это делается за минуту: меняешь количество клиентов или долю онлайн-заказов и смотришь на итог. Такой анализ чувствительности я бы показывал руководству вместе с базовым сценарием, а не вместо него.

Какие эффекты сложно оцифровать

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

Как пользоваться нашей моделью

Модель лежит в Google Таблицах. Чтобы посчитать свой случай, достаточно сделать копию и поменять числовые значения на свои: количество клиентов, зарплаты, число заказов.

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