# Заказное ПО или готовое решение (SaaS)?

По мнению Mesterséges Intelligencia Központ Kft., компании по разработке программного обеспечения из Будапешта, готового ПО (SaaS) достаточно, если оно охватывает процессы; заказное ПО оправдано, если компания работает не так, как принято, или если само ПО и есть преимущество для бизнеса.

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

## Что означают заказное ПО, готовое ПО и SaaS?

Эти три понятия отвечают на два разных вопроса: для кого создано ПО и как оно попадает к пользователю.

- **Заказное ПО:** программа, разработанная по заказу под потребности конкретной компании. Она умеет то, что заказчик запросил в спецификации, и так, как в компании принято работать, а о направлении дальнейшего развития тоже решает заказчик.
- **Готовое (коробочное) ПО:** продукт, создаваемый для множества клиентов, который компания лицензирует и, как правило, устанавливает и эксплуатирует на своих компьютерах или на своём сервере. Его можно адаптировать с помощью настроек, но логику работы определяет производитель.
- **SaaS (Software as a Service, программное обеспечение как услуга):** готовое ПО, которое производитель запускает в своём облаке, а компания пользуется им по подписке через браузер или через программный интерфейс. Программный интерфейс (API, application programming interface) представляет собой точку подключения, через которую две программы обмениваются данными без участия человека.

Согласно определению облачных вычислений Национального института стандартов и технологий США (NIST), при SaaS пользователь работает с приложением поставщика, запущенным в облаке, и не управляет стоящей за ним инфраструктурой (сетью, серверами, операционной системой, хранилищем) и даже отдельными функциями приложения, за исключением ограниченных пользовательских настроек ([NIST SP 800-145](https://csrc.nist.gov/pubs/sp/800/145/final)). В этом одновременно сила и ограничение SaaS: производитель снимает с компании бремя эксплуатации, но и решает, что и когда меняется в продукте.

## Третий путь: готовая основа с индивидуальными дополнениями

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

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

Преимущество гибридного пути в том, что компания платит за разработку только того, что действительно уникально. Недостаток в том, что индивидуальные части должны следовать за изменениями интерфейса готовой системы, поэтому в интеграции нужны журналирование и оповещение об ошибках, и кто-то должен заниматься её сопровождением. О связывании систем и автоматизации повторяющейся работы мы пишем на странице [Автоматизация процессов](https://www.mestersegesintelligenciakozpont.hu/ru/services/process-automation).

## Критерии выбора в одной таблице

| Критерий | В пользу готового ПО (SaaS), если… | В пользу заказной разработки, если… |
|---|---|---|
| Соответствие процессам | процесс типовой, и компания готова подстроиться под ПО | компания работает не так, как принято, и хочет сохранить это отличие |
| Конкурентное преимущество | эта область не отличает компанию от конкурентов | само ПО и есть преимущество для бизнеса или его носитель |
| Количество интеграций | подключаться нужно к немногим системам, и для них есть готовые коннекторы | нужно связать много систем, или для них нет готовых коннекторов |
| Данные и выход | производитель предоставляет полный машиночитаемый экспорт, и условия выхода понятны | модель данных и контроль над системой являются стратегическим вопросом |
| Пользователи и модель лицензирования | пользователей мало, и их число предсказуемо | пользователей много или их круг быстро растёт, и плата за пользователя становится определяющей |
| Скорость запуска | система должна заработать быстро, и готовых функций достаточно | запуск может дождаться разработки или проходить поэтапно |
| Кто будет сопровождать? | собственных ИТ-ресурсов нет, и сопровождения производителя достаточно | есть кому эксплуатировать: собственная команда или разработчик по договору |
| Размещение данных и соответствие требованиям | место хранения данных и договор производителя отвечают требованиям | данные должны оставаться в определённом месте, или на них распространяются строгие отраслевые требования |

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

## От чего зависит совокупная стоимость владения?

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

У готового ПО и SaaS стоимость, как правило, определяют:

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

У заказного ПО:

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

Стоимость заказной разработки можно спланировать, если объём работ измеряют, а не оценивают на глаз. Функциональный размер разработки мы измеряем в функциональных точках COSMIC (ISO/IEC 19761), и на его основе составляются предложение и график работ; метод описан на странице [Ценообразование](https://www.mestersegesintelligenciakozpont.hu/ru/pricing). Какой путь в долгосрочной перспективе обойдётся дешевле, зависит от количества пользователей, частоты изменений и числа интеграций. Общего ответа здесь нет, есть только расчёт для конкретного случая.

## Зависимость от производителя и переносимость данных

О зависимости от производителя (по-английски vendor lock-in) говорят, когда переход на другой продукт настолько сложен или дорог, что компания фактически не может уйти. Причиной может быть закрытый формат данных, неполный экспорт, множество настроек, привязанных только к этому продукту, или договор, который трудно расторгнуть.

Регламент Европейского союза о данных (Data Act, [Регламент (ЕС) 2023/2854](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R2854)) применяется с 12 сентября 2025 года и в отдельной главе регулирует переход между услугами обработки данных; его преамбула относит к ним и SaaS. Текст регламента, помимо прочего, предписывает следующее (проверено 17 октября 2026 года):

- Условия перехода должны быть закреплены в письменном договоре, а срок уведомления, необходимый для начала перехода, не может превышать двух месяцев (статья 25).
- Переход должен быть обеспечен по запросу, без неоправданной задержки, в пределах переходного периода продолжительностью не более 30 календарных дней, в течение которого услуга должна продолжать работать; если это технически невыполнимо, поставщик может с обоснованием установить переходный период продолжительностью до семи месяцев (статья 25).
- Договор должен исчерпывающе перечислять данные, которые можно перенести, и предусматривать период не менее 30 календарных дней для извлечения данных (статья 25).
- С 12 января 2027 года поставщик не вправе взимать плату за процесс перехода; до этой даты допускается только сниженная плата, не превышающая его расходов, непосредственно связанных с переходом (статья 29).

Важное исключение: правило о плате и некоторые технические обязанности не распространяются на услуги, основные характеристики которых в значительной мере адаптированы под потребности одного клиента и которые не предлагаются в широком масштабе (статья 31). Если готовая система обрабатывает персональные данные по поручению компании, обязательства на поставщика накладывает и Общий регламент по защите данных (GDPR): по окончании оказания услуги он по выбору контролёра удаляет или возвращает все персональные данные ([GDPR, статья 28, пункт 3, подпункт (g)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)). Это информация, а не юридическая консультация.

Законодательство улучшает условия, но выход компания всё равно должна спланировать сама, желательно уже при выборе. Стоит проверить:

- в каком формате можно выгрузить все данные, например в CSV (текстовый файл с разделителями-запятыми), JSON (машиночитаемый структурированный текстовый формат) или в виде резервной копии базы данных, и входят ли в выгрузку вложения, комментарии и журнал изменений;
- есть ли документированный API, через который данные можно извлекать и непрерывно;
- можно ли пробным экспортом проверить, что данные загружаются в другую систему;
- что говорит договор о расторжении, плате за переход и удалении данных.

## Кому принадлежит исходный код?

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

При заказной разработке вопрос исходного кода и прав на использование решает договор, поэтому стоит прямо зафиксировать, кому принадлежит код, получает ли заказчик полный исходный код и документацию и можно ли развивать систему дальше с другим разработчиком. У нас вопросы исходного кода и прав на использование также регулируются договором. О других важных пунктах договора мы пишем в статье [Как выбрать компанию по разработке ПО?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/how-to-choose-a-software-development-company)

## Для разных типов систем критерии весят по-разному

Приведённые выше критерии универсальны, но для разных типов систем их вес различается. Для системы управления предприятием решающим вопросом является соотношение доработки и возможности обновления (об этом мы пишем в статье [Индивидуальная ERP или доработанная готовая ERP?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/custom-erp-vs-off-the-shelf-erp)). Для системы управления взаимоотношениями с клиентами многое значат особый процесс продаж и лицензирование с оплатой за каждого пользователя (см. статью [Когда стоит разрабатывать индивидуальную CRM?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/when-is-a-custom-crm-worth-it)). Для интернет-магазина быстрому запуску на арендуемых платформах противостоит свобода расширения (см. статью [Интернет-магазин: арендуемая платформа или заказная разработка?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/hosted-webshop-vs-custom-development)). О разработке бизнес-систем в целом вы можете прочитать на странице [ПО для бизнеса](https://www.mestersegesintelligenciakozpont.hu/ru/services/business-software).

## Чек-лист для принятия решения

Ответы на эти вопросы обычно сами указывают путь:

1. Можем ли мы описать процесс настолько подробно, чтобы на демонстрации готового продукта проверить его по пунктам?
2. Какую часть процесса готовый продукт охватывает с помощью настроек, без разработки?
3. Отличает ли эта область компанию от конкурентов или она устроена одинаково во всех компаниях?
4. К скольким системам нужно подключаться и есть ли для них готовые коннекторы, поддерживаемые производителем?
5. Сколько пользователей будет работать в системе через несколько лет и как с этим изменится подписка?
6. Получим ли мы полный машиночитаемый экспорт и проверили ли мы его пробным экспортом?
7. Где хранятся и где обрабатываются данные и соответствует ли это требованиям компании к защите данных и отраслевым требованиям?
8. Кто будет эксплуатировать и развивать систему и что произойдёт, если этот партнёр выбудет?
9. Сколько времени есть до запуска и может ли система запускаться поэтапно?

## Типичные ошибки

- **Сравнение списков функций вместо процесса:** два продукта могут обещать одну и ту же функцию, а разница в том, как она вписывается в повседневную работу компании. Демонстрацию стоит пройти на собственных реальных случаях.
- **Сравнение стоимости только за первый год:** подписка растёт вместе с численностью персонала, а эксплуатация и дальнейшее развитие заказной системы дают о себе знать с годами.
- **Забытый выход:** экспорт данных нужно проверять при выборе, а не при расторжении договора.
- **Слишком много доработок в готовом продукте:** после определённого момента обновление многократно доработанной готовой системы требует больше работы, чем сопровождение хорошо обособленного индивидуального модуля.
- **Замена всего сразу:** поэтапный переход (сначала один модуль, потом следующий) несёт меньший риск, чем один большой единовременный переход.

## Частые вопросы

### Когда стоит разрабатывать заказное ПО?

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

### Дороже ли заказное ПО в долгосрочной перспективе?

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

### Что будет с нашими данными, если мы откажемся от SaaS?

Это зависит прежде всего от договора, поэтому его стоит изучить уже при выборе. Согласно европейскому Регламенту о данных, договор должен исчерпывающе определять данные, которые можно перенести, и предоставлять не менее 30 календарных дней для их выгрузки; а персональные данные по GDPR по окончании оказания услуги должны быть удалены или возвращены по выбору контролёра. На практике пробный экспорт показывает, насколько данные пригодны для использования в другой системе.

### Можно ли сочетать оба варианта?

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

### Кому будет принадлежать исходный код?

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

## Как мы можем помочь?

Mesterséges Intelligencia Központ Kft. разрабатывает заказное ПО и там, где это экономит реальный труд, связывает готовые системы, в том числе с помощью искусственного интеллекта: мы подключаем языковые модели OpenAI (ChatGPT), Anthropic (Claude) и Google (Gemini) к существующим системам. Первая консультация бесплатна, и на ней мы также скажем, если достаточно готового продукта. Если нужна заказная разработка, мы измеряем её функциональный размер в функциональных точках COSMIC, и на его основе составляются предложение и график работ. По запросу мы заключаем соглашение о неразглашении (NDA), а после передачи также берём на себя эксплуатацию и сопровождение. Вопросы исходного кода и прав на использование регулируются договором.

Подробности изложены на странице [Заказная разработка ПО](https://www.mestersegesintelligenciakozpont.hu/ru/services/custom-software-development). Если вы хотите поговорить с нами о своей ситуации, напишите нам по контактам, указанным на странице [Контакты](https://www.mestersegesintelligenciakozpont.hu/ru/contact).

## Источники

- [NIST: SP 800-145, The NIST Definition of Cloud Computing](https://csrc.nist.gov/pubs/sp/800/145/final)
- [EUR-Lex: Регламент (ЕС) 2023/2854 (Регламент о данных, Data Act)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R2854)
- [EUR-Lex: Регламент (ЕС) 2016/679 (Общий регламент по защите данных, GDPR)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)