Когда система всё-таки решает меняться, кажется, что самое сложное уже позади. Проблему увидели. Решение начали искать. Движение появилось. Но именно в этот момент чаще всего происходит главная ошибка.
Система начинает действовать — и выбирает не те способы изменений.
Это проявляется в типовых сценариях.
Покупка решения «как у других». Лидер отрасли внедрил — значит, и нам подойдёт. Вендор показал кейсы — значит, работает.
Привлечение консультантов с передачей внедрения внутрь. Проект посчитали. Рекомендации получили.
Дальше — «реализуйте сами».
Замена людей. «Найти сильного руководителя» вместо изменения самой системы.
Снаружи это выглядит как осмысленные действия. По факту — это разные формы одного и того же. Разрыв между контуром принятия решения и операционной реальностью.
Решение принимается на уровне, где видна логика. А реализуется на уровне, где действуют ограничения.
Если между этими уровнями нет связки, решение становится технически слепым — потому что строится на неполной модели системы.
ЛПР видит:
Но не видит:
И чем выше уровень принятия решения, тем выше абстракция и тем больше разрыв.
В результате любое решение превращается в лотерею.
Повезло — работает.
Не повезло — начинаются обходные пути.
Важно здесь одно. Решения не работают не потому, что они плохие.
Они не работают, потому что недостаточно адаптированы к реальности системы.
И это не только про технологию.
Это про:
На практике это выглядит так.
Вы купили решение.
Иногда всё действительно работает идеально, но чаще:
Типичный пример.
Внедряется роботизация и переход на модель «товар к человеку».
Расчёты сходятся. Кейсы есть.
По факту:
Формально решение внедрено.
Фактически — система не работает так, как была задумана.
И такие проекты регулярно можно увидеть на отраслевых конференциях как успешные кейсы внедрения.
Но проблема здесь не в конкретной технологии. И не в конкретном решении.
Проблема в том, как это решение выбирается и как оно дальше проходит через систему.
Даже если решение выбрано правильно, его ещё нужно удержать.
Проект можно:
Но если внутри нет команды, которая:
Каждый участник упрощает, адаптирует под себя, оптимизирует локально — действуя в рамках своих интересов и ограничений.
В результате после внедрения получается: другая система, отличная от той, которую изначально проектировали.
И почти всегда — менее эффективная.
Чтобы этого не происходило, в системе должны одновременно существовать два типа компетенции.
С одной стороны — управленческая.
Которая обеспечивает:
С другой — техническая.
Которая:
Если одного из этих элементов нет, система неизбежно выбирает не те решения или искажает их в процессе внедрения.
И здесь проявляется главный принцип. Проблема не в том, что система не меняется.
И не в том, что она выбирает плохие решения.
Проблема в том, что она не способна связать решение с реальной системой, в которой оно должно работать.
Пока этого нет:
И тогда любые изменения становятся не управляемым процессом, а цепочкой попыток, часть из которых случайно срабатывает.
Дальше имеет смысл посмотреть:
Система начинает действовать — и выбирает не те способы изменений.
Это проявляется в типовых сценариях.
Покупка решения «как у других». Лидер отрасли внедрил — значит, и нам подойдёт. Вендор показал кейсы — значит, работает.
Привлечение консультантов с передачей внедрения внутрь. Проект посчитали. Рекомендации получили.
Дальше — «реализуйте сами».
Замена людей. «Найти сильного руководителя» вместо изменения самой системы.
Снаружи это выглядит как осмысленные действия. По факту — это разные формы одного и того же. Разрыв между контуром принятия решения и операционной реальностью.
Решение принимается на уровне, где видна логика. А реализуется на уровне, где действуют ограничения.
Если между этими уровнями нет связки, решение становится технически слепым — потому что строится на неполной модели системы.
ЛПР видит:
- концепцию;
- экономику;
- примеры.
Но не видит:
- конкретный поток;
- реальные ограничения;
- поведение системы в деталях.
И чем выше уровень принятия решения, тем выше абстракция и тем больше разрыв.
В результате любое решение превращается в лотерею.
Повезло — работает.
Не повезло — начинаются обходные пути.
Важно здесь одно. Решения не работают не потому, что они плохие.
Они не работают, потому что недостаточно адаптированы к реальности системы.
И это не только про технологию.
Это про:
- процессы;
- людей;
- ограничения;
- способность системы внедрять изменения.
На практике это выглядит так.
Вы купили решение.
Иногда всё действительно работает идеально, но чаще:
- система начинает жить с ограничениями;
- появляются обходные процессы;
- часть функциональности не используется;
- или происходит откат к предыдущей модели.
Типичный пример.
Внедряется роботизация и переход на модель «товар к человеку».
Расчёты сходятся. Кейсы есть.
По факту:
- у каждого поста очередь из 10–15 роботов;
- часть простаивает;
- часть уходит на зарядку;
- реально используется лишь малая часть системы.
Формально решение внедрено.
Фактически — система не работает так, как была задумана.
И такие проекты регулярно можно увидеть на отраслевых конференциях как успешные кейсы внедрения.
Но проблема здесь не в конкретной технологии. И не в конкретном решении.
Проблема в том, как это решение выбирается и как оно дальше проходит через систему.
Даже если решение выбрано правильно, его ещё нужно удержать.
Проект можно:
- посчитать;
- описать;
- провести тендер;
- закупить решение;
- быть организационно готовым.
Но если внутри нет команды, которая:
- понимает реальную сложность проекта;
- удерживает его логику;
- не даёт упростить или локально «оптимизировать».
Каждый участник упрощает, адаптирует под себя, оптимизирует локально — действуя в рамках своих интересов и ограничений.
В результате после внедрения получается: другая система, отличная от той, которую изначально проектировали.
И почти всегда — менее эффективная.
Чтобы этого не происходило, в системе должны одновременно существовать два типа компетенции.
С одной стороны — управленческая.
Которая обеспечивает:
- принятие решений;
- движение проекта;
- согласование интересов.
С другой — техническая.
Которая:
- понимает реальную сложность системы;
- проверяет применимость решений;
- удерживает логику проекта;
- защищает интересы заказчика.
Если одного из этих элементов нет, система неизбежно выбирает не те решения или искажает их в процессе внедрения.
И здесь проявляется главный принцип. Проблема не в том, что система не меняется.
И не в том, что она выбирает плохие решения.
Проблема в том, что она не способна связать решение с реальной системой, в которой оно должно работать.
Пока этого нет:
- решения остаются абстрактными;
- внедрение превращается в адаптацию «на ходу»;
- результат оказывается случайным.
И тогда любые изменения становятся не управляемым процессом, а цепочкой попыток, часть из которых случайно срабатывает.
Дальше имеет смысл посмотреть:
