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

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

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. Но такой подход выглядит сложно реализуемым. Ваше мнение?

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

Комментариев: 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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT