Проверить систему в реестре российского ПО — значит открыть карточку конкретного продукта и сверить четыре реквизита с тем, что написано в коммерческом предложении: точное наименование продукта, правообладателя, номер реестровой записи и класс ПО. На один продукт уходит около пятнадцати минут. Всё остальное — письмо менеджера, логотип «в реестре» на сайте вендора, устное заверение на демонстрации — проверкой не является и на приёмке никого не защитит.
Важная деталь, из-за которой эта проверка вообще нужна: в подавляющем большинстве случаев поставщик не обманывает. Запись действительно есть — но на другой объект. В реестре платформа, а вы покупаете отраслевой модуль. В реестре ядро, а в спецификации — ядро плюс доработка под ваш процесс. В реестре предыдущая редакция, а поставляется текущая. Каждый из этих случаев выглядит как соответствие требованию и им не является.
Ниже — маршрут сверки, четыре типовые подмены объекта записи, перечень того, что запись подтверждает и чего не подтверждает, порядок встраивания проверки в закупочный процесс и три варианта действий, когда продукта нужного класса в реестре нет вовсе. Зачем реестр вообще существует и на кого он влияет, мы разбирали отдельно в материале про реестр отечественного ПО; здесь — только процедура.
Проверяются четыре реквизита, а не факт наличия
Вопрос «есть ли продукт в реестре» некорректен, потому что в реестре не бывает «продукта вообще». Там есть запись с номером, датой включения, наименованием, правообладателем и классом по классификатору. Ваша задача — доказать себе, что эта запись описывает ровно то, что вы собираетесь купить и поставить на учёт.
Позиция единого реестра российского программного обеспечения с собственным номером, датой включения, наименованием продукта, правообладателем и классом ПО. Запись относится к продукту, а не к компании, не к линейке и не к вашему проекту внедрения.
- Наименование продукта. Сверяется посимвольно со спецификацией — вплоть до слов «модуль», «конфигурация», «редакция», номера версии и указания на профессиональную либо корпоративную поставку. Расхождение в одном слове — повод остановиться и переспросить, а не додумать.
- Правообладатель. Сверяется с тем юридическим лицом, которое подписывает с вами договор. Дистрибьютор, партнёр и интегратор — не правообладатели; это нормальная схема поставки, но в спецификации должно быть видно, чей продукт вы покупаете.
- Номер записи и дата включения. Номер переносится в спецификацию и в акт. Без него требование непроверяемо на приёмке: принимающий не обязан искать карточку сам.
- Класс ПО. Сверяется с тем классом, который назван в вашем требовании или в положении о закупке. Продукт может быть в реестре и при этом относиться к другому классу, чем тот, который вы обязаны закупать из перечня.
Маршрут на пятнадцать минут
Порядок действий один и тот же для любого продукта. Он не зависит ни от отрасли, ни от суммы закупки, и его стоит держать отдельным пунктом чек-листа выбора системы — до демонстраций, а не после подписания.
- 1Возьмите наименование из спецификации, а не из письма
Источник — приложение к коммерческому предложению или проект спецификации к договору. В переписке менеджер пишет короткое рыночное имя продукта, в спецификации — полное. Проверять надо полное: именно оно попадёт в акт.
- 2Ищите карточку продукта, а не страницу компании
Поиск по названию правообладателя даёт список всех его записей — и в нём легко принять чужую строку за нужную. Ищите по наименованию продукта и открывайте карточку целиком, а не превью в результатах.
- 3Сверьте правообладателя с будущим контрагентом
Если договор подписывает партнёр, а правообладатель другой, это не нарушение, но в спецификации должна быть цепочка: чей продукт, кто поставляет, на каком основании. Иначе на приёмке вы не сможете показать связь между записью и поставкой.
- 4Сверьте класс ПО с формулировкой вашего требования
Класс из карточки выписывается рядом с классом из положения о закупке или из тендерной документации. Совпадение классов — отдельная проверка, которую пропускают чаще всего, потому что она не про продукт, а про ваш собственный документ.
- 5Зафиксируйте результат датой и фамилией
Номер записи, дата включения, дата проверки и кто проверял — в файле решения по проекту. Состав реестра меняется, и через год восстановить, что там было на день сделки, будет нечем. Одна строка в таблице закрывает этот вопрос навсегда.
Схема-маршрут слева направо из пяти блоков со стрелками: «Наименование из спецификации» → «Карточка продукта в реестре» → «Сверка правообладателя с контрагентом» → «Сверка класса ПО с положением о закупке» → «Запись в файл решения: номер, дата включения, дата и автор проверки». Над вторым блоком гребёнка из четырёх подписей: «наименование», «правообладатель», «номер записи», «класс ПО». Под маршрутом плашка «15 минут на продукт, 3 часа на шорт-лист из 6, 5 400 ₽ рабочего времени». Чертёжный стиль, подписи по-русски.
Четыре подмены объекта записи
Все они выглядят одинаково убедительно и различаются одной строкой в карточке. Таблица ниже — то, что стоит держать перед глазами при разборе коммерческого предложения.
| Как звучит от поставщика | Что на самом деле | Как увидеть за минуту |
|---|---|---|
| «Наш вендор в реестре» | Реестр ведётся по продуктам. У компании с двенадцатью продуктами в перечне может быть четыре, и это обычная ситуация | Открыть карточку именно того продукта, который стоит в спецификации, а не список записей правообладателя |
| «Платформа в реестре» | Отраслевой модуль или конфигурация поставляется как самостоятельный продукт — со своей записью или без неё | Сверить наименование посимвольно, включая слова «модуль» и «конфигурация»: в карточке платформы их не будет |
| «Продукт в реестре с 2023 года» | В записи предыдущая редакция или версия, а поставляется текущая. Редакции нередко значатся раздельно | Сравнить редакцию и номер версии в карточке с редакцией и версией в спецификации |
| «Решение на базе продукта из реестра» | Реестровое ядро плюс доработка под вас. Доработка в реестр не попадает и попасть не может: туда включают продукты, распространяемые на рынке | Разделить спецификацию на две части: лицензии с номерами записей отдельно, работы по доработке отдельно |
Пятый случай стоит особняком и в таблицу не помещается: облачный сервис. Российское юридическое лицо, российское облако, поддержка на русском и реестровая запись — четыре разные вещи, и наличие первых трёх ничего не говорит о четвёртой. Если вы покупаете подписку, а не лицензию, спросите прямо: включён ли в реестр сам сервис, включён ли продукт, на котором он работает, и чем это подтверждается. Ответ про хранение данных в России на этот вопрос не отвечает — локализация данных требование отдельное и с реестром не связанное.
Сравнение в две колонки по четыре строки. Левая колонка «Звучит от поставщика»: «наш вендор в реестре», «платформа в реестре», «продукт в реестре с 2023 года», «решение на базе продукта из реестра». Правая колонка «Что в карточке»: «в перечне 4 продукта из 12», «модуль — отдельный продукт», «в записи предыдущая редакция», «доработка в реестр не попадает». Между колонками вертикальная линия с подписью «разница в одной строке карточки». Внизу отдельная плашка на всю ширину: «облачный сервис: российское облако — ещё не запись». Чертёжный стиль, подписи по-русски.
Что запись подтверждает, а что нет
Это место, где ошибаются уже не поставщики, а покупатели. Реестровая запись отвечает ровно на один вопрос — о происхождении продукта. Всё остальное проверяется другими способами и другими документами.
- Не подтверждает качество и работоспособность. Включение в перечень не означает ни аудита кода, ни нагрузочных испытаний, ни того, что продукт закроет вашу задачу. Функциональность проверяется пилотом, а не карточкой.
- Не подтверждает, что ваши данные лежат в России. Это требование 152-ФЗ, оно предъявляется к вам как к оператору персональных данных и выполняется независимо от того, что показала карточка.
- Не подтверждает отсутствие зарубежных компонентов внутри. В любом продукте есть открытые библиотеки и среды исполнения. Требование «все компоненты из реестра» буквально невыполнимо, и записывать его в техническое задание бессмысленно.
- Не гарантирует, что запись будет и через год. Состав перечня меняется: записи добавляют, изменяют и исключают. Значение имеет статус на дату заключения договора — и обязанность поставщика сообщить вам, если он изменится.
Продукт может выбыть из перечня уже во время эксплуатации, и по умолчанию последствия несёт покупатель: заново обосновывать закупку, а иногда и менять систему, придётся вам. Три пункта в договоре снимают большую часть этого риска — заверение о наличии записи на дату заключения, обязанность уведомить об исключении в согласованный срок и порядок действий сторон в этом случае. Формулировки удобно готовить вместе с остальными условиями — что ещё должно быть в договоре, мы разбирали в материале про договор на разработку.
Как встроить проверку в закупку
Проверка работает, только если она стоит в процессе раньше денег. Практический минимум — три действия, каждое из которых занимает меньше часа.
- 1Запишите требование проверяемо: продукт должен быть включён в реестр на дату заключения договора, поставщик указывает номер записи и наименование продукта в спецификации. Формулировка «система должна быть отечественной» непроверяема и на приёмке не работает.
- 2Запросите у поставщика три документа: справку с номером записи и полным наименованием продукта, спецификацию, в которой наименование совпадает с карточкой, и письмо о статусе записи на планируемую дату договора.
- 3Зафиксируйте в договоре заверение о наличии записи, обязанность уведомить об её изменении или исключении и порядок действий в этом случае. Дальше проверка на приёмке сводится к сверке номера в акте с номером в карточке.
Сколько это стоит и что стоит вместо этого. Модельный случай: компания с государственным участием, требование реестра прописано в собственном положении о закупке, шорт-лист из шести систем. Проверка всех шести вместе со сбором справок и оформлением файла решения — три часа работы руководителя подразделения по полной стоимости часа 1 800 ₽. Альтернатива — узнать о несоответствии после того, как закупочная комиссия уже согласовала выбор, и пройти цикл заново.
Диаграмма из двух столбиков с подписанными значениями в рублях. Левый низкий столбик «Проверка шорт-листа из 6 продуктов — 5 400 ₽», подпись под ним «3 часа». Правый высокий столбик «Повторный закупочный цикл — 106 800 ₽», разбитый на три сегмента с подписями «обоснование 16 800 ₽», «согласование 18 000 ₽», «демонстрации и сравнение 72 000 ₽». Справа от правого столбика вертикальная плашка «+6 недель к сроку». Между столбиками подпись «в 20 раз». Ось в рублях, единицы подписаны. Чертёжный стиль, подписи по-русски.
Если продукта нужного класса в реестре нет
Ситуация встречается регулярно и почти всегда в отраслевом и инженерном ПО, а не в офисном. Правильных ответов здесь три, и все три — рабочие. Неправильный ответ один: сделать вид, что подходящий продукт нашёлся, и подогнать под него класс.
- 1Обоснование невозможности закупки из перечня. Применимо, если требование к вам предъявляется как процедура: тогда отсутствие продукта нужного класса — это документ, а не проблема. Готовится один раз, хранится вместе с решением по проекту и переиспользуется в следующих закупках того же класса.
- 2Разделить поставку: реестровое ядро отдельно, заказная надстройка отдельно. Требование закрывается тем классом, который в перечне есть, а недостающая функциональность делается как работы, с правами на результат у вас. Это чаще всего и происходит на практике; главное — не смешивать лицензии и работы в одной строке спецификации.
- 3Отложить класс и закрыть задачу тем, что уже работает. Если процесс сегодня живёт в таблицах или внутри учётной системы, честнее оставить его там и вести список кандидатов на замену, чем покупать неподходящий продукт ради галочки. Через год перечень меняется, а неудачная покупка — нет.
Требование, которое нельзя принять по документу, не защищает никого — ни заказчика, ни поставщика.
Когда проверять не надо
Честная оговорка, без которой инструкция превращается в лишний ритуал. Для значительной части компаний правильный вывод — не открывать реестр вообще и выбирать систему по существу задачи.
- У вас нет государственных и муниципальных заказчиков, нет государственного участия в капитале, вы не субъект критической информационной инфраструктуры и требование не передано вам по контракту. Тогда реестр в вашем выборе не участвует. Кому обязанность действительно предъявляется, разобрано в статье про обязательность перехода.
- Вы покупаете работы, а не лицензии: настройку, интеграцию, доработку. Реестр относится к продуктам, и три четверти бюджета типового проекта автоматизации он не затрагивает.
- Вы заказываете систему под себя. В реестр она не попадёт по устройству процедуры, и вместо этого вопроса решается вопрос о правах на результат работ.
- Требование звучит не про реестр, а про размещение данных или про средства защиты. Это разные основания, и карточка на них не отвечает.
И обратный случай назовём так же прямо. Если требование к вам применимо, проверка перестаёт быть формальностью и становится первым фильтром шорт-листа — раньше сравнения функциональности, раньше демонстраций и раньше сметы. Пятнадцать минут на карточку в начале проекта стоят дешевле любого другого действия, которое вы сможете совершить позже. Всё описанное — по состоянию на сентябрь 2026 года; состав перечня и правила включения меняются, поэтому маршрут проверки важнее любого списка продуктов.
