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

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

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

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

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

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

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

Значит, нужен ещё один инструмент.

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

На встрече это стало видно довольно быстро

Клиент описывал понятную бизнесовую проблему.

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

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

Проблема в регулярности исполнения.
Руководитель сначала проходит отчёт с сотрудниками.

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

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

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

Это не теоретический вывод. Я сам часто действовал именно так.
В компании появлялась проблема.
Я видел её.

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

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

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

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

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

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

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

Почему вы плохо работаете с отчётом?

А в формате конкретной бизнес-задачи. Например:

Мы теряем продажи из-за отсутствия ходовых товаров и продолжаем копить неликвиды. Что ты предлагаешь изменить в работе отдела, чтобы эти два показателя начали двигаться в нужную сторону?

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

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

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

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

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

Для меня здесь важнее принцип:

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

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

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

KPI для меня вообще не вечная конструкция

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

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

Я не воспринимаю KPI как табличку, которую один раз повесили на должность и больше не трогаем.
Бизнес меняется.
Ограничения меняются.
Процессы меняются.
Автоматизация меняет сам состав работы человека.

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

Они всё ещё двигают ту проблему, которая сегодня важна бизнесу?

Если нет, то наличие KPI само по себе ничего не доказывает.

Технологическую часть я при этом не отменяю

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

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

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

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

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

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

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

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

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

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

А потом возникает ложный запрос:

Давайте автоматизируем, чтобы руководитель наконец начал контролировать.

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

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

Идеальная для меня ситуация выглядела бы так.
Руководитель получает конкретную цель.
Пытается её выполнить.
Несколько недель реально работает с текущим отчётом.

Видит, что процесс занимает слишком много времени или системно приводит к ошибкам. И приходит с проблемой:

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

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

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

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

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

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

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

Для меня это полезное изменение управленческого стандарта.
Но оно не меняет владельца функции.
ИИ может помочь руководителю думать.
Внешний специалист может помочь спроектировать автоматизацию.
Система может снять ручную работу.

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

В итоге исходная задача разделилась ещё на два слоя

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

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

Первая:

Что в самой работе можно упростить или автоматизировать?

Вторая:

Кто отвечает за результат этой работы и почему текущий управленческий контур допускает повторение проблемы?

Для меня это важная граница.

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

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

Все материалы этого исследования собраны в серии “Автоматизация оптовой компании”.

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