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