Реестр отечественного ПО перевалил за 15 000: как правильно писать ТЗ под закупку и что смотреть на приёмке

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

Откуда растут проблемы

Нас зовут на этот участок работы по-разному: одни клиенты с самого начала просят помочь с ТЗ, другие приходят когда поставщик уже выбран и начинается приёмка - а там выясняется, что с техническим заданием что-то пошло не так. Второй сценарий неприятнее, потому что исправлять сложнее.

Типичная цепочка ошибок начинается в момент, когда в ТЗ пишут «программный продукт должен быть включён в реестр отечественного ПО» - и считают, что этого достаточно. Это не достаточно.

Что нужно проверить до того, как писать ТЗ

Первое - класс ПО в реестре. Реестр структурирован по классам: операционные системы, офисное ПО, СУБД, средства виртуализации и так далее. Если вам нужна СУБД, а продукт числится в реестре в классе «инструменты разработки» - это формально не то. В ТЗ стоит прямо указывать нужный класс, иначе недобросовестный поставщик легко сыграет на размытости формулировки.

Второе - правообладатель и страна регистрации. Само по себе включение в реестр не гарантирует, что правообладатель - российское юрлицо без иностранного участия свыше 50%. Минцифры проверяет это при включении, но реестр обновляется непрерывно, а ситуации у компаний меняются. Для государственных заказчиков, которых касаются ограничения по 44-ФЗ, это существенно: если поставщик не может подтвердить структуру владения, вопрос встанет при проверке.

Третье - актуальность версии. В реестре продукт числится в определённой версии или версионном диапазоне. Поставщик может привезти более новую версию, которая формально ещё не прошла реестровую процедуру, - и это нужно либо предусмотреть в ТЗ отдельным условием, либо зафиксировать, какая именно версия допустима.

Четвёртое - совместимость с сертификатами ФСТЭК, если она нужна. Реестровый номер и сертификат ФСТЭК - это два независимых атрибута. Мы про это уже писали в контексте приказа ФСТЭК №76: для ГИС второго и третьего класса нужно и то, и другое. Часть заказчиков об этом не думает при составлении ТЗ, а потом обнаруживает на приёмке, что реестровый продукт без нужного сертификата - не то, что им требовалось.

Как это выглядит в ТЗ

Конкретная формулировка важна. Вместо абстрактного «отечественное ПО» в ТЗ стоит прописывать:

• класс ПО согласно классификатору реестра;
• требование наличия действующей записи в реестре на момент заключения контракта (не на момент подачи заявки - записи могут исключаться);
• требование предоставить реестровый номер в составе заявки;
• требование подтвердить версию - номер сборки или релиза, который будет поставляться;
• если нужен сертификат ФСТЭК - его класс и уровень доверия отдельным пунктом.

Это не бюрократическое усложнение - это страховка от ситуации, когда победитель тендера поставляет то, что формально соответствует размытому ТЗ, но не соответствует реальной потребности.

Что проверять на приёмке

Если ТЗ написано без ошибок, приёмка становится проще: есть чёткие критерии, с которыми сверяешься. Если ТЗ размыто - приёмка превращается в переговоры.

Три вещи, которые мы обязательно проверяем при сопровождении приёмки:

Соответствие версии. Что реально установлено на серверах, совпадает с тем, что указано в документах поставщика и в реестровой записи. Это звучит очевидно, но мы видели кейс, где поставщик привёз production-версию, а в документах указал version string от другого релиза.

Действующий статус реестровой записи. Открываем реестр и проверяем запись на дату приёмки. Между заключением контракта и приёмкой проходит время - за это время запись теоретически может измениться. Один раз такое видели вживую: поставщик со временем приёмки имел запись, но она была приостановлена - ситуация разрешилась, но нервов стоила.

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

Импортозамещение создаёт давление на весь процесс

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

Сопровождение тендерной документации по части реестра - это методическая работа, которую, к сожалению, часто недооценивают до момента, когда что-то уже пошло не так. В рамках аудита закупочной документации мы проверяем ТЗ до его публикации - обычно это несколько часов работы, которые экономят куда больше на этапе приёмки или разбора претензий.