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

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

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

Что должна учитывать система, чтобы в такой ситуации не предложить формально оптимальный, но управленчески неприемлемый вариант?

Если ответ свести к «нужно больше данных и лучше алгоритм», проблема останется.

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

Цифровой системе мало знать, что выгоднее

В простой модели всё выглядит логично.

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

В реальном управлении этого недостаточно.

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

Другой окажется дороже, зато сохранит устойчивость.

Третий ухудшит выполнение текущего плана, но не допустит выхода нагрузки за установленную границу.

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

Не менее важно оценивать состояние, в которое каждый из них переведёт предприятие.

То есть рядом с вопросом:

«Что мы получим сейчас?»

появляется второй:

«Что останется после этого решения?»

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

Не все ограничения одинаковы

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

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

Но здесь важно не складывать все ограничения в одну категорию.

Есть абсолютные ограничения.

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

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

Есть другой класс — управленческие границы.

Например:

допустимый уровень риска;

минимальный резерв ресурсов;

предельная стоимость решения;

максимальная загрузка;

приоритет срока относительно затрат.

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

Разница принципиальна.

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

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

После этого вопрос перестаёт быть исключительно вычислительным.

Он становится управленческим.

Цена компромисса должна быть частью самого решения

Представим обычную производственную ситуацию.

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

Предел безопасности ещё не превышен.

Можно продолжить работу и сохранить производительность.

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

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

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

Поэтому рекомендация:

«Продолжить работу»

сама по себе мало что говорит руководителю.

Полезная система должна показать иначе:

продолжение сохраняет текущую производительность;

увеличивает технический риск;

уменьшает доступный резерв;

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

То есть вместе с результатом появляется цена компромисса.

Она редко выражается одной цифрой.

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

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

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

Алгоритм может считать. Приоритеты задаёт управление

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

Проблема не в недостатке математики.

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

Какой риск считается допустимым?

Какой резерв нельзя расходовать ниже установленной границы без отдельного решения?

Когда выполнение срока важнее дополнительных затрат?

В какой момент сохранение устойчивости становится важнее максимального текущего результата?

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

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

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

Через веса показателей.

Через коэффициенты.

Через заданные пороги.

Через правила оптимизации.

Через логику программного продукта.

В результате техническая настройка незаметно превращается в управленческую политику.

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

Поэтому вопрос:

«Как настроен алгоритм?»

в какой-то момент становится недостаточным.

Появляется другой:

«Чьи управленческие приоритеты реализуют эти настройки?»

Система должна объяснять не только расчёт, но и выбор

Руководителю необязательно понимать внутреннюю математику каждого алгоритма.

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

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

Какое ограничение стало определяющим?

Какой риск изменился?

Какой резерв сохраняется или расходуется?

Чем предприятие платит за выбранный вариант?

Насколько близко решение подходит к установленной управленческой границе?

Это другой уровень объяснимости.

Не только:

«как алгоритм получил результат»,

а:

«почему именно этот компромисс считается допустимым».

В первом случае мы объясняем технологию.

Во втором — управленческую логику решения.

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

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

Автоматизация возможна только внутри понятного коридора

Из сказанного не следует, что любое сложное решение необходимо возвращать человеку.

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

Для этого нужен коридор допустимых решений.

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

Дальше возможны две принципиально разные ситуации.

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

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

Это важное различие.

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

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

И тогда задача цифровой системы — не продолжать поиск любой ценой, а показать человеку:

что предлагается изменить;

почему это стало необходимо;

что предприятие получит;

и какой ценой будет оплачен следующий шаг.

Кто имеет право менять правила допустимого

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

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

допустимый риск;

минимальный резерв;

граница стоимости;

приоритет срока относительно затрат.

Кто определил эти значения?

И кто имеет право их изменить?

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

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

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

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

кто устанавливает границы;

кто имеет право их пересматривать;

при каких условиях это происходит;

и кто несёт ответственность за последствия изменения этих правил.

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

От рекомендации — к архитектуре выбора

Простая цифровая модель обычно выглядит так:

данные → алгоритм → рекомендация.

Для сложной системы управления этого уже мало.

В одном контуре необходимо связать:

текущее состояние объекта;

доступные варианты действий;

абсолютные ограничения;

изменяемые управленческие границы;

приоритеты;

ресурсы и резервы;

риск;

цену компромисса;

состояние после решения;

полномочия системы;

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

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

«Что выгоднее сделать?»

Она помогает разобраться:

«Какое решение допустимо сейчас, какой ценой оно достигается и кто имеет право принять его в этой ситуации?»

Это уже не просто более сложный алгоритм оптимизации.

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

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

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

А дальше ограничением становится сама организация

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

Она быстро пересчитывает варианты.

Учитывает установленные ограничения.

Показывает цену компромисса.

Работает внутри собственных полномочий.

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

Но дальше это решение попадает в реальную организацию.

В уровни согласования.

В распределение полномочий.

В регламенты.

В ответственность нескольких руководителей.

И может оказаться, что цифровая система уже способна пересчитывать ситуацию быстрее, чем организация способна пересматривать собственные решения.

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

Ограничением становится архитектура управления.

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

почему бюрократия возникает не из-за глупости.