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

Начните с честной позиции

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

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

Когда готовое решение подходит лучше

• Процесс стандартный. Если выставление счетов, расчёт зарплаты или заявки на отпуск устроены у вас так же, как в большинстве компаний, хороший продукт уже хорошо справляется с ними.
• Правила часто меняются, и поставщик за ними следит. Налоговые правила, правила расчёта зарплаты и электронных счетов регулярно меняются. Широко распространённый местный продукт обновляется сразу для всех, и собственной команде трудно с этим сравниться.
• У вас нет ИТ-специалистов. Облачный продукт с поддержкой избавляет от необходимости обслуживать серверы, резервные копии и обновления.
• Решение нужно на следующей неделе. Настройка занимает дни или недели. Разработка на заказ занимает больше времени.
• Им пользуются многие компании. Ошибки находят и исправляют другие пользователи ещё до того, как вы с ними столкнётесь, а людей, которые уже знают этот инструмент, проще нанять.

Когда заказная разработка окупается

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

Гибридный вариант

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

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

Так вы получаете надёжность продукта и его обновления в соответствии с законодательством, а заказное ПО только там, где оно добавляет ценность. Условие одно: у основного продукта должен быть документированный API и он должен давать доступ к вашим данным. Проверьте это до покупки, а не после.

Скрытые затраты с обеих сторон

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

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

В случае заказной разработки обращайте внимание на:

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

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

Зависимость от поставщика и владение данными

Зависимость от поставщика означает цену ухода от него. Если речь идёт об облачном продукте, до подписания договора спросите: можем ли мы экспортировать все наши данные, включая историю и вложения, в пригодном для использования формате? Есть ли API? Какую помощь поставщик оказывает по окончании договора? Регламент ЕС о данных (Data Act), который применяется с 12 сентября 2025 года, содержит нормы, призванные упростить клиентам переход между сервисами обработки данных, например между облачными провайдерами. Это полезная защита, но важнее всего по-прежнему ваш договор и реальная функция экспорта.

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

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

Короткий чек-лист для принятия решения

• Этот процесс является вашим отличием или это функция, которая нужна любой компании?
• Покрывает ли существующий продукт большую часть ваших потребностей без серьёзных доработок?
• Скольким пользователям понадобится доступ через три года, включая клиентов и партнёров?
• К каким системам нужно подключаться и есть ли у них документированные API?
• Можете ли вы в любой момент экспортировать все свои данные в пригодном для использования формате?
• Кто будет сопровождать решение через три года и сколько это будет стоить?
• Что произойдёт, если поставщик поднимет цены, будет куплен или закроет продукт?
• Какова совокупная стоимость за несколько лет, включая время ваших сотрудников?

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

Чем может помочь NOWANI TECH

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