Мировая конкурентоспособность России

Архитектура пятилетней Программы «Мировая конкурентоспособность России»

********
© В.К. Петросян (Вадимир) © Lag.ru [Large Apeironic Gateway, Большой Апейронический Портал (Шлюз), Суперпортал в Бесконечность].
При копировании данного материала и размещении его на другом сайте, ссылки на соответствующие локации порталов Lag.ru и Proza.ru обязательны 

Работа написана на основе концепции и разработок В.К. Петросяна при творческом и техническом участии ChatGPT 5.6. Thinking, Sol - Демичат Сапиенс (Саппи), Солярис.
*********


Предыдущие главы последовательно сформировали три слоя будущей программы.

Первый слой — диагностика.

Были определены:

мировой frontier;
структура конкурентоспособности;
основные российские разрывы;
причины этих разрывов;
критические bottleneck.
Второй слой — субпрограмма-минимум.

Она отвечает на вопрос:

какие доказанные мировые механизмы необходимо воспроизвести, адаптировать и масштабировать, чтобы вывести Россию к прогнозируемому мировому top-3?

Третий слой — субпрограмма-максимум.

Она отвечает на другой вопрос:

где Россия способна не просто догнать существующий frontier, а создать более сильную национальную систему следующего поколения?

Теперь оба контура необходимо превратить в единую систему исполнения.

Именно на этом этапе стратегия должна перестать быть совокупностью:

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

Каждое преобразование должно иметь:

причинное основание;
измеримый результат;
владельца;
ресурс;
срок;
зависимости;
KPI;
критерий прекращения или масштабирования.
Поэтому архитектура пятилетней Программы «Мировая конкурентоспособность России» должна строиться не вокруг ведомств и не вокруг заранее выделенных бюджетов.

Она должна строиться по цепочке:

мировой benchmark ; российский разрыв ; первопричина или frontier-гипотеза ; решение ; мероприятие ; ресурс ; владелец ; KPI ; фактический результат.

Именно эта причинная прослеживаемость отличает национальную программу преобразований от обычного перечня мероприятий.

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

На аналитическом уровне может быть правильно установлено:

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

провести форум;
создать рабочую группу;
разработать концепцию;
организовать конкурс;
сформировать центр.
Так возникает потеря причинной связи.

Мероприятие существует, но неясно:

какую именно первопричину оно устраняет и насколько изменит конечный outcome.

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

Стадия 1. Зафиксировать разрыв
Например:

время типового инвестиционного процесса значительно выше benchmark.

Стадия 2. Декомпозировать
Почему?

повторный сбор данных;
последовательные согласования;
отсутствие SLA;
инфраструктурные задержки;
нормативные коллизии.
Стадия 3. Выделить первопричины
Не все факторы одинаково значимы.

Необходимо определить те, которые объясняют основную часть потери времени.

Стадия 4. Выбрать механизм решения
Это может быть:

международная практика;
лучшая российская практика;
новое frontier-решение.
Стадия 5. Спроектировать мероприятие
Только теперь возникает проект.

Например:

не:

«цифровизация инвестиционного процесса»

а:

«создание единого end-to-end инвестиционного контура, устраняющего повторное предоставление данных и переводящего независимые согласования в параллельный режим, с целевым сокращением медианного времени от инвестиционного решения до готовности площадки на X процентов».

Такое мероприятие уже связано с outcome.

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

И обратное правило:

критическая первопричина без мероприятия означает неполноту программы.

7.2. Архитектура мероприятий конкурентоспособности
Пятилетняя программа не должна состоять из одного типа решений.

Конкурентоспособность — свойство системы.

Следовательно, преобразования должны охватывать несколько взаимосвязанных классов.

Основные типы:

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

Например, повышение технологической производительности среднего промышленного предприятия может потребовать одновременно:

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

Три крупных контура портфеля
Весь портфель целесообразно разделить на три контура.

Контур А. Сокращение текущего разрыва
Это мероприятия субпрограммы-минимум.

Их основа:

доказанная проблема;
доказанное мировое или российское решение;
высокая вероятность эффекта.
Контур Б. Создание нового frontier
Это мероприятия субпрограммы-максимум.

Их отличает:

более высокая неопределенность;
экспериментальный режим;
stage-gate;
возможность раннего stop.
Контур В. Общие национальные capabilities
Они необходимы многим направлениям одновременно.

Например:

данные;
compute;
talent infrastructure;
interoperability;
project management;
benchmarking;
система измерения.
Контур В особенно важен.

Если каждая субпрограмма будет создавать собственные:

данные;
цифровые платформы;
учебные центры;
аналитические системы,
возникнут:

дублирование;
несовместимость;
избыточные затраты.
Размер портфеля
Число мероприятий не должно становиться нормативной квотой.

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

Главный критерий:

достаточен ли портфель для устранения основных причин разрыва и реализации ключевых frontier-гипотез?

Не:

достигнуто ли заранее заданное количество мероприятий?

7.3. Институциональные мероприятия
Институциональные мероприятия меняют устойчивые правила и механизмы взаимодействия.

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

Возможные направления
1. Персонализация ответственности за outcome
Каждый крупный результат программы получает одного владельца.

2. Институционализация regulatory predictability
Для ключевых инвестиционных сфер вводятся:

обязательные transition periods;
единые правила интерпретации;
процедуры предварительного обсуждения значимых изменений.
3. Новая архитектура коммерциализации исследований
Функции:

защита интеллектуальной собственности;
proof-of-concept;
first customer;
технологический трансфер.
4. Институциональная поддержка scale-up
Отдельный контур для компаний, уже доказавших:

рынок;
технологию;
способность расти.
5. Институты long-term capital
Развитие механизмов финансирования с горизонтом, соответствующим:

промышленности;
инфраструктуре;
технологиям.
6. Система национального benchmarking
Международный и внутрироссийский benchmarking становится постоянной функцией, а не разовым исследованием.

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

Иначе вместо конкурентоспособности возникает институциональная инфляция:

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

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

можно ли изменить функцию, полномочия или incentive существующего института?

И только затем создавать новый.

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

Их цель — не механическая дерегуляция.

Цель:

минимально необходимая стоимость достижения общественно значимого результата.

Основные направления
1. Regulatory inventory
Полный цифровой реестр существенных требований к бизнесу.

2. Zero-based review
Для наиболее дорогих процедур задается вопрос:

создали бы мы такое регулирование сегодня с нуля?

3. Once-only data
Запрет повторного запроса данных, уже находящихся в легально доступных государственных системах.

4. Risk-based control
Контрольная нагрузка зависит от реального риска.

5. Машиночитаемое регулирование
Формализуемые нормы получают structured digital representation.

6. Compliance automation
Часть требований проверяется автоматически.

7. Regulatory SLA
Для решений устанавливаются:

сроки;
критерии;
прозрачная эскалация.
8. Experimental legal regimes
Для новых технологий создается контролируемая среда тестирования.

Главный KPI
Не число отмененных требований.

А:

сокращение полной регуляторной и административной стоимости бизнеса при сохранении либо улучшении качества регулирования.

7.5. Финансовые мероприятия
Финансовый блок должен устранить разрыв между:

наличием капитала

и

доступностью капитала нужного типа для сильного проекта.

Основные направления
1. Длинное инвестиционное финансирование
Для проектов с продолжительным сроком окупаемости.

2. Growth equity
Для компаний, уже доказавших бизнес-модель и переходящих к масштабированию.

3. Venture capital
Для проектов высокой технологической неопределенности.

4. Guarantees
Там, где bottleneck — риск кредитора.

5. Project finance
Для крупных капиталоемких проектов.

6. Milestone financing
Для frontier-проектов.

Финансирование увеличивается вместе с уровнем доказательности.

7. First-customer mechanisms
Государственный или корпоративный заказ помогает технологии перейти из прототипа в первый рынок.

8. Capital marketplace
Перспективное направление субпрограммы-максимум:

проект один раз формирует стандартизированный data package и получает предложения от нескольких типов капитала.

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

Финансовая поддержка оправдана, когда существует диагностированный market failure.

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

Основные направления
1. National productivity technology map
По приоритетным отраслям определяется:

мировой технологический frontier;
российский top;
российская медиана;
основные технологии разрыва.
2. Reference architectures
Типовые архитектуры модернизации для:

промышленности;
логистики;
строительства;
торговли;
услуг.
3. AI transformation packages
Типовые сценарии применения ИИ с доказанным экономическим эффектом.

4. Technology integrator network
Сеть организаций, способных помочь компании:

диагностировать;
выбрать;
интегрировать;
изменить процесс.
5. Digital twins
Для сложных производственных и инфраструктурных систем.

6. Industrial software
Развитие критических программных систем и открытых интерфейсов.

7. Technology diffusion platform
Механизм распространения решений из frontier firms к median firms.

Главный KPI
productivity effect от внедренной технологии.

Не:

количество цифровых проектов.

7.7. Кадровые мероприятия
Кадровая система должна быть связана с будущим спросом программы.

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

Основные направления
1. National critical skills map
По каждой крупной программе:

профессия;
компетенция;
количество;
регион;
срок подготовки.
2. Time-to-skill program
Сокращение времени между возникновением нового спроса и массовым появлением компетенции.

3. Reskilling
Особенно для работников отраслей, меняющихся под действием:

ИИ;
автоматизации;
новых технологий.
4. Corporate-university programs
Образование проектируется вместе с работодателем.

5. Management capability
Отдельная программа развития:

top management;
middle management;
project leaders.
6. Talent attraction
Fast track для критически важных специалистов.

7. Talent return
Создание сильных проектов для возвращения российских специалистов.

8. Talent mobility
Более свободное движение:

наука ; бизнес;
бизнес ; университет;
корпорация ; startup;
регион ; регион.
Главный принцип
Кадровый ресурс должен проектироваться одновременно с мероприятием, а не после него.

7.8. Инфраструктурные мероприятия
Инфраструктура должна обеспечивать не наличие объекта, а снижение системных издержек.

Основные направления
1. Industrial-ready sites
Площадки, где заранее подготовлены:

земля;
мощность;
связь;
транспорт;
базовые разрешения.
2. Логистические corridors
Снижение:

времени;
стоимости;
variability.
3. Energy infrastructure
Особое внимание:

time-to-connect;
надежность;
доступность мощности.
4. Digital infrastructure
broadband;
cloud;
compute;
data centers;
edge capabilities.
5. Shared scientific infrastructure
Высокотехнологичное оборудование не должно многократно дублироваться там, где возможно совместное использование.

6. AI compute infrastructure
Поскольку compute становится новым фактором производства.

Принцип
Каждый крупный инфраструктурный проект должен отвечать:

какой измеримый конкурентный bottleneck он устраняет?

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

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

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

Основные направления
1. National Competitiveness Center
Не новое суперведомство, а стратегический интегратор:

benchmarking;
National Panel;
dependencies;
portfolio management;
quarterly review.
2. Владельцы outcomes
Один итоговый результат — один accountable owner.

3. PMO субпрограмм
Отвечают за:

critical path;
dependencies;
риски;
forecast.
4. Decision rights
Должно быть ясно:

кто может изменить проект;
перераспределить ресурс;
остановить;
масштабировать.
5. Escalation architecture
Bottleneck должен быстро попадать туда, где существует полномочие.

6. AI-native project management
Максимальная автоматизация:

отчетности;
risk detection;
forecasting;
dependency tracking.
KPI управленческой системы
time-to-decision;
time-to-resolve bottleneck;
forecast accuracy;
pilot-to-scale;
time-to-stop.
7.10. Платформенные и межотраслевые мероприятия
Наиболее высокий мультипликативный эффект имеют capabilities, которые используются многими секторами одновременно.

Именно поэтому их необходимо проектировать централизованно на уровне функции.

Примеры
National data layer
Общие:

определения;
стандарты;
trusted data exchange.
Digital identity
Единая надежная идентификация:

граждан;
организаций;
полномочий.
Payment infrastructure
Общие механизмы расчетов.

AI infrastructure
compute;
базовые модели;
tooling;
безопасность.
Skills platform
Связка:

вакансий;
skill demand;
программ обучения;
skill passports.
Procurement platform
Возможность:

инновационных закупок;
пилотов;
first-customer contracts.
Regulatory technology platform
Машиночитаемые:

требования;
compliance;
проверки.
Главный принцип
одна capability — один основной владелец — многократное использование.

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

7.11. Frontier-эксперименты
Frontier-эксперименты должны быть выделены отдельно от обычных проектов.

Причина — различие в логике управления.

Обычный проект отвечает:

выполнено ли известное решение?

Frontier-проект:

подтвердилась ли неизвестная заранее гипотеза?

Возможные направления
zero-transaction business services;
proactive business regulation;
machine-readable law;
continuous automated compliance;
AI-native PMO;
national capital marketplace;
AI-personalized reskilling;
national technology diffusion network.
EXP не должен начинаться с крупного бюджета
Первая задача — уменьшить неопределенность.

Поэтому финансирование по этапам:

гипотеза ; experiment ; prototype ; pilot ; scale.

Frontier portfolio
Одновременно необходимо вести несколько гипотез.

Именно портфель позволяет:

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

Дорогой масштабированный эксперимент без доказательства — управленческая ошибка.

7.12. Устранение дублирования
Крупные национальные программы естественно склонны к дублированию.

Разные ведомства могут независимо создавать:

цифровые платформы;
центры компетенций;
программы обучения;
фонды;
аналитические системы.
Это повышает:

стоимость;
несовместимость;
кадровый дефицит;
complexity.
Functional registry
До запуска мероприятия необходимо проверить:

существует ли уже такая функция в другом проекте?

Три возможных решения
1. Удалить дубликат
Если функция полностью совпадает.

2. Объединить
Если различия несущественны.

3. Создать shared capability
Если одинаковая потребность существует у многих программ.

Особенно жесткая проверка
Необходима для:

data platforms;
AI infrastructure;
compute;
talent centers;
monitoring systems;
financing institutions.
Дублирование целей
Еще одна проблема — два проекта могут называться по-разному, но пытаться изменить один и тот же outcome.

Поэтому необходима матрица:

причина ; решение ; мероприятие.

Она сразу показывает:

пробелы;
пересечения;
конкурирующие инструменты.
7.13. Межмеропрограммные зависимости
Портфель мероприятий является не списком.

Он представляет собой граф зависимостей.

Одно мероприятие может быть невозможно до завершения другого.

Типы dependencies
Hard dependency
Проект B физически или юридически не может начаться без A.

Soft dependency
B может начаться, но его эффект будет существенно меньше.

Shared resource dependency
Два проекта конкурируют за:

специалистов;
капитал;
compute;
инфраструктуру.
Data dependency
Один проект требует данных другого.

Пример
AI modernization среднего бизнеса может зависеть от:

compute;
standard data architectures;
интеграторов;
квалифицированных кадров;
финансирования.
Если запустить только субсидию на AI, эффект будет ограниченным.

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

Именно critical path должен получать повышенное внимание.

Главный принцип
Сначала разблокировать — затем масштабировать.

7.14. Общие enabling capabilities
Некоторые мероприятия не создают конечный конкурентный outcome напрямую.

Но без них десятки других проектов теряют эффективность.

Это enabling capabilities.

Ключевые категории
1. Data capability
Качественные и совместимые данные.

2. Compute capability
Доступные вычислительные мощности.

3. Talent capability
Система быстрого формирования компетенций.

4. Financial capability
Набор инструментов капитала.

5. Regulatory capability
Способность быстро тестировать и менять нормы.

6. Scaling capability
Машина тиражирования доказанных решений.

7. Measurement capability
Benchmarking, KPI, National Panel.

8. Management capability
Owners и PMO.

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

Он должен стать национальным enabling project.

Мультипликативный эффект
Именно такие мероприятия часто заслуживают P1.

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

7.15. Приоритизация мероприятий
Нельзя одновременно одинаково интенсивно реализовывать весь портфель.

Ограничены:

деньги;
кадры;
управленческое внимание;
инфраструктура;
time.
Поэтому необходима приоритизация.

Основные критерии
1. Effect
Какой вклад в сокращение разрыва?

2. Feasibility
Можно ли реализовать за пять лет?

3. Cost
Какова полная стоимость?

4. Time-to-impact
Когда появится результат?

5. Multiplicativity
Разблокирует ли другие мероприятия?

6. Cross-sector effect
Сколько отраслей получат эффект?

7. Strategic criticality
Можно ли достигнуть цели без этого проекта?

8. Evidence
Насколько доказан механизм?

9. Resource availability
Есть ли:

деньги;
люди;
технологии?
10. Reversibility
Можно ли дешево остановить при ошибке?

Не использовать простую арифметическую сумму
Пять средних баллов не всегда важнее одного критического bottleneck.

Именно поэтому количественная оценка должна дополняться portfolio judgement.

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

7.16. P1, P2, P3 и EXP
Для программы целесообразно использовать четыре класса.

P1 — критические мероприятия
Без них невозможно достижение ключевых целей.

Характеристики:

высокий вклад;
системный effect;
critical dependency;
усиленный контроль;
защищенный ресурс.
P1 не должно быть много.

Если почти все проекты P1, приоритизации фактически нет.

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

P3 — резерв и отложенный портфель
Проекты:

меньшей срочности;
активируемые при наличии ресурса;
зависящие от других результатов.
EXP — экспериментальные frontier-проекты
Их нельзя оценивать по той же логике, что P1–P3.

Главный критерий:

качество гипотезы и скорость получения нового evidence.

Переход между классами
EXP может стать P1 после доказательства.

P2 может перейти в P1 при обнаружении нового bottleneck.

P1 может быть понижен или закрыт, если причинная гипотеза опровергнута.

Приоритет — не награда и не статус навсегда.

Это управленческое решение на основе текущих данных.

7.17. Первая очередь программы
Самая опасная ошибка — пытаться запускать весь портфель одновременно.

Первая очередь должна быть ограниченной.

Ее задача:

получить быстрые результаты;
устранить блокирующие bottleneck;
запустить длинные проекты;
проверить ключевые гипотезы.
В первую очередь должны входить четыре типа мероприятий
1. Quick wins
Высокий эффект при сравнительно простой реализации.

2. Enablers
Данные, стандарты, talent, management systems.

3. Bottleneck removers
То, что блокирует следующие волны.

4. Long-cycle starts
Инфраструктура, образование, наука — то, что нельзя отложить на третий год.

Frontier experiments
Некоторые EXP также запускаются в первой волне, потому что им необходимо время пройти несколько stage-gate.

Размер первой очереди
Она должна быть достаточно небольшой, чтобы получить:

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

7.18. Быстрые результаты первого года
Первый год не может быть только годом:

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

