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

127

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

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

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

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

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

Сразу уточню.

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

Вопрос в другом:

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

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

Типовой процесс описали.

Возникло исключение — добавили условие.

Появилась новая ситуация — уточнили алгоритм.

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

Постепенно цифровая система должна знать всё больше и ошибаться всё меньше.

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

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

И проблема постепенно переходит от вопроса:

«Сколько регламентов мы оцифровали?»

к значительно более сложному:

«Как цифровая система определит, какое из этих правил действительно применимо сейчас?»

Регламент для человека и правило для цифровой системы — не одно и то же

Представим простой производственный регламент:

«При длительной остановке основной техники и наличии доступного резерва использовать резервную машину».

Для опытного руководителя такая формулировка вполне понятна.

Он примерно представляет, что считать длительной остановкой. Знает, какая техника действительно является резервной. Уточнит её состояние. Посмотрит, где она находится. Вспомнит, не понадобится ли она через несколько часов в другом процессе. Поймёт, есть ли свободный механизатор. Оценит время и стоимость переброски.

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

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

Но фактически использовал значительно больше знаний, чем в ней написано.

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

Сразу появляются вопросы.

Что значит «длительная остановка»?

Два часа или четыре?

Для любой операции одинаково?

Что означает «резервная машина доступна»?

Она просто не работает сейчас?

Она технически исправна?

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

Есть возможность её перебросить?

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

Какую задержку допустимо создать там, откуда мы её заберём?

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

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

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

Цифровое правило может работать на разных уровнях самостоятельности

Здесь важно разделить ещё три ситуации.

В первой цифровая система только контролирует правило: обнаруживает отклонение и сообщает человеку.

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

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

Формально правило может быть одним и тем же.

Но требования к нему — совершенно разные.

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

Если она рекомендует решение, цена ошибки выше.

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

Поэтому вопрос цифровизации регламентов — это не только:

«Можем ли мы описать правило?»

Но и:

«Какое право на действие мы готовы этому правилу передать?»

Само наличие правила ещё не означает, что его можно применить

Возьмём другую распространённую формулировку:

«При существенном отклонении требуется дополнительная проверка».

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

Но цифровой системе необходимо определить:

что именно считается существенным;

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

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

как долго должно сохраняться отклонение;

какие сопутствующие признаки необходимо учитывать;

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

Поэтому цифровое правило постепенно превращается из простой конструкции:

событие → действие

в более сложную:

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

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

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

Данные в системе тоже имеют разную ценность

К вопросу цифровой наблюдаемости мы уже подходили раньше.

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

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

Для автоматического применения правила недостаточно спросить:

«Есть ли у нас необходимые данные?»

Нужно спросить:

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

Вернёмся к резервной машине.

В системе стоит статус:

«Доступна».

Но откуда он появился?

GPS показывает, что машина сейчас стоит.

Механик вчера отметил её исправной.

Диспетчер вручную поставил статус «свободна».

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

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

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

«доступна».

Но основания для решения разные.

Показание датчика минутной давности — одно.

Ручная отметка вчера вечером — другое.

Профессиональная оценка специалиста — третье.

Предположение алгоритма — четвёртое.

Особенно сложны данные, которые вообще не поступают автоматически:

«поле готово»;
«работа выполнена качественно»;
«поставщик подтвердил срок»;
«техника исправна»;
«ресурс свободен».

Все эти сведения можно записать в информационную систему.

Но для автоматического действия важно понимать:

кто предоставил информацию;

на основании чего;

когда;

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

как долго остаётся актуальной;

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

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

Нужны ещё требования к качеству этих параметров.

Каждое исключение делает отдельное правило точнее

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

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

В большинстве случаев всё работает.

Но однажды возникает исключение.

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

Добавляем условие:

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

Правило стало точнее.

Затем появляется другая ситуация.

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

Добавляем ещё одно условие.

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

Появляется новая ветка.

Позже меняется техника.

Структура подразделений.

Производственная технология.

Финансовые ограничения.

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

Но постепенно возникает другой эффект:

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

Новыми становятся не обязательно факторы — новыми становятся их сочетания

Эту проблему мы уже увидели при масштабировании успешного опыта.

Техника может быть знакомой.

Люди — тоже.

Логистика, деньги, сроки и ограничения давно известны.

Новой оказывается комбинация.

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

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

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

Технически решение допустимо.

Финансово тоже.

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

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

Ремонт требует:

остановить машину для диагностики.

Производство:

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

Правило резерва:

не использовать запас ниже установленной границы.

Финансы:

не превышать лимит без дополнительного решения.

Технологический план:

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

Каждое требование может быть правильным.

Но выполнить их одновременно иногда невозможно.

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

После правил появляются правила выбора между правилами

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

Например:

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

Разумно.

Но позже возникает ситуация, в которой физической угрозы безопасности ещё нет, а технический риск уже существенно вырос.

Как действовать теперь?

Появляется более подробное условие.

Потом исключение.

Затем новый критерий, определяющий, какое правило применять при конфликте предыдущих.

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

Возникают правила выбора между правилами.

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

Проблема не в памяти компьютера.

Главная сложность становится другой:

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

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

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

Возникает естественный вопрос.

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

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

Допустим, алгоритм обнаружил:

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

Полезная информация?

Да.

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

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

Нужно понять:

приводило ли это действие к лучшему общему результату;

при каких условиях оно работало;

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

какие последствия появлялись позже;

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

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

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

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

ИИ способен резко ускорять такую работу.

Но он не отменяет необходимость верификации организационного знания.

Одного отдельного правила цифровой системе недостаточно

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

Возможно, проблема находится не в недостатке правил.

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

