← Предыдущая статья

Суверенитет обсуждают регулярно. Его уже можно не выносить отдельной темой: он и так появляется в обычном разговоре про корпоративные ИТ, инфраструктуру, ERP, данные, безопасность и даже ИИ.

Однако чем чаще звучит это слово, тем сильнее хочется задать неприятный, почти детский вопрос: чем мы его измеряем?

Не в смысле «кто за счет каких продуктов продвинулся по пути независимости». Тут обычно хватает докладов, дорожных карт и уверенных формулировок. А в смысле: по каким показателям видно, что конкретный ИТ-контур стал более самостоятельным, управляемым и устойчивым, чем это было бы в случае использования программно-аппаратных комплексов недружественных стран?

Факты

По итогам АКПО-Конф 2026

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

В пост-релизе зрелость рынка описана через совместимость решений, надежность под промышленной нагрузкой, встроенную кибербезопасность и готовность разработчиков работать в логике крупного заказчика.

В утренней пленарной дискуссии этот общий вопрос несколько раз раскладывался на более прикладные моменты.

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

При этом в том же выступлении прозвучала важная оговорка: движение идет неравномерно. В потребительских онлайн-сервисах и ряде цифровых платформ замещение выглядит увереннее. В микроэлектронике, робототехнике и части средств защиты информации остаются заметные разрывы. Для средств защиты это не отвлеченная тревога: указ Президента РФ № 250 прямо вводит запрет на использование средств защиты информации из недружественных государств для ряда органов и организаций с 1 января 2025 года недопустимым (официальное опубликование правовых актов, Право.ру). Значит, вопрос уже не только в стратегии, а в конкретном сроке, после которого старый вариант стал.

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

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

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

Российские реалии

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

Реестр российского ПО важен: он дает формальный статус продукта, нужен для закупок, льгот и регуляторной рамки. Но сам по себе реестр не отвечает на вопрос, выдержит ли конкретный контур вашу нагрузку, вашу архитектуру, ваши интеграции и ваш регламентный ужас в конце месяца (реестр российского ПО, Реестр).

Регулирование критической информационной инфраструктуры задает другую рамку. 187-ФЗ описывает безопасность КИИ через устойчивое функционирование при компьютерных атаках. Здесь снова важен не паспорт решения, а реальная, проверенная опытом, способность контура продолжать работу в условиях атаки, сбоя или инцидента (187-ФЗ о безопасности КИИ, Кремль).

Опыт эксплуатации SAP

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

Внешний SAP-фон здесь тоже полезен, но именно как фон. Исследования пользовательских SAP-сообществ показывают: ценность системы проявляется не в одной системе самой по себе, а в процессах, данных, аналитике, приложениях и связях между SAP- и не-SAP-решениями. Это не про российское импортозамещение напрямую, но про тот же взрослый вопрос: система ценна не названием, а работой в контуре (исследование SAP и ASUG, SAP).

Редакционное наблюдение

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

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

Все это важно. Но это разные показатели.

Отсюда и ощущение тумана. Не потому, что суверенитет — пустое слово. А потому, что слово слишком широкое по смыслу и пока не собрано в единую шкалу оценки.

Попытка объяснения

Возможно, мы буксуем именно там, где одну шкалу незаметно подменяют другой.

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

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

Поэтому происхождение продукта важно, но это только один показатель. Пусть даже первый, но он не единственный.

Возможно, стоит ответить на несколько вопросов, без которых разговор о суверенитете будет оставаться слишком общим.

Первый: кто контролирует данные? Не в рекламном смысле, а буквально. Где они находятся? Кто управляет доступом? Кто понимает их структуру? Кто может восстановить их после сбоя? Кто знает, какие данные критичны, а какие просто годами копились «на всякий случай»?

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

Третий: что происходит под нагрузкой? Суверенитет, который хорошо выглядит только на демонстрации, — слабое утешение. Промышленная система должна выдерживать рабочий объем, пики, интеграционные сбои, закрытие периода и живых пользователей. Особенно живых пользователей. Они, как известно, редко ведут себя как аккуратный тестовый сценарий.

Четвертый: как устроена безопасность? Не как отдельная наклейка поверх системы, а как часть архитектуры, разработки, эксплуатации, мониторинга и реакции на инциденты. Иначе выходит знакомая конструкция: дверь железная, замок дорогой, а рядом в стене аккуратная дыра.

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

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

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

Это не аргумент против импортозамещения. Совсем наоборот. Но это аргумент против самоуспокоения.

Гипотеза

Следующий откровенный разговор об ИТ-суверенитете будет идти не вокруг общего вопроса «свое или не свое», а вокруг набора проверяемых показателей.

Что контролируем? Что можем сопровождать? Что выдерживает нагрузку? Что защищено? Что восстанавливается? Что можно развивать без героизма? Где риск ошибки уже слишком высок?

Ответить на подобные вопросы поможет лишь ваш опыт.

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

Пишите на y.nechitaylov@sappro.ru, в комментариях к соответствующим постам Telegram-канала или в комментариях под этими материалами на sappro.ru.

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

Автор

Юрий Нечитайлов, главный редактор SAP Professional Journal Россия