Короткий ответ
SaaS-продукт можно готовить к включению в реестр российского программного обеспечения, если можно показать, что у заявителя есть права на программный продукт, функциональность продукта проверяема, есть документация, демо-доступ или тестовый контур, понятное описание назначения и корректно выбран класс ПО. Главная сложность SaaS в том, что эксперт должен увидеть не «коробку», а работающий сервис, его функции, роли пользователей, интерфейсы и документы.
Чем SaaS отличается от коробочного ПО
У SaaS обычно нет привычного дистрибутива, который пользователь устанавливает локально. Пользователь получает доступ к сервису через интернет, а программная часть работает на стороне правообладателя или его инфраструктурного партнера. Поэтому при подготовке к заявке особенно важны демо-доступ, документация и проверяемое описание функций.
Если коробочное ПО можно описать через установку, дистрибутив и локальный сценарий использования, то SaaS нужно показывать через роли, интерфейсы, пользовательские сценарии, тестовые данные и доступы. Эксперт должен иметь возможность проверить не маркетинговое обещание, а реальную функциональность.
Что подготовить перед заявкой
- Описание назначения. Какие задачи решает сервис, для кого он предназначен и какие функции доступны.
- Функциональные возможности. Модули, роли, пользовательские сценарии, ключевые экраны и ограничения.
- Документация. Руководство пользователя, администрирование, описание интеграций, API, если применимо.
- Демо-доступ. Тестовый аккаунт, тестовый контур или иной способ проверить заявленные функции.
- Сайт продукта. Публичная страница с описанием продукта, правообладателя, функций и контактов.
- Сведения о правообладателе. Кто владеет продуктом и получает доход от его использования.
Права на SaaS-продукт
Для SaaS вопрос прав часто сложнее, чем кажется. Продукт мог создаваться годами: backend писал один подрядчик, frontend — другой, мобильное приложение — третья команда, а часть модулей создавалась сотрудниками. Перед заявкой стоит проверить договоры с разработчиками, акты, служебные задания, передачу исключительных прав, права на интерфейсы, базы данных, документацию и отдельные модули.
Демо-доступ и документация
Для SaaS особенно важно заранее продумать, как эксперт будет проверять продукт. Недостаточно написать «сервис автоматизирует бизнес-процессы». Нужно дать проверяемый сценарий: как войти, где увидеть функции, какие роли есть, что считается ключевым функционалом.
- тестовая учетная запись;
- инструкция по входу;
- сценарии проверки ключевых функций;
- описание пользовательских ролей;
- скриншоты или руководство пользователя;
- контакт для технических вопросов по доступу.
Типовые риски SaaS при подготовке к РОПО
- Нет понятной документации, а функциональность описана только маркетинговыми словами.
- Демо-доступ не показывает ключевые функции или не работает стабильно.
- Права на отдельные модули оформлены на разных лиц или не оформлены вообще.
- Сайт продукта не совпадает с описанием в заявке.
- Не проанализированы open-source компоненты и сторонние лицензии.
- Неправильно выбран класс ПО.
- Неясно, кто является правообладателем и кто фактически монетизирует продукт.
Чек-лист готовности SaaS к заявке
- Есть понятное описание продукта и его назначения.
- Определен класс программного обеспечения.
- Подготовлена пользовательская документация.
- Есть демо-доступ или тестовый контур.
- Сайт продукта содержит актуальное описание функций и правообладателя.
- Проверены договоры с разработчиками и подрядчиками.
- Проверены права на базу данных, интерфейсы и документацию.
- Составлен перечень сторонних компонентов и open-source библиотек.
- Подготовлены пояснения по инфраструктуре и доступу.