На практике это почти никогда не выглядит как «мы что-то не учли».

Это выглядит иначе.
Вы проработали решение. Посчитали экономику. Собрали концепцию.
Начинаете внедрение — и в этот момент в процесс начинают включаться другие службы.

ИТ задаёт свои вопросы.
Безопасность — свои.
Финансы — свои.

Чтобы получить согласование, концепцию приходится адаптировать. Потом ещё раз. И ещё.

В какой-то момент она формально внедрена, но от исходной логики и расчётной эффективности почти ничего не остаётся. Это не сбой внедрения. Это проявление неполной модели.

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

Но система гораздо шире, чем:

• процессы;
• расчёты;
• выбранные технологии.

В ней есть факторы, которые почти никогда не попадают в поле внимания:

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

Любое проявление саботажа — это не «плохие люди». Это неучтённые интересы.

Любой провал на внедрении — это не «ошибка исполнения». Это неучтённое ограничение системы.

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

В итоге:

• на половине мощности система «захлебнулась»;
• эффект не достигнут;
• начинается поиск «проблемы».

Или
Процесс логически выстроен, но:

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

Формально решение есть. Фактически — оно не работает.

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

И это системная проблема. Система в принципе не видит всё, что на неё влияет.

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

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

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

Но это тупиковая логика. Систему нельзя «досчитать до конца». Факторов всегда больше, чем вы способны удержать в модели.

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

Реальная система устроена иначе. Часть факторов:

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

Это означает, что: любая модель изначально неполная — и это нормально.

И тогда меняется сама задача. Не «учесть всё заранее».
А: построить систему, которая способна работать с неполной моделью и дообучаться по ходу изменений.

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

Пока этого нет:

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

Но как только система:

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

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

Дальше имеет смысл посмотреть:

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

Заполните форму и мы свяжемся с вами

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