Тендеры и лиды
Информация
Меня зовут Алексей Постригайло, я старший партнер ИТ-интегратора «Энсайн». В этом кейсе расскажу, как наш внутренний инструмент HConfig превратился в самостоятельный программный продукт, зачем мы решили включить его в реестр российского ПО и почему путь до реестровой записи оказался сложнее, чем мы ожидали.
HConfig появился из вполне практической задачи. Нам нужно было воспроизводимо настраивать Linux-серверы и меньше зависеть от ручных действий конкретного специалиста. Со временем внутренняя утилита выросла в продукт, который можно было использовать в проектах заказчиков. Когда мы начали рассматривать его для государственных заказчиков и инфраструктуры с повышенными требованиями к используемому ПО, возник логичный следующий шаг: включить HConfig в реестр российского программного обеспечения.
На старте нам казалось, что основная сложность будет бюрократической: правильно оформить документы, подтвердить права на программу, загрузить материалы и дождаться решения. На практике процедура заставила нас гораздо глубже разобрать сам продукт. Пришлось одновременно приводить в порядок юридическую историю HConfig, бухгалтерские документы, техническое описание, зависимости и сценарии эксплуатации.
Первую заявку мы подали 24 октября 2025 года. К ней приложили техническое задание, исходный код и свидетельства Роспатента. На тот момент HConfig уже использовался в рабочих системах, поэтому внутри команды пакет выглядел вполне убедительно.
Получили отказ.
Причины оказались достаточно приземленными. Домен с документацией был оформлен на физическое лицо, а не на компанию. Недостаточно подробно была описана модель бесплатного распространения. Не хватало акта ввода в эксплуатацию. Краткое техническое задание тоже не устроило экспертов.
Для нас это был первый полезный вывод. Наличие работающего продукта и наличие продукта, готового к формальной внешней проверке, — две разные вещи.
Внутри компании многое существует на уровне понятных всем договоренностей. Разработчик знает, где лежит документация. Команда понимает, кто создавал код и как разворачивалась система. Бухгалтерия ведет свои документы. Для внешнего эксперта этой внутренней логики не существует. Вся история продукта должна быть собрана в последовательную и доказуемую цепочку.
После первого отказа мы переоформили домен, расширили документацию и подготовили вторую заявку.
Она тоже не прошла.
На этот раз вопрос возник из-за правообладателей HConfig.
Несколькими годами ранее программа была зарегистрирована в Роспатенте. Правообладателями выступали компания и разработчик. На момент регистрации это выглядело естественно: специалист создавал код, компания предоставляла ресурсы и развивала продукт.
При подаче в реестр выяснилось, что такая конструкция требует отдельного комплекта подтверждающих документов. Стандартного набора оказалось недостаточно. Нужно было дополнительно оформлять отношения между правообладателями и полномочия на подачу заявления.
Это хороший пример того, почему подготовку к реестру опасно сводить к проверке одного свидетельства.
Важно не только доказать, что программа кому-то принадлежит. Нужно показать всю цепочку возникновения прав: кто создавал продукт, на каком основании, кому принадлежат исключительные права сейчас и кто имеет право действовать от имени всех правообладателей.
Если у программного продукта сложная история разработки, несколько авторов или несколько правообладателей, разбираться с этим лучше до подачи заявки. Иначе юридическая деталь легко превращается в еще один цикл регистрации.
После второй попытки мы решили запросить разъяснение причин отказа через поддержку. Честно говоря, ожидали формальный ответ со ссылкой на инструкции.
Получилось наоборот.
Сотрудник поддержки связался с нами и фактически разобрал заявку по пунктам. Стало понятно, каких документов не хватает и где именно наша логика расходится с требованиями процедуры.
Нам потребовались дополнительные документы по двум правообладателям, подтверждение отсутствия соответствующих выплат иностранным лицам, а также бухгалтерские документы по созданию и учету программного обеспечения. Отдельное внимание пришлось уделить формату материалов и тому, как они подаются.
После этого регистрация перестала выглядеть как абстрактный список требований. Мы начали воспринимать ее как полноценный проект со своими треками: юридическим, бухгалтерским и техническим.
Именно здесь скрывается одна из главных сложностей. Юрист видит права. Бухгалтерия видит нематериальный актив. Разработчик видит код. Системный администратор видит зависимости и окружение. В заявке все эти части должны описывать один и тот же продукт без противоречий.
Параллельно мы проходили техническую часть подготовки.
Здесь уже недостаточно было подтвердить, что код существует. Нужно было показать, что HConfig является самостоятельным продуктом, описать его зависимости и подтвердить возможность эксплуатации в заявленной среде.
Отдельно разбирали используемый стек. Пришлось документировать работу с Python, модулями и репозиториями операционной системы. Некоторые участки продукта потребовали пересмотра из-за используемых компонентов.
Еще один принципиальный вопрос: HConfig не должен выглядеть как небольшая оболочка над сторонним программным продуктом. Мы подтверждали самостоятельность решения и описывали его работу с РЕД ОС 8.
Для интегратора такой подход понятен. Если система предполагает длительную эксплуатацию у заказчика, недостаточно знать, что она запускается сегодня. Нужно понимать, от каких внешних компонентов она зависит и что произойдет при изменении этих компонентов.
Это особенно заметно в изолированных контурах.
Эксперты отдельно интересовались тем, как HConfig будет работать без доступа в интернет. Нам пришлось описывать сценарии автономной эксплуатации, работу с сертификатами и отсутствие критической зависимости от внешних сервисов.
Фактически вопрос звучит просто: если убрать интернет и внешнюю инфраструктуру, сохранит ли продукт свою работоспособность в заявленном сценарии?
Для корпоративного ПО это полезный тест независимо от того, планирует компания попадать в реестр или нет.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13838 тендеров
проведено за восемь лет работы нашего сайта.
Отдельный объем работы появился вокруг документации.
Внутри технической команды часто достаточно README, нескольких инструкций и накопленного опыта специалистов. Разработчики понимают, что происходит в системе, потому что сами ее создавали.
Эксперт находится в совершенно другой позиции.
Он должен получить экземпляр программы и самостоятельно пройти путь от установки до работающей системы. Поэтому потребовалось полноценное руководство с требованиями к окружению, последовательностью развертывания и описанием архитектуры. Причем инструкция должна была учитывать конкретную среду проверки.
После этого мы стали иначе смотреть на техническую документацию вообще.
Есть простой критерий ее качества: сможет ли квалифицированный специалист, который раньше не видел продукт, установить его и понять устройство системы только по переданным материалам.
Если для этого обязательно нужен звонок разработчику, документация пока описывает знания команды, а не продукт.
В сумме юридическая и техническая часть потребовали десятки человеко-часов. Причем значительная часть времени уходила не на создание новых сущностей, а на формализацию уже существующих.
Нужно было описать архитектуру, собрать подтверждающие документы, привести в порядок бухгалтерскую часть и подготовить инструкции. Затем каждый документ требовалось разместить в соответствующем разделе заявления.
По масштабу это оказалось сопоставимо с отдельным небольшим внутренним проектом.
Поэтому я бы не советовал воспринимать регистрацию как задачу, которую можно передать одному сотруднику со словами «собери документы к пятнице». Особенно если продукт долго развивался внутри компании и раньше никто специально не выстраивал его документальную историю.
После трех попыток HConfig был включен в реестр российского ПО под номером 32983.
Для нас ценность результата оказалась шире самой записи.
Во-первых, мы получили формально подтвержденный статус продукта, который имеет значение для проектов с требованиями к российскому программному обеспечению.
Во-вторых, сама подготовка заставила нас провести инвентаризацию HConfig. Мы уточнили права, описали архитектуру, разобрали зависимости, улучшили документацию и проверили сценарии автономной эксплуатации.
В-третьих, продукт стал меньше зависеть от знаний конкретных людей внутри команды. Это уже влияет не на формальную регистрацию, а на качество дальнейшей эксплуатации и поддержки.
Именно этот эффект я считаю самым полезным.
Если бы мы проходили этот путь заново, то начинали бы не с формы заявления.
Сначала проверили бы правообладателей и всю историю возникновения прав на код. Затем собрали бы документы о создании и учете продукта, убедились бы, что домены и публичная документация оформлены корректно. Параллельно техническая команда должна описать архитектуру, внешние зависимости и сценарии эксплуатации.
После этого имеет смысл отдать продукт специалисту, который раньше с ним не работал, и попросить установить систему только по инструкции.
Если он не сможет это сделать, проблема почти наверняка обнаружится и на внешней проверке.
Еще один вывод из нашего опыта — стоит пользоваться поддержкой и уточнять требования, если ситуация отличается от типовой. После второго отказа именно такой разбор помог нам быстрее увидеть пробелы в заявке и перестать действовать методом предположений.
До начала процесса мы воспринимали включение HConfig в реестр российского ПО в первую очередь как административную процедуру.
После трех попыток отношение изменилось.
Регистрация действительно требует большого количества документов. Но за этим находится вполне инженерная логика: у продукта должны быть понятные правообладатели, воспроизводимая установка, описанная архитектура и контролируемые зависимости.
Если все эти вопросы начинают решаться только перед подачей заявки, процесс становится долгим и дорогим.
Если они заложены в жизненный цикл продукта заранее, регистрация превращается из экстренной сборки документов в проверку того, что компания и так должна знать о собственном ПО.
Для нас HConfig стал именно таким кейсом. Запись в реестре была конечной целью процесса, но по дороге мы получили гораздо более формализованный и управляемый программный продукт.
Здесь я обычно пишу про проекты, кейсы и ИТ-практику. А если хочется увидеть меня не только в рабочих текстах — приходите в мой ТГ https://t.me/alekseypostrigaylo. Там — сын, поездки, работа за кадром, личные наблюдения и попытка жить так, чтобы было что вспомнить.
