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

но и запас устойчивости.

Как понять, выдержит ли предприятие отклонение ещё до того, как оно произошло

Идёт посевная.

Несколько посевных комплексов работают на своих массивах. Семена и удобрения распределены. Маршруты подвоза выстроены. Механизаторы находятся на смене. Техника исправна.

Есть и один свободный трактор.

На экране цифровой системы всё выглядит нормально.

Работы выполняются.

График выдерживается.

Техника используется достаточно плотно.

Критических отклонений нет.

Но попробуем задать системе другой вопрос:

что произойдёт, если трактор одного из посевных комплексов прямо сейчас станет недоступен на четыре часа?

Пока ничего не сломалось.

Никто не опоздал.

План не нарушен.

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

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

Есть свободный трактор.

Значит, резерв существует.

Но действительно ли это так?

Устойчивость трудно увидеть, пока всё работает нормально

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

Для цифровой системы возникает следующий вопрос:

как проверить реальную способность предприятия к манёвру, если никакого отклонения пока ещё не произошло?

В нормальном режиме слабое место может вообще никак себя не показывать.

Техника работает.

Материалы поступают.

Люди знают свои задачи.

Следующие операции подготовлены.

По текущим показателям предприятие выглядит устойчивым.

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

Один и тот же свободный трактор может быть настоящим резервом.

А может только выглядеть им на экране.

Свободный ресурс ещё не означает реальную замену

Вернёмся к нашему условному сценарию.

Трактор одного посевного комплекса недоступен четыре часа.

Система видит другой свободный трактор.

Но дальше появляются вопросы.

Подходит ли он по мощности?

Где находится?

Сколько времени займёт переброска?

Можно ли быстро соединить его с нужным агрегатом?

Есть ли механизатор?

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

Сможет ли снабжение поддержать изменившуюся последовательность?

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

Если нет, возникает странная ситуация:

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

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

Поэтому цифровой системе мало знать:

сколько ресурсов сейчас свободно?

Намного важнее понять:

какие отклонения каждый из них действительно способен компенсировать в нужное время?

У резерва тоже есть условия применимости

Мы привыкли считать резерв количеством.

Три машины работают.

Одна свободна.

Значит, одна машина находится в резерве.

Но для сложного предприятия этого недостаточно.

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

Человеком.

Оборудованием.

Материалами.

Временем.

Связанными мощностями.

Поэтому цифровая модель должна видеть не только свободный объект.

Ей нужно понимать возможность выполнить с его помощью конкретный манёвр.

Именно здесь начинается отличие реального резерва от строки «свободно» в информационной системе.

Один резерв можно случайно посчитать дважды

Допустим, свободный трактор действительно подходит идеально.

Он рядом.

Исправен.

Есть механизатор.

Его можно быстро включить в работу.

Проверяем первый посевной комплекс.

Если основной трактор станет недоступен, свободный его заменит.

Резерв есть.

Теперь проверяем второй комплекс.

Для него этот же трактор тоже подходит.

Снова резерв есть.

Каждый процесс по отдельности выглядит защищённым.

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

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

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

Отсюда появляется важный цифровой вопрос:

сколько разных критических ситуаций одновременно рассчитывают на один и тот же резерв?

Пока всё работает нормально, такая зависимость почти незаметна.

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

Запас может быть у техники, но отсутствовать у системы

Предположим, подходящий трактор нашли и замену выполнили.

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

Не обязательно.

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

Тогда выясняется:

техника есть;

но не хватает другого связанного ресурса.

Или воспользоваться техникой можно только ценой изменения соседнего процесса.

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

Важно другое:

могут ли необходимые ресурсы собраться в работающую альтернативу именно тогда, когда она понадобится?

В этом смысле устойчивость принадлежит уже не отдельной машине.

Она возникает на уровне связанной системы.

А если проверить её заранее?

Здесь появляется главный цифровой механизм статьи.

Не ждать реальной проблемы.

А временно внести отклонение в цифровую модель.

Например:

трактор посевного комплекса №2 недоступен следующие четыре часа.

После этого система пытается определить:

какая замена действительно доступна;

какие дополнительные ресурсы для неё потребуются;

что придётся изменить;

и насколько далеко эта перестройка распространится.

Такую проверку можно пока условно назвать цифровым стресс-тестом устойчивости.

Не как окончательный термин.

Скорее как рабочий принцип:

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

Проверять нужно не всё, что теоретически может произойти

Здесь легко уйти в другую крайность.

Можно рассчитать отказ одной машины.

Двух.

Трёх.

Задержку материалов.

Погоду.

Отсутствие людей.

Изменение производительности.

Ещё сотни вариантов.

Модель станет сложнее.

Но управление от этого не обязательно станет лучше.

Поэтому задача не в количестве сценариев.

Сначала нужно определить:

какие элементы текущей конфигурации предприятия сейчас труднее всего заменить?

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

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

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

А с критических зависимостей сегодняшнего состояния предприятия.

Главное — не только выдержим ли мы отклонение

Допустим, расчёт показал:

один трактор предприятие временно потерять может.

Хорошо.

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

Важнее понять:

как именно система его компенсирует?

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

Остальные процессы практически не меняются.

Проблема остаётся локальной.

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

Её приходится переносить.

