Почему цифровая система должна сравнивать ожидаемые и фактические последствия

107

Как решения могут постепенно уточнять понимание того, как работает предприятие

Представим условную ситуацию.

Идёт уборка.

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

Цифровая система видит текущую загрузку и предлагает временно перебросить несколько машин с соседнего участка.

Расчёт выглядит разумно.

Ожидание комбайнов должно уменьшиться.

Темп уборки — вырасти.

Соседний участок пока способен выдержать снижение количества транспорта.

Приёмка, по имеющимся данным, тоже должна справиться с дополнительным потоком.

Решение принимают.

Через несколько часов становится видно: основная задача действительно решена.

Комбайны ждут меньше.

Уборка ускорилась.

Но одновременно на приёмке начинает формироваться очередь.

Соседний участок отстаёт сильнее ожидаемого.

Нельзя сказать, что решение не сработало.

Оно сработало.

Но предприятие ответило на него не совсем так, как предполагалось.

На первый взгляд здесь можно сказать:

— Это обычное сравнение плана и факта. Или обычная обратная связь.

Если говорить совсем образно — да.

Но давайте посмотрим немного глубже.

Обычный план-факт прежде всего отвечает на вопрос:

получили мы тот результат, который планировали, или нет?

Здесь вопрос другой:

как предприятие в действительности отреагировало на конкретное управленческое воздействие?

Потому что одно решение способно одновременно изменить несколько связанных процессов.

В нашем случае переброска транспорта сократила простой комбайнов.

Но одновременно изменила загрузку приёмки, ритм соседнего участка и движение самого транспорта.

Более того, фактически выполненное действие тоже может отличаться от того, которое первоначально рассчитывала система.

Поэтому сравнить одну плановую цифру с одной фактической уже недостаточно.

Нужно понимать:

что предполагали сделать → что сделали фактически → какой реакции предприятия ожидали → что произошло в действительности.

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

Решение одновременно становится проверкой гипотезы

Когда цифровая система предлагает действие, внутри рекомендации уже существует определённое предположение.

Если сделать А при текущем состоянии предприятия, должно произойти Б.

В нашем примере логика примерно такая:

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

Это уже не только рекомендация.

Это рабочая гипотеза о поведении предприятия.

Она может опираться на текущие данные, прошлые ситуации, известные ограничения и рассчитанные последствия.

Но до выполнения решения всё равно остаётся гипотезой.

Реальность ещё должна её проверить.

После вмешательства появляется фактическая реакция.

И тогда возникает следующий вопрос.

Что система должна сделать с результатом этой проверки?

Недостаточно записать: «решение сработало»

Если смотреть только на основную задачу нашего примера, решение можно назвать успешным.

Простой комбайнов уменьшился.

Темп уборки вырос.

Но цифровая модель правильно оценила не всё.

Она достаточно точно предположила реакцию комбайнов и хуже — реакцию приёмки и соседнего участка.

Поэтому запись:

«Перераспределение транспорта дало положительный результат»

сохранит слишком мало.

Для обучения полезнее знать:

что должно было измениться;

что действительно изменилось;

какие последствия оказались сильнее или слабее ожидаемого;

и что возникло такого, чего первоначальный прогноз вообще не учитывал.

Тогда результат решения перестаёт быть оценкой:

получилось / не получилось.

Он становится проверкой того, насколько правильно цифровая модель понимала поведение предприятия.

Но сначала нужно установить, какое действие вообще проверялось

Это один из самых важных моментов.

Допустим, система рассчитала:

перебросить три автомобиля на четыре часа.

Руководитель решение принял.

Но к моменту исполнения свободными остались только две машины.

Прибыли они позже.

Вернули их не через четыре часа, а через семь.

Фактическое воздействие на предприятие оказалось уже другим.

Если теперь связать полученный результат с первоначальной рекомендацией, система начнёт обучаться на действии, которого в реальности не произошло.

Поэтому необходимо различать:

что рекомендовала система;

что решил человек;

что фактически было выполнено.

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

Для цифровой модели это принципиально.

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

Подтверждение тоже должно накапливаться

Предположим, ожидаемая реакция совпала с фактической.

Система считала, что переброска транспорта уменьшит ожидание комбайнов.

Так и произошло.

Гипотеза получила подтверждение.

Но одного случая недостаточно, чтобы сказать:

«Теперь мы знаем, что это работает».

В другом состоянии предприятия результат может измениться.

Будет другое расстояние.

Другая загрузка приёмки.

Другой резерв транспорта.

Другой темп соседнего участка.

Поэтому правильнее сохранить:

при этих условиях гипотеза получила дополнительное подтверждение.

Если похожая реакция повторяется в нескольких сопоставимых ситуациях, уверенность постепенно растёт.

Так у цифровой модели появляется не просто вывод, а степень уверенности в нём.

И прошлые решения начинают превращаться уже не в набор рецептов, а в знание:

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

Расхождение — это ещё не объяснение

Теперь обратная ситуация.

Приёмка должна была выдержать дополнительный поток.

Не выдержала.

Самый простой вывод:

значит, мы переоценили её пропускную способность.

Возможно.

Но это ещё не установлено.

Одновременно могла остановиться одна линия разгрузки.

Мог измениться поток с другого участка.

Могла вырасти влажность продукции и время обработки партии.

Мог появиться транспорт, которого не было в исходном расчёте.

Сам факт расхождения говорит только одно:

