«Зачем разрабатывать за миллион, если есть подписка?» — разумный вопрос. «Зачем годами платить подписку, если можно один раз написать свое?» — тоже звучит разумно.
Оба вопроса пропускают часть расходов. Готовую систему нужно настроить, наполнить данными и встроить в работу. Собственную — сопровождать, размещать и менять. Доработка платформы объединяет часть расходов обоих вариантов.
Выбор стоит начать с одной задачи, одинакового горизонта и списка обязательных условий. Тогда спор о подходах можно заменить сравнением покупок.
Одна задача для трех вариантов
Возьмем учебную компанию, которой нужен кабинет дилера. Пятьдесят пользователей видят каталог и персональные цены, согласуют заказ, получают статусы из одной учетной системы. Оплату и логистику пока оставляем за пределами кабинета.
Компания рассматривает готовый сервис, доработку платформы и разработку с нуля. По условиям примера все три варианта поддерживают минимальный рабочий сценарий. Цены, ограничения и оценки полностью учебные, ни к какому реальному поставщику они не относятся.
Перед расчетом компания проверяет обязательные вещи: можно ли разделить данные дилеров, обмениваться с нужной базой, выгрузить заказы и клиентские карточки. Если готовое решение не выполняет обязательное требование, низкая цена не делает его подходящим. Если требование можно упростить без вреда работе, это стоит обсудить до исключения варианта.
Например, индивидуальная многоступенчатая схема согласования может быть привычкой одного отдела. А разграничение доступа между компаниями — обязательное условие. Их нельзя взвешивать одинаково.
Сколько стоит начать и сколько стоит продолжать
Посчитаем подготовку к запуску и 36 месяцев эксплуатации после него. Суммы в таблице — тысячи рублей, все денежные платежи приведены к одной базе без дополнительных налоговых начислений. Внутренний труд оценивается по полной условной стоимости часа и показан отдельно. Налоговые вычеты, инфляцию и дисконтирование не моделируем.
| Статья затрат | Готовый сервис | Доработка платформы | Своя разработка |
|---|---|---|---|
| Настройка или разработка, разово | 120 | 600 | 1 400 |
| Перенос данных, разово | 80 | 100 | 150 |
| Обучение, разово | 40 | 50 | 50 |
| Участие команды заказчика в запуске | 60 | 150 | 200 |
| Всего до запуска | 300 | 900 | 1 800 |
| Лицензии или инфраструктура, в месяц | 40 | 15 | 5 |
| Сопровождение, в месяц | 10 | 15 | 15 |
| Внутреннее администрирование, в месяц | 10 | 10 | 5 |
| Всего в месяц | 60 | 40 | 25 |
| Выгрузка и передача данных при выходе, разово | 60 | 100 | 150 |
| За весь горизонт | 2 520 | 2 440 | 2 850 |
Формула для каждого столбца одна: запуск + 36 × ежемесячные затраты + выход. Например, для доработки: 900 + 36 × 40 + 100 = 2 440 тысяч рублей.
Расходы на выход включены как плановый сценарий в конце горизонта. Если компания продолжит пользоваться системой, этого платежа в тот момент не будет. Цена следующей системы здесь не учтена: мы сравниваем возможность закончить работу с текущей.
Внутренний труд тоже не всегда означает новое списание со счета. Он показывает, сколько ресурса команды потребует вариант. Для утверждения денежных платежей его нужно отделить от внешних расходов. Поэтому результат таблицы — сравнение экономических затрат, а не готовый платежный календарь.
Разница в 80 тысяч еще не выбирает за вас
В исходном сценарии доработка платформы дешевле готового сервиса на 80 тысяч за три года. При этом требует на 600 тысяч больше до запуска.
Если деньги на старте ограничены, готовый сервис может оказаться предпочтительнее даже при чуть большей итоговой сумме. Если платформа лучше поддерживает обязательную работу и у команды есть время на внедрение, доработка заслуживает проверки.
Собственная разработка пока самая дорогая. Чтобы выбрать ее, нужно показать преимущество, которое имеет значение для бизнеса: обязательную функцию, контроль над развитием или другую подтвержденную ценность. Само наличие исходного кода этого расчета не заменяет.
Не стоит добавлять в таблицу выдуманную денежную оценку «гибкости». Лучше записать конкретное будущее изменение и выяснить, как его выполнят в каждом варианте.
Что произойдет, если пользователей станет вдвое больше
Пусть с тринадцатого месяца пользователей будет сто. По условным условиям вариантов ежемесячные затраты вырастут до 90, 45 и 30 тысяч рублей соответственно. Первые двенадцать месяцев остаются прежними, следующие двадцать четыре считаются по новым суммам.
Получаем:
- готовый сервис: 300 + 12 × 60 + 24 × 90 + 60 = 3,24 млн рублей;
- доработка: 900 + 12 × 40 + 24 × 45 + 100 = 2,56 млн;
- своя разработка: 1 800 + 12 × 25 + 24 × 30 + 150 = 2,97 млн.
Доработка по-прежнему дешевле. При этом собственная разработка обошла готовый сервис по трехлетним затратам.
Эти числа не означают, что у любого сервиса цена удваивается вместе с пользователями, а собственный продукт масштабируется почти бесплатно. Такое поведение тарифов и нагрузки специально задано для примера. В своей модели нужно использовать условия выбранного тарифа и оценку инфраструктуры.
Крупное изменение может переставить варианты местами
Теперь добавим к сценарию роста новую задачу: вторую учетную базу с нестандартным согласованием взаиморасчетов. В учебных оценках полная стоимость изменения, включая сопровождение до конца горизонта, составляет 900 тысяч для сервиса, 1 миллион для доработанной платформы и 200 тысяч для собственной системы.
Почему у платформы получилось дороже? По условию примера новое правило требует переработки существующего расширения. У собственной системы нужная часть уже предусмотрена в архитектуре. Это конкретные допущения, которые в реальном выборе потребовали бы проверки инженером и письменной оценки.
| Сценарий | Готовый сервис | Доработка платформы | Своя разработка |
|---|---|---|---|
| Исходный, 50 пользователей | 2,52 млн | 2,44 млн | 2,85 млн |
| 100 пользователей с 13-го месяца | 3,24 млн | 2,56 млн | 2,97 млн |
| Рост и крупное изменение | 4,14 млн | 3,56 млн | 3,17 млн |
Теперь по сумме выигрывает собственная разработка. Но закладывать дорогой сценарий как неизбежный только ради желаемого ответа нельзя. Если второй базы в планах нет, последний ряд описывает возможность, за которую вы собираетесь заплатить заранее.
Решение зависит от вероятности и срока изменения. Их обсуждают с бизнесом, а не выводят из желания IT-команды иметь свой код.
Как сформулировать решение
Для исходного сценария вывод мог бы быть таким: «Проверяем доработку платформы как вариант с наименьшими трехлетними затратами. Готовый сервис сохраняем как альтернативу с меньшим платежом на старте. Своя разработка оправдана по нашей модели только при подтвержденном росте и конкретном крупном изменении».
К выводу приложите список неизвестных: реальный состав тарифа, доступ к API, трудоемкость переноса, возможность экспорта, время запуска. Если сроки внедрения различаются, учтите дополнительные расходы на параллельную работу старого процесса. В нашей учебной таблице их нет.
С такой моделью уже можно готовить записку для решения о бюджете. Если ни один вариант не помещается в доступные деньги, полезнее сократить первый этап, чем маскировать проблему длинным сроком окупаемости.
Если выбор уже стоит перед вашей компанией
В аналитическом отделе MoranaLabs можно сопоставить реальные варианты: требования, запуск, эксплуатацию, изменения и выход. Результат — расчет на согласованный период и рекомендация с условиями, при которых она меняется.
Для первого обращения опишите задачу, число пользователей и варианты, которые уже рассматриваете. Если готовая система решает ее лучше, это и будет основанием рекомендации. Заказ разработки из такого исследования автоматически не следует.