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