Skip to content

Latest commit

 

History

4 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Анализ инцидентов и SLA в телеком-подразделении

Задача:

Выявить драйверы нарушения SLA и выработать рекомендации по снижению штрафных санкций. Данные с Kaggle: открытый лог ITSM-процесса ServiceNow, структура типична для корпоративного Service Desk.

Стек:

Python, pandas, numpy, matplotlib, seaborn, jupyter. Дашборд: Yandex DataLens.

Ключевые выводы

  • made_sla описан как "логический атрибут, показывающий, превысил ли инцидент целевой SLA" - классический случай, когда описание в документации неточное или вводит в заблуждение. Принимаем True как выполнение SLA (большая доля значений).
  • Период данных 29.02–13.05.2016, ~75 дней, ~277 инцидентов/день. Формат единый, без пропусков.
  • Есть пропуски в ответственных за инцидент и ответственных подразделениях. У "брошенных" тикетов SLA хуже: разница в ~4 п.п.
  • Идентификатор проблемы и Вендор отсутствуют - либо это все клиентские инциденты и нет групповых аварий, либо нарушена связка с системой ГП и работа с Вендором. Также вполне верятно что это обезличенный набор данных.
  • Заявки в большинстве передаются по телефону как умеренно срочные в будние дни (похоже на клиентов b2b).
  • Критичные и высокие по приоритету тикеты - с нарушением SLA. Исполнение 2,27% и 0,3% соответственно при среднем уровне SLA в 60,64%.
  • Использование базы знаний только в 17% случаев. В инцидентах с применением БЗ SLA 27% против 68%. Гипотеза: БЗ пользуются новые сотрудники.
  • В анти-ТОП 10 групп ТП (с порогом более 20 ТТ) уровень SLA ниже среднего на 40-60%.
  • 51 инцидент с нулевым SLA и передачей между группами более 10 раз. Гипотеза: сложные кейсы либо размытие зоны ответственности между подразделениями.
  • На 13 марта просадка по всем категориям тикетов кроме низкоприоритетных. Гипотеза: подозрение на массовую аварию, которая длилась более 8 суток и менее 16.
  • Есть пропуски в датах решения, но у всех тикетов есть дата закрытия. Честный SLA (по решенным): 58,72% против 60,64% - ниже на 2 п.п.

Рекомендации для руководства

  • Привести описания полей БД в БЗ к коректному виду.
  • Сделать дату решения обязательной для закрытия; аудит таких записей.
  • После приведения бизнес-процесса к целевому виду: назначения/автоназначения ответственного сотрудника/подразделения - прогнозируется рост SLA.
  • Проверить тех карты в БЗ, уточнить: на сколько они информативны, чего не хватает.
  • Выделение дополнительной группы поддержки на высокоприоритетные заявки.
  • После оптимизации бизнес-процессов в группах риска (анти-ТОП 10 групп ТП) прогнозируется повышение уровня SLA.
  • Для тикетов с многократной передачей между подразделениями привлечение руководителя/эксперта к решению. Проверка зон ответственности подразделений в регламентах по данным кейсам.

Интерактивный дашборд:

https://datalens.yandex/z0tcoq0rk4u4i?_share_link=public

About

Анализ инцидентов и SLA в телеком-подразделении

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages