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