Идут стрельбы на полигоне.
Дали автоматы, патроны, показали куда стрелять.
Айтишник отстрелялся, подводят итоги.
Мишень айтишника чистая.
Командир: «Как так?»
Айтишник, проверяя автомат: «С моей стороны все пули вылетели.
Проблемы на вашей стороне».
Современный бизнес-фольклор
Каждый, кто когда-либо видел отчеты IT-подразделений о проделанной работе, наверняка обращал внимание на такой показатель, как «количество обработанных заявок». Этот KPI является предметом особой гордости айтишников и, как правило, в отчете красуется на отдельном слайде, а вслух произносится с придыханием. Давайте попробуем разобраться, о чем же на самом деле свидетельствует этот показатель и когда пора бить тревогу.
Итак, внушительное (как правило) количество обработанных заявок свидетельствует только об одном – где-то на вашем предприятии есть айтишники. И это, к сожалению, единственный вывод, который можно сделать из этого слайда. Вы спрашиваете почему? Давайте обратимся к теории IT-менеджмента, а точнее, к ее практическому воплощению – библиотеке ITIL. Тех, кто не закрыл эту статью сразу после слов «библиотека ITIL», спешу успокоить: я постараюсь минимизировать количество заумных определений и цитат из словаря терминов ITIL. Все максимально своими словами. И начну с примера из собственного опыта.
Я как-то заключил договор на предоставление услуг доступа в интернет с одним довольно известным московским провайдером. И все вроде бы ничего, вот только интернет периодически отваливался. Проблема каждый раз решалась звонком на горячую линию поддержки. Сказать по правде – происходило это довольно быстро. Но где-то после четвертого или пятого отключения интернета я сменил провайдера. Месяца через три мне позвонил представитель компании и поинтересовался причиной, по которой я перестал пользоваться их услугами. На мою реплику о неприемлемом качестве этих самых услуг он искренне удивился: «Ведь мы же очень оперативно устраняли все проблемы!». Согласитесь, довольно типичная история. Сервисные компании, оказывающие те или иные услуги, очень часто путают такие понятия, как «удовлетворенность поддержкой» и «удовлетворенность услугой».
Давайте посмотрим на эту проблему с точки зрения менеджмента (в частности IT-менеджмента). Ключевой компонент любого сервиса – это услуга. А ключевой показатель услуги – это уровень ее качества. Таким образом, можно сказать, что Соглашение об уровне услуги (SLA – Service Level Agreement), в котором прописаны измеримые параметры качества, является краеугольным камнем всего сервиса. Тут прошу обратить особое внимание на словосочетание – измеримые параметры качества. Измерить качество довольно сложно, оно по своей природе очень субъективно. А любые попытки формализовать качество, чем в общем-то и занимается SLA, совершенно не гарантируют достижение заданных параметров удовлетворенности (лояльности) пользователей. Таким образом, качество услуги это нечто большее, чем просто SLA. А в ситуации с моим провайдером, когда Service Level Agreement деградировал в Support Level Agreement, все выглядит еще более печально. То есть фактически управление услугой сведено к управлению обращениями пользователей.
Вывод: информация о количестве заявок, обработанных айтишниками, это не более чем информация о количестве «пуль», которые они выпустили в анекдоте, который сделан эпиграфом этой статьи. И если айтишники не имеют представления, каким образом эти заявки-пули повлияли на цель, пора бить… нет, не айтишника, тревогу.
Для начала необходимо выяснить, из чего складывается это общее количество заявок. Причины могут быть следующими (в скобках указан перевод на язык ITIL):
- Сбои (инциденты);
- Доработки (запросы на изменение);
- Прочие вопросы (запросы на обслуживание).
Айтишники в своих отчетах любят сваливать эти три компонента в одну кучу: так проще (особенно если нет нормальной системы учета заявок), да и общая цифра выглядит куда внушительнее. И это первое, с чем надо бороться, ибо тренды у этих составляющих могут быть разнонаправленными, и за их общей суммой можно не заметить тревожные сигналы.
Вернусь к моему примеру с провайдером. Очевидно, что отключения интернета классифицируются как сбои (или инциденты в терминах ITIL). Один и тот же сбой повторялся несколько раз, то есть, скорее всего, существовала какая-то проблема с оборудованием (в терминах ITIL, проблема – это причина одного или нескольких инцидентов). Но все мои заявки на эту тему не инициировали поиск этой проблемы. Причины этого могут быть разными, и в данном конкретном случае они достоверно известны только провайдеру. Но одно можно сказать точно: шанс проморгать проблему резко увеличится, если информацию о сбоях разбавить прочими вопросами, да еще и сверху «присыпать» заявками на доработки.
Это все в общем-то понятные и очевидные вещи. И оттого еще больше досадно, когда периодически сталкиваешься с плохо организованным с сервисом (не только айтишным).
Подвожу итог. Наука по организации сервиса весьма сложна, а сама организация довольно затратна. Но что можно сделать быстро просто и относительно дешево – неустанно следить за трендами количества сбоев, доработок и прочих вопросов. А для этого начните с дифференциации всех поступающих обращений от клиентов (либо от сотрудников, если сервис ориентирован на внутренних потребителей).
Следующий шаг – организуйте ретроспективный анализ количества поступающих заявок. Если в этом месяце количество запросов на изменение (доработок) оказалось больше, чем в прошлом, то неплохо было бы выяснить, с чем это связано. Возможно, как-то изменились внешние условия, законодательство, например, и теперь нужно дорабатывать сервис под новые требования. Это достаточно стандартная ситуация. Рост количества прочих вопросов тоже вполне объясним и допустим. В целом, за динамикой этих двух показателей (доработок и прочих вопросов) можно следить, так сказать факультативно.
А вот динамика количества инцидентов (сбоев) должна в фокусе нашего внимания. Если их число месяц к месяцу остается неизменным, то, скорее всего, работы по устранению причин сбоев просто не ведутся. Наверняка многие из вас сталкивались с ситуацией, когда проблему зависшего в очередной раз компьютера предлагают решить его перезагрузкой. Вот это как раз тот случай, когда систематически устраняют последствия сбоя, а не его причины. Устойчивый рост количества инцидентов – явление вообще за гранью допустимого. Если вы его не заметили в этом отчетном периоде, то уже в следующем вы заметите отток клиентов. А стоимость привлечения новых клиентов в купе с финансовыми потерями от тех кто ушел, обойдется вам в разы дороже, чем устранение причины сбоев.
За время написания этой статьи ни один айтишник не пострадал. Да и не в айтишниках, в общем-то, дело. Они тут просто как пример, наиболее мне близкий и знакомый. Но на их месте легко могут быть, например, работники автосервиса или труженики отельного бизнеса. Служба поддержки, безусловно, является важнейшим компонентом сервиса, а ее вклад в общее дело очень весом, но, к сожалению, легко нивелируется бесполезностью самой услуги.
Правильно автор отметил, не он предлагает, а ITIL. Анонс тут слегка ошибочен. Правда, в библиотеке ITIL смысл предлагаемого текста выглядит несколько по-другому. Поэтому отчасти автор и правда является автором :-)
Про ошибки умолчу: никто, видимо, корректуру не провел.
А по сути, вот несколько примеров, когда не соглашусь с автором. Не все, конечно.
1. «качество услуги это нечто большее, чем просто SLA» - не стоит сравнивать документ с термином, круглое с зеленым: разные это типы понятий, как мне кажется.
2. «такой показатель, как «количество обработанных заявок. Этот KPI является предметом особой гордости айтишников и, как правило, в отчете красуется на отдельном слайде, а вслух произносится с придыханием. ».
Этот показатель в науке управления используется не сам по себе, и не является KPI, а является базовым показателем, как раз для сравнения, выявления тенденций. Если кто-то считает такой показатель KPIем, то смело можно сказать, что этот кто-то ничего не понимает в управлении чем бы то ни было.
3. «Сервисные компании, оказывающие те или иные услуги, очень часто путают такие понятия, как «удовлетворенность поддержкой» и «удовлетворенность услугой».
Тут сравнивается процесс с результатом, хотя при определенном подходе к терминологической базе эти понятия могут совпадать по смыслу. А могут и отличаться, как посмотреть.
4. «А любые попытки формализовать качество, чем в общем-то и занимается SLA, совершенно не гарантируют достижение заданных параметров удовлетворенности (лояльности) пользователей.» Тут все очень интересно.
Во-первых, SLA – документ. Он ничем не занимается, он хранит все, что в него напишут те, кто должен этим заниматься. По науке управления (по ITIL) это – участники процесса, которые следят за судьбой документа под названием SLA. Т.е. процесса Service Level Management.
Во-вторых, не вижу связи между многими параметрами, как раз объективными и измеряемыми при помощи инструментария, и одним параметром, субъективным, под названием «удовлетворенность». Т.е., так называемые «жесткие» и «мягкие» критерии качества используются, опять-таки по ITIL (и не только) вместе, чтобы оценить уровень работы сервисного подразделения со всех сторон:
- насколько технически грамотно работает подразделение (при условии, что «жесткие» критерии качества определены и отслеживаются правильно),
- и насколько при этом сотрудники этого подразделения умеют грамотно общаться с потребителями.
В-третьих, я бы не сравнивала деятельность по «формализации» параметров с достижением этих параметров. Конечно «не гарантируют», поскольку опять круглое с зеленым. За этим стоит огромный пласт работ.
В заключение хочется посоветовать как автору, так и всем, кому хотелось бы постичь азы управления услугами: изучайте матчасть, господа. Но этого мало. Надо бы и практику применения матчасти понимать.Цитата - не в айтишниках, в общем-то, дело. Они тут просто как пример, наиболее мне близкий и знакомый. Но на их месте легко могут быть, например, работники автосервиса или труженики отельного бизнеса.
С чем могу только согласиться.
Цитата - А ключевой показатель услуги – это уровень ее качества.
И здесь голосую За.
Цитата - То есть фактически управление услугой сведено к управлению обращениями пользователей.
Что это за управление услугой? Есть управление компанией, подразделением.
Насколько я понял решение проблемы - Цитата - Но что можно сделать быстро просто и относительно дешево – неустанно следить за трендами количества сбоев, доработок и прочих вопросов. А для этого начните с дифференциации всех поступающих обращений от клиентов и далее по тексту.
В целом не спорю предложение полезное, но, как мне видится, много туману (еще его больше от коллеги, что дала коммент первой, сори - "кому хотелось бы постичь азы управления услугами: изучайте матчасть, господа" - нет никакой матчасти - есть спрос на туман под названием "особые услуги по улучшение сервиса" ).
Рискну его рассеять:
1. Качество продуктов (товаров, услуг) - это показатель практики управления. Добавлю - на заводе, где вроде бы делают "железяки" - осязаемые товары - также сплошные услуги - их оказывают, в частности, рабочие (внутренние услуги коллегам по работе).
2. Соответственно, нужно постоянно повышать уровень этой практики управления, получается это или нет - помогает понять наблюдение за качеством услуг (как предложено, например, в статье).
3. То есть, понятно, что нужен разбор управленческих ситуаций - сбоев. Но он должен происходить одновременно с освоением современного менеджмента. И тогда мероприятия (чтобы произошедшие сбои не повторялись) - будут не только опираться на здравый смысл, но и на растущий уровень управленческих знаний
4. Достаточно много (и крайне дорогие) предлагаются моими коллегами услуги по улучшению сервиса (услуг) - считаю это ошибкой (правда, кроме денег клиенты ничего не теряют, разве что рынок, если конкуренты на этом экономят). Это к автору статьи уже не относится, но относится к теме.
Приведу такое сравнение - обучение деловому английскому - лажа (тоже очень дорого и тоже много предлагается коллегами) - нужно просто изучить иностранный язык, а затем лексику того или иного раздела деловой сферы (их много).
Татьяна, спасибо за ваш комментарий. Ваша реакция на статью схожа с тем, как гуру реагируют на книжки, в названии которых есть фраза «для чайников». Целевая аудитория этого текста – не it менеджеры. It менеджеры (точнее сказать сколь-либо толковые it менеджеры) ничего нового тут не узнают. За «откровениями» им лучше идти на специализированные ресурсы.
Целевая аудитория моей статьи – начальники it менеджеров, которым регулярно сдаются отчеты о доблестно проделанной работе. Матчасть в виде ITIL или COBIT эти люди учить точно не будут, да оно им и не надо. А вот иметь хотя бы поверхностное представление о ITSM однозначно стоит.
И да, заголовок и анонс не моего авторства )