Критерии оценки отечественных ИТ-решений: что определяет выбор заказчика в 2026 году

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

В 2026 году заметно, что наличие отечественного происхождения само по себе уже не является достаточным аргументом для выбора. Для государственных и регулируемых организаций значение имеют требования к происхождению и статусу ПО, в том числе наличие записи в соответствующем реестре. 

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

Реестр: необходимое, но недостаточное условие

Регуляторные требования в 2026 году

Регуляторные требования к использованию российского и доверенного ПО также меняются. В 2026 году для заказчиков важно учитывать не только статус конкретного продукта в реестрах, но и требования, применимые к их организации, инфраструктуре и классу используемого ПО. Для отдельных классов сроки начинаются с сентября 2026 года и продолжаются в 2027-2028 годах.

Однако наличие записи в реестре не равно доказательству технологической зрелости!

Что нужно проверить сверх реестра

Заказчику важно проверять отдельно, насколько решение закрывает конкретные сценарии его инфраструктуры:

• Поддерживает ли оно нужные протоколы?
• Как работает с существующими приложениями?
• Какие есть ограничения по масштабированию?
• Как устроено резервирование?
• Что происходит при отказе одного из компонентов?
• Насколько предсказуемо ведет себя система при обновлении?

В крупных проектах эти вопросы определяют итоговую стоимость владения.

Оцениваем функциональность в контексте инфраструктуры

Одна из распространенных ошибок при выборе ПО заключается в сравнении таблиц функций. У одного продукта напротив пункта стоит «Есть», у другого тоже, и кажется, что различий, в общем-то, и нет.

А на практике одинаковое название функции может означать совершенно разный уровень возможностей и реализации.

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

Это проявляется заметно при импортозамещении Active Directory (AD). Российские каталоги могут использовать другие архитектурные подходы и, конечно, не обязаны повторять все возможности AD один в один, поэтому задача заказчика заключается не в поиске продукта с максимально длинным feature list, а в проверке собственных критичных сценариев.

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

А что с масштабированием?

Пилот на сотнях пользователей ничего не говорит о десятках тысяч

Пилот на нескольких сотнях пользователей практически ничего не говорит о поведении системы в организации с десятками тысяч учетных записей. Давайте разберем почему:

• при росте инфраструктуры меняется характер нагрузки;
• увеличивается объем репликации, количество одновременно выполняемых операций, число запросов к каталогу;
• становятся заметными особенности топологии контроллеров и сетевого взаимодействия.

Для заказчика это означает простое правило: производительность необходимо проверять на объеме, максимально близком к промышленному.

Что тестировать кроме массового создания пользователей

Причем тестировать нужно не только массовое создание пользователей. В реальном проекте важны операции с группами, изменение членства, синхронизация атрибутов, удаление и повторное создание объектов, восстановление после сбоя. Если речь идет о миграции – отдельно проверяется способность инструмента повторно запускать операции без неконтролируемого дублирования.

Идемпотентность

Здесь появляется понятие идемпотентности. Повторный запуск операции после сбоя не должен разрушать уже перенесенные данные или создавать новую копию каждого объекта. Для больших инфраструктур это уже практический способ сократить окно обслуживания.

Интеграции важнее красивого интерфейса

Веб-интерфейс сегодня стал практически обязательным атрибутом корпоративного ПО. Некоторые отечественные продукты сделали управление инфраструктурой значительно удобнее именно за счет web UI.

Но удобство администратора не должно подменять оценку интеграционных возможностей.

Корпоративное решение редко существует изолированно. Оно взаимодействует с системами информационной безопасности, средствами мониторинга, SIEM, резервным копированием, IDM, сервис-деском и прикладными системами.

Поэтому при выборе я бы обязательно задавала вопрос: какие события система способна отдавать наружу и насколько полно можно контролировать происходящее внутри нее?

Это важно с точки зрения информационной безопасности. Если изменение состава привилегированной группы произошло, служба ИБ должна иметь возможность узнать об этом, установить источник операции и сопоставить событие с политикой доступа.

