Своевременность обработки запросов пользователей

На первый взгляд, своевременность обработки запросов измерить несложно:

где R— количество своевременно обработанных запросов, а N— общее количество запросов, обработанных за некоторый период времени.

Однако за простотой этой формулы скрывается несколько любопытных особенностей.

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

запросам (знаменатель N), то если я откладываю обработку просрочен- ного запроса, я дважды выигрываю:

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

• и высвобождая время для обработки ещё не просроченных запросов.

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

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

Для решения данной проблемы формулу (5) можно модифицировать, точнее — уточнить определение операнда N. А именно, пусть N, поми- мо фактически решённых запросов, будет включать в себя запросы, срок обработки которых на момент окончания отчётного периода истёк, а они так и не были решены. Тогда «зависшие» запросы будут снижать значение метрики, и шансы, что на них обратят внимание, возрастут.

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

Для того чтобы учесть, насколько нарушен срок, определим показатель своевременности обработки Timely Processing Index следующим образом:

где Riрейтинг обработки i-того запроса, равный 1, если i-тый запрос обработан в срок и 0 в случае, если он просрочен. А вес Wiопределяется формулой:

В (7) ti— фактическое время обработки запроса (рассчитанное по календарю рабочего времени или, если возможно, по календарю, указанному в SLA, согласно которому обрабатываются данные запросы), Ti — максимальное время обработки15, n — натуральное число, которое является параметром алгоритма (обычно его принимают равным 1). Тогда чем сильнее просрочен i-тый запрос, тем больше его вес Wi, снижающий значение метрики (поскольку ti > Ti). Причём чем больше значение параметра n, тем быстрее возрастает Wi с увеличением срока обработки (заметим, что при n=0 определение TPI становится тождественным K1 — длительность обработки просроченных запросов перестаёт оказывать влияние на значение метрики).

Для наглядной демонстрации приведём значения метрики TPI на примере. Предположим за некоторый период мы обработали 20 запросов. Из них 19 — в срок (равный четырём рабочим часам), а один — просрочили. Рисунок 7 показывает, какое влияние на значение метрики TPI оказывает фактическое время решения просроченного запроса:

Рисунок 7. Влияние длительности просрочки на значение TPI

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

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

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

По большому счёту нам известно два способа — системный, но не очень реалистичный и быстрый, но немного «шарлатанский» (недостаточно обоснованный). Выбирайте, какой больше подходит вам — оба неидеальны. Системный способ заключается в стандартизации и нормировании операций, необходимых для обработки запросов (теоретически такое нормирование возможно и для решения инцидентов). Типовые запросы должны быть представлены в виде стандартных цепочек заданий с известным составом, последовательностью и сроками исполнения. После этого передача запроса заменяется назначением заданий в составе запроса, и качество работы группы оценивается аналогично TPI, но уже по назначенным в группу заданиям. Инциденты с длинными цепочками эскалаций «укорачиваются» за счёт введения каталога инфраструктурных услуг и OLA так, чтобы у каждой группы был определён свой состав услуг и свои сроки обработки поступающих к ним инцидентов (Рисунок 8). Нормируется также и время пребывания инцидентов на каждой из линий поддержки.

Рисунок 8. Привлечение других групп к решению инцидента / запроса на основании OLA

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

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

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

где Rij— рейтинг обработки i-того запроса в j-той группе, определяемый формулой:

а Wij— вес i-того запроса для j-той группы, определяемый формулой:

В (9)-(10) tij— время обработки i-того запроса в j-той группе, Ti— максимальное время обработки i-того запроса. n, как и в (7), натуральный пара- метр алгоритма (обычно равный 1).

Рассмотрим показатель TPIj подробнее:

• если запрос обработан своевременно, то Rij и Wij равны 1, все в порядке;

• если запрос просрочен, причём j-тая группа обрабатывала его дольше, чем общее максимальное время обработки Ti, то рейтинг Rij равен 0, а вес Wij – больше единицы пропорционально времени обработки в группе. То есть группа, потратившая все время, выделенное на обработку запроса, получает снижение значения метрики TPIj аналогично общему показателю TPI для процесса;

• если запрос просрочен, но j-тая группа обрабатывала его, например, в течение половины срока, то вес Wij равен 1, рейтинг Rij равен 0,5. То есть группа получает промежуточный штраф, величина которого тем больше, чем больше времени она удерживала запрос;

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

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

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

Скорость устранения инцидентов

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

Строго говоря, подтвердить минимальность времени устранения инцидента каким-либо простым расчётом нельзя. Вот опровергнуть — можно. Например, если сегодня некоторый инцидент решался дольше, чем вчера. Поэтому при анализе результативности процесса в отношении инцидентов важно помимо метрики своевременности TPI наблюдать за динамикой среднего времени решения инцидентов (Mean Time To Restore Service, MTRS).

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

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

Удовлетворённость пользователей качеством ИТ-поддержки

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

«Качество — это не то, что вы вкладываете в продукт или услугу. Это то, что от них получает заказчик».

Управление инцидентами и запросами в этом смысле очень удобный процесс — ведь в ходе обработки обращений пользователей у нас есть непосредственный контакт с пользователями, и, следовательно, оценить их удовлетворённость несложно. Мы используем два основных способа измерения:

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

• проведение целевых опросов пользователей.

Оценка удовлетворённости непосредственно перед закрытием обработанного обращения, как правило, обеспечивается средствами web-интерфейса системы автоматизации ITSM-процессов или по телефону — пользователя просят оценить, насколько он удовлетворён оказанной ему поддержкой по некоторой балльной шкале. Иногда таких шкал несколько, например оценка скорости поддержки, вежливости специалиста, доступности для пользователя информации по обработке его обращения. Средний балл по этим показателям за период может являться основанием для оценки. Более того, такая информация может помочь выявить несоответствие нормативов на поддержку ожиданиям пользователей, если показатели своевременности решения «на высоте», а многие пользователи оперативностью поддержки не удовлетворены (или наоборот). Ещё один плюс — такие оценки всегда персонифицированы (ведь заявитель обращения известен), а значит, вы можете анализировать информацию в различных разрезах: центральный офис и регионы, различные языки, разные способы обращения за поддержкой (теле- фон, электронная почта, web-интерфейс…), ИТ-услуги, по которым поступают обращения, и так далее. Наконец, эти показатели можно считать в разрезе отдельных функциональных групп и даже ИТ-специалистов, чтобы индивидуально оценивать их работу (что, впрочем, опять же осложнено функциональной эскалацией — обращение пользователя может быть последовательно обработано несколькими специалистами).

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

Численную оценку ответов пользователей Customer Satisfaction Index (полученных как при закрытии их обращений, так и в результате проведения опроса) по произвольной целочисленной шкале удобно представить следующим образом:

где M— средний балл по ответам пользователей, Mminи Mmax— минимальный и максимальный баллы по шкале оценок (для пятибалльной шкалы Mmin = 1, Mmax = 5).