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

Новые правила готовы. Рынок еще не готов к их исполнению

Гипотетический учебный кейс

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

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

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

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

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

Киневин Окно Джохари
← К хабу стратегических кейсов

Диагностика

Две ошибки в одной ситуации

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

01

Киневин

План еще не означает предсказуемый результат

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

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

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

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

02

Окно Джохари

Самая важная информация может находиться у тех, кого регулируют

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

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

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

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

Что нужно сделать общим до запуска

Регулятор знает

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

Рынок знает

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

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

До масштаба

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

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

01

Проверить систему в реальной среде

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

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

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

02

Сделать плохой сигнал безопасным

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

  • обратная связь участников пилота;
  • наблюдение за профессиональными сообществами;
  • работа с ИТ-интеграторами и отраслевыми экспертами;
  • возможность сообщить о системной проблеме без опасения привлечь дополнительный контроль.

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

03

Показать, что обратная связь что-то изменила

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

Рабочая последовательность другая: проблема обнаружена, причина подтверждена, решение изменено, результат снова проверен.

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

Рабочий цикл до масштабирования

Пилот
Сигнал
Изменение
Повторная проверка

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

Практический итог

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

01

Какие участники хуже всего представлены в нашей проверке?

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

02

Что рынок уже видит такого, чего пока не видит центральная команда?

И где сегодня обсуждается эта информация — в официальной отчетности или между специалистами?

03

Насколько безопасно сообщить нам о неудобной проблеме?

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

04

Кто может изменить решение после повторяющегося сигнала?

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

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

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