Возможные быстрые результаты
1. Сокращение числа повторно предоставляемых государству данных
2. Снижение времени нескольких массовых процедур
3. Перенос лучших региональных практик в группу отстающих регионов
4. Запуск fast track для приоритетных инвестиций
5. Запуск первых финансовых инструментов scale-up
6. Начало системного измерения management practices
7. Запуск отраслевых technology diffusion pilots
8. Внедрение National Panel
9. Regulatory inventory
10. Запуск frontier experiments
Почему quick wins важны
Они:

доказывают работоспособность программы;
формируют доверие;
обучают систему;
дают ранние данные.
Но есть риск.

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

Иначе будут отложены самые важные длинные преобразования.

7.19. Долгосрочные преобразования, которые необходимо начинать немедленно
Некоторые результаты не появятся быстро.

Но именно поэтому их необходимо начинать в первый год.

1. Human capital
Подготовка сложного специалиста требует времени.

2. Научно-технологические ecosystems
Не создаются за несколько месяцев.

3. Большая инфраструктура
Имеет длинный цикл:

проектирования;
строительства;
ввода.
4. Management culture
Меняется постепенно.

5. Capital market architecture
Требует:

институтов;
доверия;
накопления опыта.
6. Machine-readable regulation
Потребует:

стандартизации;
правовой методологии;
software infrastructure.
7. National data architecture
Нельзя построить качественно мгновенно.

8. Technology diffusion
Массовый эффект потребует нескольких волн.

9. Skills system
Переход от образовательных программ к динамическому skills architecture занимает годы.

10. Frontier projects
Некоторые гипотезы потребуют нескольких последовательных стадий доказательства.

Принцип
Длинный time-to-impact не является основанием снижать приоритет, если мероприятие стратегически критично.

Наоборот:

чем длиннее цикл, тем раньше нужно начинать.

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

Год 1. Разблокирование и запуск
Основные задачи:

финальная диагностика;
паспортизация мероприятий;
назначение owners;
National Panel;
regulatory inventory;
quick wins;
запуск P1;
запуск EXP;
начало длинных кадровых и инфраструктурных проектов.
Ключевой результат:

программа перешла из документа в operating system.

Год 2. Доказательство
Основной фокус:

пилоты;
первые институциональные reforms;
regional transfer;
первые financial instruments;
первые technology diffusion waves.
Ключевой вопрос:

какие механизмы реально доказали effect?

Слабые проекты закрываются.

Сильные готовятся к scale.

Год 3. Масштабирование
Главный год реализации.

Успешные решения:

распространяются;
стандартизируются;
финансируются в большем масштабе.
Первые EXP могут переходить в основной портфель.

Ключевой результат:

изменение национальных KPI становится системным, а не локальным.

Год 4. Концентрация на остаточном разрыве
Проводится повторная диагностика.

Возможно, первоначальная структура проблем изменилась.

Необходимо определить:

какие bottleneck устранены;
какие остались;
какие мировые benchmark изменились;
какие новые frontier появились.
Ресурс перераспределяется.

Ключевой принцип:

не завершать старый план механически, а достигать исходной цели в новой реальности.

Год 5. Закрепление и переход к следующему циклу
Проводятся:

независимый аудит;
международное сравнение;
оценка устойчивости;
institutionalization успешных mechanisms;
подготовка следующего Benchmark-5.
Часть frontier-проектов может не завершиться в пятилетнем цикле.

Но для них должна быть доказана:

состоятельность механизма;
новая траектория;
программа следующей стадии.
Итоговая сенсограмма пятилетнего цикла
Год Доминирующая логика Основной управленческий вопрос
1 Разблокировать и запустить Готова ли система к исполнению?
2 Проверить Какие решения доказали эффект?
3 Масштабировать Как максимально быстро распространить сильное?
4 Сконцентрировать Где остается основной разрыв?
5 Закрепить и обновить Достигнут ли Benchmark-5 и что становится следующим frontier?
Выводы главы
Архитектура Программы «Мировая конкурентоспособность России» не должна быть списком инициатив.

Она должна представлять собой системно спроектированный портфель преобразований.

Каждое мероприятие должно происходить из одного из четырех источников:

критическая российская первопричина;

доказанное мировое решение;

frontier-гипотеза;

необходимая общая enabling capability.

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

Портфель должен включать взаимодополняющие:

институциональные;
регуляторные;
финансовые;
технологические;
кадровые;
инфраструктурные;
организационные;
платформенные
решения.

При этом главный объект управления — не отдельное ведомство и даже не отдельный проект.

Им является причинная цепочка получения конкурентного результата.

Например:

высокая стоимость капитала ; недостаточная модернизация ; низкая производительность ; разрыв конкурентоспособности.

Или:

длительная процедура ; задержка инвестиции ; увеличение стоимости проекта ; снижение инвестиционной привлекательности.

Или:

сильная научная разработка ; отсутствие первого заказчика ; отсутствие scale ; потеря технологического преимущества.

Программа должна вмешиваться именно туда, где возникает потеря результата.

Из этого следует центральный принцип главы:

не финансировать активность — менять механизм.

Второй принцип:

не запускать все одновременно — сначала разблокировать систему.

Третий:

не создавать одно и то же многократно — строить shared capabilities.

Четвертый:

не путать неопределенный frontier-эксперимент с обычным проектом исполнения.

Для них нужны разные режимы управления.

Пятый:

не фиксировать приоритет на пять лет навсегда.

P1, P2, P3 и EXP должны изменяться вместе с доказательствами.

Шестой:

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

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

диагностика ; проектирование ; приоритизация ; запуск ; доказательство ; масштабирование ; измерение ; перераспределение ; следующий цикл.

Именно такая архитектура позволяет одновременно реализовать две стратегии:

достигнуть существующего мирового top-3

и

создать отдельные элементы следующего мирового frontier.

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

У каждого мероприятия должны быть:

деньги;
кадры;
данные;
технологии;
инфраструктура;
полномочия;
владелец.
Необходима система, которая способна управлять всеми этими ресурсами и принимать решения в реальном времени.

Поэтому следующая глава посвящена последнему критическому слою пятилетней программы — ресурсам, управлению и контролю реализации Программы «Мировая конкурентоспособность России».

**************
Ресурсы, управление и контроль реализации программы
Даже наиболее качественно разработанная программа не создает результат автоматически.

Можно:

правильно определить мировой benchmark;
точно измерить российский разрыв;
выявить первопричины;
выбрать сильные мировые решения;
сформировать frontier-гипотезы;
создать качественный портфель мероприятий.
Но если программа не обеспечена:

