1) Что такое реестр российского ПО (ссылка на первую статью)
2) Рассматриваем инструкцию подачи заявки в реестр ПО
3) Рассмотрим так же ()
Когда разработчик впервые решает включить продукт в реестр российского ПО, он почти всегда смотрит на это как на простую административную задачу. Кажется, что это примерно как регистрация домена или подача заявки в какой-нибудь сервис: есть форма, есть поля, есть документы — всё заполнил и отправил.
Но уже при первом открытии формы становится понятно, что это не «заявка», а целая система проверки, в которой государство по сути разбирает ваш продукт на составные части и проверяет каждую из них отдельно: кому он принадлежит, как он создан, как устроен, где хранится, как распространяется и соответствует ли он тем требованиям, которые предъявляются к российскому программному обеспечению. И именно поэтому правильнее воспринимать включение в реестр не как разовое действие, а как небольшой проект внутри компании.
С чего начать?
Всё начинается не с формы и даже не с описания продукта, а с гораздо более базовой вещи — с прав. Экспертиза в первую очередь смотрит на то, кто именно является правообладателем и есть ли у этого лица законное и документально подтверждённое право распоряжаться программным обеспечением. На этом этапе часто выясняется, что продукт разрабатывался разными командами, часть кода писалась по договорам подряда, где-то использовались сторонние решения, а где-то права оформлялись не совсем аккуратно. Для бизнеса это может не быть проблемой, но для реестра — это первый фильтр.
Когда с правами всё приведено в порядок, на первый план выходит сам продукт. И здесь появляется вторая важная задача — правильно представить программное обеспечение так, чтобы оно соответствовало требованиям реестра и корректно попадало в классификацию. Это не маркетинговое описание и не текст с сайта. Это техническое и юридически значимое описание, которое будет читаться экспертами и сравниваться с формальными критериями. От того, как сформулированы функции продукта, зависит то, к какому классу он будет отнесён и не возникнут ли у экспертизы вопросы о корректности классификации.
Следующие шаги
Дальше процесс начинает усложняться за счёт того, что описание должно быть не просто красивым и понятным, а согласованным с остальными частями заявки. Архитектура, способы распространения, лицензирование, взаимодействие с другими системами — всё это должно быть описано таким образом, чтобы не возникало внутренних противоречий. Это тот момент, где разработчики чаще всего недооценивают важность формулировок: кажется, что смысл понятен, но для эксперта любая двусмысленность — это повод задать уточняющий вопрос.
Отдельная зона внимания — исходный код и его хранение. В заявке нужно чётко показать, где находится код, под чьим контролем он находится и в какой юрисдикции расположена инфраструктура. Это не формальность, а важный критерий, связанный с контролем над продуктом. Если этот блок заполнен «в общих словах», почти всегда возникают дополнительные вопросы, которые тормозят процесс.
Параллельно с этим готовится документальная часть. И здесь как раз становится видно, насколько продукт «упакован» с точки зрения права и документации. Все сведения, которые вы указываете в форме, должны иметь подтверждение. Названия, права, описания — всё должно совпадать и не противоречить друг другу. Даже небольшие расхождения могут вызвать дополнительные проверки.
Когда вся эта подготовка сделана, сама форма заявки заполняется довольно быстро. И вот здесь многие впервые понимают, что форма — это действительно финальный этап, а не начало процесса. К этому моменту у вас уже должны быть готовы все формулировки, описания и документы, которые вы просто переносите в нужные поля.
Этап экспертизы
После подачи начинается экспертиза. И именно здесь становится видно, насколько качественно была проведена подготовка. Если заявка логична, согласована и не вызывает вопросов — она проходит проверку относительно спокойно. Если же в ней есть неточности или нестыковки, начинается цикл уточнений, ответов на запросы и доработок. Формально это часть процесса, но по факту именно она чаще всего растягивает включение в реестр на месяцы.
Поэтому ключевая мысль, которую мы стараемся донести до наших клиентов заключается следующем: до начала подачи заявки важно понять, что скорость и успешность включения в реестр определяются не тем, как быстро вы заполнили форму, а тем, насколько качественно вы подготовили всё до этого момента.
И именно поэтому компании, которые уже проходили этот путь, воспринимают включение в реестр как отдельную задачу с собственной логикой, рисками и стоимостью ошибок. Потому что каждая неточность здесь — это не просто формальность, а потенциально потерянное время и упущенные сделки.
Какие документы нужны для подачи заявки в реестр
Когда разработчик доходит до этапа подготовки документов, обычно возникает ощущение, что это просто «формальный пакет приложений». Но на практике именно документы становятся фундаментом всей заявки. Это та часть, на основании которой экспертиза понимает: действительно ли продукт ваш, действительно ли он разработан в нужной юрисдикции и действительно ли всё, что вы указали в форме, соответствует реальности.
Заявка в реестр — это не рассказ о продукте, а юридически и технически подтверждённая картина. И документы в этом процессе выполняют роль доказательств.
Первое, что проверяется, — это права на программное обеспечение. У правообладателя должна быть непрерывная цепочка прав: от момента разработки до текущего владельца. Если разработчики работали по трудовым договорам — это одно. Если по договорам подряда — другое. Если часть кода создавалась сторонними командами — третье. И в каждом случае это должно быть корректно оформлено и подтверждено.
Дальше — документы, подтверждающие статус правообладателя. Это учредительные документы, сведения о структуре владения, информация о бенефициарах. Именно на основании этих данных экспертиза делает вывод, является ли компания российской с точки зрения требований реестра.
Отдельный блок — это описание самого продукта, которое также оформляется документально. Сюда входит описание функциональных характеристик, области применения, архитектуры, способов распространения. И здесь очень важно, чтобы это описание совпадало с тем, что вы указываете в форме заявки. Любое расхождение — это повод для уточняющих вопросов.
Есть ещё один нюанс, который часто недооценивают, — документы, связанные с исходным кодом и его хранением. В форме заявки есть блок, где вы указываете, где хранится исходный код, в каких системах, на чьих серверах, в какой юрисдикции. И эти сведения также должны быть подтверждаемыми.
На практике чаще всего сложности возникают не потому, что у компании нет документов, а потому, что они оформлены фрагментарно или не согласованы между собой. Где-то указано одно наименование продукта, где-то другое. Где-то не прописана передача прав. Где-то используются старые версии договоров.
Поэтому подготовка пакета документов — непростая задача. Это аудит и приведение в порядок всей правовой и технической базы продукта. Именно от качества этого этапа напрямую зависит, как быстро и спокойно пройдёт экспертиза.
Когда документы собраны и заявка подана, возникает следующий логичный вопрос — сколько времени это займёт. Разберём этот вопрос.
Сроки рассмотрения заявки в реестре российского ПО
Когда заявка отправлена, большинство компаний ожидают чёткий и понятный срок: условно «через 30 дней будет результат». Формально у процедуры действительно есть регламентированные сроки рассмотрения. Он составляет до 45 рабочих дней. Но на практике время включения в реестр почти всегда отличается от ожиданий, и ключевая причина этого — качество самой заявки.
Если заявка подготовлена аккуратно, логично и без противоречий, она проходит экспертизу значительно быстрее. Эксперты проверяют сведения, сопоставляют документы и, если всё соответствует требованиям, двигают её дальше по процедуре без лишних вопросов. В таких случаях эксперты могут справиться с заявкой и за 7 рабочих дней.
Но если в заявке есть неточности, нестыковки или формулировки, которые можно трактовать по-разному, начинается этап уточнений. Экспертиза направляет запросы, вы готовите ответы, корректируете документы, отправляете повторно. Затем заявка снова проверяется. Иногда таких циклов бывает несколько. На досылку рабочих документов заявителю дают 20 рабочих дней. Нетрудно посчитать, сколько дополнительного времени может уйти, если эксперты будут отправлять вашу заявку на правку несколько раз.
И вот здесь срок начинает увеличиваться. Формально всё происходит в рамках регламента, но фактически процесс может растянуться в разы.
Есть ещё один фактор — загруженность экспертизы. Поток заявок достаточно большой, и при прочих равных быстрее проходят те, которые не требуют дополнительной коммуникации. Поэтому правильный вопрос звучит не «сколько длится рассмотрение», а «насколько корректно подготовлена заявка до подачи». Именно это в большинстве случаев определяет итоговый срок.
Для бизнеса это критично. Потому что пока продукт не включён в реестр, вы не можете участвовать в части закупок, не можете закрыть ряд сделок и фактически теряете деньги каждый месяц задержки.
Чтобы не доводить до затягивания сроков, важно понимать, какие ошибки чаще всего приводят к возвратам и отказам.
Именно об этом мы и поговорим с вами в следующей статье.