К содержанию
← Все посты← На главную
Рабочие процессы

Оценивая эффективность работы компании, измеряйте не время работы, а время от появления сигнала до реакции компании

Оценивая эффективность работы компании, измеряйте не время работы, а время от появления сигнала до реакции компании

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

Эти величины могут различаться очень существенно.

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

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

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

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

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

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

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

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

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

Я бы начал с одного недавнего сбоя и восстановил его хронологию по сообщениям и действиям. Какой первый сигнал действительно позволял заподозрить проблему? Что компания знала в тот момент? Сколько времени ушло на проверку, а сколько — на ожидание?

Возможно, после такого разбора главным вопросом станет: зачем мы ускоряем подготовку документа, который потом три дня никто не открывает?

← ПредыдущийСамая важная система компании может отсутствовать в вашей IT-архитектуре
Следующий →AI автоматизирует не профессии. Он забирает отдельные когнитивные операции