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

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

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

Идёт напряжённый период полевых работ.

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

Машина продолжает выполнять задачу.

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

Резервная машина занята.

Через несколько дней уже запланировано окно обслуживания.

Возникает вполне реальный выбор.

Остановить трактор сейчас — изменить текущий график, искать замену и затрагивать другие работы.

Продолжить — принять дополнительный технический риск.

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

Через два дня узел выходит из строя.

Теперь всё выглядит почти очевидно.

Был сигнал.

Была возможность остановить машину раньше.

Есть простой.

Есть затраты.

И очень легко спросить:

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

Но этот вопрос задаётся уже после результата.

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

После результата прошлое выглядит проще, чем было тогда

Сегодня мы видим всю линию.

Изменение показателя.

Ухудшение.

Отказ.

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

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

Он ещё не знал, продолжится ли ухудшение.

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

И одновременно видел вполне реальную цену немедленной остановки.

Поэтому одно и то же решение выглядит по-разному:

до результата

и

после того, как результат уже известен.

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

Система может очень хорошо сохранить историю событий.

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

Журнал действий ещё не является памятью решения

Обычная информационная система способна показать:

когда появился сигнал;

кто создал заявку;

кто изменил статус;

когда техника остановилась;

когда начался ремонт;

какие затраты возникли.

Это важная история.

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

Почему в тот момент продолжить работу считалось допустимым?

Одной записи:

«Продолжить эксплуатацию»

для этого недостаточно.

Нужно восстановить:

какое состояние техники тогда считалось наиболее вероятным;

что уже было подтверждено;

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

какие реальные альтернативы существовали;

какие ограничения действовали;

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

То есть журнал отвечает:

Что сделали?

А память решения должна позволять понять:

Почему это имело смысл именно тогда?

Проблема в том, что цифровая реальность постоянно обновляется

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

Появляются новые измерения.

Меняется статус машины.

Проводится диагностика.

Перераспределяются ресурсы.

Обновляется прогноз.

Освобождаются люди и техника.

Появляются данные, которых в момент выбора ещё не существовало.

Через месяц карточка объекта уже описывает совсем другую ситуацию.

Но решение принималось не в ней.

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

И если при последующем разборе система просто использует актуальные данные, возникает незаметная подмена:

мы оцениваем прошлое решение с помощью информации, которая появилась позже.

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

Ей необходимо фиксировать ещё и версию знания на момент выбора.

Цифровой снимок контекста решения

Можно пока условно назвать такой механизм:

цифровой снимок контекста решения

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

И не архив всех баз данных на каждую секунду.

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

Например:

что было известно;

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

какие реальные варианты существовали;

какие ограничения действовали;

какой риск принимался;

какие данные и профессиональные оценки стали основанием решения.

Причём система должна сохранить именно их состояние на тот момент.

Не исправленное потом.

Не дополненное результатом.

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

Это и есть главное отличие снимка от обычной истории данных.

Для прошлого решения важна не только цифра

Допустим, в системе было записано:

«Техника исправна».

Сегодня эта фраза выглядит довольно определённо.

Но что стояло за ней тогда?

Диагностика час назад?

Полевой осмотр?

Отсутствие критических сигналов?

Предположение алгоритма?

Само значение одинаковое.

Качество основания — разное.

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

В этой статье появляется другой шаг.

Такое различие нужно сохранить во времени вместе с решением.

Для критичных данных иногда важно знать:

откуда они пришли;

когда были получены;

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

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

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

Нужно помнить и пространство выбора

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

— Почему не использовали другую машину?

— Почему не остановились раньше?

— Почему не перенесли работу?

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

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

Не было механизатора.

Окно для переноса уже закрывалось.

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

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

из чего организация реально выбирала.

И почему существенные альтернативы были исключены.

Не все возможные варианты будущего.

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

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

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

Память решения не должна стать ещё одной бюрократией

Здесь легко испортить хорошую идею.

Можно обязать руководителя после каждого действия заполнять:

что знал;

чего не знал;

какие варианты рассматривал;

какой риск принимал;

почему выбрал именно так.

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

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

Если цифровая система уже знает:

состояние техники;

план;

доступность ресурсов;

ограничения;

прогноз;

рассматриваемые варианты,

эту часть она должна сохранить сама.

Человек добавляет только то, чего система не видит.

Например:

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

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

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

И даже такой снимок нужен не для каждого действия.

Обычное решение внутри стабильного процесса можно оставить обычным логом.

Расширенная память нужна прежде всего там, где:

есть несколько существенных альтернатив;

принимается заметный риск;

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

расходуется критический резерв;

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

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

Объяснить решение и сохранить его объяснение — разные задачи

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

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

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

какой риск принимается;

какой приоритет используется.

Но это работает в момент решения.

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

Данные обновятся.

Приоритеты станут другими.

Интерфейс перестроят.

Поэтому объяснимость и память — не одно и то же.

Объяснимость помогает понять решение сейчас.
Память контекста позволяет понять то же решение потом.

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

Как это может выглядеть

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

состояние предприятия

↓

доступные данные

↓

подтверждённое / предполагаемое / неизвестное

↓

реальные варианты

↓

ограничения и риски

↓

выбранный вариант

↓

снимок контекста решения

Через год вместо одной строки:

«12 мая. Продолжить эксплуатацию»

можно увидеть:

какое состояние тогда наблюдалось;

насколько свежими были ключевые данные;

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

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

почему один из них исключили;

какой риск организация сознательно приняла.

После этого обсуждать решение можно уже не с позиции:

«мы теперь знаем, чем всё закончилось».

А с позиции:

«насколько разумным был выбор относительно того, что мы действительно знали тогда?»

Контекст решения — не цифровое алиби

Есть очевидное возражение.

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

— Тогда мы этого не знали.

Но сохранённый контекст работает в обе стороны.

Он может показать:

предупреждение существовало;

данные были доступны;

альтернатива рассматривалась;

риск был понятен;

но его всё равно проигнорировали.

Поэтому смысл не в том, чтобы снять ответственность.

Скорее наоборот.

Контекст решения — не цифровое алиби.
Это защита управленческой истории от переписывания.

И от обвинения задним числом.

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

Предприятие должно помнить не только события

Люди меняются.

Руководитель уходит.

Инженер переходит в другое подразделение.

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

В системе остаются:

событие;

решение;

действие;

результат.

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

Получается странный парадокс.

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

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

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

Не только:

что сделали,

а:

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

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

Через некоторое время почти любое прошлое решение кажется проще, чем было в момент выбора.

Результат уже известен.

Неопределённость уменьшилась.

Одни риски реализовались.

Другие — нет.

Но решение принималось раньше.

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

что сделали

и

чем всё закончилось.

Необходимо сохранить ещё одно:

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

Что было известно.

Что оставалось неизвестным.

Из чего действительно выбирали.

На каких основаниях приняли риск.

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

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

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

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

Мы знаем, чего ожидали.

Позже появилась фактическая реакция предприятия.

Насколько она совпала с первоначальным ожиданием?

И что это расхождение способно рассказать о самой цифровой модели?

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

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