финансированием;
специалистами;
данными;
вычислительными мощностями;
инфраструктурой;
полномочиями;
управленческим вниманием,
она останется документом.

Поэтому завершающий слой Программы «Мировая конкурентоспособность России» — это система ресурсного обеспечения, организационного управления и контроля исполнения.

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

Главный вопрос главы:

способна ли организационная и ресурсная архитектура программы превратить десятки взаимозависимых преобразований в измеримое сокращение разрыва России до мирового top-3 и одновременно обеспечить масштабирование решений, создающих новый frontier?

Для этого необходимо соединить пять контуров:

ресурсы;

персональную ответственность;

операционное управление;

измерение результата;

адаптивную корректировку.

Базовая цепочка должна выглядеть следующим образом:

приоритетный outcome ; мероприятие ; ресурсный пакет ; владелец ; команда ; реализация ; данные ; прогноз ; управленческое решение ; аудит ; перераспределение ; масштабирование или прекращение.

8.1. Ресурсная архитектура программы
Ресурсное обеспечение не должно начинаться с вопроса:

«Какой бюджет нужен программе?»

Финансы — только один из ресурсов.

Мероприятие может быть полностью профинансировано и одновременно невыполнимо из-за отсутствия:

специалистов;
данных;
compute;
оборудования;
инфраструктуры;
управленческой capacity;
времени.
Поэтому для каждого мероприятия необходим полный ресурсный пакет.

Основные категории ресурсов
1. Финансовый ресурс
Включает:

бюджет;
заемный капитал;
equity;
гарантии;
частные инвестиции;
специальные финансовые инструменты.
2. Человеческий капитал
Необходимо определить:

роли;
компетенции;
количество специалистов;
место их работы;
время подготовки.
3. Управленческий ресурс
Особенно дефицитны:

сильные владельцы;
руководители программ;
PMO;
системные архитекторы.
4. Данные
Для многих проектов данные становятся таким же производственным ресурсом, как капитал.

5. Вычислительная мощность
Особенно для AI-native проектов.

6. Технологии и оборудование
Необходимо заранее определить:

собственную разработку;
закупку;
лицензирование;
совместное создание.
7. Инфраструктура
Физическая и цифровая.

8. Время
Один из наиболее недооцененных ресурсов.

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

Полный ресурсный паспорт
Для каждого P1 и крупного EXP необходимо фиксировать:

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

Например:

если для AI-transformations не хватает compute,

недостаточно написать:

«обеспечить вычислительные мощности».

Необходимо создать отдельный проект:

объем;
архитектура;
сроки;
экономика;
владелец.
Основной принцип
ресурс должен следовать за стратегическим приоритетом, а не стратегический приоритет — за историческим распределением ресурса.

8.2. Государственное финансирование и частный капитал
Программа мировой конкурентоспособности не должна финансироваться только из бюджета.

Это привело бы одновременно к:

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

Государственное финансирование особенно оправдано там, где присутствуют
общественные блага;
инфраструктура;
фундаментальная наука;
высокий ранний технологический риск;
положительные внешние эффекты;
стратегическая необходимость.
Частный капитал должен играть ведущую роль там, где
существует коммерческий cash flow;
риск поддается рыночной оценке;
проект создает частную доходность.
Возможные источники
федеральный бюджет;
региональные бюджеты;
институты развития;
государственные компании;
банки;
private equity;
venture capital;
project finance;
корпоративные инвестиции;
blended finance.
Инструмент должен соответствовать типу проекта
Нельзя финансировать одинаково:

дорогу;
AI-стартап;
фундаментальную лабораторию;
программу переподготовки;
industrial upgrade.
Этапное финансирование
Особенно важно для frontier-проектов.

На ранней стадии ресурс должен быть небольшим.

С ростом доказательности — увеличиваться.

Не финансировать намерение
Крупный объем ресурсов должен следовать за:

подтвержденным механизмом;
реальным owner;
готовностью инфраструктуры;
измеримым KPI.
Ресурсный резерв
Программа должна иметь ограниченный резерв для:

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

8.3. Additionality государственной поддержки
Одним из центральных критериев государственной поддержки должна стать additionality.

То есть:

что произошло благодаря государственному вмешательству, чего без него не произошло бы?

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

Она только изменила источник финансирования.

Виды additionality
Финансовая
Проект иначе не получил бы капитал.

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

Временная
Проект был бы реализован, но значительно позже.

Масштабная
Без поддержки решение осталось бы локальным.

Рисковая
Государство взяло на себя часть риска, который частный рынок объективно не мог принять.

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

что бы произошло без поддержки?

Это особенно важно для:

субсидий;
льгот;
гарантий;
специальных налоговых режимов.
Crowding-out
Государство не должно вытеснять частного инвестора из проектов, которые рынок способен финансировать сам.

Crowding-in
Хорошая поддержка, наоборот, должна привлекать дополнительный частный капитал.

KPI
Следует измерять:

частный капитал, мобилизованный на единицу государственного ресурса,

но не превращать этот показатель в самоцель.

Некоторые стратегически важные проекты могут объективно иметь низкий leverage.

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

8.4. Кадровое обеспечение программы
Ни одна национальная трансформация не может быть реализована только финансированием.

Особенно критичны кадры.

Программа потребует:

системных архитекторов;
инженеров;
AI-специалистов;
экономистов;
финансистов;
регуляторных экспертов;
project managers;
data engineers;
специалистов по change management.
Кадровая карта должна строиться одновременно с портфелем
Для каждого крупного мероприятия необходимо определить:

ключевые роли;
количество людей;
уровень квалификации;
регион;
срок появления.
Skill gap
Если специалиста нет сегодня, нужно понять:

можно ли обучить;
сколько это займет;
можно ли привлечь;
можно ли автоматизировать часть функций.
Transformation teams
Для P1 и EXP необходимы команды, способные работать:

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

Это практически гарантирует низкое качество.

Профессиональные траектории
Люди должны иметь возможность переходить:

из бизнеса в государственный проект;
из университета в frontier-команду;
из региона в федеральный проект;
обратно.
Кадровый резерв программы
Необходим pool руководителей и специалистов, готовых:

принимать новый проект;
заменять owner;
усиливать проблемную команду.
Главный KPI
Не:

число обученных участников.

А:

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

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

Они необходимы для:

диагностики;
управления;
AI;
регулирования;
финансовой оценки;
мониторинга.
Но данные полезны только при наличии:

качества;
совместимости;
своевременности;
доступности;
понятных прав использования.
Data inventory
Каждая субпрограмма должна определить:

какие данные необходимы;
где они находятся;
кто владелец;
качество;
периодичность;
legal basis.
Единые определения
Критическая проблема возникает, если разные системы по-разному понимают:

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

Data quality classes
Можно использовать уровни:

A — высокая надежность;

B — приемлемая;

C — ограниченная;

D — недостаточная для стратегического решения.

Once-only data
Пользователь не должен многократно производить данные, уже существующие в системе.

Data latency
Важно измерять задержку между:

событием

и

моментом, когда оно стало видно управлению.

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

Главный принцип
данные должны собираться ради решения и результата, а не ради отчетности.

8.6. Вычислительная и цифровая инфраструктура
С ростом роли ИИ compute становится новым критическим ресурсом.

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

GPU;
CPU;
storage;
high-speed networking;
cloud infrastructure;
cybersecurity;
power capacity.
Проблема фрагментации
Если каждая организация самостоятельно создает небольшой вычислительный контур, возможны:

низкая загрузка;
дублирование;
высокая unit cost.
Shared compute
Для части задач рациональна совместная инфраструктура.

Но необходима диверсификация
Полная централизация создает:

single point of failure;
security risks;
capacity bottleneck.
Следовательно, архитектура должна сочетать:

общие крупные мощности

и

распределенные специализированные контуры.

Цифровая инфраструктура включает не только hardware
Необходимы:

APIs;
standards;
identity;
access management;
security;
monitoring.
Interoperability
Главный принцип:

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

Модульность
Критические цифровые платформы должны быть:

модульными;
заменяемыми;
масштабируемыми.
Иначе сегодняшний shared capability завтра превращается в технологический lock-in.

8.7. Управленческая capacity как ограниченный ресурс
Один из наиболее недооцененных ресурсов — способность управлять сложными преобразованиями.

Деньги можно дополнительно выделить.

Некоторые мощности — построить.

Но быстро создать большое число сильных владельцев трудно.

Поэтому management capacity должна планироваться отдельно.

Owner load
Для каждого ключевого руководителя необходимо видеть:

количество программ;
P1;
EXP;
critical dependencies;
объем решений.
Нельзя назначать одного сильного руководителя на все критические проекты
Формально это повышает статус.

Фактически — снижает качество.

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

Поэтому на верхний уровень должны попадать:

стратегические отклонения;
cross-program bottleneck;
крупные resource conflicts.
Не текущие детали.

PMO как усилитель capacity
Сильный PMO позволяет владельцу концентрироваться на:

решениях;
отклонениях;
приоритетах.
AI как multiplier management capacity
AI-native инструменты могут сократить время на:

сбор статусов;
анализ;
подготовку материалов;
risk scanning.
Но нельзя автоматизировать ответственность
Даже лучшая система не заменяет owner.

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

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

Условно — Национальный центр мировой конкурентоспособности.

Но его нельзя превращать в еще одно отраслевое министерство.

Основные функции
поддержание архитектуры программы;
международный benchmarking;
Benchmark-0 и Benchmark-5;
Национальная панель;
управление портфелем;
cross-program dependencies;
приоритизация;
координация квартального review;
annual portfolio rebuild;
институциональная память.
Чего Центр не должен делать
Он не должен:

самостоятельно реализовывать большинство проектов;
дублировать функции ведомств;
согласовывать каждую операционную деталь;
владеть всеми бюджетами.
Его роль
Не «управлять вместо всех».

А:

обеспечить, чтобы вся система видела один benchmark, один портфель, одни критические зависимости и принимала решения на основе одной фактической картины.

Полномочия Центра
Он должен иметь возможность:

получать данные;
инициировать review;
требовать corrective plan;
выносить unresolved bottleneck на высший уровень;
предлагать перераспределение ресурсов.
Центр не должен контролировать независимый аудит
Иначе возникает конфликт интересов.

Он обеспечивает доступ к данным и исполнение рекомендаций, но не определяет вывод аудитора.

8.9. Владельцы субпрограмм и мероприятий
Каждый значимый outcome должен иметь одного владельца.

Это фундаментальный принцип.

Владелец субпрограммы отвечает за
положение России относительно benchmark;
динамику gap;
портфель;
ресурсы;
dependencies;
прогноз.
Он не отвечает только за исполнение перечня действий
Если все мероприятия выполнены, но разрыв не сократился, outcome не достигнут.

Владелец мероприятия
Отвечает за более конкретную причинную гипотезу и результат проекта.

Owner contract
Для владельца фиксируются:

outcome;
KPI;
полномочия;
ресурс;
ограничения;
dependencies;
escalation path.
Ответственность без полномочий невозможна
Если owner не может:

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

Один outcome — один owner
Совместная работа возможна.

Совместная финальная ответственность — опасна.

Она создает ситуацию, когда никто не является последней точкой решения.

8.10. Проектные офисы
PMO должен быть операционным механизмом исполнения, а не фабрикой отчетности.

Основные функции
roadmap;
milestones;
dependencies;
risk register;
decision log;
forecast;
подготовка review.
PMO не должен
создавать параллельную бюрократию;
требовать данные, уже доступные автоматически;
измерять успех количеством документов.
Хороший PMO
Повышает:

скорость принятия решения;
качество прогнозов;
прозрачность bottleneck;
дисциплину исполнения.
Уровни PMO
Возможны:

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

KPI PMO
прогнозная точность;
доля проблем, выявленных до срыва;
скорость снятия зависимостей;
исполнение решений review;
качество данных.
8.11. Персональная ответственность за outcome
Персональная ответственность не означает автоматическое наказание за любой плохой показатель.

Сложная программа работает в условиях неопределенности.

Поэтому необходимо различать:

плохой результат

и

плохое управление.

Плохой результат может возникнуть из-за
внешнего шока;
неверной исходной гипотезы;
появления новой технологии;
изменения мирового benchmark.
Плохое управление проявляется, если
проблема скрывалась;
данные искажались;
слабый проект не закрывался;
bottleneck не эскалировался;
corrective action отсутствовал.
Следовательно, owner оценивается по двум группам критериев
Outcome
Что произошло с результатом.

Quality of management
насколько рано обнаружена проблема;
насколько точен прогноз;
насколько быстро принято решение;
насколько качественно перераспределены ресурсы.
Культура раннего сигнала
Система должна институционально поощрять раннее сообщение о проблеме.

Красный статус — это информация.

Сокрытие красного статуса — управленческий риск.

Замена владельца
Она необходима, если наблюдается:

повторяющийся провал решений;
неспособность использовать полномочия;
искажение данных;
хроническая поздняя эскалация.
Но смена owner не должна стирать историю проекта.

8.12. Межведомственная координация
Многие bottleneck мировой конкурентоспособности лежат между ведомствами.

Например, технологическое масштабирование может зависеть одновременно от:

науки;
образования;
промышленности;
финансов;
регулирования;
закупок.
Поэтому традиционная ведомственная координация через переписку часто слишком медленна.

Coordination-by-outcome
Команда должна формироваться вокруг результата.

Каждый участник получает:

конкретный deliverable;
срок;
decision right.
Межведомственное совещание имеет смысл только при необходимости решения
Информационный обмен должен происходить преимущественно цифровым образом.

Interface agreement
Для критических dependencies можно фиксировать:

что одна сторона предоставляет другой;
в каком формате;
когда.
Joint KPI
Допустимы как дополнительный инструмент.

Но они не должны уничтожать персональную ответственность.

Эскалация
Если два ведомства не могут решить конфликт в пределах установленного срока, вопрос автоматически поднимается на следующий уровень.

Главный KPI
среднее время снятия межведомственного bottleneck.

8.13. Управление dependencies и critical path
Программа должна рассматриваться как граф.

Каждый крупный проект имеет зависимости
Например:

массовое AI-внедрение может зависеть от:

compute;
данных;
кадров;
regulation;
финансирования.
Hard dependencies
Без завершения A проект B невозможен.

Soft dependencies
B возможен, но эффект значительно ниже.

Resource dependencies
Несколько проектов конкурируют за один дефицитный ресурс.

Critical path
Это минимальная последовательность событий, задержка которой сдвигает конечный outcome.

Управленческое следствие
Высший уровень не должен одинаково контролировать тысячи сроков.

Он должен видеть прежде всего critical path.

Dependency owner
Критическая межпрограммная зависимость должна иметь владельца.

Иначе каждый проект будет считать, что проблема находится «у другого».

Digital graph
Национальная панель должна позволять увидеть:

какие проекты зависят от bottleneck;
какой cumulative effect создаст задержка.
8.14. Квартальный мониторинг
Квартальный мониторинг — основной стратегический ритм программы.

Это не ежеквартальная отчетность ради отчетности.

Главный вопрос:

если текущая траектория сохранится, будет ли достигнут Benchmark-5?

Review должен начинаться не с выполненной работы
А с:

отклонений;
прогноза;
bottleneck;
решений.
Структура
актуальный мировой benchmark;
российский факт;
target trajectory;
forecast;
основные отклонения;
причины;
необходимые решения.
Статусы
Для исполнения можно использовать:

зеленый — траектория соответствует цели;

желтый — повышенный риск;

красный — текущая траектория недостаточна;

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

Важно отдельно показывать позицию относительно frontier.

Исполнение проекта может быть зеленым, а конкурентный gap — красным.

Решение каждого review
По значимому отклонению должно быть принято одно из действий:

продолжить;
ускорить;
изменить метод;
перераспределить ресурс;
сменить владельца;
масштабировать;
остановить.
Decision log
Фиксируются:

решение;
owner;
срок;
ожидаемый effect.
Следующий review начинается с проверки исполнения предыдущих решений.

8.15. Ежегодная корректировка программы
Квартальный цикл корректирует исполнение.

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

Главный вопрос:

остается ли программа лучшим способом достижения мировой конкурентоспособности с учетом новой реальности?

Ежегодно пересматриваются
Benchmark-5;
российские разрывы;
cause trees;
P1/P2/P3/EXP;
ресурсная карта;
owners;
dependencies;
frontier hypotheses.
Что может измениться
Проект, считавшийся критическим, может потерять значение.

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

Мировой лидер может создать новый benchmark.

Sunk cost
Уже потраченный ресурс не является достаточной причиной продолжать слабый проект.

Versioning
Каждая годовая версия программы должна иметь номер.

Необходимо сохранять:

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

Цель остается стабильной.

Меняются средства.

8.16. Национальная панель мировой конкурентоспособности
Национальная панель является цифровой основой стратегического управления.

Она не должна быть витриной красивых показателей.

Ее задача — связывать результат с причиной и исполнением.

Главная цепочка
мировой benchmark ; российский показатель ; gap ; причина ; мероприятие ; owner ; ресурс ; KPI ; факт ; forecast.

Уровень 1. Национальный профиль
Несколько десятков ключевых KPI.

Уровень 2. Субпрограммы
Более детальные показатели.

Уровень 3. Причины
Root-cause trees.

Уровень 4. Проекты
milestones;
resources;
status;
dependencies.
Уровень 5. Audit
Степень независимого подтверждения.

Data freshness
Для каждого KPI должна быть видна дата последнего обновления.

Methodology version
Изменение методики не должно незаметно улучшать показатель.

Forecast layer
Панель должна показывать:

факт;
target;
forecast.
Early warning
Система должна автоматически выявлять:

ухудшение trajectory;
просрочку dependency;
resource bottleneck;
аномалию данных.
Главный вопрос панели
где Россия потеряет целевой результат, если сегодня не принять решение?

8.17. Прогноз достижения Benchmark-5
Управление только по факту слишком медленно.

Поэтому программа должна постоянно прогнозировать вероятность достижения Benchmark-5.

Forecast не равен плану
План говорит:

куда мы хотим прийти.

Forecast:

куда мы придем при текущей траектории.

Разница между ними — главный объект управления.

Сценарии
Необходимо иметь минимум:

базовый;
негативный;
ускоренный.
Движущийся frontier
Forecast должен обновляться не только при изменении российского показателя.

Но и при изменении:

top-3;
технологий;
мировой экономики.
Forecast accuracy
После каждого периода сравнивается предыдущий прогноз с фактом.

Это позволяет оценивать качество модели.

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

Ранний corrective action
Если вероятность достижения цели падает ниже установленного порога, решение принимается до официального срыва KPI.

Главное преимущество
Программа переходит:

от управления прошлым

к управлению будущей траекторией.

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

