Почему система, которая держит установку, душит новый проект

У тебя есть две задачи, которые живут на одной площадке. Первая — чтобы установка шла без сбоев: показатели в норме, отклонения замечаются и закрываются, регламенты работают. Вторая — найти, как делать что-то иначе: новый режим, новая схема, новая идея, которая снизит затраты или откроет рынок. Ты выписываешь обе задачи в одну рабочую группу. Ставишь общий KPI. Ждёшь результата.

Через полгода первая задача идёт нормально. А вторая стоит. Люди вроде делают, отчёты пишут, но никаких новых ходов. Только аккуратные предложения «оптимизировать существующее на 3%». Ты собираешь команду, спрашиваешь — что не так. И слышишь ответы, в которых правды никто не скажет вслух.

Что обычно идёт не так

Происходит вот что. Система, которая хорошо держит надёжность, устроена под одну логику: любое отклонение — это плохо. Чем меньше отклонений, тем выше показатель. Кто допустил — тот объясняется. Кто заметил — молодец. Это разумная конструкция для плановой эксплуатации. Она действительно снижает аварийность и держит регламент.

Но эту же конструкцию ты, не задумываясь, опускаешь на инновационную задачу. Те же отчётные формы. Тот же KPI на «отсутствие отклонений». Тот же разбор, если что-то пошло не по плану. И команда быстро считывает: эксперимент, который не дал результата, — это отклонение. Лучше не предлагать смелого. Лучше идти по краю — внутри известного. Так появляются предложения, которые звучат красиво, но ничего не меняют.

Это не безответственность команды. Это предсказуемая реакция на систему, которую ты задал.

Что меняется, когда у тебя две зоны вместо одной

Любая инновация начинается с гипотезы, которая может не подтвердиться. Если из десяти проб одна выстрелит — это уже хороший результат. Девять остальных — это не брак, это материал, из которого ты понял, что не работает. Без этих девяти не будет десятой.

Дальше простая мысль. Если у тебя в одной зоне нельзя девять раз промахнуться, в этой зоне инновации не будет. Поэтому система под двойную задачу строится не как «одна большая система с разными KPI», а как две зоны с разными правилами игры на одной площадке.

Надёжная зона. Здесь правит регламент. Отклонение — это сигнал, его разбирают, его закрывают. Премии — за стабильность. Это всё, как ты привык.

Экспериментальная зона. Здесь правит гипотеза. Отклонение от ожидаемого результата — это и есть данные, ради которых всё затевалось. Если эксперимент не сработал, но команда поняла почему — это успешный эксперимент. Премии — за скорость проверки и качество разбора, а не за «отсутствие отклонений».

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

Где это видно в обычной работе

Сцена первая. Главный механик предлагает попробовать новый материал прокладок на нескольких узлах. Дороже, но обещает дольше держать. Если ты заводишь это в обычную систему контроля — он должен будет на каждом этапе доказывать, что всё под контролем, отклонений нет, риски закрыты. Через два месяца он сам свернёт инициативу, потому что отчётности больше, чем работы. Если ты сразу говоришь: «Это пилот. Здесь правила другие. Нам важно, чтобы через три месяца ты сказал — работает или нет, и почему. Если не работает — это не минус тебе. Минус — если потеряешь время и не поймёшь, что было причиной» — материал попробуют, и ты получишь ответ.

Сцена вторая. Технологическая служба запускает изменение режима, которого раньше на этой установке не было. Если разбор первой нештатной ситуации в этом режиме идёт по тем же правилам, что разбор инцидента на отлаженной линии, — у тебя в команде закроются. Все наблюдения, которые могли бы помочь, уйдут в личные блокноты. Если ты на старте сказал: «Здесь мы первый раз. В первые два месяца я жду от вас не отсутствия событий, а быстрых разборов, что мы поняли», — ты получаешь то, ради чего запускал.

Третья сцена, тоньше. Молодой инженер в надёжной зоне приносит идею, которую для него самого ещё не очевидно как защитить. Если у тебя одна общая система, эта идея пройдёт через защиту бюджета, через согласование с дивизионом, через все проверки — и умрёт. Если у тебя есть отдельный лёгкий формат для ранней проверки идеи (без больших согласований, с маленьким ресурсом, с коротким сроком и заранее проговорённым «получилось/не получилось — оба варианта норма») — у инженера есть путь.

Что попробовать завтра

Начни не с системы, начни с разговора. На ближайшем совещании, где ты ставишь команде задачу с элементом нового, проговори вслух, в какой зоне эта задача. Не «эта задача важная, делайте качественно», а конкретно: «Здесь мы пробуем то, что раньше не делали. Я ожидаю, что часть гипотез не подтвердится. От вас мне нужны быстрые проверки и честные ответы — не красивые отчёты». Команда впервые услышит это и не поверит сразу. Но это первый шаг.

Дальше — отдели формат отчётности. Если у тебя на пилотном проекте та же форма, что на плановой эксплуатации, — никакая речь не поможет, форма перевесит. На пилоте оставь короткую запись: что хотели проверить, что получилось, что не получилось, что поняли. Без графиков выполнения плана, без процентов от целевого. План в инновационной зоне меняется по ходу — это норма, а не срыв.

Потом посмотри, как ты сам реагируешь на новости с пилота. Если на «не сработало» ты в той же интонации, что на «отклонение от регламента», — команда считает это за две секунды. Попробуй заметить разницу. На отклонение в надёжной зоне ты спрашиваешь «как закроем». На результат пилота, который не подтвердил гипотезу, ты спрашиваешь «что мы из этого узнали». Два разных вопроса. Два разных управленческих движения.

И последнее. Защити людей в экспериментальной зоне от привычной премиальной логики. Если их доход зависит от показателя «нет отклонений», они никогда не пойдут в риск, как бы ты их ни уговаривал. Премия за пилот — это премия за скорость и качество разбора, а не за то, что гипотеза подтвердилась. Иначе у тебя будет не инновационная зона, а театр инноваций.

Откуда взята концепция

Идея, что системы надёжности и системы инноваций требуют разной конструкции, развёрнута в работах Эми Эдмондсон, профессора Гарвардской школы бизнеса, на материале промышленных компаний, медицинских клиник и исследовательских лабораторий. У неё это противопоставление между производственной системой Toyota, которая вычищает отклонения, и системой 3M, которая допускает «умные неудачи» как способ дойти до прорыва. Здесь я разложил тот же принцип на материале российской производственной площадки: что меняется, когда ты внутри одной команды признаёшь, что у тебя две разные задачи, и не смешиваешь правила игры между ними.