Тезисы доклада Михаила Крихели о рисках текущей системы импортозамещения.
Импортозамещение, которое не работает.
Уважаемые коллеги, сегодня много говорится о цифровой трансформации и импортозамещении.
Однако главный вопрос остаётся без ответа: кто реально отвечает за то, чтобы технология работала не в день приёмки, а через пять или десять лет?
Современная практика реестров создаёт иллюзию управляемости. Продукт внесён в список, формальные требования выполнены, отчёт сдан.
Для конечного пользователя это почти ничего не гарантирует: ни устойчивости, ни эффективности, ни долгосрочного результата.
В итоге мы получаем технологическую стагнацию под видом импортозамещения.
ИТ компании вместо создания новых решений вынуждены копировать западные продукты десятилетней давности, чтобы просто попасть в критерии отбора. Заказчики внедряют не лучшее, а то, что формально соответствует реестру. Бюджетные деньги идут не на развитие, а на поддержание бумажного соответствия.
Это противоречит тому, о чём неоднократно говорил Президент: импортозамещение должно вести к технологическому лидерству, а не ограничиваться формальной заменой продуктов.
Суверенитет всё чаще измеряется наличием записи в базе данных, а не реальной устойчивостью системы и способностью страны самостоятельно развивать критические технологические контуры. Подмена понятий наличие в реестре и реальная безопасность — это опасная иллюзия.
Ярким примером такой иллюзии является проблема лоскутного одеяла, с которой сегодня сталкиваются крупнейшие заказчики.
Пытаясь соответствовать формальным требованиям, организация собирает критическую систему из десяти разных продуктов разных вендоров. В реестре каждый из них является чемпионом. Однако, когда их соединяют в один контур, они начинают конфликтовать на уровне ядер и протоколов, так как не тестировались на совместимость.
В результате ИТ служба заказчика превращается в пожарную команду, которая круглосуточно латает дыры в интеграции. Разработчики ПО кивают друг на друга, регулятор ссылается на реестр, а за общую работоспособность системы не отвечает никто. Мы получили кирпичи российского происхождения, но не построили из них устойчивое здание.
Нужна смена парадигмы, переход от формального списка к архитектурному мышлению. Реальная зрелость системы определяется не статусом продукта, а тем, насколько технологии, данные, процессы и люди связаны в работающий контур. Сегодня ответственность за результат деперсонализирована. Она фактически перекладывается на регуляторов, которые не эксплуатируют системы и не живут с их последствиями. Такая модель нежизнеспособна.
Реальная ответственность должна лежать там, где создаётся и потребляется ценность. Разработчики отвечают за качество кода, ИТ службы заказчика несут ответственность за архитектурную связность, а конечные пользователи отвечают за эффективность применения.
Проблема реестров глубже, чем кажется. Они разрывают цепочку ответственности ещё на входе. Стратегические решения принимаются без архитектурного владельца. Закупка ориентируется на формальное соответствие спискам и регламентам. Реализация и эксплуатация перекладываются на ИТ-команды и заказчиков. В момент сбоя формально все этапы пройдены, но ответственного за целостный результат не существует.
Эта же разорванная цепочка ответственности проявляется и в управлении инвестициями. Миллиарды, направленные на цифровизацию, часто не превращаются в активы, потому что решения советов директоров, закупочные процедуры и формальные KPI обнуляют эффект вложений. Подробнее об этом в статье Как крупному бизнесу перестать субсидировать хаос и перейти к капитализации технологий.
Роль реестра должна быть пересмотрена. Реестр может и должен быть информационным ориентиром и инструментом прозрачности. Но он не может подменять собой архитектурную экспертизу и персональную профессиональную ответственность.
Особенно ярко это видно в силовых структурах. Там решения принимаются не по спискам, а исходя из архитектуры, рисков и личной ответственности, потому что цена ошибки неприемлемо высока. Именно такой подход даёт устойчивость и должен стать нормой для всей страны.
Импортозамещение не является заменой одного продукта на другой при сохранении старой логики. Если архитектура и процессы остаются прежними, то через год или два система либо деградирует, либо начинает работать хуже западного оригинала. Это не суверенитет, а имитация.
Для перехода к реальному лидерству нам необходимо:
1) Сместить фокус с продуктовых карточек на проектирование целевой архитектуры систем.
2) Ввести национальные стандарты архитектурной совместимости, чтобы продукты из реестра гарантированно работали друг с другом.
3) Вернуть субъектность и ответственность за выбор ИТ службам заказчиков, сделав реестры инструментом анализа рынка и лучших практик, а не пропускным пунктом.
4) Адаптировать технологии под развитие бизнеса и государства, а не под статичные требования прошлых лет.
Выиграют те, кто умеет собирать сложные контуры и лично отвечать за результат. Если мы не вернём ответственность туда, где она должна быть, любые списки будут не усиливать, а ослаблять технологическую мощь страны.
При всем этом возникают вопросы:
1) Зачем превращать реестр в простой ориентир, если сейчас он защищает рынок от скрытого иностранного софта?
Мой ответ заключается в том, что реестр как фильтр происхождения кода обязан сохраниться. Однако сегодня он превратился в конечную остановку и формальную гарантию закупки. Суверенитет — это не просто отсутствие иностранных строк в коде, а возможность бесшовно заменить любой элемент системы без её обрушения. Если продукт из реестра невозможно интегрировать в отечественный контур без сложнейших доработок, его наличие в списке никак не помогает нашей безопасности. Мы предлагаем дополнить проверку кода обязательной проверкой архитектурной зрелости и совместимости.
2) Кто должен определять новые стандарты совместимости и не создаст ли это новую волну бюрократии?
Стандарты должны диктовать крупнейшие заказчики и лидеры ИТ рынка, которые ежедневно эксплуатируют системы в реальных условиях. Это должна быть живая экосистема совместимости, а не очередной ГОСТ, написанный в кабинетах. Мы предлагаем создать технологические полигоны, где вендоры на практике доказывают, что их решения работают в связке с другими продуктами из реестра. Это не бюрократия, а необходимый технологический контроль качества.
3) Не приведет ли передача ответственности заказчикам к росту коррупции и попыткам вернуться к западным решениям?
Сегодняшнее бумажное соответствие реестру как раз и служит идеальным прикрытием для неэффективных закупок. Когда чиновник говорит, что он купил товар из списка, он автоматически снимает с себя ответственность за то, что система в итоге не работает. Мы же предлагаем вернуть персональную ответственность за работоспособность и результат. Если руководитель ИТ службы сам выбирает архитектуру, он отвечает своей должностью за то, чтобы через несколько лет система развивалась и приносила пользу. Реальная ответственность является лучшим антидотом от имитации деятельности.
4) Проектирование архитектуры является сложным процессом, а у многих ведомств просто нет кадров такого уровня. Как быть в этой ситуации?
Содержать лоскутную систему, которая постоянно падает и требует бесконечных вложений в доработку интеграций, обходится государству гораздо дороже. Отсутствие квалифицированных кадров не является поводом упрощать государственное управление до уровня формальных списков. Напротив, институты развития и ведущие технологические консорциумы должны стать центрами компетенций. Они помогут ведомствам проектировать правильную архитектуру на старте, а не просто одобрять закупку очередных программных коробок.
Спасибо за внимание!
Связанные материалы:
Страница Михаила Крихели на сайте Федерал-пресс.
Стратегические беседы с Михаилом Крихели.
Интеллектуальный капитал как новая нефть России. Почему мы упускаем цифровое будущее?
Консорциум представил в Совет при Президенте РФ перечень актуальных потребностей ИТ-бизнеса