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

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

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

В какой-то момент на встрече с клиентом это стало главным вопросом.
Если хороший закупщик смотрит на тот же отчёт, что и остальные, но принимает более качественные решения, что именно он делает иначе?
Не в общих словах.
Не «учитывает сезонность» или «смотрит на динамику».
А буквально по шагам.
Что он открыл.
Как отсортировал позиции.
На какой показатель посмотрел первым.
Что сравнил.
Почему согласился с рекомендацией отчёта в одном случае и проигнорировал её в другом.

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

Отчёт не показывал весь реальный алгоритм

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

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

Если я просто попрошу такого человека:

Расскажи, как ты принимаешь решение?

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

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

Я хочу видеть не итог, а путь к нему

Сам по себе ответ «заказать 50 единиц» мало что даёт.
Чтобы потом превратить работу в правила, мне нужно понять, откуда это решение появилось.
Например:

1. какой отчёт человек открыл;
2. какие фильтры применил;
3. как сгруппировал номенклатуру;
4. на какие показатели посмотрел;
5. с чем сравнил текущую ситуацию;
6. какие отклонения заметил;
7. какие дополнительные обстоятельства вспомнил;
8. какое решение принял;
9. почему именно такое.

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

Почему?

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

Для меня исключения важнее очевидных случаев

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

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

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

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

Запись экрана одновременно решает несколько задач

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

1. Я получаю материал для алгоритма

Из последовательности действий можно выделить:

• какие данные действительно используются;
• какие сравнения повторяются;
• какие правила стабильны;
• какие исключения встречаются;
• где человеку не хватает данных;
• где решение пока нельзя формализовать.

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

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

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

Когда логика проговорена вслух, её можно обсуждать.
Почему именно этот период сравнивается с текущим?
Почему эта группа товаров считается особой?
Всегда ли это исключение действительно работает?
Какие правила появились исторически и давно не проверялись?

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

3. Появляется материал для обучения новых сотрудников

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

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

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

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

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

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

Если просто сказать сильному сотруднику:

Запиши подробно всё, что ты делаешь и думаешь.

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

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

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

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

После записи я бы не строил ИИ сразу

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

Следующая ошибка - сразу скормить всё модели и объявить, что цифровой сотрудник готов.
Я бы сначала превратил наблюдения в более простую карту.
Например:

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

Если правило звучит:

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

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

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

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

Хороший эксперт не обязательно умеет сразу описать свой алгоритм

Для меня это один из важных практических выводов встречи.

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

Я анализирую продажи и остатки.

А:

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

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

Автоматизация начинается не с модели, а с наблюдения

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

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

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

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

Что я хочу получить на выходе

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

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

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

Необходимый контекст.
Какие данные нужны для решения кроме основного отчёта.

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

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

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

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

Я бы применял этот подход далеко не только к закупкам

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

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

Это умеет только один сильный сотрудник.

или:

Здесь слишком много нюансов, чтобы всё описать.

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

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

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

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

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