С этой точки зрения ценность продукта определяется уже не отдельной функцией, а тем, насколько органично он встраивается в существующий контур управления.

Безопасность начинается с процесса обновлений

Что проверять у разработчика

В случае инфраструктурного ПО безопасность нельзя оценивать только по наличию сертификатов или заявленных механизмов защиты.

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

Поэтому на этапе выбора стоит изучать:

• процесс выпуска исправлений;
• историю обновлений;
• сроки реакции на уязвимости;
• организацию технической поддержки.

Доверенное ПО и ответственность заказчика

В 2026 году это становится еще актуальнее и с точки зрения регулирования. Российская нормативная база постепенно развивает отдельные требования к доверенному отечественному ПО. С 1 марта 2026 года действует отдельный перечень доверенного российского ПО, формирование и ведение которого регулируется постановлением Правительства № 1931, а для ряда категорий ПО предусмотрены дополнительные критерии и переходные сроки.

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

Компетенции или лицензия?

Еще один критерий, который часто недооценивают в процессе закупки, – это наличие специалистов.

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

Экосистема вокруг вендора

Поэтому я бы оценивала не только самого вендора, но и экосистему вокруг него:

• Есть ли интеграторы?
• Насколько подробно документирована система?
• Можно ли получить техническую консультацию?
• Как решаются нестандартные инциденты?
• Есть ли практика внедрения в организациях сопоставимого масштаба?

Bus factor

Отдельный вопрос касается зависимости от конкретного специалиста. В ИТ-проектах хорошо известен термин bus factor. Он показывает, насколько сильно результат зависит от одного или нескольких сотрудников, обладающих уникальными знаниями. Если вся эксплуатация сложной системы держится на одном инженере, это уже полноценный операционный риск.

Стоимость владения считают после внедрения

Из чего складывается TCO

Цена лицензии или подписки хорошо видна в коммерческом предложении. А стоимость владения становится понятна значительно позже.

В совокупную стоимость владения обычно приходится учитывать не только приобретение самого продукта, но и:

• инфраструктуру;
• резервирование;
• поддержку;
• обучение специалистов;
• интеграцию;
• последующее сопровождение.

При выборе решения полезно заранее построить хотя бы упрощенную модель TCO (Total Cost of Ownership, совокупная стоимость владения) на несколько лет.

Стоимость переходного периода

Особое внимание стоит уделить стоимости переходного периода. Если отечественный продукт предполагает длительное сосуществование с Microsoft Active Directory, заказчику потребуются механизмы синхронизации, причем синхронизировать придется не только учетные записи. В зависимости от архитектуры проекта речь может идти о паролях, группах, атрибутах и изменениях прав доступа.

В проектах миграции для этого применяются специализированные средства автоматизации. Например, Pragmatic Tools Migrator может использоваться для переноса доменной структуры из Microsoft Active Directory в каталоги, поддерживаемые отечественными ОС, а также для двусторонней синхронизации каталогов в период гибридной эксплуатации.

Для заказчика в данном случае важен прежде всего сам принцип: переходная инфраструктура должна оставаться управляемой до момента полного вывода старой среды из эксплуатации.

Пилот должен отвечать на неприятные вопросы

Хороший пилот нужен, чтобы найти слабые места до промышленного внедрения.

Поэтому тестировать стоит именно проблемные сценарии:

• Что произойдет при отказе контроллера?
• Как поведет себя репликация?
• Можно ли восстановить систему после сбоя?
• Как переносится существующая структура групп?
• Что происходит с правами на файловые ресурсы?
• Как работает интеграция с конкретными корпоративными приложениями?

Если продукт предполагается использовать для миграции, нужно провести полноценную репетицию. Желательно использовать копию или репрезентативный срез реальной структуры, а не искусственный стенд из нескольких десятков объектов.

Чем дороже ошибка в промышленной среде, тем дешевле становится полноценное стендовое испытание.

Итоги

В 2026 году выбор заказчиком отечественного ИТ-решения становится комплексным:

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

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

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

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

Изображение на обложке: Pragmatic Tools, генерация ChatGPT