Kpi

Любите ли вы KPI? Полагаю, скорее всего, нет. Трудно найти человека, который не пострадал от KPI в том или ином виде: кто-то не дотягивал до целевых показателей, кто-то столкнулся с субъективной оценкой, а кто-то поработал, уволился, но так и не смог узнать, из чего состояли те самые KPI, которые в компании даже упомянуть боялись. И вроде бы хорошее дело: в показателе тебе транслируют цель компании, ты делаешь всё для её достижения, в конце месяца получаешь премию или другой бонус. Прозрачная игра, честные ставки. Но нет, KPI превратились в страшного и неудобного монстра, который то и дело норовит подстегнуть нерадивых, но при этом ничего не даёт исполнительным сотрудникам. Что-то с этими показателями не так!

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

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

KPI нужны. Точка

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

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

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

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

• KPI объединяют и дают небольшой эффект соревновательности внутри компании. Хорошая конкуренция в команде двигает бизнес к прибыли.

• Благодаря KPI виден прогресс каждого отдельного сотрудника, сглаживается напряжённость внутри коллектива, оценка работы каждого приобретает очевидную, доказательную форму.

Конечно, это всё актуально только в том случае, если выбранные KPI отвечают ряду требований.

Где она, грань нормальности KPI?

Хоть эта статья и является частным мнением, всё же отмечу причины такой глубокой заинтересованности в теме KPI. Дело в том, что в релизе RegionSoft CRM 7.0 появился крутой проапгрейженный модуль расчёта KPI: теперь в CRM-системе можно создавать показатели любой сложности с любыми оценками и весами. Это удобно и логично: в CRM фиксируются все действия и достижения (показатели) по каждому сотруднику компании, а уже на их основе производится расчёт значений KPI. Мы уже писали две большие статьи на эту тему, они были академичными и серьёзными. Эта статья будет злой, потому что компании относятся к KPI как к прянику, к кнуту, к отчёту, к формальности и т.д. А это, между тем, инструмент управления и классная штука измерения результата. Но почему-то всем гораздо приятнее сделать из KPI оружие массового поражения мотивации и подавления духа сотрудников.

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

Это не должен быть случайный набор показателей

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

а) KPI были созависимы, то есть на выполнение индивидуальных KPI одного сотрудника влияла бы работа других сотрудников (классика 1: маркетолог приводит лиды, а его KPI объём продаж, если отдел продаж недорабатывает, страдает маркетинг, который не может никак повлиять на коллег; классика 2: KPI тестировщика включают скорость исправления бага, на которую он тоже практически не может влиять);

б) KPI слепо тиражировались на всех сотрудников (а давайте сделаем выполнение плана продаж KPI для всей компании-разработчика вот так нельзя, а вот сделать коэффициент достижения общей цели поводом к премированию вполне можно);

в) KPI влияли на качество работы, то есть количественное измерение было бы в ущерб качественной оценке.

Это не должна быть матрица с субъективными оценками

В памяти сразу всплыли матрицы KPI с моей первой работы торжество бессмысленности и субъективности, где сотрудников топили в прямом смысле слова двойками за поведение (ставили -2 за поведение в компании и снижали премию сразу на 70%) . Да, KPI бывают разные: они мотивируют или пугают, исполняются или фиктивно накручиваются, делают бизнес недосягаемо классным или окончательно топят компанию. А проблема-то, она не в KPI, а по-прежнему в головах тех людей, которые ими занимаются. Субъективные KPI это те, которые имеют привязку к оценочным характеристикам, таким как: готовность помочь коллегам, следование корпоративной этике, принятие корпоративной культуры, ориентированность на результат, позитивное мышление. Эти оценки сильный инструмент в руках оценивающих, в том числе hr-отдела. Увы, нередко наличие таких KPI превращает всю систему в орудие корпоративных разборок, метод приближения нужных и отдаления сотрудников, которые невыгодны (не всегда это плохие сотрудники).

В связи с наличием субъективных оценок в KPI (как правило, это балльная система или +- шкалы) возможно только одно решение: их не должно быть ни в каком виде. Хотите поощрять личностные качества внедрить геймификацию на корпоративном портале, внутреннюю валюту, наклейки, фантики, да хоть пуговицы раздавайте. KPI это о целях бизнеса и о работе. Не допускайте формирования в компании коллектива с чётко разграниченными кланами, которые будут больше бороться, чем вести вашу компанию к поставленным целям.

Малый бизнес нуждается в KPI. Любой бизнес нуждается в KPI

Скажу честно: я не часто видела KPI в малом бизнесе, обычно внедрение системы показателей эффективности начинается со среднего бизнеса. В малом бизнесе чаще всего есть план продаж и всё. Это очень плохо, потому что компания упускает из вида показатели работы и факторы, на них влияющие. Хорошая связка для малого бизнеса: CRM-система + KPI, так как данные будут собираться на основе заводимых клиентов, сделок и событий и коэффициенты будут также вычисляться в автоматическом режиме. Это сделает компактными не только рутинные процессы, но и сэкономит время на заполнении различной отчётности. Если хотите узнать, как сделать эту связку недорогой, удобной и работающей, оставляйте контакты в таблице (bonus inside) с вами свяжутся.

KPI тесно связаны с бизнес-процессами

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

Оптимальный путь: пересмотреть бизнес-процессы (именно пересмотреть, потому что на самом деле они есть у всех, но в разных состояниях) установить CRM-систему, в которой начать сбор всех показателей оперативной работы в CRM же автоматизировать бизнес-процессы внедрить KPI (лучше тоже в CRM, чтобы показатели считались автоматически, а сотрудники могли видеть свой прогресс и понимать, из чего состоит их система KPI) считать KPI и заработную плату в автоматическом режиме.

Кстати, мы все эти шаги реализовали в своей RegionSoft CRM. Посмотрите, как у нас делаются простые и сложные (продвинутые) KPI. Я, конечно, знаю функциональность не всех CRM мира, а каких-то жалких 15-20 систем, но могу смело утверждать: механизм уникальный. Ладно, хватит хвастаться, обсуждаем тему дальше.

Можно отлично работать и не выполнить ни одного KPI

В основном, это бич сотрудников-перфекционистов, которые доводят свои задачи до совершенства и тратят на это уйму времени. Но такая же история свойственна практически всем: можно отлично обслужить двух клиентов, которые принесут по 2,5 млн. рублей, но при этом не уложиться ни в один норматив по времени обслуживания. Кстати, именно благодаря таким KPI мы все часто получаем негодный сервис у рекламных площадок, рекламных агентств, операторов связи и прочих компаний на потоке: у них есть показатели, которые определяют премию, и им выгоднее закрыть таск, чем докопаться до решения проблемы. И это очень серьёзная цепочка ошибок, потому что KPI вышестоящих менеджеров привязаны к KPI нижестоящих и никто не хочет прислушиваться к просьбе скорректировать систему показателей. А зря. Если вы из таких, инициируйте пересмотр, потому что рано или поздно погоня за премией и коэффициентами выльется в вал жалоб клиентов (на который, конечно, есть свой KPI) и всё будет гораздо неприятнее и сложнее исправить.

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

KPI это подведение итогов периода, а не тотальный контроль

KPI это вообще никогда не контроль. Если ваши сотрудники заполняют ежедневные/еженедельные таблички, где указывают сколько времени заняла какая задача, то это не KPI. Если ваши сотрудники оценивают друг друга по шкале от -2 до +2, это не KPI. Кстати, это ещё и не контроль, потому что все задачи и их время пишутся от балды, абы 8 часов размазать, а оценки коллегам даются примерно так: о, Вася и Гоша пиво со мной пили, юморные пацаны, по +2 им, терпила Маша сделала за меня 4 большие задачи, но такая кривая физиономия у неё была, так и быть, 0 поставлю, смилуюсь, не -2.

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

KPI не должны мучать сотрудников

Часто бывает так: в конце месяца сотрудникам рассылаются большие файлы Excel с 4-5 вкладками, где они должны прописать свои KPI и заполнить определённые поля. Особый вид пыток:

• прописать каждую свою задачу и дать ей балльную оценку (чисто психологически наглые бездельники выигрывают у самокритичных скромников);

• оценить коллег;

• оценить корпоративный дух компании;

• рассчитать свой коэффициент и в случае, если он сильно выше или ниже среднего за предыдущие периоды, в комментарии к ячейке со значением написать объяснительную, почему так произошло (причём Я хорошо работал, потому что фарт пошёл не катит) и план по устранению проблемы в дальнейшем (Больше хорошо работать не буду).

Надеюсь, сейчас никто этот реальный опыт не воспримет как руководство к действию.

Так вот, KPI должны быть видимыми, доступными и прозрачными для сотрудников, но работники не должны врать, заполняя таблички, вспоминать свои задачи и восстанавливать выполненные объёмы по документам и договорам, самостоятельно рассчитывать свои показатели и т.д. 2020 год время, достойное автоматического расчёта KPI. Без автоматизации система ключевых показателей эффективности может оказаться не просто недостоверной, но даже вредоносной, потому что на основе выдуманных цифр и баллов будут приниматься ошибочные реальные решения.

KPI это не вся система мотивации, а её часть

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

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

KPI должен быть обоснован, цифры с потолка приведут к конфликтам

Если вы знаете, что ваши сотрудники в среднем в месяц выпускают два обновления, фиксят 500 багов и продают 200-м клиентам, то план на 6 релизов и 370 клиентов будет нереальным это слишком большое расширение доли рынка и слишком большая нагрузка на разработку (багов-то тоже примерно втрое больше станет). Точно также нельзя ставить высокий план по выручке, если в стране глубокая стагнация, а ваша отрасль в числе самых стагнирующих. Глубокое невыполнение плана демотивирует сотрудников, заставит их усомниться и в себе, и в эффективности вашего управления.

Поэтому KPI должны:

• точно соответствовать целям бизнеса;

• включать в формулу расчёта только реально существующие и снимаемые в компании метрики;

• не содержать субъективных оценок и характеристик;

• отражать вектор поощрения, а не наказания;

• коррелировать с реальными значениями показателей за несколько периодов;

• расти медленно;

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

Если сотрудники возмущены KPI и обоснованно отрицают возможность выполнения некоторых показателей, к ним стоит прислушаться: часто на местах некоторые аспекты достижения плана гораздо заметнее, чем в руководительском кресле (но касается это, в основном, среднего и крупного бизнеса).

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

Не существует готовых шаблонов для KPI

В интернете и у консультантов можно найти предложения о продаже сетов готовых KPI. В 90% случаев это те самые файлы Excel, о которых я говорила выше, но представляют собой они по сути план-фактный анализ для любой компании. В них не будет тех показателей, которые соответствуют вашим целям и задачам. Такие файлики просто лид-магниты, чтобы вы обратились к консультанту за разработкой системы KPI. Поэтому очень не рекомендую вам брать чужие шаблоны и использовать их для расчёт ключевых показателей эффективности для ваших сотрудников. В конце концов, на то они и ключевые, а не единые и не универсальные.

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

Показателей KPI не должно быть много

Оптимально от 3 до 10. Большое количество KPI рассеивает фокус сотрудников на целях и снижает эффективность работы. Особенно неэффективны малозначительные, рутинные KPI, привязанные не к макропроцессам, а к количеству листов договоров, строчкам текстов, количеству знаков и т.д. (данный тезис можно проиллюстрировать понятием Индусский код или Glitch, когда в Индии в середине 80-х было принято платить программистам за количество строк написанного кода. Это приводило к тому, что страдало качество кода, он становился лапшеобразным, объектно неориентированным, с большим количеством багов).

Часть показателей KPI должны относиться к индивидуальной работе сотрудника или подразделения, а часть должны быть интегральными, общими для всей компании (например, количество обнаруженных багов индивидуальный показатель, а выручка достижение всех подразделений в целом). Таким образом сотрудникам транслируются правильные цели компании, и они осознают, что внутри компании установлен паритет между индивидуальной и командной работой.

Да, реально есть профессии, где KPI применить сложно, либо вовсе невозможно

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

Чтобы понять реальные последствия введения KPI для таких специальностей, посмотрите на состояние поликлинической помощи в нашей стране (да и не только в нашей). С тех пор, как у врачей появились нормативы по времени осмотра пациента, заполнению документации и прочие ценные указания по поведению с пациентами, государственные поликлиники превратились в филиал ада. В этом плане гораздо грамотнее оказались частные клиники, которые выставляют KPI, но при этом выделяют время на пациента с запасом, то есть прежде всего работают на лояльность и даже любовь пациента к клинике и конкретным врачам. А с таким раскладом план по выручке и посещениям выполнится сам собой.

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

К сожалению, KPI не единственная сущность, которую умудрились в бизнес-среде демонизировать и превратить в орудие устрашения. Это неправильно, поскольку KPI, как и CRM, и ERP, и диаграмма Гантта всего лишь удобный инструмент управления и диалога сотрудников и их руководителей. KPI классно работают, если они толковые. Поэтому всё в ваших руках. Лично я для малого и среднего бизнеса вижу идеальную связку CRM, автоматизации продаж и автоматизированного KPI. Сейчас, в условиях ковидно-экономической неопределённости, эта связка способна буквально перенастроить команду и перезапустить бизнес. А что бы и нет?

Если вы задавались вопросами производительности труда операторов и управления средним временем обработки контакта (Average Handling Time, AHT), то материал, который вы сейчас читаете, точно для вас.

Сразу оговоримся, что эта статья не является полноценным исследованием и не охватывает все причины, которые могут повлиять на скорость обработки звонков (например, за рамками остался любимый вопрос автора о Speech Transmission Index (STI), индексе отвлекающих факторов в операторском зале). Она фиксирует зависимости, знание которых поможет вам выжать еще несколько килограммов эффективности при планировании ресурсов КЦ.

Мы выдвинули 2 гипотезы относительно среднего времени AHT:

• 1. При условно-постоянной нагрузке на операторов AHT должно увеличиваться в течение смены из-за накапливающейся усталости сотрудников.

• 2. Если подключать операторам несколько проектов (линии с разными тематиками), AHT тоже будет расти из-за того, что переключения между задачами требуют дополнительных усилий, а значит дополнительного отдыха. Возможно, по сравнению с ситуацией, когда операторы обслуживают монопроекты, разговоры затянутся за счет условно-незаметных пауз и меньшей скорости их работы в инфосистеме КЦ.

Чтобы проверить гипотезы, мы решили провести натурный эксперимент. Главной сложностью было найти контакт-центр с относительно стабильными параметрами:

• Операторский состав не меняется

• Маркетинговых активностей нет

• Изменения в сценарии разговоров и интерфейсы автоматизированного рабочего места оператора не вносятся

• Нагрузка на контакт-центр (Workload) в пределах запланированной

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

Условия для для проверки гипотезы 1:

Проверка длилась 3 рабочих дня. Мы отобрали 13 операторов с минимальным разбросом AHT по конкретной темтике и подключили им единственный проект. На время эксперимента мы попросили операторов минимизировать время перерывов или постараться перенести их на конец дня (ни один сотрудник не пострадал, неудобства всем компенсировали). Если в течение смены требовались дополнительные операторы для обслуживания пиковой нагрузки, то они приходили на работу в нужное время (то есть были свеженькими). А после того, как необходимость в них отпадала, переводились на другие проекты и не возвращались обратно.

Количество поступивших к операторам звонков (по науке называется Volume):

Мы построили график AHT (черная линия) и время обработки по каждму оператору (тонкие синие кривые). 19 мая картина получилась такой:

Не важно, когда начинается смена, AHT растет примерно одинаково. Красные графики время обработки контакта операторами, которые начинали работу позже 8 утра:

На всякий случай мы посмотрели как выглядит динамика коэффициента загрузки операторов Occupancy:

В оставшиеся два дня эксперимента 20 и 21 мая ситуация практически не менялась. Итоги:

1. Гипотеза о том, что AHT растет в течение смены, подтвердилась. Распространять этот вывод на все проекты в любых контакт-центрах неверно, при этом на него можно опираться в дальнейших исследованиях.

2. Прирост AHT может быть больше 15-16%, зависит от конкретных условий, типа и содержания проекта, а также от индивидуальных особенностей операторов. На самом деле, бывает и 40%+.

3. Динамику AHT в течение смены следует учитывать при планировании ресурсов. Если рассчитывать потребность в операторах по среднему, есть риск, что к концу смены персонала не хватит.

4. Вероятно, пока Occupancy не относительно высок (<=75%) загрузка операторов не влияет на производительность и труда.

5. Каждый оператор устает по-своему, с разной скоростью.

6. Если не все операторы подключаются к обслуживанию проекта сразу в начале смены, это влияет на AHT.

7. Интересно изучать динмику AHT по интервалам времени, когда в линии одинаковое количество людей:

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

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

В следующий вторник (26.05) после первого эксперимента мы замеряли время среднее время обработки контактов на двух проектах по отдельности. А еще через неделю (02.06) объединили группы и посмотрели, что получится. При этом на обоих проектах мы выставили целевой Service Level одинаковым 80% вызовов должны были быть приняты за 15 сек (на втором проекте цель изначально была чуть мягче 80\20).

Итоги:

1. Гипотеза 2 подтвердилась. AHT при объединении групп операторов в течение смены растет еще быстрее, чем в каждой группе по отдельности.

2. Партнерский контакт-центр не предоставил нам возможности провести исследование для подключения операторам более чем двух проектов. Это потребовало бы существенного перепланирования графиков работы операторов. Однако у нас есть основания предполагать, что чем больше проектов одновременно обслуживает один человек, тем быстрее растет уже не AHT, аскорость ростаAHT.

3. Эффект от объединения групп тоже нужно учитывать при планировании ресурсов.

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

Дмитрий Галкин, независимый консультант по вопросам создания и управления контакт-центрами Специально для Omniline.

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

Пусть контакт-центр обслуживает входящие звонки, которые поступают на номер 8-800. Руководитель отслеживает среднюю скорость ответа (Average Speed of Answer, ASA).

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

Если смотреть только на среднее, то можно не заметить рост длины очереди, понести необоснованные расходы на 8-800 и/или потерять часть клиентов, не готовых ждать долго. При этом значения ASA вполне могут оказаться в пределах целевого коридора, как в примере.

Кстати, в e-commerce, где время перезвона по клиентской заявке часто критично для конверсии, руководители контакт-центров не уделяют этому вниманияи не смотрят одновременно на ASA и суммарное время ожидания. А клиенты переключаются на конкурентные предложения и количество чеков за период становится меньше.

Есть разные способы отловить ситуацию. Вариант 1 рассмотрели:

Вариант 2, с помощью часто используемого индикатора Service Level. Я не очень люблю им пользоваться, но это вопрос личных предпочтений.

Мне больше нравится вариант 3, учитывающий хвост Service Level, т.н. SL Tail. Хотя показатель редкий и в стандартах его нет.

Удобство в том, что можно измерять одновременно несколько хвостов для разных предельно допустимых времен ожидания. Тогда можно на гистограмму распределения вызовов по Waiting Time не смотреть: несколько чисел сразу показывают, какие доли от общего объема контактов ждут больше 1,2,3.минут. Соответственно, место на мониторе освобождается от громоздкого графика. Выглядит он, кстати, примерно так:

Аналогично с FCR долей вопросов, решенных с первого раза и его двоюродной сестрой FLR (долей вопросов, решенных на первой линии). У FCR тоже есть хвост вопросы, потребовавшие больше чем N обращений. В целом, у значимых для бизнес-процессов индикаторов очень желательно измерять хвосты, это переводит управляемость контакт-центра как системы на новый уровень, а для руководителя делает ситуацию более прозрачной.

Еще момент. Математически правильно вместо среднего арифметического использовать медиану, если результат процесса не подчиняется нормальному (гауссову) распределению, иначе получится ситуация с олигархом, трактористом и огурцами. Медиана простыми словами это число, которое занимает среднее положение в отсортированном списке (на картинке ниже медиана в первом случае равна 76, а во втором 90):

Здесь при одинаковых средних медианы разные, доступность контакт-центра различается. Во втором случае половина вызовов ждала больше 90 секунд и это бы легко понять, не залезая в детализацию звонков. Единственная проблема в том, что одной медианы недостаточно, чтобы аналитик мог увидеть разброс данных, а это характеристика качества менеджмента. Да требовать от среднестатистического супервайзера разбираться в медианах и дисперсиях кажется не очень хорошей идеей. Хвосты легко воспринимаются и понимаются даже слабо подготовленным руководителем.

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

Дмитрий Галкин, независимый консультант по вопросам создания и управления контакт-центрами Специально для Omniline.

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

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

Идеальная метрика

Впервые я с этим столкнулся в самом начале своей карьеры. Тогда я работал сетевым инженером в региональном операторе связи, и в мои обязанности входила обработка метрик из системы мониторинга для подготовки KPI-отчета по техническому блоку. За основу брались данные о том, пингуется или нет узел связи (без привязки количества абонентов, которые от него зависят). Но в жизни качество предоставляемых провайдером услуг измеряется далеко не прохождением ICMP-пакетов от сервера мониторинга до коммутатора в подъезде, тем более, когда эти коммутаторы находятся в своем стерильном VLAN-е. Этого, наверное, не знали, но смогли прочувствовать на себе абоненты, особенно, нового в то время сервиса: IPTV через multicast. Зависающие картинки на телевизорах абонентов никак не коррелировали с прекрасной зеленой картинкой, подаваемой на стол руководства, и премиальным фондом. Результатом стала проваленная маркетинговая кампания по продвижению IPTV и немного пошатнувшаяся репутация. А дальше по цепочке: пересмотр KPI для инженеров с включением в него кучи новых метрик (в том числе и с бизнес уклоном), весовых коэффициентов, которые было просто невозможно рассчитать, и на которые было сложно повлиять. И вишенка на торте: восприятие сотрудниками KPI в качестве репрессивного инструмента сокращения зарплаты, и полная неэффективность его регуляторной функции. Я думаю, что у вас будет много подобных примеров из практики, особенно если коснуться такой острой темы как KPI и SLA. Вообще тема KPI, особенно в IT, заслуживает отдельного остросюжетного романа.

Я вспомнил описанную выше историю, когда практически одновременно несколько корпоративных заказчиков обратились с проблемой непрозрачного расчета SLA и KPI своих ИТ-подразделений. Стоит пояснить, что сейчас я работаю над продуктом зонтичного мониторинга для оперативного обнаружения и устранения сбоев в ИТ нашим продуктом пользуется ряд очень крупных клиентов из разных сфер: от госуправления и финтеха до СМИ и авиакомпаний.

Памятуя о своем неудачном опыте на первом месте работы, я не очень хотел ввязываться в KPI и SLA. Вначале я предложил решить эту проблему через настройку соответствующих Service Desk, тем более так рекомендует нам ITSM (Service Desk - единая точка входа и агрегации всей информации об услугах), а мой продукт будет лишь продолжать регистрировать инциденты и помогать с их дедупликацией за счет определения массовых сбоев и понимания: относится ли новый алерт к проблеме, находящейся на контроле у инженеров, или нет. Но коллегам хотелось не отчетности и репрессивного контроля, как я изначально ошибочно предположил, - им хотелось инструмента управления, который бы помогал и бизнесу, и инженерам находить некий общий язык и добавлял бы прозрачности в их отношения.

В итоге мы сошлись во мнении, что одним из выходов является создание единой синтетической (интегральной) метрики, понятной всем сторонам. По крайней мере, введение такой метрики позволит снизить цифровой шум и, что немаловажно, задаст нашей ИТ-службе некий ориентир для принятия правильных для бизнеса решений. А еще, совсем идеально, если эта метрика позволяла бы непредвзято оценивать, на какой области нашего ИТ-окружения нам следует сосредоточить внимание (здравствуй, бюджетное планирование и портфель проектов). Таким образом, эта идеальная синтетическая метрика должна удовлетворять следующим условиям:

1. Бизнес-ориентация. Метрика должна отражать работу нашего ИТ-окружения не с позиции работоспособности какого-либо сервера, а с позиции того, насколько это важно нашим клиентам;

2. Понятность. Метрику можно однозначно интерпретировать как техническим специалистам, так и бизнесу.

3. Декомпозируемость. По результатам можно провести анализ, разложить нашу единую синтетическую метрику на компоненты/факторы и выделить наиболее критический. В идеальном случае на выходе получить root cause анализ.

В итоге было предложено два варианта реализации: 1) метрика доступности сервиса/объекта (Service Availability); 2) карта здоровья (Health Map). Карта здоровья в итоге оказалась более сложной как в реализации, так и в аналитическом сопровождении, и была определена как перспективная целевая схема, и на время ее доработки был выбран более простой и привычный подход с оценкой доступности сервиса, о котором и пойдет дальше речь.

Доступность сервиса - это про бизнес, но и про ИТ

Итак, что же такое доступность сервиса? Я сформулировал для себя следующее определение: Доступность сервиса (англ. Service Availability)- это такое состояние нашего ИТ-окружения, когда наши клиенты могут и хотят получить услугу и остаться в целом удовлетворенными. Стоит также подчеркнуть, что здесь может быть только два состояния: либо условия выполняются, либо нет. Все полутона только смазывают картинку. Никакой деградации, никакой сниженной производительности - все это технические показатели, необходимые исключительно инженерам для оценки динамики состояния системы.

