Готовое ПО или заказная разработка: как выбрать и сравнить затраты

Разделите способ получения ПО и место его работы

Готовый продукт и заказная разработка описывают происхождение решения. SaaS (software as a service, программное обеспечение как услуга) описывает модель его предоставления. Эти признаки не исключают друг друга: разработанный на заказ продукт можно предоставлять клиентам как SaaS, а готовую систему можно установить в инфраструктуре компании.

В определении NIST потребитель SaaS использует приложение провайдера и не управляет лежащей под ним облачной инфраструктурой. Для сравнения коммерческих предложений удобнее выделить три конкретных варианта:

Таблицу можно прокрутить по горизонтали.

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

Источники: NIST SP 800-145: The NIST Definition of Cloud Computing.

Проверьте обязательные сценарии до подсчёта баллов

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

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

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

• Подтверждено: сценарий выполнен на тестовых данных и результат сохранён.
• Требует проверки: поставщик заявил возможность, но демонстрации или документации пока нет.
• Требует изменения: известны необходимые работы, их стоимость и влияние на обновления.
• Не поддерживается: нужен другой процесс или другой вариант системы.

Испытайте одну критичную интеграцию

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

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

Результатом проверки должны стать схема обмена, журнал испытаний и список оставшихся ограничений. Уточните, кто следит за ошибками и обновляет интеграцию при изменении API. Эти работы нужно включить в бюджет эксплуатации, даже если первичную настройку поставщик обещает бесплатно.

Составьте сопоставимую модель стоимости на три года

Совокупная стоимость владения, или TCO (total cost of ownership), складывается из запуска, эксплуатации, изменений и выхода из системы. Используйте один объём функций, одинаковое число пользователей и единый порядок учёта налогов. Труд собственных сотрудников также стоит включить, иначе внутренний вариант получит искусственное преимущество.

Ниже условный расчёт для 50 пользователей и 36 месяцев эксплуатации после запуска. Это пример структуры бюджета, а не цены МЛТ или рыночная статистика. Все суммы указаны в тысячах рублей без НДС.

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

Таблицу можно прокрутить по горизонтали.

Подписка SaaS рассчитана как 50 × 1 800 ₽ × 36 = 3 240 000 ₽. Обновления коробочного продукта в примере стоят 15 000 ₽ в месяц. Инфраструктура с её обслуживанием стоит 45 000 ₽ для коробки и 30 000 ₽ для заказной системы. Поддержка приложения и согласованные изменения стоят соответственно 25 000, 25 000 и 75 000 ₽ в месяц.

В строку внедрения или создания входят анализ требований, настройка или разработка, тестирование и выпуск. Интеграции и перенос данных выделены отдельно. Регулярная поддержка SaaS в этой модели покрывает работу с настройками и собственными интеграциями; базовую поддержку провайдера считаем включённой в подписку. Проверяйте состав каждой строки, чтобы не посчитать одну работу дважды.

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

Проверьте рост нагрузки, изменение цены и задержку запуска

Изменяйте по одному существенному допущению, чтобы видеть причину разницы. Если в примере с первого месяца работают 100 пользователей вместо 50, подписка SaaS составит 6,48 млн ₽ за три года. При неизменных прочих строках итог вырастет до 9,58 млн ₽. Это проверка влияния числа лицензий; расходы на поддержку и инфраструктуру для всех вариантов затем нужно переоценить отдельно.

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

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

Проверьте перенос данных и возможность сменить поставщика

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

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

Для готового продукта уточните срок доступа после отказа от подписки и порядок удаления данных. Для заказного ПО проверьте, сможет ли другая команда получить доступы, собрать приложение по инструкции и развернуть его в чистом окружении. Владение исходниками снижает часть зависимости, но не заменяет документацию, актуальные резервные копии и знания об эксплуатации.

Рассмотрите отдельный модуль для уникального процесса

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

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