Почему лучший вариант — ещё не решение

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

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

Идёт напряжённый период уборки.

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

На соседнем предприятии Б ситуация спокойнее.

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

Цифровая система анализирует оба предприятия.

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

После сравнения вариантов она предлагает:

временно перебросить одну машину с предприятия Б на предприятие А.

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

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

Дополнительные расходы остаются допустимыми.

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

Кажется, цифровая система сделала именно то, чего мы от неё постепенно начинаем ждать.

Увидела взаимосвязи.

Сравнила варианты.

Оценила последствия.

Предложила предпочтительный.

Но директор предприятия Б задаёт вполне понятный вопрос:

— А если завтра остановится ещё одна моя машина?

И в этот момент становится заметно ограничение, которого практически не видно в простой схеме:

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

Показать лучший вариант — ещё не значит получить готовое управленческое решение.

Причём речь уже не только о далёком будущем.

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

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

Что вообще означает «лучший вариант»

В сложном предприятии редко существует решение, которое одновременно:

дешевле;

быстрее;

безопаснее;

сохраняет все резервы;

не увеличивает нагрузку;

не создаёт дополнительных рисков;

и одинаково выгодно всем связанным подразделениям.

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

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

Она определяет вариант, который выглядит предпочтительнее остальных:

при имеющейся информации;

при заданной цели;

при существующих ограничениях;

при определённых управленческих приоритетах;

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

В нашем примере система фактически говорит:

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

Это вполне может быть разумным выводом.

Но именно эта логика и должна быть видна руководителю.

Потому что короткое сообщение:

«Рекомендуется вариант В»

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

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

Лучший — среди чего и почему

Допустим, система рассмотрела несколько вариантов.

Можно продолжить работу существующим парком.

Можно привлечь стороннюю технику.

Можно перебросить внутренний резерв.

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

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

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

Руководителю важно понимать две вещи.

Первая:

среди каких существенных вариантов вообще происходило сравнение?

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

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

Для этой статьи важнее второй вопрос:

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

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

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

Такой ответ уже сильно отличается от:

«Алгоритм рекомендует вариант В».

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

В сложном компромиссе почти всегда что-то приходится поставить ниже

Если предприятие защищает срок, оно иногда принимает дополнительные расходы.

Если сохраняет бюджет — может потерять часть скорости.

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

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

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

Важно видеть и другое:

что ради этого результата оказалось менее приоритетным.

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

Это не означает, что интересы предприятия Б проигнорированы.

Наоборот.

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

какой резерв будет потерян;

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

при каком следующем событии положение Б станет существенно сложнее;

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

Это уже не просто расчёт эффективности.

Это описание реального компромисса.

Поэтому от цифровой системы хотелось бы видеть не только:

что стало первым вариантом,

но и:

что пришлось поставить ниже, чтобы этот вариант стал первым.

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

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

Но директор предприятия Б находится внутри другой управленческой реальности.

Именно его резерв уменьшается.

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

Если всё пройдёт хорошо, общий результат просто станет лучше.

Уборка будет завершена раньше.

Потери окажутся меньше.

Группа получит экономический эффект.

Но если завтра на предприятии Б действительно остановится вторая машина, разговор изменится.

— Почему отдали резерв?

— Кто разрешил?

— На каком основании решили, что этот риск допустим?

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

Выгода способна распределиться по всей системе.

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

Поэтому человек может понимать общий расчёт и всё равно задавать вполне профессиональный вопрос:

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

Это не обязательно сопротивление цифровизации.

Не обязательно защита собственного участка любой ценой.

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

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

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

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

Машину переместить сюда.

Транспорт — туда.

Очередность изменить.

Посчитать новые расходы.

Показать общий ожидаемый результат.

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

У директора предприятия Б остаются:

собственный производственный план;

закреплённые ресурсы;

показатели;

зона ответственности;

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

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

Но вправе ли он снизить резерв ниже определённой границы ради результата другой части группы?

Возможно, да.

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

Тогда возникает полезное различие.

Вариант может быть:

технически возможным;

экономически оправданным;

и по расчёту системы предпочтительным,

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

Например:

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

Это уже совсем другой тип цифровой рекомендации.

Система не отказывается от собственного расчёта.

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

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

Здесь возникает вполне справедливое возражение.

Почему от цифровой системы мы начинаем требовать:

покажи, что сравнивала;

объясни, почему выбрала этот вариант;

скажи, что поставила выше;

покажи оставшийся риск,

если внутри организаций мы далеко не всегда предъявляем такие же требования людям?

Главный инженер иногда говорит:

— Эту машину сегодня не трогаем.

Руководитель производства:

— Сначала закрываем этот участок.

Генеральный директор:

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

И решение начинают выполнять.

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

Иногда причина намного проще.

Человек занимает соответствующую должность.

Имеет необходимые полномочия.

Или годами доказал собственную компетентность.

Коллеги знают:

он хорошо понимает процесс;

видел похожие ситуации;

обычно замечает существенные ограничения;

и готов отвечать за результат.

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

Только в этом случае доверяют человеку.

Цифровой системе доверие ещё предстоит заработать

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

История прошлых решений.

Репутация.

Знание конкретного предприятия.

Профессиональный авторитет.

И накопленный опыт ответственности за собственные решения.

Если сильный главный инженер говорит:

— Машину пока не запускаем,

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

С цифровой системой ситуация иная.

Организация ещё не знает:

где её рекомендации особенно сильны;

где цифровая модель упрощает происходящее;

какие исключения понимает хуже;

насколько чувствительна к ошибке исходных данных;

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

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

Проблема в другом.

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

Такое доверие нельзя назначить приказом о внедрении.

Его нужно заработать.

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

Объяснение не должно превращаться в ещё один отчёт

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

Можно решить:

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

Десятки графиков.

Сотни входных параметров.

Коэффициенты.

Все промежуточные расчёты.

Полное дерево вариантов.

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

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

Получается странно.

Алгоритм обработал сложность.

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

Поэтому управленческая объяснимость не означает максимальной технической прозрачности.

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

что сравнивалось;

почему этот вариант стал предпочтительным;

что пришлось поставить ниже;

какое предположение особенно важно;

какой риск остаётся;

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

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

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

Этот вопрос, мне кажется, особенно важен.

Вернёмся к нашему примеру.

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

Что будет, если прогноз улучшится?

Если выяснится, что резервная машина Б сама требует обслуживания?

Если подрядчик сможет предоставить технику значительно раньше?

Если предприятие А восстановит неисправный комбайн за несколько часов?

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

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

На экране оба способны выглядеть одинаково:

«Рекомендуется вариант В».

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

Поэтому полезный цифровой ответ может звучать так:

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

Теперь руководитель понимает не только результат расчёта.

Он видит, на чём держится устойчивость самой рекомендации.

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

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

Не каждое цифровое решение должно всю жизнь проходить одинаковую проверку.

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

Другое дело — решение, которое:

возникает в редкой комбинации условий;

затрагивает несколько подразделений;

существенно уменьшает резерв;

опирается на неполные данные;

или имеет высокую цену ошибки.

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

То есть объём объяснения, вероятно, должен зависеть не только от сложности алгоритма.

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

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

Для текущей темы достаточно одного:

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

«Так рекомендовала система» — опасная фраза

У цифрового доверия есть и обратная сторона.

Сегодня внутри организаций можно услышать:

— Инженеры согласовали.

— Финансы проверили.

— Руководство подтвердило.

Предыдущие решения других людей действительно дают часть основания для собственного выбора.

Без этого крупная организация вообще не смогла бы работать.

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

несколько специалистов до него решение подтвердили.

И часть собственной уверенности получает из чужой.

В цифровом управлении однажды может появиться новая версия того же механизма:

— Почему сделали именно так?

— Так рекомендовала система.

Фраза удобная.

Но сама по себе она ничего не доказывает.

Если человек не понимает хотя бы:

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

какие ограничения учитывала;

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

и что оставалось неизвестным,

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

Вместо:

«До меня уже несколько человек согласовали»

появится:

«Система всё посчитала».

Само по себе это качество управления не повышает.

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

Но не подменять это основание собственным авторитетом.

А если система ошиблась?

Полностью убрать этот вопрос невозможно.

Допустим, исходные данные выглядели достаточными.

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

Решение приняли.

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

Это не означает автоматически, что первоначальное решение было неправильным.

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

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

К этой теме мы ещё вернёмся.

Для текущей статьи достаточно другого вывода.

Цифровая система не должна становиться удобной заменой фразе:

«Это не мы решили — это алгоритм».

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

А задача цифровой системы — сделать видимее основания, на которых организация принимала риск.

Как может выглядеть рекомендация следующего уровня

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

данные → алгоритм → лучший вариант.

Скорее так:

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

В такой конструкции система помогает не только ответить:

что выгоднее сделать?

Она помогает понять:

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

И это значительно ближе к реальному управлению.

Шесть вопросов к «лучшему варианту»

Даже сегодня любую серьёзную цифровую рекомендацию полезно проверить шестью вопросами:

1. Лучший — среди каких вариантов? Какие существенные альтернативы действительно сравнивались?
2. Почему этот вариант оказался предпочтительнее? Что стало определяющим в расчёте?
3. Что получило приоритет, а что пришлось поставить ниже?
4. Кто получает основной эффект, а у кого появляется дополнительный риск?
5. Кто имеет право принять этот риск? Не кто способен нажать кнопку, а кому организация действительно передала соответствующее полномочие.
6. Что должно измениться, чтобы система рекомендовала другой вариант?

Если на эти вопросы невозможно ответить, алгоритм вполне мог выполнить очень сложный расчёт.

Но организация ещё не получила полноценной поддержки управленческого решения.

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

Мы постепенно прошли довольно длинный путь.

Сначала цифровые системы помогали видеть происходящее.

Потом — раньше замечать изменения.

Связывать процессы.

Сравнивать варианты.

Учитывать ограничения.

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

Проверять применимость правил.

И вот система подходит к моменту, когда действительно способна сказать:

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

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

Предприятие состоит не только из данных, объектов и ресурсов.

В нём существуют:

люди;

локальные обязанности;

полномочия;

уровни ответственности;

и право принимать разный масштаб риска.

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

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

Руководителю необходимо понимать:

что сравнивали;

почему выбран именно этот вариант;

какой приоритет лежит в основе выбора;

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

где остаётся неопределённость;

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

и на каком уровне существует право этот риск принять.

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

И не пытается заменить её собственным авторитетом.

Она делает основания выбора более видимыми.

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

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

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

Но между расчётом и действием всё равно остаётся организация.

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

Но руководителю предприятия Б всё равно необходимо понимать:

почему это выгодно всей системе;

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

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

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

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

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

Разница в другом.

У этих людей доверие формировалось годами.

Цифровой системе этот путь ещё только предстоит пройти.

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

А как способ показать:

почему её рекомендация заслуживает доверия именно здесь;

насколько устойчив её вывод;

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

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

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

Первое.

Второе.

Десятое.

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

В какой-то момент цифровая система уже способна достаточно быстро найти варианты.

Показать основания выбора.

Обозначить риски.

Определить необходимый уровень решения.

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

И тогда следующим ограничением становится уже не алгоритм.

Не данные.

И даже не доверие к цифровой системе.

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

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

Почему сложное предприятие невозможно долго удерживать одним центром решений?