Приведу пример: потенциальный клиент хочет подать онлайн-заявку на оформление кредита в банке, но система работает со сбоями. Из-за высокого времени ожидания ответа сервера форма постоянно сбрасывается или на ней возникают ошибки, но минут за 30 заявку можно подать. Это приводит к тому, что конверсия в воронке продаж резко падает. С позиции классического инженерного мониторинга это серьезная деградация, но услуга доступна, а вот с позиции бизнеса это неприемлемое состояние системы, когда он теряет потенциальных клиентов. В данном примере доступность сервиса должна считаться равной 0. Приведу обратный пример: у вас, в силу каких-то непредвиденных обстоятельств, полностью выключается целый ЦОД и ваши системы переходят на резервный, при этом клиенты в штатном режиме, правда, чуть дольше, чем обычно, но регистрируют заявки на кредит, и конверсия не падает. А тут мы говорим, что сервис доступен полностью и мы, как инженеры, молодцы - обеспечили горячее резервирование. Хотя при этом половина наших серверов и каналов связи находятся в коме и не доступны. Таким образом, определение доступности сервиса целиком находится на стороне бизнеса, а мы должны лишь зафиксировать в каком соответствующем состоянии должно находится наше ИТ-окружение. Можно поддаться искушению сделать все просто и повесить, например, метрику конверсии как KPI для ИТ-департамента, забывая при этом, что ИТ не про конверсию, его нормальная работа - необходимое, но недостаточное условие для продвижения клиентов по воронке продаж. Поэтому использование бизнес-метрики в лоб приведет к непониманию и отторжению инженерного состава. К сожалению, этому искушению простоты очень часто поддаются руководители и в результате получают прямо противоположный эффект.

Особенности реализации

Необходимо сразу пояснить, что в нашей системе зонтичного мониторинга мы зачастую имеем дело не с метриками, а с уже конкретными событиями, алертами, возникшими в различных системах мониторинга. Эти алерты мы распределяем по конфигурационным единицам (сервисы, сервера, виртуальные машины, кластеры и т.д., далее - КЕ) в ресурсно-сервисной модели. Также, в зависимости от пришедших событий, мы изменяем статус синтетических триггеров (синтетические - потому что могут рассчитываться на основании алертов из разных систем мониторинга, далее СТ). По сути синтетический триггер - это аналог аварийной ситуации / бизнес-проблемы, у которой есть начало и конец.

В нашей системе мы позволяем рассчитывать доступность, как отдельной КЕ, так и совокупную доступность группы КЕ. Метрика доступности для группы КЕ - это и есть искомая верхнеуровневая метрика доступности конечного сервиса, потому что сервис зачастую оказывается целым комплексом информационных систем и, в целом, представляет цепочку более мелких сервисов (ЦОД отвечает за сервис предоставления виртуальных машин, Облако за сервис системных компонентов, Информационная систем за прикладные сервисы и так далее). А доступность отдельной КЕ - это оценка работоспособности того или иного объекта с позиции оказания конечного сервиса. Взаимоувязка позволяет в дальнейшем проводить факторный анализ и определять вклад каждого объекта в общий результат, таким образом, находить узкое горлышко.

При построении отчета необходимо прежде всего определить список аварийных ситуаций или их совокупности, которые свидетельствуют о нарушении работы сервиса. Определить также такие дополнительные параметры (при необходимости), как:

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

• Есть ли у нас RTO (recovery time objective) - максимально допустимое время, в течение которого наш объект может находиться в аварийном состоянии;

• Учитываем или нет согласованные сервисные окна.

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

Собственно методика

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

Для расчета доступности за период SA (Service Availability) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t), которая в каждый момент времени принимает одно из четырех значений:

• Значение (0) говорит о том, что в конкретный момент времени на КЕ не зафиксированы проблемы, отвечающие фильтру;

• Значение (1) - в конкретный момент времени на КЕ зафиксирована проблема (-ы), подпадающая под условия;

• Значение (N), что КЕ находится в необслуживаемом состоянии;

• Значение (S), что КЕ находится в согласованном сервисном режиме.

В результате мы получим следующие показатели:

• timeNonWorking - нерабочее время КЕ на исследуемом периоде. Значение функции равно "N";

• timeWorkingProblem - время нахождения КЕ в не удовлетворяющим SLA состоянии на исследуемом промежутке времени. Значение функции равно "1";

• timeWorkingService - время согласованного простоя, когда, в рабочее время, КЕ находилась в сервисном режиме. Значение функции равно "S";

• timeWorkingOK - время, в которое наша КЕ удовлетворяла SLA. Функция fProblem(t) находилась в состоянии "0".

Расчет доступности за период для одиночной КЕ SA (Service Availability) осуществляется по формуле:

SA =timeWorkingOK / (timeWorkingOK+timeWorkingProblem) * 100%

Для группового расчета доступности за период SAG (Service Availability Group) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t) для каждой КЕ, входящей в группу. Далее наложить получившиеся функции fProblem(t) по каждой КЕ друг на друга, исходя из определенных правил (см. Табл. 1)

ТАБЛИЦА 1.

В результате получаем функцию fGroupProblem(t). Суммируем длительность участков данной функции следующим образом:

• timeGroupService - время, когда fGroupProblem(t)= S;

• timeGroupOK - время, когда fGroupProblem(t) = 0;

• timeGroupProblem - время, когда fGroupProblem(t) = 1;

Таким образом, искомая метрика:

SAG = timeGroupOK / (timeGroupOK+timeGroupProblem) * 100%

Факторный анализ

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

Факторный анализ позволяет определить: какой фактор-проблема повлиял за отчетный период на расчет доступности и сравнить степень такого влияния с остальным факторами-проблемами.

Предположения методики:

• В методике определения доступности невозможно определить вес той или иной проблемы, если они произошли одновременно. Таким образом, единственным параметром будет длительность проблемы.

• В случае, если одновременно произошли две и более проблемы, то на такой период будем считать длительность каждой с коэффициентом 1/N, где N - количество одновременно произошедших проблем.

Методика расчета:

1. Необходимо взять функцию fProblem(t), построенную при расчете SA.

2. Для каждого участка, где итоговая функция fProblem(t) = 1, составить список проблем данной КЕ, на основании которых данному участку было присвоено значение. При составлении списка необходимо учитывать и проблемы, которые начинались или заканчивались за пределами участка функции.

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

4. При расчете следует учесть следующие моменты:

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

   2. Одна и та же проблема может присутствовать на разных участках fProblem(t) = 1. Например, проблема началась в пятницу, закончилась во вторник, а в выходные КЕ не обслуживается согласно SLA.

5. В итоге должен быть сформирован список проблем, которые участвовали в расчете функции fProblem(t). При этом у каждой проблемы должна быть посчитана метрика влияния на SA.

6. Необходимо обязательно верифицировать расчет. Сумма метрик влияния всех проблем должна равняться timeWorkingProblem.

7. Пользователю необходимо выводить относительное значение влияния в %. Для этого метрику влияния необходимо разделить на timeWorkingProblem и умножить на 100%.

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

В результате получаем вот такую картину (см. рис 4.)

Промежуточные итоги

Метрика доступности сервиса обладает всеми тремя необходимыми свойствами идеальной метрики: понятность, декомпозируемость и бизнес-ориентация. Благодаря данной метрике можно однозначно оценить работоспособность ИТ-окружения с позиции вашего бизнеса, а инженерному составу держать в фокусе самое важное - уровень сервиса, который он предоставляет. Но есть и ряд серьезных недостатков: все-таки предложенная методика расчета метрик доступности носит ретроспективный характер, и не позволяет строить прогнозов; нет оценки рисков, что не позволяет принимать оперативные решения при ликвидации аварий.

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

В любом случае, это не последняя наша попытка найти Святой Грааль - идеальную метрику и метод ее расчета, чтобы помочь нашим клиентам не превратить свое ИТ-окружение в тот самый арбуз. Следующая наша ставка на Карту здоровья. Надеюсь в дальнейшем продолжить делиться с вами полученными результатами.

Первое о чем стоит подумать при определении ключевых показателей (KPIs) - это для кого они предназначены.