наше ожидание оказалось неполным или неточным.

Но он ещё не говорит, почему.

Поэтому расхождение сначала создаёт новый вопрос к модели.

Что оказалось оценено неправильно?

Исходное состояние?

Связь процессов?

Доступность ресурса?

Производительность?

Фактическое исполнение?

Внешнее обстоятельство?

Если причину удалось подтвердить, появляется новое знание.

Если нет, честнее сохранить:

причина пока неизвестна;

или:

существуют несколько рабочих гипотез.

Лучше сохранить такую неопределённость, чем превратить первое удобное объяснение в новое цифровое правило.

У расхождения должен появиться адрес

Мне кажется, именно здесь появляется одна из наиболее полезных функций такой системы.

Недостаточно сообщить:

«Прогноз не совпал с фактом».

Полезнее понять:

какой участок нашего понимания предприятия требует проверки.

Например, система регулярно недооценивает влияние загрузки приёмки.

Или считает транспорт доступным дольше, чем он остаётся свободным фактически.

Или плохо учитывает влияние одной операции на соседнюю.

Или предполагает одну скорость реакции людей, а на практике она другая.

Тогда ошибка прогноза перестаёт быть просто плохой статистикой.

Она показывает:

здесь цифровая модель понимает предприятие хуже, чем нам казалось.

И именно этот участок модели можно проверять дальше.

Постепенно формируется знание о реакции предприятия

Можно накопить огромную базу прошлых действий: перебрасывали технику, меняли график, добавляли смену, оставляли резерв, останавливали операцию.

Но список решений сам по себе мало говорит о том, почему они давали разный эффект.

Намного ценнее знать:

в каком состоянии находилось предприятие;

какое воздействие фактически произошло;

как на него отреагировали связанные процессы;

какие ожидания подтвердились;

где возникли устойчивые расхождения;

какие ограничения проявлялись снова и снова.

Тогда постепенно формируется не просто база:

«что мы когда-то делали».

А знание:

«как наше предприятие обычно реагирует на такое воздействие при таких условиях».

И это уже совсем другая ценность накопленного опыта.

Это знание должно вернуться в следующий план

Наступает новый сезон.

Возникает похожая ситуация.

Но теперь система начинает анализ не с чистого листа.

Она уже знает:

в нескольких прошлых случаях перераспределение транспорта действительно сокращало простой комбайнов;

при высокой загрузке приёмки положительный эффект быстро начинал ограничиваться;

при небольшом резерве соседнего участка отставание росло сильнее расчётного;

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

Это всё ещё не готовый рецепт.

Условия могли измениться.

Но новый план строится уже на более точном понимании предприятия.

Цикл начинает выглядеть так:

состояние

↓

гипотеза о реакции

↓

ожидаемые последствия

↓

решение

↓

фактическое исполнение

↓

фактические последствия

↓

сравнение

↓

подтверждение или расхождение

↓

проверка причины

↓

уточнение знания

↓

следующее планирование

Каждый такой цикл потенциально делает следующее решение немного более обоснованным.

Не потому, что система получила ещё одну строку данных.

А потому, что она получила ещё одну проверку собственного понимания предприятия.

Но здесь появляется и опасность

Можно сказать:

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

Но это слишком простая картина.

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

В цифровом обучении возникает ещё один риск.

Ошибочная гипотеза создаёт рекомендацию, рекомендация влияет на предприятие, система неверно объясняет последствия и сохраняет этот случай как подтверждённый обучающий пример.

Тогда ошибка уже не просто произошла — она начинает увеличивать уверенность модели в самой себе.

Именно поэтому обучение нельзя свести к простой схеме:

прогноз не совпал — изменили коэффициенты;

совпал — усилили уверенность.

Прежде чем менять модель, необходимо достаточно хорошо понимать, что фактически произошло и чему именно этот случай способен нас научить.

Предприятие всё равно не станет предсказуемой машиной

Даже очень большая история наблюдений не отменит неопределённость.

Меняется погода, стареет техника, меняются сотрудники, технологии, поставщики, ограничения и цены.

Само предприятие со временем становится другим.

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

Ценность такой системы — в способности постоянно проверять собственные представления о предприятии и уточнять их.

Поэтому задача не в том, чтобы накапливать абсолютные истины, а в том, чтобы получать всё более обоснованное понимание:

в каких условиях определённое воздействие с какой вероятностью приводит к определённой реакции.

Не каждое решение требует такой глубины

Здесь тоже важна граница.

Если заставить предприятие подробно разбирать каждое небольшое действие, очень быстро появится новая отчётность.

Люди начнут заполнять её формально.

Поэтому глубокая проверка нужна прежде всего там, где:

цифровая система участвовала в подготовке значимого решения;

существовала заметная неопределённость;

решение затрагивало связанные процессы;

или полученный результат способен изменить будущие рекомендации.

После такого решения полезно сохранить связку:

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

Тогда сохраняется уже не просто история событий.

Сохраняется история проверки наших представлений о предприятии.

Вместо заключения

За последние годы цифровые системы научились очень хорошо хранить:

что произошло.

Следующий уровень требует сохранить ещё одну вещь:

чего мы ожидали до того, как это произошло.

Но и этого недостаточно.

Нужно знать:

что фактически сделали и как именно предприятие на это ответило.

Ожидание подтвердилось — гипотеза получила дополнительную опору.

Не подтвердилось — возник вопрос к модели.