Портал №1 по управлению цифровыми
и информационными технологиями

Вопрос из зала: KPI и своевременность обработки инцидента

Опубликовано 20 октября 2016
Рубрики: ITSM, Service Desk, Вопрос из зала, Измерение и оценка ИТ, Обо всём на свете, Управление инцидентами
Комментарии

2010В редакцию портала поступил вопрос:

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

Представим ситуацию, когда был просрочен инцидент, и в процессе решения было несколько смен услуг и несколько смен групп ТП. SLA по услуге = OLA(Время 1ЛТП)+OLA(Гр ТП в зависимости от выбранной услуги).

Допустим, инцидент по первоначальной услуге надо было решить в срок 10 дней. 1ая Гр ТП была занята или просто приступила к решению на 5ый день. В итоге было установлено, что услуга выбрана не та и проблема не в её компетенции. Затем была произведена смена услуги. SLA по этой услуге составляет 2 дня. Т.е. у нас получается ситуация когда на следующую группу упал уже просроченный инцидент, так как SLA/OLA начинает свой отсчет с момента создания инцидента.

Вопросы:

  1. Как мы можем просчитать объективную долю своевременности обработки инцидента. Ведь первая Гр ТП действовала в рамках своего установленного времени OLA? По своему времени у них всё в порядке. Вести расчет R и W относительно времени SLA, по которому закрывался инцидент не совсем корректно. Как вариант, веса и рейтинги можно расчитывать относительно своего для каждой услуги и Гр ТП времени OLA. Т.е. сколько времени они удерживали инцидент.
  2.  Как описано в примере выше, 2ая ГрТП получила уже просроченный инцидент, как по SLA, так и по своему времени OLA. Если поменять смысл OLA на следующий, что вне зависимости от того, менялась или нет услуга, SLA начинает свой отсчет от момента регистрации инцидента, и следующая группа может получить уже просроченный инцидент по SLA. Но время OLA при переназначении будет начинаться с момента переназначения, т.е. у группы будет оставаться своё регламентированное время на решение OLA. А расчет своевременности по просроченным инцидентам мы будем вести: 1. по просроченным инцидентам. 2. R и W будем высчитывать отностительно OLA1,OLA2… OLA N. В данном случае у нас получается. что общее время OLA выходит за пределы SLA по услуге. Хочется услышать мнение экспертов по данному поводу, ведь время OLA не может быть больше SLA.

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

Пример. У пользователя проблема с почтой (не отправляются письма). Заводится инцидент по услуге "Проблема почтового ПО", и в рамках инцидента создается первая задача для Гр ТП1 "проверка почтового ПО". Гр ТП1 устанавливает, что "проблема не связана с ПО". Далее в рамках инцидента создается задача 2 "Проверка сети", в ходе решения которой Гр ТП2 устанавливает, что это не проблема сети. Создается задача 3 "Проверка ПК" – инцидент закрывается.

В этом случае чтобы гарантировать Заявителю конечное время SLA, мы должны понять и определить какие дополнительные задачи могут возникнуть, чтобы просчитать и гарантировать финальное время SLA. SLA = OLA1+OLA2+…+OLA N. Но такой подход выглядит сложно реализуемым. Ваше мнение?

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Построение системы KPI для ИТ
Как обеспечить управление процессами, проектами, услугами, персоналом

Также по теме:

Комментариев: 14

  • Сергей

    Вопрос: на сколько корректно менять бизнес-услугу по ходу решения инцидента? В примере меняется операционная услуга, ПО на Сеть.

    Бизнес же услуга остается прежней "электронная почта", поэтому SLA по ходу решения меняться не будет.

    • Дмитрий

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

  • Дмитрий Исайченко

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

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

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

    Третий – мой ответ на Ваш вопрос в конце поста (Ваше мнение?) таков: "Это тупик".

    • Сергей

      Это тупик.

      А как решать принято "в лучших домах"?

      • Дмитрий Исайченко

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

    • Дмитрий

      Дмитрий, т.е. получается по логике вещей при переназначении с группы на группу, их регламентированное время OLA начинает свой отсчет с момента переназначения, хотя SLA по услуге может быть просрочен. (В данном случае cлучае OLA по конечной группе>SLA по услуге)

      По поводу гуляния запросов и подзапросов не совсем понял. Что является запросом и подзапросом.

      • Дмитрий Исайченко

        …при переназначении с группы на группу, их регламентированное время OLA начинает свой отсчет с момента переназначения, хотя SLA по услуге может быть просрочен

        Совершенно верно.

        Что является запросом и подзапросом

        Для рассчета времени по OLA от времени назначения в группу с сохранением исходного срока и SLA в известных мне ITSM-продуктах удобнее не переназначать исходный запрос пользователя, а создать по отношению к нему подзапрос.

        Исходный запрос: заявитель – пользователь, время регистрации – время его обращения в Service Desk, услуга – бизнес-услуга, срок – рассчитан по SLA.

        Подзапрос: заявитель – сотрудник ИТ, отвечающий за восстановление бизнес-услуги, время регистрации – время назначения в рабочую группу, услуга – поддерживающая услуга, за которую отвечает данная рабочая группа, срок – рассчитан по OLA.

        • Дмитрий

          Для рассчета времени по OLA от времени назначения в группу с сохранением исходного срока и SLA в известных мне ITSM-продуктах удобнее не переназначать исходный запрос пользователя, а создать по отношению к нему подзапрос.

          Исходный запрос: заявитель — пользователь, время регистрации — время его обращения в Service Desk, услуга — бизнес-услуга, срок — рассчитан по SLA.

          Подзапрос: заявитель — сотрудник ИТ, отвечающий за восстановление бизнес-услуги, время регистрации — время назначения в рабочую группу, услуга — поддерживающая услуга, за которую отвечает данная рабочая группа, срок — рассчитан по OLA.

          Дмитрий, т.е. картина получается такая?

           

  • Владимир

    Исходя из того, что SLA заключается между Исполнителем и Заказчиком, которому все равно какая именно группа Исполнителя будет решать его задачу: если был просрочен SLA – виноваты все группы исполнения, которые поучаствовали в решении (с точки зрения Заказчика). Для поиска виновной группы исполнения (с точки зрения Исполнителя) можно заключить OLA на выполнение нарядов в часах или в процентах об общего времени выполнения обращения по SLA. А не лучше всех участников сделать виновными, как с точки зрения Заказчика? Тогда группы перестанут играть в футбол и начнут пасовать только тем, кто добивается результата.

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

    По поводу выбора услуги/системы: IMHO всегда нужно указывать ту услугу/систему, которая являлась первопричиной события. Т.е. обратился Заказчик по поводу почты – выбирается услуга почты. Но если становится известно, что причина в неработоспособности сети, то должна выбраться услуга Сети. Далее, построить матрицу взаимозависимостей, согласно которой, становится понятным, что у Заказчика не работали все услуги, зависящие от работоспособности сети, включая почту.

    • Дмитрий

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

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

       

      • Владимир

        Можно сделать так: занимаешься нарядом – он в работе; не занимаешься – наряд на паузе. Но практика показывает, что фактическое время работы с нарядом очень сильно отличается от реального времени: не все сотрудники точно следуют инструкциям – по факту работают, но статус "в работе" не устанавливают и наоборот. Нормировщики труда говорят, что определенные виды работ нужно нормировать по времени, т.е. для учета нагрузки нужно нормативное время выполнения наряда перемножить на штуки выполнения.

  • Анна

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

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

    • Александр

      Анна, если я вас верно понял, этим действием вы "избегаете" нарушения SLA, но как быть с отчётностью? В вашем примере вы применяете неверную классификацию, т.е. 1 уровень зарегистрировал инцидент по услуге 1, у которой норматив 3 дня, но специалиcт 2 линии, получив этот инцидент видит что это вообще услуга 2, у которой норматив решения 2 часа!, понятно что поменяв услугу вы автоматом нарушите SLA, но это будет честно по отношению к заказчику (уметь признавать свои ошибки) и позволит выявить проблемные места (нехватка компетенции или понимания со стороны сотрудников, нереалистичность SLA). Если же использовать ваше "обходное" решение это не что иное как попытка не допустить нарушения SLA любым способом, в том числе подтасовкой фактов.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.