Меняется снабжение.

Сдвигается следующая работа.

Появляется ещё одна корректировка.

Исходное отклонение одинаковое.

Но глубина перестройки предприятия совершенно разная.

Именно она может многое сказать о фактическом запасе устойчивости.

Когда локальная проблема перестаёт быть локальной

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

Но если его недостаточно, приходится затрагивать соседний процесс.

Меняется уже его состояние.

После этого требуется следующая корректировка.

Потом ещё одна.

Так небольшое отклонение начинает распространяться.

Для цифровой системы появляется новый объект наблюдения:

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

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

Первый манёвр возможен. А второй?

Предположим, предприятие успешно прошло такую проверку.

Один трактор временно потерять можем.

Замена существует.

Работа продолжится.

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

Временной запас сократился.

Одна альтернативная возможность исчезла.

Следующая операция стала плотнее.

Первое отклонение предприятие выдержало.

Но само состояние системы после компенсации уже изменилось.

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

Здесь объект другой.

Мы проверяем текущее состояние предприятия целиком.

Поэтому вопрос звучит так:

если система справилась с первым обычным отклонением, остаётся ли у неё нормальный ответ на следующее?

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

Для цифры важен не только размер резерва, но и оставшиеся действия

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

Если после небольшой перестройки остаётся несколько приемлемых вариантов, система сохраняет манёвренность.

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

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

Именно это становится измеримым следствием состояния системы.

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

Обычная панель способна показать:

загрузка техники — 92%;

свободно — 8%.

Это полезная информация.

Но для оценки устойчивости её недостаточно.

Руководителю важно понимать ещё несколько вещей:

1. какой ресурс действительно способен заменить выпавший;
2. что потребуется для такой замены;
3. кто ещё рассчитывает на тот же резерв;
4. останется ли проблема локальной;
5. какие возможности сохранятся после перестройки.

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

Не обязательно отдельный красивый экран.

Скорее логика, которую цифровая система должна удерживать внутри расчёта.

Запас устойчивости постоянно меняется

Даже такую оценку нельзя сделать один раз.

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

Через несколько часов он может стать критическим.

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

После одной задержки его уже нет.

Сегодня нужный специалист доступен.

Завтра он занят другой нестандартной задачей.

Поэтому фраза:

«у предприятия есть 10% резерва»

сама по себе говорит мало.

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

резерв для чего, где и в какой момент?

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

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

Возможно, границу можно увидеть ещё до реальной проблемы

Предположим, загрузка продолжает расти.

Сначала проверка показывает:

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

Через некоторое время:

замена по-прежнему возможна, но уже требует изменения одной соседней задачи.

Ещё позже:

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

При этом фактически всё ещё работает.

Нет аварии.

Нет простоя.

План выполняется.

Но цифровая модель уже показывает:

пространство локального манёвра почти закончилось.

Возможно, именно такой сигнал окажется полезнее обычного:

«загрузка достигла 95%».

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

Как тогда меняется цифровая рекомендация

Сегодня система может сообщить:

«Трактор свободен».

Или:

«Парк загружен на 92%».

В более развитой системе сообщение могло бы выглядеть иначе:

«Свободный трактор существует, но его использование для комплекса №2 потребует переноса следующей операции».

Или:

«Один и тот же трактор является единственным резервом для двух критических участков».

Или:

«Недоступность трактора на четыре часа компенсируется локально. После этого свободного технического резерва не остаётся».

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

Она помогает увидеть:

насколько предприятие ещё способно перестроиться.

Что для этого должен уметь цифровой продукт

Если свести механизм статьи к основным требованиям, система должна уметь:

1. определять реально доступные замены, а не только свободные ресурсы;
2. видеть связанные условия, необходимые для выполнения манёвра;
3. замечать, когда один резерв одновременно страхует несколько критических ситуаций;
4. проверять текущую конфигурацию наиболее существенными для неё отклонениями;
5. показывать глубину перестройки и состояние предприятия после компенсации;
6. пересчитывать эту картину по мере изменения самой системы.

Это уже не просто управление запасами.

И не только контроль выполнения плана.

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

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

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

Но нормальный режим почти ничего не проверяет.

Более интересный вопрос возникает раньше реальной проблемы:

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

Чем его заменим?

Успеем ли?

Что ещё понадобится?

Сколько процессов придётся изменить?

Останется ли отклонение локальным?

И что останется для следующего манёвра?

Возможно, именно такие вопросы постепенно расширят само понятие цифровой эффективности.

Сильная система — это не только та, которая хорошо использует ресурсы в расчётном режиме.

Это ещё и та, которая сохраняет несколько нормальных вариантов следующего действия, когда реальность начинает отклоняться от расчёта.

Поэтому цифровому продукту следующего уровня придётся показывать руководителю не только:

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

Но и:

насколько свободно оно ещё способно изменить своё следующее действие.

А дальше возникает новый вопрос.

Допустим, система помогла оценить состояние.

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

Через некоторое время предприятие получило хороший результат.

Доказывает ли этот результат, что решение было правильным?

Не обязательно.

Качественное решение иногда заканчивается плохо из-за события, которое невозможно было знать заранее.

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

Но это уже следующая тема:

Почему хороший результат ещё не доказывает, что решение было правильным?