Автор: Сергей Вихарев, специалист по автоматизации управления компанией, руководитель компании Atlas Software.
Зачастую KPI называют систему оплаты труда. Предлагаю взглянуть на этот термин более широко с позиции стратегического и оперативного управления компанией. Вся суть заложена в самом понятии. «Ключевые» — это данные, важные именно для вас и вашего бизнеса. «Показатели» — те метрики, которые действительно описывают управленческий объект и показывают, что на самом деле происходит в компании. И, наконец, «эффективность» — то есть действие выполняется качественно, в рамках планируемых затрат, и приносит необходимый результат.
Например, какие ключевые показатели эффективности могут быть у бизнес-процесса по привлечению клиентов? Во-первых, количество заявок в день, во-вторых, стоимость одной конкретной заявки. А система оплаты труда вашего сотрудника (допустим, 20% от заказа) в данном случае мало что покажет.
Руководителю показатели нужны, в первую очередь, для того, чтобы принимать обоснованные управленческие решения. Так что, прежде чем начать изменения, нужно собрать показатели и понять, что в принципе происходит. Например, вместе с заказчиком мы анализировали процесс привлечения клиентов в его компании. Благодаря сбору метрик выявилось, что поступающие лиды обрабатываются медленно. Период между получением заявки и звонком менеджера был слишком длинным. За это время потенциальный клиент или забывал об оставленной заявке, или переходил к конкуренту. Через анализ показателей (сколько приходит заявок, сколько времени проходит до звонка, какая конверсия в клиенты) были выявлены болевые точки, и только после этого из множества возможных решений было выбрано доступное и наиболее оптимальное.
У нашего клиента после регистрации заявка сразу попадает в систему автоматизации. Поэтому было разработано следующее решение: во-первых, настройка сигнализации — если заявка в течение длительного времени не обрабатывается, система сообщает об этом сотрудникам. Во-вторых, настройка уведомлений для клиентов — для того чтобы потенциальный клиент знал, что работа по его заказу ведется, были сделаны специальные уведомления о ходе обработки обращения. После этого только на основе показателей можно сделать вывод, насколько верным было принятое решение. Для этого мы снова замеряем показатели и смотрим, как наши действия повлияли на результат. Только так можно оценить адекватность управленческих решений.
Например, в нашей компании все управленческие решения заносятся в систему автоматизации, где записано, на какие показатели должно повлиять конкретное решение. Через месяц я посмотрю, как изменились метрики. Только в случае, если показатели не изменились или ухудшились, я могу сказать, что глава отдела неправ. Других причин быть не может. И не важно, хорошо он защищает свою концепцию или нет. Это лирика. Если его решения улучшили показатели — значит, он эффективный руководитель. Не изменили — неэффективный.
Таким образом, показатели нам нужны, во-первых, чтобы принимать управленческие решения, и, во-вторых, чтобы оценивать качество этих управленческих решений. Но прежде чем начать собирать показатели, нужно их структурировать и понять, какие вам действительно нужны. Считать можно практически что угодно, а современные системы автоматизации позволяют собирать огромные объемы информации. Но не все из них умеют этот огромный объем информации обрабатывать и выдавать в сжатом виде. Если вы будете собирать все показатели подряд, то получите огромные таблицы, которые невозможно качественно проанализировать.
Не нужно отталкиваться от возможностей. Допустим, у вас есть система, которая показывает длину воронки продаж. Это не значит, что теперь нам обязательно нужно это знать. Попробуйте абстрагироваться от возможностей и просто пофантазировать, какие показатели вам хотелось бы получить. Затем, основываясь на стратегических целях компании и целях каждого отдела, создайте таблицу показателей. Их следует разделить на несколько групп. Первая группа — показатели, которые вы уже собираете (можно отметить их зеленым цветом), вторая — показатели, которые в данный момент не собираются. Важно сразу определить, как вы планируете их получать.
Конечно, этот процесс следует максимально автоматизировать. Например, вы владелец розничной сети и хотите знать, сколько людей ежедневно проходит мимо вашего магазина. Возможно, есть некие технические средства, которые будут собирать показатели и предоставлять только общий отчет. И если у вас есть подобные метрики, сбор которых можно автоматизировать, отмечайте их желтым. Следующая группа показателей — показатели, которые вы не можете собрать автоматически. В этом случае нужно продумать ручной способ сбора. Допустим, у вас нет возможности купить специальные датчики, но вы можете нанять сотрудника, который будет дважды в день по часу считать проходящих мимо людей. Или вам нужно знать, сколько раз менеджер по продажам не дозвонился до клиента. А ваша система отображает только сам факт звонка, но не его результат. Тогда следует попросить менеджеров заполнять показатели вручную. Скорее всего, сотрудники ответят, что это долго и отнимает время, которое можно потратить непосредственно на звонки. Не слушайте. Сбор нужных показателей, пусть даже ручной и дорогой, в итоге принесет больше, чем затраченные ресурсы. При этом показатели, собранные вручную, всегда будут хуже по качеству. Значит ли это, что их не нужно собирать? Нет. Если метрики, полученные любым способом, помогают принимать управленческие решения, их обязательно нужно собирать.
Например, в Atlas Software мы придаем большое значение службе поддержке. Ее качество значительно влияет на потребительскую ценность нашего продукта. Поэтому наша цель — увеличить скорость и качество обработки обращений и уменьшить количество багов. Для этого мы смоделировали процесс работы с багами и сразу установили несколько показателей. Я, как руководитель, вижу, во-первых, общее количество обращений, во-вторых, сколько пришло обращений по каждой категории, и в-третьих, сколько из обращений по багам реально связаны с ошибкой. Порой пользователи неверно оценивают ситуацию, говоря о баге, хотя на самом деле просто не до конца знают функционал системы.
В-четвертых, я знаю скорость реагирования службы поддержки на новое обращение с момента получения заявки до начала ее обработки. В-пятых, я знаю средний срок работы с багом. По плану все баги должны быть закрыты в течение дня, срочные — в течение нескольких часов.
Первоначально распределением багов по разработчикам занимался сотрудник из смежного отдела. Это была его дополнительная работа. Но с ростом и развитием компании выросло и число обращений — показатели ухудшились. План не соответствовал реальности, хотя субъективно мне казалось, что все в порядке. Статистика говорила об обратном, поэтому был выделен отдельный специально обученный сотрудник, который занимался исключительно распределением обращений. Это позволило нам вернуться к плановым показателям.
Другой пример связан с отделом маркетинга и продаж. Это must have всех компаний. Мы установили цели и план по показателям, в том числе по охвату и количеству лидов, и запустили рекламную кампанию. Но после первой итерации процесса стало понятно, что показатель по охвату мы выполняем легко, а по лидам — с трудом. Соответственно, качество лидов низкое, поэтому все следующие за этим показатели мы также не выполняем. Мы поменяли способ лидогенерации и стали наблюдать, как изменится ситуация. Показатели по охвату остались прежними, но количество лидов и их качество выросло. По такому же принципу строится управление всей компанией в целом и каждого отдела, каждого процесса в отдельности.