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