Когда метрика «лечится», а процесс продолжает сбоить — что на самом деле пошло не так?
Может ли цифра болеть и сбоить?
Очевидно, нет. Сама цифра — это просто констатация факта, так почему же часто чинят метрику, а не процесс?
Не так давно наблюдал интересную картину: в сервисном подразделении увеличился (а может, просто перестал устраивать бизнес) срок исполнения одного из типов заявок. Было собрано совещание, ключевым решением которого стало внедрение SLA по данному типу заявок. Решение было оперативно исполнено и внедрено: разработаны дашборды по контролю SLA, определён алгоритм контроля и назначены регулярные встречи для контроля выполнения SLA.
Через некоторое время SLA стал выполняться, но стал ли счастлив бизнес? Нет, потому что SLA был заключён только на один тип обращения, и чтобы его стабильно выполнять, коллеги ввели приоритизацию заявок с SLA перед заявками без SLA. Таким образом, починили метрику, а не сам процесс.
Из этого кейса можно развить сразу несколько тем:
- необходимость сбалансированных комплексных метрик (система сдержек и противовесов);
- сначала нужно разобраться и устранить причину сбоя, а потом уже обвешивать процесс KPI.
К первой теме мы ещё вернёмся (если будет интерес), а вот вторую тему я бы хотел обсудить более подробно.
Итак, я часто сталкиваюсь с тем, что когда сбоит какой-то процесс, срочно начинают исправлять метрику, которая демонстрировала, что процесс нездоров.
Основной алгоритм действий в таких ситуациях следующий:
- ввести новый отчёт, чтобы оперативно “контролировать ситуацию”;
- постоянно “какделировать” исполнителей по статусу решения проблемы / текущей ситуации;
- проводить совещания на разных уровнях по исправлению текущей ситуации;
- кнут и пряник для “повышения мотивации” сотрудников к овертаймам и прочему героизму (и да, некоторые могут пряником тоже бить 🙂).
А также, как в примере выше, начинают творчески подходить к расчёту показателя метрики: либо откладывая “на потом” на другие процессы, в которых метрик нет (хотя они тоже важны), либо, ещё проще, меняют калькулятор и начинаем считать по-новому.
Если действующий менеджер не справляется с исправлением показателя, то нанимаем нового, более эффективного менеджера, который быстро наводит “красоту” в метриках — и все счастливы до следующего сбоя.
В результате таких манипуляций метрика приходит в норму, может быть, даже сама собой (так как на процесс перестал влиять какой-то фактор), эффективные менеджеры счастливы, но процесс остался с костылём или держится на героизме исполнителей. Говоря языком разработки — копится технический долг. Со временем процесс обрастает костылями, и в какой-то момент опять падает. И начинается новый круг героического исправления показателей процесса.
Такие случаи встречаются достаточно часто. В какой-то момент подобные действия начинают даже романтизироваться и ставиться в пример — мол, вот человек не жалея сил постоянно борется за показатели (или с показателями? 🙂 ) процесса. Но такой подход к управлению процессом никак нельзя назвать целевым.
Так как же нужно поступить в ситуации выше и ей подобных?
Важно помнить, что метрика — это не сама цель, а лишь индикатор состояния процесса. И если она изменяется, то нужно найти причину изменений.
И да, я осознанно написал “изменяется”, а не “ухудшается”, т.к. первопричину нужно искать всегда — даже в том случае, когда показатель улучшается без видимых на то причин.
Как ни странно, улучшение показателя тоже может свидетельствовать о сбое. Например, особо талантливый исполнитель срезал путь и перестал делать часть процесса. Это — реализация операционного риска, который был в процессе и не был прикрыт.
Даже если по факту это окажется оптимизацией процесса — всё равно мы допустили возможность отклонения от процесса. Да и в принципе стоит задуматься о культуре оптимизации процессов: почему исполнитель сам принял решение делать проще, не рассказав другим? Обладал ли он достаточными компетенциями, чтобы оценить все последствия этих изменений?
Но в любом случае, все эти размышления мы можем делать после того и только после того, как нашли первопричину, по которой процесс сбойнул.
На том, как искать первопричины, я сейчас не буду останавливаться — это тема для отдельного поста. Инструментов и подходов для этого множество. И выбор конкретного инструмента — за профессионалом, который благодаря своему опыту и текущей ситуации может выбрать подходящий. А не забивать шурупы молотком только потому, что он про него знает.
Ключевое, что я хотел сегодня донести: когда изменилась метрика в процессе, нужно звать не того, кто умеет чинить метрики, а того, кто умеет чинить процессы.
Это не значит, что метрики не важны. Наоборот — они нужны. Но только если мы используем их по назначению: как сигнал, а не как самоцель. Метрика должна помогать нам заметить и поймать тот момент, когда процесс начал меняться, а не подменять собой сам процесс.
И да, у «чинителя» метрик результат, если мы оцениваем его только по показателям, будет намного быстрее. Но эффект от работы архитектора процесса — существенно дольше и устойчивее.
Может, это только мне “повезло” такое наблюдать?
Было ли у вас так, что “по цифрам всё хорошо”, а в реальности — всё держится… на честном слове?