ГлавнаяСтатьиСтатистический анализ на основе реальных данных Сервис-Деск

Статистический анализ на основе реальных данных Сервис-Деск

ВВЕДЕНИЕ

Статья продолжает серию публикаций по теме «Применение статистического анализа в ИТ».

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

 При написании данной статьи мы ставили целью показать, каким образом, на основе реальных данных из ИТ Сервис-Деск, можно проанализировать работу службы поддержки пользователей, и какие выводы можно сделать.

 За основу для анализа взят процесс Управления Инцидентами. Данные были любезно предоставлены нам одним из наших Заказчиков, с правом использования в статье. На момент получения данных, ИТ Сервис-Деск находился в эксплуатации более 3-х лет. Данные для анализа взяты за последний год работы.

  

НАЧАЛЬНЫЕ УСЛОВИЯ

Кратко опишем статус процесса Управления Инцидентами:

  • Процесс Управления Инцидентами документирован (было проведено проектирование процесса, документация в наличии);
  • ПО ИТ Сервис-Деск было сконфигурировано в соответствии с утверждённой процессной документацией;
  • В ходе эксплуатации возникали запросы на изменения процесса Управления Инцидентами, и соответственно было сконфигурировано ПО ИТ Сервис-Деска;
  • Изменения не были документированы.

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

 Давайте на этом этапе зафиксируем для себя то, как оценивали ситуацию сотрудники компании:

  • Процесс Управления Инцидентами (далее - процесс) спроектирован;
  • Процесс автоматизирован;
  • В течение последнего года коллективно принимались решения по улучшению процесса (связано с тем, что ПО не удовлетворяло требованиям ИТ и приходилось его конфигурировать);
  • Данные решения по улучшению процесса превращались в задания на доработки системы автоматизации (ИТ Сервис-Деск);
  • Система автоматизации была доработана по всем запросам на улучшения;
  • Документация стала несколько отличаться от реального процесса, но - незначительно.

 Пока в целом всё радует - не так ли?

Давайте проверим эти выводы с помощью статистического анализа.

  

ЧТО БЫЛО СДЕЛАНО ДЛЯ ПРОВЕДЕНИЯ СТАТИСТИЧЕСКОГО АНАЛИЗА

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

  1. Получены выгрузки из ИТ Сервис-Деск за последний год;
  2. Выбраны данные только для процесса Управления Инцидентами;
  3. Выделены данные только по одному из типов инцидентов;
  4. По выборке построены карты Шухарта;
  5. Проведён анализ карт Шухарта.

 Далее последовательно детализируем эти пять шагов.

  

1.     Выгрузки из ИТ Сервис-Деск за последний год

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

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

 Пример блока данных приведён на картинке ниже:

 

2.     Выборка данных только для процесса Управления Инцидентами

Из массива данных были выбраны только те, которые относились к процессу Управления Инцидентами.

 3.     Выделение данных только по одному из типов инцидентов

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

 4.     Построение карт Шухарта

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

 

По оси «Х» - номер Инцидента.
По оси «Y» - время в сутках.

 В случае вопросов о том, как были построены данные карты, рекомендуем обратиться к статье «Применение статистического анализа в ИТ» и первоисточникам, указанным в ней.

 5.     Анализ карт Шухарта

Не перегружая картинку, проставим несколько точек:

Перечислим проставленные точки:

  • 1, 2, 3, 7 - Верхний контрольный лимит;
  • 4 (и точки, подобные этим) - время решения заявок, вышедшее за рамки Верхнего контрольного лимита (особая вариабельность);
  • 5, 6 - среднее время устранения Инцидентов.

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

 Что нам говорит полученная карта?

 Вывод неожиданный (вспомните, как оценивали ситуацию сотрудники компании) - оказалось, что внесённые в процесс доработки и улучшения на деле УХУДШИЛИ его показатели.

Это видно по нескольким параметрам:

  • «всплеску» количествава заявок, вышедших по времени решения за Верхний контрольный лимит (заявки в интервале с 25-ой по 100-ую);
  • постоянного увеличения Верхнего контрольного лимита (точки 1, 2, 3);
  • постоянного увеличения среднего времени решения заявок (точки 5, 6).

 

 Про SLA, или  - ПОБОЧНЫЕ РЕЗУЛЬТАТЫ СТАТИСТИЧЕСКОГО АНАЛИЗА

Несколько слов на тему того, как с помощью карт Шухарта оценивать и контролировать SLА.

Для дальнейшего обсуждения примем, что SLA определяется показателями Верхнего контрольного лимита карты Шухатра. Более детально - в статье «Применение статистического анализа в ИТ» и первоисточниках, указанных в ней.

 На тот момент, по утверждённому у Заказчика SLA (внутренний документ), время устранения данного типа Инцидентов равнялось 4-ём часам.

 Вернёмся к полученным картам Шухарта.

Четыре часа (+/-) на устранение данного типа Инцидентов можно было ожидать до начала внесения изменений в Сервис-Деск (заявки с 1 по 23).

Далее вносимые в систему корректировки (изменения процесса) стали влиять - в худшую (!) сторону - на время решения данного типа ицидентов. Из-за этого «поплыл» Верхний контрольный лимит.

Что это означает для ИТ?

Это означает, что - при подписанном (и ранее актуальном) SLA в 4 часа - в середине года SLA не мог быть обеспечен лучше, чем 2,5 суток (заявки с 24 по 130).

Далее изменения «заморозили» и стали разобрались с первопричинами возникновения проблем (заявки 130 и далее).

Заметьте, что Верхний контрольный лимит (с заявки 131) стал УМЕНЬШАТЬСЯ.

 

 ВЫВОДЫ

Несколько выводов:

  • Для проведения анализа должны использоваться только однотипные данные (как в данном примере - только Инциденты, а из них - только Инциденты определённого типа);
  • В идеале уже при проектировании систем автоматизации ИТ должны закладываться аналитики, позволяющие строить карты Шухарта «в он-лайн» (можно читать это как «приобретая систему, нужно уточнить, возможно ли будет в ней сконфигурировать необходимые для статистического анализа аналитики»);
  • Невозможно построить карты по всем процессам ИТ - так, например, не имеет практического значения построения аналитик по Управлению Изменениями;
  • Существует деятельность ИТ, для которой статистический анализ имеет практическое применение - например, инциденты определённых типов, наряды на работы определённого вида и т.п.

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

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

В третьей статье - "Как работать с результатами статистического анализа" - сжато приводится порядок действий при работе со статистическим анализом.