Почему цифровая система должна видеть решения до их исполнения
Как обнаружить конфликт между действиями ещё до того, как он стал производственной проблемой
Вернёмся к ситуации из предыдущей статьи, но теперь посмотрим на неё со стороны цифровой системы.
Идёт уборка.
В 10:00 агроном смотрит прогноз погоды и решает ускорить работу на нескольких массивах. Для этого после обеда понадобится дополнительная машина.
Решение выглядит разумным.
В 10:05 инженер получает информацию о состоянии той же техники. По его оценке, машину лучше сегодня вывести на обслуживание, пока небольшое отклонение не превратилось в серьёзную неисправность.
Это решение тоже вполне обоснованно.
В 10:10 логистика, не зная о двух предыдущих решениях, меняет часть маршрутов транспорта, рассчитывая на прежнюю последовательность уборки.
Третье решение тоже профессиональное.
При этом фактически пока ничего не произошло.
Машина продолжает работать.
Транспорт идёт по прежним маршрутам.
Техника ещё никуда не переброшена.
Если в этот момент посмотреть только на текущее состояние предприятия, всё может выглядеть нормально.
Техника доступна.
Работы выполняются.
Ресурсы распределены.
Критических отклонений нет.
Но внутри предприятия конфликт уже появился.
Пока он существует не между действиями.
Он существует между решениями, которые ещё не успели стать действиями.
Мы привыкли считать такие ситуации обычной работой
Самое интересное, что для реального производства в этой истории почти нет ничего необычного.
Через некоторое время выяснится, что машину одновременно ждут в поле и в ремонте.
Логистика поймёт, что новый маршрут уже не соответствует изменившейся последовательности.
Кто-то позвонит.
Кто-то изменит задачу.
Найдут другую машину.
Что-то перенесут.
Кто-то подождёт.
Если ситуация сложнее — подключится руководитель.
Потом работа снова продолжится.
И очень часто никто даже не назовёт произошедшее отдельной проблемой системы.
Скорее скажут:
— Обычный рабочий процесс.
— Всё заранее всё равно не предусмотришь.
— Производство есть производство.
— Человеческий фактор никуда не денется.
И последнее утверждение во многом справедливо.
Люди никогда не будут обладать полной информацией о действиях друг друга.
Условия будут меняться.
Специалисты будут по-разному оценивать риски.
Решения будут пересматриваться.
Что-то по-прежнему будет решаться звонком, разговором в поле или сообщением в рабочем чате.
Цифровая система этого полностью не устранит.
Но отсюда совсем не следует, что последствия человеческого фактора обязательно нужно обнаруживать только после того, как они превратились в производственный конфликт.
Мне кажется, здесь появляется более интересный вопрос.
Не как убрать человека из процесса.
А как раньше увидеть часть конфликтов, которые человеку потом всё равно придётся разруливать вручную.
То, что мы умеем быстро разрулить ситуацию, ещё не означает, что она обязательно должна была возникнуть
Сегодня значительная часть подобных конфликтов компенсируется людьми.
Причём сильные специалисты делают это настолько привычно, что сама компенсация начинает восприниматься как нормальная работа.
Позвонили.
Передоговорились.
Сдвинули график.
Переназначили технику.
Нашли обходной вариант.
По отдельности каждый такой эпизод может казаться мелочью.
Но предприятие всё равно платит.
Временем ожидания.
Повторным планированием.
Переключением внимания.
Срочными перестановками.
Простоями.
Иногда — дополнительными расходами.
Можно пока назвать это ценой поздно обнаруженной несовместимости решений.
Не как строгий научный термин.
Скорее как способ увидеть потерю, которую мы привыкли относить к обычной производственной жизни.
И тогда вопрос становится конкретнее:
можно ли обнаружить часть таких конфликтов ещё до того, как людям пришлось начать их компенсировать?
Цифровая система не всегда видит всё, что предприятие уже собирается изменить
Сегодня внутри крупного предприятия может быть очень много цифровой информации.
Известно местоположение техники.
Есть производственный план.
Фиксируются ремонты.
Существуют задачи, маршруты, заявки, графики, остатки.
Во многих цифровых контурах фактическое и уже утверждённое состояние видно достаточно хорошо.
Но значительно сложнее одновременно увидеть совокупность решений, которые разные участники только формируют или уже собираются исполнять.
Агроном ещё не переставил технику.
Он только решил это сделать.
Инженер ещё не остановил машину.
Он только готовит её вывод на обслуживание.
Логист ещё не изменил маршрут.
Он только сформировал новую схему.
Между текущим состоянием предприятия и следующим фактическим состоянием появляется ещё один слой:
решение уже существует, но физическая реальность ещё не успела измениться.
Именно этот слой становится важным для цифровой системы.
Решение появляется раньше действия
Представим, что машина сейчас отображается как свободная.
Это правда.
Но агроном уже решил использовать её с 14:00.
До 14:00 статус:
«свободна»
формально остаётся правильным.
Однако для другого руководителя, который тоже строит решение на доступности этой машины после 14:00, такой информации уже недостаточно.
Физически ресурс свободен.
Но часть его ближайшей будущей доступности уже занята сформированным решением.
Получается необычное состояние:
фактическое состояние ещё не изменилось, а ближайшее управленческое будущее ресурса уже изменилось.
Значит, рядом с привычным вопросом:
Что происходит сейчас?
появляется ещё один:
Что участники предприятия уже собираются изменить?
Но системе не нужно знать каждую мысль человека
Здесь легко построить очень неудобную цифровизацию.
Обязать человека заранее регистрировать каждую идею, возможную перестановку или разговор.
Получится дополнительная бюрократия.
Люди начнут тратить время уже не на решение проблемы, а на описание системе собственных намерений.
Поэтому граница должна проходить в другом месте.
Не каждую мысль нужно оцифровывать.
Цифровому контуру важно увидеть решение тогда, когда локальное решение начинает создавать существенные последствия за пределами собственной зоны.
Например, оно:
занимает общий ресурс;
меняет будущую доступность техники;
сдвигает критический срок;
изменяет последовательность;
увеличивает нагрузку следующего процесса;
меняет состояние объекта;
или разрушает предположение, на котором уже строится другое решение.
Именно тогда локальный выбор становится частью общей цифровой картины.
Это больше, чем календарь занятости ресурсов
Самый простой конфликт очевиден.
Два подразделения хотят одну машину в одно время.
Но реальные решения способны становиться несовместимыми значительно сложнее.
Конфликт ресурса
Две задачи одновременно рассчитывают на одну машину, специалиста, ремонтную бригаду, транспорт или площадку.
Конфликт времени
Для одного процесса задержка на три часа допустима.
Но следующий рассчитывал получить его результат именно к определённому моменту.
Конфликт состояния
Производство строит решение на предположении, что машина исправна.
Инженер уже принял решение остановить её на диагностику.
Конфликт последовательности
Одно подразделение меняет порядок работ, а связанный процесс продолжает действовать по старой очередности.
Конфликт ограничения
Два действия по отдельности допустимы.
Но вместе они создают нагрузку, превышающую возможность следующего этапа.
Конфликт предположений
Решение А построено на условии:
ресурс будет доступен завтра утром.
Решение Б делает это условие неверным.
При этом второе решение может вообще относиться к другому процессу.
Вот этот вариант особенно интересен.
Он показывает, что цифровому продукту мало проверять занятость ресурсов.
Нужно понимать ещё и основные условия, на которых держатся решения.
Одно решение может сделать другое устаревшим ещё до исполнения
Ранее в серии мы уже разбирали, почему план теряет актуальность после изменения фактической реальности.
Прошёл дождь.
Сломалась машина.
Задержалась поставка.
Здесь механизм другой.
Ситуацию собирается изменить другое решение.
В 10:00 агроном решил использовать агрегат после обеда.
В 10:05 инженер решил после текущей операции направить его на диагностику.
Первое решение не стало ошибочным.
Просто изменились условия, на которых оно строилось.
Причём агрегат всё ещё работает.
То есть:
одно решение способно изменить применимость другого раньше, чем любое из них было исполнено.
Именно здесь, на мой взгляд, находится главное отличие сегодняшней темы от предыдущих разговоров о планах, отклонениях и локальной оптимизации.
Хорошее решение и совместимое решение — не одно и то же
До этого в серии мы много обсуждали качество отдельного выбора.
Какой вариант предпочтительнее?
Какие ограничения существуют?
Какова цена компромисса?
Какой риск остаётся?
Теперь появляется ещё одно качество:
может ли выбранное решение одновременно существовать с другими решениями, которые предприятие уже собирается выполнять?
Решение способно быть:
профессионально обоснованным;
экономически разумным;
допустимым по риску;
находиться в полномочиях человека;
и всё равно конфликтовать с другим таким же разумным решением.
Условно цифровой продукт мог бы различать три состояния.
Независимое решение.
Существенно не меняет условий других активных решений.
Совместимое решение.
Связи существуют, но решения могут выполняться одновременно.
Конфликтующее решение.
Каждое допустимо отдельно, но совместное исполнение невозможно либо выводит систему за существенное ограничение.
Именно третий вариант требует вмешательства.
Ценность появляется до физического конфликта
Сегодня несовместимость часто обнаруживается уже в производстве.
Машины нет там, где её ждут.
Маршрут уже изменён.
Люди получили новую задачу.
Следующий процесс начал ждать.
После этого начинается ручная координация.
Цифровая система могла бы сдвинуть эту точку раньше.
Например:
«Оба решения допустимы отдельно. Одновременно выполнить их невозможно: они предполагают использование агрегата №7 с 14:00 до 18:00».
Или:
«Изменение очередности работ делает неверным предположение логистического решения о завершении участка к 17:00».
Конфликт ещё не превратился в простой.
Не потребовал срочного звонка.
Не вызвал перестройку уже начавшейся работы.
Но причина уже видна.
Получается, цифровой продукт не устраняет человеческий фактор.
Он переносит часть корректировок в точку, где их цена ещё значительно ниже.
Проверка совместимости не должна становиться новым согласованием
Вот здесь находится принципиальная граница.
Если после каждого значимого решения система начинает просить подтверждение, уведомлять всех, подключать руководителя и создавать дополнительный маршрут, мы просто построили ещё один слой бюрократии.
Поэтому проверка должна отвечать прежде всего на вопрос:
существует ли существенный конфликт?
Если его нет:
«Решение затрагивает связанные процессы, но несовместимости с действующими и готовящимися решениями не обнаружено. Дополнительное согласование не требуется».
Если конфликт есть, система должна показать конкретную причину.
Например:
Агроном планирует использовать агрегат №7 с 14:00.
Инженер планирует вывести его на обслуживание с 13:30.
Решения несовместимы по доступности машины.
И уже после этого можно рассматривать варианты:
перенести обслуживание;
использовать другую машину;
изменить очередность;
сдвинуть работу.
То есть хороший цифровой продукт должен быть почти незаметным там, где решения друг другу не мешают.
Такую логику можно назвать минимально необходимой координацией.
Не каждый конфликт требует более высокого руководителя
Если после обнаружения любого противоречия система просто отправляет вопрос наверх, предприятие получает очень эффективный механизм централизации.
Но не решение проблемы.
Допустим, агроному достаточно сдвинуть операцию на три часа.
Инженер способен перенести обслуживание в допустимом диапазоне.
Оба обладают нужными полномочиями.
Система показывает точку конфликта и последствия корректировок.
Люди разрешают его на своём уровне.
Наверх вопрос имеет смысл передавать тогда, когда локальной корректировки уже недостаточно и требуется:
изменить общий приоритет;
пересмотреть допустимый риск;
задействовать критический ресурс;
выйти за установленную границу;
или изменить общую цель.
Поэтому задача цифрового продукта — не ускорять передачу всех вопросов наверх, а сокращать количество ситуаций, которые невозможно разрешить без верхнего уровня.
Как может выглядеть контур совместимости решений
Условно:
значимое готовящееся решение
↓
какие ресурсы, сроки, состояния и предположения оно использует
↓
что изменится после исполнения
↓
какие действующие или готовящиеся решения зависят от этих элементов
↓
совместимы ли решения?
Если да:
дополнительного вмешательства не требуется
Если нет:
↓
где находится конфликт
↓
какие изменения способны его устранить
↓
можно ли выполнить корректировку внутри имеющихся полномочий
Если можно:
конфликт разрешается локально
Если нельзя:
на следующий уровень передаётся конкретный конфликт приоритетов, риска или ограничения
После выбора:
↓
общая цифровая модель обновляется
↓
следующие решения строятся уже на изменившейся ситуации.
Так система начинает работать уже не только с отдельной рекомендацией.
Она начинает удерживать совместимость множества решений до их исполнения.
Но кто увидит решения, возникающие в разных цифровых системах?
На крупном предприятии одна система может работать с техникой.
Другая — с ремонтами.
Третья — с логистикой.
Четвёртая — со складом.
Пятая — с финансами.
Шестая — с производственным планом.
Каждая способна качественно выполнять собственную функцию.
Но если агроном меняет задачу в одной системе, инженер планирует обслуживание в другой, а логист перестраивает движение в третьей, появляется вопрос:
кто увидит эти изменения вместе до того, как они изменили фактическую реальность?
Каждая программа отдельно может считать своё решение нормальным.
Несовместимость возникает уже на уровне предприятия целиком.
Поэтому может потребоваться общий цифровой слой координации решений.
Не ещё одна универсальная программа, в которую нужно перенести весь учёт.
Не замена ERP.
Не замена ремонтной системы.
Не очередная панель мониторинга.
А слой, способный связывать существенные изменения между существующими цифровыми контурами и проверять, не делают ли они решения разных участников несовместимыми.
Что тогда должен уметь такой цифровой продукт
Если перевести наблюдение в требования к продукту, получается уже достаточно конкретный контур.
Система должна уметь:
- видеть значимое решение до начала исполнения, а не только его последствия;
- понимать ресурсы, сроки, состояния и ключевые предположения, на которых оно строится;
- определять, что решение собирается изменить;
- находить другие активные решения, условия которых будут затронуты;
- проверять их совместимость;
- объяснять конкретную причину конфликта и возможные точки корректировки;
- отделять ситуации, которые могут быть разрешены локально, от тех, где действительно нужен другой уровень полномочий;
- после изменения обновлять общую цифровую модель.
Это уже не только мониторинг.
Не только планирование.
Не только аналитика.
И не только рекомендация отдельному человеку.
Появляется цифровая поддержка совместимости множества решений.
Но цифровой продукт не должен становиться новым генеральным директором
Если система способна видеть решения, находить конфликты и оценивать последствия, возникает естественный вопрос:
почему бы ей самой не определять, кто должен уступить?
В части типовых ситуаций автоматизация со временем действительно может идти дальше.
Но сегодня не все существенные ограничения предприятия полностью представлены в цифровой модели.
Есть неполные данные.
Редкие исключения.
Профессиональные оценки.
Неформализованный контекст.
Управленческие приоритеты.
Ограничения, которые сегодня ещё трудно полностью выразить цифрой.
Возможно, со временем часть этой границы тоже сдвинется.
Но практическая задача уже существует раньше:
помочь многим людям принимать больше решений самостоятельно, не теряя цифровой связи между этими решениями.
Это существенно отличается от попытки создать один огромный алгоритм, который будет решать всё за всех.
Чем меньше решений собирается в центре, тем важнее цифровая связность между ними
Централизация удерживает целостность понятным способом.
Значимые решения проходят через одну точку.
Там легче увидеть конфликт.
Но в предыдущей управленческой статье мы уже пришли к другому пределу: право окончательного выбора может находиться в центре, а существенное знание для этого выбора — одновременно у нескольких специалистов и подразделений.
Поэтому распределение решений становится не только вопросом скорости.
Оно связано ещё и с распределением знания.
Но как только решения начинают возникать в разных точках, их целостность уже нельзя удерживать только одним местом принятия решения.
Появляется другая задача:
достаточно рано понимать,
какие решения формируются;
что они собираются изменить;
и где одно из них начинает менять условия другого.
То есть чем больше самостоятельности получает организация, тем важнее становится цифровая связность решений.
Вместо заключения
Конфликты между решениями появились не вместе с цифровизацией.
Они существовали всегда.
И будут существовать дальше.
Люди будут по-разному видеть ситуацию.
Менять планы.
Ошибаться.
Договариваться.
Что-то решать устно.
Иногда действовать быстрее, чем информация успеет попасть в систему.
Это нормальная часть живого предприятия.
Поэтому задача следующего этапа цифровизации, вероятно, не в устранении человеческого фактора.
И не в том, чтобы система принимала всё больше решений вместо человека.
Вопрос значительно практичнее:
можно ли часть неизбежных конфликтов между решениями увидеть раньше, чем они превратились в простой, переделку, срочный звонок или очередное ручное разруливание?
Для этого цифровому продукту недостаточно знать только то, что существует сейчас.
Ему постепенно придётся учитывать ещё и то, что организация уже собирается изменить.
Машина ещё свободна.
Маршрут ещё прежний.
Работа ещё не перенесена.
Но два решения уже предполагают разное будущее.
Если система способна увидеть это в такой точке, она не устраняет человеческий фактор.
Она просто переносит конфликт туда, где цена его исправления значительно ниже.
Наверное, именно здесь и появляется следующий уровень цифровой поддержки управления:
не решать всё за людей, а помогать их решениям не разрушать друг друга ещё до исполнения.
Но допустим, эту задачу мы решили.
Решения совместимы.
Ресурсы распределены.
Маршруты синхронизированы.
Техника загружена.
Люди заняты.
Свободные мощности используются почти идеально.
Предприятие выглядит очень эффективным.
Что произойдёт, если в такой системе сломается одна машина?
Задержится транспорт?
Изменится погода?
Если свободного резерва почти не осталось, даже очень хорошо скоординированная система может оказаться удивительно хрупкой.
И тогда следующий вопрос звучит уже иначе:
Почему устойчивость системы может оказаться важнее максимальной эффективности?