Менеджер ИТ-процесса должен действовать по следующему алгоритму: 1. Идентифицировать и локализовать проблему, определив конкретные факторы, негативно влияющие на процесс 2. Подготовить одну или несколько мер, направленных на устранение проблемы или минимизацию ущерба 3. Найти и обеспечить выделение ресурсов для осуществления плана 4. Проконтролировать реализацию мер и убедиться в их эффективности, при необходимости вернувшись к первому шагу Важно, что на первом этапе необходимо определить, какие изменения произошли в последнее время, проанализировать характер и структуру проблемных обращений, идентифицировать критические точки в процессе. Второй этап включает разработку как временных, так и постоянных решений. Третий этап требует защиты плана и убеждения заинтересованных сторон в необходимости выделения ресурсов. Четвертый этап предполагает постоянный мониторинг и измерение эффективности внедренных мер.

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

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

Четкое определение того, что входит в предоставляемую услугу, необходимо для предотвращения недоразумений между поставщиком и потребителем. Без этого могут возникнуть споры о том, какие обязанности лежат на поставщике, а какие — на клиенте. Например, если услуга аренды квартиры включает предоставление работающей стиральной машины, то её поломка должна устраняться арендодателем. Если же это не прописано, то ответственность за ремонт может лечь на арендатора

"Сквозная" ответственность за релиз означает наличие единой роли или лица, отвечающего за управление и координацию деятельности в рамках релиза на всём протяжении его жизненного цикла — от планирования и подготовки до непосредственного развёртывания и закрытия. Эта концепция аналогична роли координатора изменений в процессе управления изменениями, где отдельный ответственный следит за всеми этапами изменения. В ITIL такая сквозная ответственность фактически возлагается на менеджера процесса, хотя прямого указания на роль "Координатор релизов" в стандарте не существует. Это создаёт некоторые неопределённости для организаций, внедряющих ITIL, особенно при необходимости четко распределить ответственность внутри команды.

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

Цели для каждого ITSM-процесса формулируются через его уникальное назначение. Например, для управления инцидентами цель: 'Сократить время устранения инцидентов на 10% к концу квартала'. Для управления проблемами: 'Уменьшить количество повторяющихся инцидентов на 15% через внедрение анализа корневых причин'. Все цели должны быть измеримыми, конкретными и напрямую влиять на качество ИТ-услуг, соответствуя принципам SMART и ориентируясь на потребности конечных пользователей.

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

Традиционную схему оценки влияния инцидентов можно улучшить следующими способами: 1) Ввести специальные правила для критичных периодов, например, повышать уровень влияния для отчетности в конце месяца. 2) Определить функциональных VIP-пользователей, чьи обращения всегда имеют повышенный приоритет. 3) Установить особые правила оценки влияния для отдельных ИТ-услуг, которые имеют стратегическое значение для бизнеса. 4) Сформулировать более четкие критерии различия между 'частичным' и 'полным' отсутствием функционала. При этом важно сохранять баланс между детализацией правил и их практической применимостью для сотрудников первой линии поддержки.

Добавление критериев завершения (Definition of Done) в визуализацию процесса важно потому что в вытягивающей системе (Pull System) каждый следующий шаг в потоке сам забирает задачи. Чтобы система работала правильно, необходимо четко понимать, какие задачи на предыдущем этапе завершены, а какие нет. Без явных критериев завершения невозможно определить, когда задача готова к переходу на следующую стадию, что нарушает принципы потока ценности и эффективности DevOps подхода.