Кто те заинтересованные лица, кому вы будете предоставлять отчеты? В описываемом случае мы хотели измерять последствия процесса улучшения, который планировался. Отчеты использовались менеджером процесса Управления изменениями (change manager), операционным менеджером (IT operations manager), офисом управления проектами и менеджерами процесса Управления уровнем обслуживанием (service level managers).

Мы поговорили с заинтересованными лицами, чтобы понять, что для них важно, и определили четыре критичных фактора успешности (critical success factors, CSFs) для процесса Управления изменениями (change management):

1. Защита бизнеса от негативного влияния последствий изменений

2. Поддержание скорости изменений, необходимой бизнесу

3. Предоставление знаний и информации о новых и изменяемых услугах, требуемых ИТ сотрудникам и бизнес персоналу

4. Рациональное использование ИТ ресурсов

Ваши факторы успешности (CSFs) могут значительно отличаться от озвученных, но вы должны быть готовы покащать их список вашим заинтересованным лицам. Еще один неплохой вариант, способный помочь найти ваши факторы успешности (CSFs), - примеры из книги ITIL Service Transition (но их тоже не стоит бездумно копировать).

Факторы успешности (CSFs) не могут быть точно измерены, но то, что более важно, они представляют собой фразы, с которыми согласны ваши стейкхолдеры, иони описывают результаты, ожидаемые от процесса Управления ИТ изменениями (change IT management).

Следующий шаг - определить не более 3 ключевых показателей результативности (KPIs), которые могут помочь понять достигнуты ли все критические факторы успешности (CSFs). Ключевые показатели (KPIs) однозначно не доказывают, что фактор успешности (CSF) достигнут, но помогают продемонстрировать, как хорошо выполнеятся то, что направлено на достижение фактора успешности (CSF). Вполне допустимо иметь один и тот же ключевой показатель (KPIs) в нескольких факторах успешности (CSFs), но важно, чтобы показателей не было много.

Пока мы обсуждали ключевые показатели (KPIs) для процесса Управления изменениями (change management) осознали, что необходимо улучшить качество данных об изменениях. Ранее каждое изменение помечалось, как успешное, и сотавалось таким до тех пор, пока его не возвращали на доработку, но это не давало нам информации достаточной для внедрения факторов успешности (CSFs). Мы решили оценивать каждое изменение на основе признаков:

• Было ли изменение полностью реализовано без необходимости возврата на доработку?

• Было ли изменение реализовано в заявленные при планировании время и ресурсы?

• Вызвало ли изменение инциденты?

• Обеспечило ли изменение результаты, на которые рассчитывал заказчик?

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

И теперь мы смогли определить ключевые показатели (KPIs), поддерживающие наши факторы успешности (CSFs)

CSF1 - Защита бизнеса от негативного влияния последствий изменений

• Уменьшать количество и долю изменений, которые вызывают инциденты

• Уменьшать общее влияние на бизнес от инцидентов, вызванных изменениями

CSF2 - Поддержание скорости изменений, необходимой бизнесу

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

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

• увеличение уровня удовлетворенности от процесса Управления изменениями (change management) у проектного офиса и конечных заказчиков

CSF3 - Предоставление знаний и информации о новых и изменяемых услугах, требуемых ИТ и бизнес персоналу

• увеличение доли изменений, по которым были предоставлены материалы в базе знаний для техподдержки (service desk)

• увеличение уровня удовлетворенности от процесса Управления изменениями (change management) у ИТ персонала и конечных заказчиков (я бы сюда поставил пользователей, но автору виднее)

CSF4 - Рациональное использование ИТ ресурсов

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

• уменьшение числа и доли срочных и аварийных изменений

В результате получили довольно небольшое количество ключевых показателей для измерения и отчетности, которые были сфокусированы на интересах и заботах заинтересованных лиц (stakeholders), а также способствовало пониманию нами результативности процесса улучшений, который мы планировали.

А когда вы последний раз пересматривали ключевые показатели (KPIs), используемые в процессе управления изменениями (change management)?
Почему бы не пересмотреть показатели и отчеты по ним, чтобы сделать их более полезными для вас и ваших стейкхолдеров?

Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов.

Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели.

Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете.

Первый шаг для определения качественных ключевых показателей (KPIs) - определить цели процесса Управления проблемами, которые его результаты должны помочь вам достигнуть. Для у правильного процесса Управления проблемами есть два ключевых результата:

• уменьшение количества возникающих инцидентов

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

Мы можем просто измерять количество инцидентов и их общее влияние на бизнес. Это точно будет полезно знать, но я не уверен, что они смогут показывать, как хорошо работает именно процесс Управления проблемами, т.к. слишком много факторов на него влияет. Я немного разбавлю их и предложу несколько критических факторов успешности (CSFs), которые могут поспособствовать получению результатов:

• определение проблем, которые являются причиной множественных инцидентов

• создавать среду, которая снижает влияние от инцидентов

• инициирование изменений, которые уменьшают количество инцидентов

Стоит сказать, почему я не упомянул поиск корневых причин проблем (root cause analysis, RCA). Я видел много людей в управлении проблемами, кто думал только о поиске корневых причинах, но это не давало им особого результата, потому что RCA - это не более чем одна из техник, используемых в Управлении проблемами. Худшие ключевые показатели, которые можно придумать, - это среднее время обнаружения корневой причины, доля проблем, у которых ключевая причина была выявлена не хуже 3 дней и т.п. Использование таких показателей провоцирует участников Управления проблемами на поведение, которое мне бы не хотелось получить. Это равносильно заявлению, что в сложной многофакторной ситуации нужно искать единственную корневую причину. Для меня более правильный способ - это проведение постоянного анализа, даже если в его результате удастся идентифицировать только одну значимую причину.

Одни из моих заказчиков имеет процесс приоритезации проблем, который определяется частотой и влиянием на бизнес проблемы, включая смягчение последствий производимое рабочим окружением. Они также используют показатель среднее время уменьшение влияние проблемы до 3-го приоритета. Это уменьшение может быть достигнуто за счет решения проблемы или внедрением правильного рабочего окружения. Этим показателем они измеряют как Управления проблемами уменьшает боль бизнеса. Я не буду советовать всем это ключевой показатель, потому что для его использования требуется применять довольно сложный подход к приоритезации проблем, который не все компании смогут реализовать, но если у вас получится измерять, тоопределенно можете задуматься о таком показателе.

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

CSF1 - определение проблем, которые являются причиной множественных инцидентов

• увеличение доли инцидентов ассоциированных с записями о проблемах или известными ошибками

• отчет о топ 5 проблем создается каждый месяц

CSF2 - создавать среду, которая снижает влияние от инцидентов

• увеличение доли инцидентов, для которых в базе знаний есть статьи с решениями

• увеличение доли инцидентов решенных пользователями с использованием инструментов самостоятельного решения

• уменьшение влияния инцидентов, ассоциированных с топ 5 проблем прошлого месяца

CSF3 - инициирование изменений, которые уменьшают количество инцидентов

• уменьшение количества инцидентов, ассоциированных с топ 5 проблем прошлого месяца

• уменьшение беклога незавершенных проблем

Я сформулировал эти ключевые показатели, как Увеличение или Уменьшение, так как я не хватает необходимыми данными для установки точных целей. Вы можете использовать метрики похожие на эти, но подставить в них оцифрованные цели, с точкой отсчета, которую вы определите после первых измерений и их анализа.

На сколько метрики, измеряемые в вашем процессе Управления проблемами, соответствуют потребностям ваших заказчиков?
Когда вы пересматривали в вашем процессе Управления проблемами ключевые показатели (KPIs) и связанные с ними факторы достижения успешности (CSFs) и цели?

PS Если тема интересна, можно познакомиться со статьями Стюарта Рейнса:

Как определять метрики для процесса Управления (перевод, оригинал)

Осторожно. Как использовать метрики процессов без вреда для здоровья процессов (перевод, оригинал)

Я уже писал о там, как можно опеределить метрики (metrics) и ключевые показатели (KPIs) для некоторых процессов управления ИТ услугами (IT service management). В статье Как определить метрики для процесса Управления изменениями (перевод, оригинал) я рассуждал о важности идентификации заинтересованных лиц и определения факторов достижения успеха (CSFs), и дальнейшего использования этого при поиске ключевых показателей (KPIs) для измерений и отчетности. В статье Как определить метрики для процесса Управления проблемами (перевод, оригинал) продолжил тему и показал, как ключевые показатели (KPIs), предлагаемые в лучших практиках (например, ITIL), могут не подходить под реальные ситуации.

