Любая боль – это сигнал о том, что есть проблема, о которой нам сообщает организм. А что в ITSM? Есть проблемы, о которых нам сигнализируют инциденты. Мелкие или значительные – они все равно остаются инцидентами, сигнализирующими об уровне боли для бизнеса. И как скорая помощь, Service Desk бросается на устранение боли. Подчеркну, это всего лишь снятие симптоматики, анестезия, которая потребует последующей терапии. С этой ситуацией сталкиваются и те, кто находится на стороне потребителя, и те, кто находится на стороне поставщика услуг.
Вопросы управления инцидентами рассматриваются в рамках одноименного процесса в библиотеке ITIL v3, а также в руководстве по практике управления инцидентами ITIL4. В чем же отличие, дело ведь не в переименовании процессов в практики?
Начнем с того, что основным компонентов в ITIL v3 были 5 этапов жизненного цикла услуги, а в ITIL4 этим компонентом стала сервисная система создания ценности (service value system, SVS). Если управление инцидентами в ITIL v3 рассматривалось, как особый процесс, которому необходимо следовать, ITIL4 предполагает, что управление инцидентами лучше всего работает, когда организации применяют гибкий, целостный подход. Теперь это называется практикой, состоящий из двух процессов: обработки и разрешения инцидентов, а также периодическом анализе инцидентов.
Инцидент все так же остается инцидентом, а значит глобальных изменений в определении инцидента и назначении практики в ITIL 4 не произошло.
Инцидент – незапланированное прерывание или деградация качества услуги, а назначение практики – минимизация негативного влияния инцидентов за счёт скорейшего восстановления нормальной работы услуги.
Под “нормальной работой” понимается возможность продолжить работу потребителями услуг, используя Обходное решение, называемое в народе “костыль”, а сама “нормальная работа” обычно описывается в соглашении об уровне услуг (SLA).
Обходное решение (workaround) – решение, которое уменьшает или устраняет влияние инцидента или проблемы, для которого полное разрешение еще не доступно.
Обходные решения могут увеличить технический долг и могут привести к новым инцидентам в будущем.
Технический долг (technical debt) – новый термин, появившийся в управлении инцидентами ITIL4. Технический долг – общее отставание за счет переделок, накопленных путем выбора обходного решения вместо решений, которые займут больше времени.
Technical debt – the total rework backlog accumulated by choosing workarounds instead of system solutions that would take longer.
ITIL®4 Practice Guide Incident management
Каждая организация, разрабатывая практику управления инцидентами, обеспечивает выделение ресурсов и управление ими для различных типов инцидентов:
- Простые инциденты решаются силами первой линии с использованием определенных моделей и процедур
- Значительные инциденты и инциденты информационной безопасности потребуют создания отдельных моделей с привлечением специалистов с экспертными знаниями для диагностики и решения
- В очень сложных ситуациях, когда для решения инцидента невозможно или сложно определить область и группу экспертов или определенные группы экспертов не могут найти решение, применяется подход, описанный техникой “роения”.
Роение (Swarming) — это новый термин для управления инцидентами. Аналогия с роем пчел или муравьев, которые собираются вместе для решения задач.
При «роении» множество людей с разными областями знаний работают вместе над задачей, пока не станет ясно, какие компетенции являются наиболее актуальными и необходимыми.
В практике управления инцидентами ITIL4 поменялся взгляд на приоритизацию инцидентов.
Вот несколько рекомендаций по расстановке приоритетов:
- Инциденты должны обрабатываться в едином бэклоге вместе с другими задачами.
- Приоритизация — это инструмент для назначения людей на задачи в контексте команды
- Расстановка приоритетов необходима только в случае конфликта ресурсов
- Оценка влияния и срочности инцидента (и временных ограничений для его расследования и разрешения) не является приоритетом.
Исторически сложилось так, что команды, работающие над инцидентами, делились на линии поддержки, в которых компетентность, опыт и специализация повышались с каждым последующим уровнем. Функциональная эскалация, как правило, это всегда увеличение времени решения инцидента. Основной движущей силой изменений в управлении инцидентами ITIL4 является использование более динамичных, самоорганизованных плоских структур с соответствующими методами (swarming, например) для облегчения сотрудничества и передачи информации, в отличии от применения жесткого многоуровневого деления на линии поддержки. Эта деятельность требует и создания новой культурной среды: уход от “героев-одиночек”, получающих вознаграждение за решенные инциденты, и приход к коллективной ответственности. Отказ от культуры обвинений и фокусе на экспериментировании, непрерывном обучении из вынесенных уроков от неудач и ошибок.
Ну и вопрос вопросов: как работает наша практика? Достигает ли она своего назначения и что надо сделать для достижения максимальной эффективности?
В ITIL v3 эти разделы назывались как критические факторы успеха (critical success factors, CSF), в ITIL4 это факторы успеха практики (practice success factors, PSF). Эффективность практик ITIL следует оценивать в контексте потоков создания ценности и только в контексте ее применения.
PSF управления инцидентами включают в себя:
- Раннее обнаружение инцидентов. (Уместно задаться вопросом: а способны ли мы выявить инциденты на ранней стадии? Обнаружение инцидентов возможно благодаря практике мониторинга и управления событиями.)
- Разрешение инцидентов быстро и эффективно. (Вопрос: довольны ли наши потребители скоростью и качеством нашей работы?)
- Постоянное совершенствование подходов к управлению инцидентами. (Вопрос: можем ли мы выполнять работу лучше и как это сделать?)
Управление инцидентами – скорая помощь для бизнеса. Каждая команда, предоставляя услуги, сталкивается с задачей, как выстроить эту деятельность в соответствии с потребностями бизнеса. ITIL 4 не столь специфичен в сравнении с ITIL v3, чтобы точно сказать вам, что надо делать. В этом есть рациональное зерно, на мой взгляд. Ведь даже если бы было четкое пошаговое описание построения управления инцидентами – это была бы одна точка зрения, пусть даже проверенная временем. В конце концов ITIL – не свод законов, требующий соответствия.
Лучший подход к решению инцидентов – подход, основанный на креативности и оригинальности, а не на строгом выполнении сценария. Невозможно придумать инструкции на все случаи жизни, т. к. многообразие инцидентов и специфики не описать одним документом. Здесь потребуются работа и усилия специалистов с разным профилем компетенций и специальными знаниями.
Командам, занимающимся управлениям инцидентами, будет полезно разобраться вникнув в подробности по данной практике, опубликованной в My ITIL на сайте AXELOS, а также с возможностями применения практики, рассматриваемыми в рамках курсов:
- ITIL 4 Create Deliver and Support (CDS),
- ITIL 4 High Velocity IT (HVIT),
- Operational Support and Analysis (ITIL OSA).
