Почему цифровая система должна замечать, когда план перестал быть актуальным
Современные цифровые системы достаточно хорошо умеют контролировать выполнение плана.
Они показывают, что выполнено, где возникла задержка, какая техника остановилась и насколько фактический результат отличается от расчётного.
Но само отклонение ещё не отвечает на главный управленческий вопрос:
нужно ли менять план?
Иногда задержка в несколько часов спокойно поглощается существующим резервом и почти ничего не меняет дальше.
А иногда гораздо меньшее отклонение возникает в критической точке и делает неприменимыми сразу несколько следующих действий.
Поэтому цифровой системе недостаточно сравнивать план с фактом.
Ей постепенно придётся понимать, остаётся ли сам план применимым к изменившемуся состоянию предприятия.
Поломку система увидела. А что произошло с планом?
Представим условную производственную ситуацию.
На предприятии идёт предпосевная подготовка.
Предпосевной культиватор должен последовательно обработать несколько массивов. За ним с определённым интервалом запланирован сев.
Под эту последовательность распределены техника, люди, семена, удобрения, транспорт и время последующих операций.
В середине дня культиватор выходит из строя.
Само событие цифровая система способна увидеть достаточно быстро.
Техника остановилась.
Появился простой.
Создана заявка на ремонт.
Местоположение агрегата известно.
Но для управления этого недостаточно.
Потому что дальше необходимо понять:
что эта поломка изменила в уже построенной последовательности?
Допустим, ремонт займёт один час.
В графике есть резерв.
Следующий посевной комплекс всё равно не подойдёт к этому массиву раньше вечера.
Поломка произошла.
Отклонение есть.
Но сам план может остаться полностью актуальным.
Теперь предположим, что ремонт займёт сутки.
Следующий массив не будет подготовлен к моменту выхода сеялки.
Люди и техника, которые должны были работать там завтра, останутся без подготовленного фронта.
Часть ресурсов уже направлена под первоначальную последовательность.
Возникает необходимость менять следующие действия.
Событие одно и то же — поломка культиватора.
Но для плана это две совершенно разные ситуации.
Размер отклонения ещё не определяет необходимость вмешательства
Классическая цифровая логика выглядит просто:
План
↓
Факт
↓
Отклонение
Планировали обработать 300 гектаров.
Обработали 250.
Отклонение — 50 гектаров.
Но что означают эти 50 гектаров?
Возможно, предприятие спокойно выполнит их за счёт свободного времени, и следующие операции вообще не почувствуют задержки.
А возможно, именно эти 50 гектаров означают, что сеялка завтра не получит подготовленного поля.
То же самое со временем.
Планировали закончить в 18:00.
Закончили в 21:00.
Отклонение — три часа.
Но три часа сами по себе ещё не говорят, нужно ли менять дальнейшую последовательность.
Значение имеет то, какой резерв был у плана и что задержка изменила дальше.
Получается, что системе недостаточно определить величину отклонения.
Ей необходимо понимать:
способен ли действующий план это отклонение поглотить или изменение уже требует вмешательства?
Именно здесь начинается цифровая проверка актуальности плана.
У плана есть не только задачи, но и резервы
Чтобы ответить на этот вопрос, цифровой план должен содержать значительно больше, чем перечень задач и сроков.
В реальности любой рабочий план существует не на одной точной траектории.
Внутри него почти всегда есть определённый запас.
Резерв времени.
Резерв производительности.
Свободная техника.
Возможность изменить последовательность нескольких операций.
Запас ресурсов.
Допустимая задержка следующего процесса.
Пока отклонение находится внутри этих возможностей, предприятие способно продолжать работу без серьёзного изменения плана.
Но резерв постепенно расходуется.
Например, один час ремонта система способна поглотить.
Три часа — возможно, тоже.
Но в определённый момент задержка начнёт влиять на следующий процесс.
Тогда проблема меняется качественно.
Это уже не просто:
«Мы отстаём на четыре часа».
А:
«Существующего резерва больше недостаточно, и следующее действие начинает терять применимость».
Для цифровой системы это принципиальная разница.
План держится ещё и на предположениях
Кроме резервов существует другой слой, который в цифровом планировании часто почти не виден.
План строится на определённых условиях.
Мы предполагаем, что культиватор будет доступен.
Что его производительность сохранится в расчётном диапазоне.
Что следующее поле будет подготовлено вовремя.
Что посевной комплекс сможет войти туда после обработки.
Что люди и материалы будут находиться в нужной точке.
Что следующий производственный этап сможет принять результат предыдущего.
Для человека такие условия нередко очевидны.
Но цифровая система может хранить только:
«Завтра обработать поле Б».
Тогда после поломки она видит одну невыполненную задачу.
Если же цифровой план знает, что подготовка поля Б связана с последующим входом сеялки, поставкой семян, загрузкой механизаторов и дальнейшей последовательностью полей, перед системой появляется уже другая картина.
Она видит не только задачу.
Она видит зависимости, на которых держится дальнейший план.
Именно сочетание трёх элементов — действий, зависимостей и резервов — позволяет понять, действительно ли отклонение требует вмешательства.
Не всякое крупное событие важно для плана
Здесь появляется ещё одно различие.
Мы можем заранее составить список событий, которые кажутся серьёзными:
поломка техники;
срыв поставки;
отсутствие работника;
изменение производительности;
нехватка ресурса.
Но даже крупное событие не обязательно разрушает план.
Если существует достаточный резерв или альтернативный ресурс, предприятие продолжит работу почти без изменений.
И наоборот.
Небольшое событие способно стать критическим, если возникает в точке, от которой зависит вся последующая последовательность.
Поэтому значимость события для плана определяется не самим событием.
Оно становится значимым, когда происходит хотя бы одно из трёх:
изменяется условие, на котором держатся следующие действия;
расходуется критический резерв;
следующее запланированное действие перестаёт соответствовать новому состоянию системы.
Тогда цифровая система должна запускать уже не обычную фиксацию отклонения, а проверку дальнейшего плана.
Проверять нужно не только выполнение, но и следующее действие
В предыдущей статье мы пришли к выводу, что управленческое действие нельзя оценивать отдельно от состояния системы.
С планом возникает тот же принцип, но уже растянутый во времени.
Предприятие рассчитывало получить:
Состояние 1
и после него выполнить:
Действие Б
Но после поломки возникло:
Состояние 1′
Значит, цифровая система должна проверить:
Действие Б всё ещё применимо к состоянию 1′?
Если да — существующий план продолжается.
Если действие остаётся возможным после небольшой корректировки — меняется только часть последовательности.
Если нет — этот участок первоначального плана больше нельзя считать актуальным.
Получается, что после значимого события системе необходимо не просто пересчитать процент выполнения.
Она должна пройти по цепочке зависимостей вперёд и определить, где изменение фактического состояния впервые делает следующее действие сомнительным или невозможным.
Вот здесь и находится реальная цифровая граница между обычным отклонением и потерей актуальности плана.
Три состояния плана
Такой подход позволяет не превращать цифровое планирование в постоянное переписывание графика.
План может находиться как минимум в трёх состояниях.
План актуален
Изменение произошло, но существующие резервы его поглощают.
Критические зависимости сохранены.
Следующие действия остаются применимыми.
План требует локальной корректировки
Часть резервов израсходована или одна из зависимостей изменилась, но основную последовательность ещё можно сохранить.
Часть плана потеряла актуальность
Изменилось состояние, для которого рассчитывались несколько последующих действий, и дальнейшее движение по прежней последовательности уже начинает вести предприятие не туда, куда планировалось.
Важно, что устаревшим не обязательно становится весь план.
Чаще всего проблема локализована.
И задача системы — определить именно эту границу.
Цифровой системе нужно показывать, куда распространилось изменение
Вернёмся к культиватору.
Простая система увидит:
Агрегат №7 — ремонт.
Более связанная модель должна понимать дальнейшую цепочку.
Агрегат не завершит подготовку поля.
Поле не будет готово к запланированному входу сеялки.
У посевного комплекса появляется ожидание или необходимость перестановки.
Перестановка меняет потребность в ресурсах и транспортной логистике.
Меняется последовательность следующих полей.
Но одновременно часть других работ может вообще не зависеть от этой поломки.
Следовательно, системе важно показать две зоны:
что затронуто изменением;
и
что продолжает работать по первоначальному плану.
Это позволяет избежать очень распространённой ошибки — после локальной проблемы начать перестраивать гораздо большую часть предприятия, чем действительно необходимо.
Иногда важнее узнать, что менять не нужно
Адаптивность часто воспринимается как способность быстро изменить план.
Но это только половина задачи.
Вторая половина — способность сохранить то, что менять не требуется.
После поломки естественно начать переставлять технику, менять очередность, переназначать людей.
Но каждое новое изменение само создаёт последствия.
Если первоначальный план способен поглотить отклонение, чрезмерная реакция может оказаться дороже самой исходной проблемы.
Поэтому цифровая система должна помогать отвечать сразу на два вопроса:
Что уже необходимо изменить?
и
Что пока можно оставить без изменений?
Возможно, именно способность удерживать эту границу и отличает адаптивную систему от системы, которая просто постоянно перепланирует сама себя.
Система должна объяснять статус плана
Недостаточно вывести сообщение:
«План требует корректировки».
Руководителю важно понимать, почему.
Например:
Событие: культиватор вышел из строя.
Изменившееся условие: поле Б не будет подготовлено к запланированному сроку.
Израсходованный резерв: допустимая задержка подготовки поля исчерпана.
Затронутые действия: вход посевного комплекса и следующая последовательность нескольких работ.
Сохраняется: остальные участки плана.
Требует решения: ждать ремонт, задействовать замену или изменить очередность.
Такое объяснение важно не только для удобства интерфейса.
Оно определяет доверие к цифровой системе.
Руководитель должен видеть не просто итог алгоритма.
Он должен понимать, какое изменение и через какую зависимость сделало часть прежнего плана сомнительной.
Цифровая система не должна автоматически переписывать весь план
Следующий шаг кажется очевидным.
Система обнаружила проблему.
Значит, пусть сама перестроит график.
Но в реальной организации новый план зависит не только от математической оптимизации.
Есть приоритеты собственника.
Допустимый риск.
Неформализованные ограничения.
Состояние людей.
Договорённости между подразделениями.
Ограничения, которых система пока вообще не наблюдает.
Поэтому на данном уровне её задача может быть другой.
Не обязательно сразу построить новую идеальную траекторию.
Сначала необходимо определить:
какая часть существующего плана больше не соответствует фактическому состоянию и почему.
После этого человек уже принимает решение о новой последовательности.
Контур проверки актуальности плана
Тогда цифровой процесс можно представить следующим образом:
Действующий план
↓
Фактическое изменение
↓
Проверка затронутых зависимостей
↓
Проверка доступных резервов
↓
Изменилось ли состояние, необходимое для следующих действий?
↓
Остаются ли следующие действия применимыми?
↓
Статус плана
Актуален
или
Требует локальной корректировки
или
Частично потерял актуальность
↓
Объяснение причин
↓
Решение человека
↓
Обновлённая последовательность
↓
Новый действующий план
В таком контуре цифровая система уже не просто сравнивает факт с графиком.
Она удерживает связь между планом и той реальностью, для которой этот план когда-то был построен.
Меняется сам смысл цифрового контроля плана
Предприятию по-прежнему необходимо знать:
что выполнено;
что не выполнено;
где появилась задержка;
какой ресурс используется;
насколько факт отличается от плана.
Но этого уже недостаточно.
Более сложный вопрос звучит так:
Меняет ли возникшее отклонение дальнейший план?
Пятьдесят гектаров могут ничего не значить, если есть запас времени.
А небольшая задержка может стать критической, если она уничтожает резерв в точке, от которой зависит следующий процесс.
Поэтому качество цифрового планирования, возможно, постепенно придётся оценивать не только по точности контроля исполнения.
Но и по способности системы вовремя определить:
какое отклонение план ещё способен поглотить;
где требуется локальная корректировка;
и в какой момент дальнейшее следование первоначальной последовательности перестаёт соответствовать фактическому состоянию предприятия.
Вместо заключения
Поломку техники цифровая система способна увидеть почти сразу.
Гораздо сложнее понять, что эта поломка изменила дальше.
Сам факт отклонения ещё не означает, что план нужно менять.
Для этого необходимо увидеть зависимости между действиями, понять доступные резервы и проверить, остаются ли следующие операции применимыми к новому состоянию предприятия.
Тогда цифровой контроль начинает развиваться дальше простой схемы:
план → факт → отклонение.
Появляется другой контур:
изменение → зависимости → резервы → применимость следующих действий → статус плана.
И задача цифровой системы уже не сводится к двум крайностям:
любой ценой вернуть предприятие к первоначальному графику
или
после каждого отклонения построить новый.
Намного важнее научиться различать:
когда план ещё способен поглотить изменение
и
когда дальнейшее следование ему уже начинает противоречить фактической реальности.
Но обнаружить этот момент — только половина задачи.
Если часть плана действительно потеряла актуальность, предприятие начинает выбирать новую траекторию уже в худших условиях.
Часть времени потеряна.
Резервы уменьшились.
Некоторые первоначально доступные варианты исчезли.
И тогда организация всё чаще выбирает уже не между хорошим и плохим решением.
Она выбирает между несколькими вариантами, каждый из которых содержит собственные ограничения и потери.
Это уже следующий вопрос:
почему система постепенно начинает выбирать меньшее зло?