Поэтому независимый аудит необходим для:

P1;
крупных EXP;
ключевых итоговых KPI.
Аудит должен проверять несколько уровней
1. Данные
Правильны ли они?

2. Методология
Сопоставим ли показатель с baseline и benchmark?

3. Факт результата
Произошло ли заявленное изменение?

4. Причинность
Связано ли изменение с программой?

5. Стоимость
Какова цена результата?

6. Устойчивость
Сохраняется ли эффект?

7. Масштаб
Работает ли решение за пределами пилота?

Особый стандарт для frontier
Заявление:

«создан новый мировой benchmark»

требует максимального уровня доказательности.

Категории заключения
подтверждено;
подтверждено с ограничениями;
подтверждено частично;
не подтверждено;
опровергнуто.
Аудитор не должен управлять проектом
Иначе независимость исчезает.

Audit findings должны приводить к решению
Не к архивированию отчета.

8.19. Stop criteria и прекращение неэффективных мероприятий
Сильная программа отличается от слабой не только способностью запускать.

Но и способностью прекращать.

Почему слабые проекты живут слишком долго
Возникают:

sunk cost;
организационный престиж;
интерес команды;
страх признания ошибки.
Stop criteria должны задаваться до запуска
Например:

результат ниже минимального порога;
стоимость выше допустимой;
причинная гипотеза опровергнута;
появился superior alternative;
critical risk стал неприемлемым.
Для EXP это особенно важно
Эксперимент должен завершаться:

переходом на следующую stage;
корректировкой;
stop.
Не состоянием:

«продолжим исследование».

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

Post-stop review
После закрытия необходимо сохранить:

данные;
причины;
lessons learned.
Недопустимо
Закрыть проект и через два года запустить практически ту же гипотезу без учета прежнего опыта.

8.20. Ускоренное масштабирование успешных решений
Сильный результат имеет стратегическую ценность только после scale.

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

Scale trigger
Заранее определяется:

при каком доказательстве запускается масштабирование.

Scale package
Включает:

стандарт;
software;
обучение;
финансирование;
regulation;
поддержку;
KPI.
Scale fund или резерв
Сильное решение не должно ждать нового бюджетного цикла.

Scale readiness
До массового внедрения проверяются:

экономика;
supply chain;
кадры;
инфраструктура;
качество.
Масштабирование по волнам
Не всегда следует сразу переходить:

из одного пилота

в национальный scale.

Можно использовать:

1 ; 10 ; 100 ; национальный уровень.

Quality decay
При масштабировании эффект может ухудшаться.

Поэтому измеряется:

результат на каждом уровне scale.

Time-to-scale
Один из важнейших KPI программы.

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

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

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

Мировой frontier продолжит двигаться.

Поэтому следующий цикл необходимо начинать проектировать заранее.

На четвертом году
Начинается:

новый international benchmarking;
анализ новых technologies;
пересмотр системных bottleneck;
формирование frontier hypotheses.
Пятый год выполняет двойную функцию
Он:

завершает текущий цикл

и

создает baseline следующего.

Не переносить автоматически незавершенные проекты
Каждое мероприятие проходит повторную проверку.

Вопрос:

если бы этот проект предлагался сегодня с нуля, включили бы мы его в новый цикл?

Institutional memory
Следующий цикл должен использовать:

историю решений;
ошибки;
доказанные механизмы;
данные.
Новый Benchmark-5
К концу цикла первоначальный Benchmark-5 превращается практически в Benchmark-0 нового цикла.

Далее рассчитывается следующий frontier.

Переход от программы к постоянной capability
В долгосрочном горизонте Россия должна перестать каждые пять лет заново изобретать механизм повышения конкурентоспособности.

Необходима постоянно действующая система:

benchmarking ; diagnostics ; portfolio ; implementation ; audit ; next frontier.

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

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

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

Он начинается с ресурсной архитектуры.

Для каждого критического проекта должны быть одновременно обеспечены:

деньги;
люди;
технологии;
данные;
вычислительная мощность;
инфраструктура;
управленческая capacity;
время.
Отсутствие любого критического элемента превращается в bottleneck.

Следовательно, ресурсный вопрос должен задаваться не так:

«сколько денег выделено?»

а:

«обеспечен ли полный набор условий, необходимых для получения outcome?»

Финансирование должно быть многоканальным.

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

Но оно должно вмешиваться там, где существуют:

public goods;
market failures;
strategic externalities;
frontier risk.
При этом главным критерием поддержки становится additionality.

Государственный ресурс оправдан только тогда, когда он создает дополнительный национальный результат.

Второй ключевой элемент — персональная ответственность.

Каждый значимый outcome должен иметь одного владельца с:

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

Полномочия без ответственности — опасны.

Третий элемент — управление как системой dependencies.

Программа не представляет собой независимый набор проектов.

Она является графом.

Одни мероприятия:

разблокируют другие;
конкурируют за ресурсы;
формируют shared capabilities.
Поэтому управлять необходимо:

не сотнями отдельных сроков,

а critical path достижения национального результата.

Четвертый элемент — управление по прогнозу.

Квартальный review должен отвечать не:

«что было сделано?»

а:

«если текущая траектория сохранится, достигнем ли мы Benchmark-5?»

Если ответ отрицательный, решение принимается немедленно.

Не после официального провала.

Пятый элемент — независимая проверка.

Нельзя считать успехом:

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

Шестой элемент — дисциплина stop.

Слабые проекты должны прекращаться.

Седьмой — дисциплина scale.

Сильные проекты должны распространяться максимально быстро.

Именно сочетание:

stop fast + scale fast

делает программу адаптивной.

Восьмой элемент — преемственность.

Пятилетний цикл не является окончанием.

Он должен создавать:

новый baseline;
новые capabilities;
новую институциональную память;
новый frontier-портфель.
В завершенном виде система управления должна работать по следующей цепочке:

национальный outcome ; benchmark ; мероприятие ; полный ресурсный пакет ; owner ; команда ; реализация ; National Panel ; forecast ; quarterly decision ; независимый аудит ; stop или scale ; annual portfolio rebuild ; следующий пятилетний цикл.

Такой механизм превращает конкурентоспособность из темы экономического анализа в операционную систему национального развития.

Именно в этом состоит конечная задача всей Программы.

Не один раз приблизить Россию к мировому top-3.

А создать систему, которая умеет постоянно:

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

*********