В ITIL (книга ITIL Practitioner)предлагается любопытная методика определения метрик в виде последовательного декомпозита Факторов достижения успеха процесса (CSFs) - Ключевые показатели процесса (KPIs) - Метрики (Metrics). Если очень кратко, то

• CSFs - это качественное описание результатов успешной работы процесса

• KPIs - количественное описание результатов успешной работы процесса

• метрики - что именно измеряем для расчета KPIs

В ответ на эти статьи я получил несколько запросов продолжить цикл и особенно часто встречался запрос на описание метрики для процесса Управления инцидентами (Incident Management). Ниже, что я думаю о том, как можно определять метрики для Управления инцидентами (Incident Management).

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

• Мы решаем инциденты со скоростью, чтобы их последствия не влияли значительно на наших заказчиков

• Мы решаем инциденты в порядке соответствующем их влиянию и заявленной срочности

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

• Заказчики и пользователи удовлетворены тем, как мы устраняем их инциденты

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

• Мы рационально используем наши ресурсы в процессе Управления инцидентами (Incident Management)

В идеале наши ключевые показатели должны помогать понимать достигнуты ли эти цели и показывают тренды, для определения, что требуется улучшить. Теперь давайте подумаем о том, что можно для этого измерять. Пожалуйста, не забывайте, что это все только пример, показывающий как можно думать об Управлении инцидентами (Incident Management).

Часть ключевых показателей (KPIs) могут идеально подойти одним компаниям и совершенно не подойти другим. Например, некоторые измеряют решение при первом контакте (First Call Resolution, FCR), т.е. какая доля обращений была решена в течение звонка на техподдержку (service desk) с обращением о наличии инцидента. Для многих компаний это отличный способ измерения того, что они быстро решают инциденты и рационально используют ресурсы, но если вы развиваете инструменты самообслуживания, то можете обнаружить, что показатель решения при первом контакте ухудшается, при том что качество услуг повысилось.

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

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

• Мы решаем инциденты так быстро, чтобы их последствия значительно не влияли на наших заказчиков

  • процент инцидентов 1-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

  • процент инцидентов 2-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

  • процент инцидентов 3-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

• Мы решаем инциденты в порядке соответствующем их влиянию и заявленной срочности

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

  • количество жалоб заказчиков или обращений для поднятия приоритета инцидента

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

  • процент инцидентов, в которых заказчик запрашивал информацию о состоянии решения инцидента

• Заказчики и пользователя удовлеитворены тем, как мы устраняем их инциденты

  • процент пользователей давших оценку 4 или 5 в опросе удовлетворенности решением инцидента

  • изменения удовлетворенности заказчиков работой процесса Управления инцидентами (Incident Management) по итогам ежегодных опросов

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

  • число проблем зафиксированных техподдержкой (service desk)

  • число проблем зафиксированных аналитиком инцидентов

• Мы рационально используем наши ресурсы в процессе Управления инцидентами (Incident Management)

  • процент инцидентов зарегистрированных на портале самообслуживания

  • процент инцидентов решенных на портале самообслуживания

  • средняя цена решения инцидентов (в разрезе приоритетов)

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

После прочтения ответьте для себя на пару вопросов:

• На чем основаны ваши текущие ключевые показатели (KPIs) процесса Управления инцидентами (Incident Management)?

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

• Почему бы на пересмотреть их и не начать измерять и оценивать то, что действительно важно для вас?

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

Я ранее написал несколько статей о метриках и ключевых показателях (KPIs) для некоторых процессов Управления ИТ услугами. Вот ссылки на них в случае, если хотите с ними ознакомиться.

• Как определить метрики для процесса Управления изменениями (перевод, оригинал)

• Как определить метрики для процесса Управления проблемами (перевод, оригинал)

• Как определить метрики для процесса Управления инцидентами (перевод, оригинал)

Очень круто иметь продуманные ключевые показатели (KPIs) индивидуально под конкретные ITSM процессы, но даже в этом случае можно получить огромный неудобный отчет, из которого не каждый сможет извлечь пользу.

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

Что такое сбалансированная система показателей?

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

• Финансы - метрики, позволяющие понять, как используются ресурсы вашей компании

• Клиенты - метрики, позволяющие понять, насколько удовлетворены потребности заказчиков и на сколько заказчики этим удовлетворены

• Внутренние бизнес процессы - метрики, позволяющие понять результативность и рациональность внутренних процессов и достигают ли они требуемых от них целей.

• Обучение и развитие - метрики, позволяющие понять, как вы готовы к будущему и позволит ли ваша процедура непрерывного улучшение оставаться вам конкурентоспособными

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

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

Например, можно в обобщающем ИТ-отчете встретить такие показатели:

• Финансы: процент расходования годового бюджета ИТ, возврат инвестиций в ИТ проектах.

• Клиенты: удовлетворенность ИТ-заказчиков, достижение целевых сервисных метрик сквозных процессов.

• Внутренние бизнес-процессы: количество ITSM процессов с достигнутыми целями, количество IT-проектов, по которым были достигнуты согласованные цели.

• Обучение и развитие: количество реализованных предложений об улучшении из регистра процесса непрерывного улучшения (CSI), среднегодовое время обучение IT-персонала.

Далее показатели могут быть разбиты для отдельных ITSM процессов или рабочих групп. Например, деятельность технической поддержки (service desk) можно измерить и оценить:

• Финансы: общегодовая затрат на работу техподдержки, средняя стоимость одного инцидента.

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

• Внутренние бизнес-процессы: количество проблем созданных техподдержкой.

• Обучение и развитие: число предложений на улучшение, поданных в реестр процесса непрерывного улучшения сотрудниками техподдержки и принятыми для реализации; число сотрудников техподдержки, которые потратили не менее 4 часов на обучение сотрудников бизнес подразделений.

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

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

На сколько текущие метрики ваших процессов управления ИТ-услугами покрывают все 4 проекции сбалансированной системы показателей?

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

Можете исключить из отчетов несколько существующих метрик и ключевых показателей, которые используются только для менеджерами процессов, чтобы исключить перегрузку отчетов для заказчиков услуг информацией о внутренней ИТ-жизни?

У меня есть серия заметок о метриках (metrics) и ключевых показателях результативности (Key Performance Indicators, KPIs), для оценки нескольких областей Управления ИТ-услугами (IT service management). И они были очень популярны, т.к. посвящены теме, в которой многие людей ищут подсказки. Вот эти заметки:

• Как определить метрики для процесса Управления изменениями (перевод, оригинал)

• Как определить метрики для процесса Управления проблемами (перевод, оригинал)

• Как определить метрики для процесса Управления инцидентами (перевод, оригинал)

• Сбалансированная система показателей для ключевых показателей IT (перевод, оригинал)

На одну из них я получил запрос: А как насчет техподдержки?. Ниже мои мысли о том как можно посчитать техподдержку.

Рекомендуемая картина мира при определении метрик и ключевых показателей

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

Также стоит помнить о пересмотре ключевых показателей, это позволит со временем менять показатели, которые хорошо работали, а потом потеряли релевантность. Не забывайте, что K в KPI означает ключевой, так что вам стоит сконцентрироваться на наиболее важных для вас моментах. Вам не стоит измерять и отчитываться обо всем, что вы сможете измерить.

Также нужно прояснять понимание целей и критичных факторов успешности (Critical Success Factors, CSFs), которые необходимо выполнить, чтобы обеспечить достижение целей. Каждый ключевой показатель должен поддерживать одну или более целей или критичных факторов. Отчеты и обсуждения с заказчиками стоит вести о целях и критичных факторах, их поддерживающих, а не о ключевых показателях. I в KPI означает индикатор. Показатели - это не доказательство достижения цели, а всего лишь индикатор, помогающий понимать тренды и проблемы.

Цели и критичные факторы для техподдержки

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

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

• Мы хорошо общаемся с нашими пользователями, поддерживаем их достаточным объемом информации и соответствуем их ожиданиям

• Мы решаем пользовательские инциденты быстро и эффективно

• Мы выполняем запросы на обслуживание быстро и эффективно

• Мы достигаем высокого уровня удовлетворенности заказчика

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

Я использовал термины цели или критичные факторы (objectives or CSFs) для обозначения высокоуровневых понятий. Мы провели бесконечное число обсуждений о разнице между двумя этими понятиями, но это не так уж и важно. Просто будьте уверены в том, что нашли то, о чем стоит заботиться. В идеале стоит остановиться на 3-6 целях или критичных факторах. Если будет больше, то отчеты будут слишком длинными и слишком размытыми.

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

  • все взаимодействия пользователи могут инициировать по телефону или через портал самообслуживания (Да/Нет)

  • процент телефонных звонков принятых в течение 30 секунд

  • процент непринятых телефонных звонков

  • результаты ответа на вопрос: Как проще всего связаться с IT, когда они нужны? в ежегодном опросе удовлетворенности заказчиков

• Мы хорошо общаемся с нашими пользователями, поддерживаем их достаточным объемом информации и соответствуем их ожиданиям

  • процент инцидентов, по которым пользователи запрашивали текущее состояние решения

  • процент инцидентов, возвращенных пользователем в работу после того, как техподдержка их закрыла

• Мы решаем пользовательские инциденты быстро и эффективно

  • процент инцидентов, решенных не хуже утвержденного уровня обслуживания (SLA)

  • процент инцидентов, решенных пользователями самостоятельно используя портал самообслуживания

  • процент инцидентов, решенных в течение первого контакта с пользователем.

• Мы выполняем запросы на обслуживание быстро и эффективно

  • процент запросов на обслуживание, выполненных не хуже утвержденного уровня обслуживания (SLA)

  • процент запросов на обслуживание, выполненных без ручных операций со стороны ИТ сотрудников

• Мы достигаем высокого уровня удовлетворенности заказчика

  • процент пользователей поставивших оценки 4 или 5 в опросе удовлетворенности результатом решения инцидента

  • увеличение удовлетворенности заказчиков работой техподдержки в ежегодном опросе удовлетворенности

Эти примеры ключевых показателей основаны на целях и критичных факторах для техподдержки. Их не стоит путать с более детальными ключевыми показателями, которые могут использоваться для измерения процесса Управления инцидентами (incident management process).Вам может также потребоваться несколько дополнительных внутренних ключевых показателей для измерения на сколько рационально техподдержка использует свои ресурсы, но это вряд ли будет интересно заказчикам (внутренним заказчикам это будет очень даже интересно).

Заключение

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

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

Привет, меня зовут Сергей и я отвечаю за техническую поддержку компании itsoft, так что, в этой статье речь пойдет именно про поддержку.

Поддержка это лицо компании для текущих клиентов. Однако, так ли часто мы сталкиваемся с хорошей поддержкой? Ответ, к сожалению, очевиден.

В данной статье я расскажу о нашем опыте и поделюсь рецептами, которые помогли стать поддержке нашего дата-центра лучше.

Что всех бесит в поддержке

Начать я решил со списка того, что меня и моих коллег (да и вас, скорее всего) бесит в поддержке:

• долгое ожидание;

• роботы;

• некомпетентность;

• ограниченное количество каналов для связи;

• письма с адреса no-reply@domain.ru;

• нельзя пожаловаться (отсутствие обратной связи).

Долгое ожидание

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

• Сейчас мы не можем ответить на звонок;

• Оператор сейчас ответит, пожалуйста, оставайтесь на линии;

• Сейчас все операторы заняты, вам ответит первый освободившийся оператор;

• Продолжать можно до бесконечности!

Мало того, что нам приходится тратить на это много времени, так еще и далеко не всегда понятно сколько придется ждать, может 5 минут, может 20.

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

Есть уникальное в своем роде решение Ричарда Брэнсона, владельца авиакомпании Virgin Atlantic, который вместо раздражающих и клишированных фраз записал на автоответчик следующее обращение:

Здравствуйте, меня зовут Ричард Брэнсон, я владелец авиакомпании Virgin Atlantic. Сейчас все операторы заняты. Это непорядок. Давайте поступим следующим образом: если через 18 секунд никто не ответит на ваш звонок, вы получите скидку 450 фунтов. Я начинаю обратный отсчет 18, 17, 16, 15

Однако, мы с хоть каким-то подобием данного подхода пока не встречались, к сожалению.

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

Роботы

Переходим ко второму нашему пункту, который нас бесит общение с роботами.

В своих попытках бороться с длительным ожиданием многие компании приходят к решению укомплектовать свою поддержку новыми сотрудниками:

• всевозможными чат-ботами, которые сегодня "умеют" практически все, даже пытаются учиться;

• автоматической системой распределения тикетов с ИИ и без него;

• роботом на телефоне и другими искусственными заменителями.

В редких ситуациях это действительно удобно и скорее всего эффективно, однако, чаще всего это очередная возможность серьезно взбесить своего клиента!

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

У нас даже есть забавная статистика, по которой около 5% обращений в наш онлайн-чат приходят с единственным вопросом: Это робот?. Однако, мы роботами не пользуемся и не планируем, так что, на все обращения отвечают живые сотрудники.

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

Некомпетентность

Следующий пункт, который нас бесит в поддержке некомпетентность сотрудников.

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

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

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

Такие причины как низкие зарплаты, а как следствие высокая текучка и низкая квалификация кадров, попавших туда по массовому отбору понятны, а вот что непонятно почему это устраивает большинство компаний?

Пример из жизни: когда-то давно, получив в банке свою первую пластиковую карточку я пытался привязать ее к счету в paypal, но была смешная по нынешним меркам проблема на карточке отсутствовал cvc-код. Забегая вперед скажу, что проблема заключалась в том, что карта не являлась дебетовой, это была visa electron, на которых наличие cvc-кода не предусмотрено. Решалась проблема просто нужно было завести другую карту, например, виртуальную. Однако, для выяснения этой информации мне пришлось раз 6 позвонить в поддержку банка и лишь на третий день на другом конце провода попался компетентный сотрудник, который за 2 минуты все объяснил. Само собой, новую карту я завел уже в другом банке.

Невнимательность

Отдельным пунктом, который мы решили выписать изолировать от некомпетентности будет невнимательность сотрудников поддержки, которая бесит не меньше!

Знакома ли вам ситуация, когда в процессе переписки с поддержкой вы задаете три вопроса, но получаете ответ только на один или два? Нам знакома! Стоит отметить, что даже педантично пронумерованные вопросы тоже могут потеряться. Комментарии тут излишни.

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

Ограниченное количество каналов для связи

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

Тут речь пойдет не о личных предпочтениях каждого, а о ситуациях, когда вам НУЖНО связаться с поддержкой, но из-за ограниченного количества каналов связи такой возможности не представляется.

Вот достаточный список:

• тикет-система, если клиенту так комфортнее и нужно отслеживать статус обращения;

• адрес электронной почты, если нет возможности авторизоваться в тикет-системе;

• номер телефона, на случай отсутствия доступа в интернет;

• возможность связаться через мессенджер или онлайн-чат, если нет возможности позвонить.

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

Не менее крутая ситуация возникает с большинством гос. учреждений, которые принципиально отказываются принимать заявления никак иначе, как на бумаге, которую вы должны привезти лично. ЭЦП? Не, не слышали!

Письма с адреса no-reply@domain.ru

Пожалуй, самый безобидный, но наиболее распространенный пункт, который нас тоже бесит.

В данной ситуации раздражает факт того, что мы не можем ответить на такое письмо. Точнее можем, но его никто не прочитает.

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

Нельзя пожаловаться

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

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

Типичный пример: в некоторых банках окна обслуживания оборудованы кнопками (чаще всего это красный и зеленый смайлик), которые позволяют оценить качество того самого обслуживания. Но что произойдет, если нажать на красный, поставить отрицательную оценку? Вероятнее всего ничего. Возможно, где-то в корпоративной системе будет зафиксирован минус в карму сотруднику, но это не точно (с). Что точно никто не побежит разбираться в причинах негативной оценки, так какой в этом смысл?!

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

На что влияет качество поддержки

Разобравшись со списком того, что нас бесит в поддержке пришло время подумать, а на что же это влияет?

Тут можно выделить 3 основных момента:

• отток клиентов;

• отсутствие лояльности;

• и как следствие, отсутствие продаж по "сарафанке".

Отток клиентов

Начнем с оттока клиентов, в чем нам поможет исследование ресурса pwc.com. В исследовании проводился анализ причин оттока клиентов, а лидерами рейтинга стали:

• плохое отношение сотрудников компании к клиентам;

• недружелюбное обслуживание клиентов;

• плохая репутация компании;

• некомпетентные сотрудники;

• низкая эффективность;

• недоступность товара (услуги).

Ничего не напоминает?

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

Отсутствие лояльности

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

Лояльность клиента подразумевает:

• адресное и продуктивно общение с отделом продаж;

• объективная, честная и своевременная обратная связь;

• готовность к изменениям, которые вы запланировали;

• помощь, в ряде ситуаций, причем как словом, так и делом;

• и конечно же, рекомендации!

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

Отсутствие продаж по сарафанке

Согласно индексу NPS, стать промоутером вашей компании могут только максимально лояльные клиенты, которые набирают 9-10 баллов, т.е. полностью довольны результатом вашего сотрудничества и качеством услуг. Будет ли доволен клиент, которого бесит ваша поддержка?! Конечно же нет.

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

Методы, которые сработали у нас

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

• запустили поддержку в Telegram;

• наладили систему премирования;

• внедрили систему оценок качества поддержки;

• перестали работать с некомпетентными и невнимательными сотрудниками.

Поддержка дата-центра в Telegram

Начнем с того, что мы первые, кто запустил возможность обращаться в поддержку дата-центра через Telegram. На данный момент около 20% обращений обрабатываются именно там. Процесс коммуникации простой и понятный всем, кто пользуется этим мессенджером.

Можно воспользоваться виджетом в правом нижнем углу на нашем сайте, либо найти чат в самом мессенджере (@itsoft_bot) и задать интересующий его вопрос.

Для интеграции с рабочей средой (у наc это Slack) использовали сервис telebot.im.

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

Система премирования

Еще один метод, который помогает нам удерживать планку это система премирования, которая завязана на ряд параметров KPI каждого сотрудника поддержки.

Многие параметры KPI связаны непосредственно со скоростью реакции сотрудника на поступившее обращение и качеством его работы, например:

• скорость реакции на поступившее обращение;

• время, которое потребовалось на его закрытие;

• количество пропущенных звонков;

• качество коммуникации с клиентом.

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

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

Если говорить о цифрах, то каждый сотрудник поддержки, который выдерживает уровень своих показателей KPI выше 95% на протяжении некоторого времени может поднять уровень своей зарплаты на 40% от базовой ставки, это не считая премии. Самые же эффективные сотрудники поддержки всегда могут рассчитывать на квартальную премию в размере 50% от уровня базовой зарплаты. Без кнута тут тоже не обходится, но об этом немного позже. Не жалейте денег на сотрудников, мотивация делает вещи!

Система оценок качества поддержки

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

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

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

Оценки можно ставить:

• в переписке по электронной почте;

• в тикет-системе;

• в чате Telegram.

Оценить можно как качество ответа, так и скорость реакции. Следовательно, все сотрудники понимают, что ответить быстро, но плохо - не подходит, хорошо, но долго тоже, придется искать золотую середину! А что самое главное, каждый сотрудник понимает, что в случае обоснованной (иногда клиенты ставят оценки случайно) негативной оценки ситуация будет разбираться и от ответственности уйти не получится.

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

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

Мы не работаем с некомпетентными и невнимательными сотрудниками

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

Звучит проще, чем кажется на самом деле. Но вот как это на самом деле:

• начинается все с длительного отбора и череды собеседований (благодаря премиальной системе и достойному уровню зарплаты мы можем позволить себе опытных специалистов);

• каждый сотрудник поддержки проходит испытательный срок длительностью три месяца;

• на испытательном сроке тратится много сил на закрытие пробелов как по части коммуникаций, так и по техническим моментам (для этого мы разработали подробную систему обучения и массу инструкций, регламентов и регулярно наполняем корпоративную wiki);

• по итогам испытательного срока обязательная аттестация;

• если испытательный срок не пройден - увольняем;

• для тех сотрудников, которые уже прошли испытательный срок действует вышеупомянутая система KPI и правила, которых мы придерживаемся (если показатели KPI продолжительное время ниже 90% - увольняем);

• если сотрудник систематически (чаще трех раз в квартал) нарушает регламент или прямые распоряжения руководства - увольняем.

Стоит отметить, что даже несмотря на строгость, текучка у нас практически отсутствует, но на это есть свои причины.

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

Риски перемен и как работать с персоналом

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

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

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

Однако, даже такой подход не может застраховать от ряда проблем, вот 3 основных:

• итальянская забастовка;

• увольнения;

• демотивация и нежелание работать.

К ним и перейдем.

Итальянская забастовка

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

Все прекрасно понимают, что такой формат взаимодействия невозможен.

Всегда находятся сотрудники, которые не хотят ничего менять в устоявшейся, родной, привычной схеме работы, им сложно самим принимать решения и ответственность в новых условиях. Они боятся навредить себе и/или компании, приговаривая дайте мне инструкции, и я буду их выполнять. Вот тут начинается самое интересное. Да, правила, инструкции и регламенты нужны и должны быть, но есть 3 момента:

• вы не закроете инструкциями 100% возможных ситуаций;

• ситуации, которые не закрыты инструкцией требуют, чтобы сотрудник думал самостоятельно;

• чем больше инструкций, тем меньше сотрудник думает самостоятельно.

Ситуация, на самом деле патовая, но мы стараемся ее избежать:

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

• в узких местах наша система оценки и мотивации гибкая, но не нарушает базовых принципов, цели и правила компании (например, если принято неверное решение, но оно имеет адекватно обоснование, мы дорабатываем систему, а не скидываем вину на сотрудника);

• мы не стесняемся объяснить сотрудникам цели компании, ее принципы, мотивацию руководителя и суть наших бизнес-процессов;

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

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

Увольнения

Да, у нас, как и у других случаются увольнения. Значит цели и ценности компании и сотрудника сейчас не совпадают.

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

• устраивает ли заработная плата? (иногда вопрос сводится к сумме, которую мы можем себе позволить, сохранив сотрудника);

• в каком направлении сотрудник решил двигаться? (может быть и нам нужен такой специалист, у нас несколько разных направлений);

• если это результат конфликта, то в чем он заключался? (может быть есть проблемы, о которых мы не знаем);

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

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

Демотивация, нежелание работать

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

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

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

Тут мы придерживаемся следующих принципов:

• система KPI прозрачна и понятна всем, причем, создавалась она не единолично, все участвовали в этом, имея возможность высказать опасения и предложить решение;

• параметры KPI реальны и достижимы, мы не пытались задрать планку на такую высоту, которую никто не возьмет, при этом, не стали опускать ее слишком низко;

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

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

Результаты

Как мы знаем, главное это результат, о котором далее и пойдет речь.

Чего мы добились благодаря нашим методам и работе с сотрудниками?

Вот краткий список:

• увеличилась скорость реакции поддержки;

• увеличилась скорость закрытия обращений;

• снизилось количество пропущенных звонков;

• увеличилось количество обращений на сотрудника;

• снизился отток клиентов.

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

Увеличилась скорость реакции поддержки

За последние три года мы смогли сократить время ожидания клиентов на 43%. Например, в рамках тикет-системы до середины 2017 года среднее время ответа поддержки составляло 8,6 минуты, на данный момент это 4,9 минуты.

Увеличилась скорость закрытия обращений

Если взять за шаблон такой тип обращения как Подключение IP-KVM, то за три года мы добились сокращения сроков на 76%! Стоит отметить, что и принцип закрытия обращений изменился. Мы не закрываем обращения без обратной связи от клиента (само собой, если это необходимо), а значит, мы добавили промежуточный этап, но все равно стали быстрее.

Снизилось количество пропущенных звонков

Пропущенным звонком мы считаем ситуацию, когда трубку не подняли за 5 гудков, так вот, таких ситуаций стало ниже. Му улучшили показатели с 9% три года назад до 3% на данный момент. 6% не такой уж и выдающийся показательно, но и звонков с тех пор стало больше примерно на 10%.

Увеличилось количество обращений на сотрудника

Многих вышеперечисленных показателей легко достигнуть, растеряв часть клиентской базы или увеличив штат поддержки, но в нашем случае клиентская база росла, а среднее количество обращений на сотрудника за три года увеличилось на 76%, а это значит, что мы стали не просто быстрее, мы стали эффективнее!

Снизился отток клиентов

Эффективность не имеет смысла, если клиенты все равно уходят, но и эту статистику мы смогли выправить.

Вот наши показатели оттока клиентов по годам:

• за 2017-й год средний отток составлял 2,8 %, для нас это много, и мы начали действовать;

• в 2018-м мы получили первые результаты, отток снизился и составил 1,6 %;

• в 2019-м показатель не сильно изменился и оставался на уровне 1,7 %;

• за текущий, 2020-й год средний отток составляет всего 1,1 %.

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

Появился отдел поддержки

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

С полным списком наших клиентов вы можете ознакомиться на нашем сайте.

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

Заключение

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