Оно часто выглядит примерно так:

ситуация №1 → правило №1;
ситуация №2 → правило №2;
исключение → ещё одно правило;
новое исключение → следующая ветка.

Но разные регламенты могут опираться на одну и ту же более общую закономерность.

Например:

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

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

В ремонте слишком быстрый вывод техники — мастерскую.

На складе увеличение поставок — мощность приёмки.

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

Внешне это совершенно разные процессы.

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

Но внутри действует одна закономерность:

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

Тогда появляется вопрос.

Должна ли цифровая система хранить всё это исключительно как независимые правила?

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

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

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

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

Условно:

Принцип

↓

Закономерность

↓

Регламент

↓

Условия применимости

↓

Необходимые данные и требования к их качеству

↓

Граница применения

↓

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

Возьмём тот же пример.

Принцип:

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

Закономерность:

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

Дальше уже появляются конкретные регламенты.

Для уборки — одни.

Для ремонта — другие.

Для склада — третьи.

Для согласований — четвёртые.

Форма действий различается.

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

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

В такой конструкции регламент никуда не исчезает.

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

У него появляется основание.

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

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

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

Люди разобрались.

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

Кажется логичным сразу записать:

«Если такое повторится — делать так».

Иногда это действительно нужно.

Но новый случай может означать совершенно разные вещи.

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

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

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

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

«Что мы сделали?»

Но и:

«Что именно этот случай изменил в нашем понимании существующих правил?»

Нужно действительно новое правило?

Достаточно уточнить старое условие?

Или мы просто получили ещё один пример уже известного механизма?

Это уже задача не только автоматизации.

Это задача управления организационным знанием.

У цифрового правила должен быть владелец

Есть ещё одна особенность.

Цифровые правила очень хорошо сохраняются.

Человек может забыть инструкцию.

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

В этом огромное преимущество.

Но одновременно существует риск.

Меняется техника.

Технология.

Структура подразделений.

Лимиты.

Полномочия.

Источники данных.

Сам производственный процесс.

А правило остаётся прежним.

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

Для него должно быть понятно хотя бы:

кто отвечает за его содержание;

кто утвердил текущую версию;

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

когда правило проверяли;

и какие изменения требуют повторной верификации.

Причём цифровой масштаб создаёт здесь отдельный риск.

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

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

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

Она так же эффективно способна масштабировать неправильно описанную логику.

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

Это масштаб управленческого риска.

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

Обычно мы ждём от автоматизации определённости.

Возникла ситуация.

Система должна найти алгоритм и дать ответ.

Но представим другое состояние.

Одно правило предлагает действие.

Второе его ограничивает.

Часть данных актуальна.

Другая давно не подтверждалась.

Один критический параметр введён человеком.

А конкретная комбинация условий раньше вообще не встречалась.

Что безопаснее?

Автоматически выбрать наиболее похожий сценарий?

Или признать, что оснований пока недостаточно?

Иногда зрелый цифровой ответ может выглядеть так:

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

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

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

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

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

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

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

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

Простая автоматизация часто строится так:

событие → правило → команда.

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

текущее состояние предприятия

↓

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

↓

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

↓

соответствующие закономерности

↓

потенциально применимые регламенты

↓

проверка условий и ограничений

↓

проверка конфликтов между правилами

↓

достаточно ли оснований для действия?

↓

автоматическое действие

или

рекомендация человеку

или

передача нестандартной ситуации на управленческий уровень

Так цифровая система перестаёт быть просто исполнителем огромного справочника инструкций.

Она начинает работать ещё и с границами применимости накопленного знания.

Это можно проверить уже сегодня

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

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

Почему это правило существует и какую проблему оно должно решать?
На какую повторяемую закономерность оно опирается?
Для каких состояний предприятия правило создавалось и какие условия обязательны для его применения?
Какие данные подтверждают наступление этих условий и насколько они должны быть актуальны и достоверны?
С какими другими правилами или ограничениями оно способно конфликтовать?
Кто отвечает за содержание и актуальность алгоритма?
Какие изменения требуют повторной проверки правила?
В каком случае система должна прекратить автоматическое применение и передать решение человеку?

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

Если же ответ заканчивается словами:

«Так настроено в системе»,

возможно, был оцифрован регламент.

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

Чем сложнее предприятие, тем важнее регламенты

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

если заранее описать все возможные состояния невозможно, зачем вообще пытаться?

Но всё наоборот.

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

Повторяемые ситуации должны становиться стандартными.

Известные ограничения — фиксироваться.

Формализуемые проверки — автоматизироваться.

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

Иначе масштаб снова начинает зависеть от конкретных специалистов, которые «знают, как здесь правильно».

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

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

тысячи условий;

сотни исключений;

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

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

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

Получится парадокс.

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

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

Возможно, правила должны выполнять более широкую функцию

Мы привыкли воспринимать правило как готовый ответ:

произошло А → делаем Б.

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

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

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

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

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

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

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

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

Опыт необходимо сохранять.

Повторяемые процессы — стандартизировать.

Типовые решения — по возможности оцифровывать и автоматизировать.

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

Цифровой системе постепенно необходимо учитывать не только:

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

но и:

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

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

Нужна более связанная структура:

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

Но даже такая архитектура не снимает следующей проблемы.

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

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

Нашла несколько применимых правил.

Обнаружила между ними противоречие.

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

И правильно определила, что готового ответа больше нет.

Решение всё равно необходимо принять.

И кто-то должен сказать:

«Да. При этих условиях мы выбираем этот вариант и принимаем связанный с ним риск».

В этот момент ограничением становится уже не количество правил.

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