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

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

В ITIL 4 управление инцидентами предполагает более продвинутый подход, ориентированный на автоматическое обнаружение и регистрацию (а часто и разрешение) инцидентов сразу после их возникновения и до того, как они начнут влиять на пользователей. Это достигается за счет использования современных технологий мониторинга и анализа данных. Вводится концепция моделей инцидентов - повторяемых подходов к управлению конкретным типом инцидентов, что позволяет решать проблемы быстро и эффективно. Основные преимущества нового подхода: некоторые инциденты могут быть разрешены до того, как они повлияют на качество услуг, сокращается продолжительность недоступности систем, что снижает связанные со сбоями расходы. В отличие от предыдущих версий, где акцент делался на оперативном восстановлении услуг, ITIL 4 ставит более высокую цель - предотвращение влияния инцидентов на пользователей.

Управление доступностью в ITIL представляет собой процесс, задачи которого включают создание и ведение плана доступности, участие в диагностике и решении инцидентов и проблем, связанных с доступностью, оценку влияния изменений на доступность услуг и ресурсов. Однако, согласно анализу, эти задачи фактически пересекаются с другими процессами, такими как управление инцидентами, проблемами, изменениями, управление уровнями сервиса (SLM), управление непрерывностью и мощностями. Процесс управления доступностью считается уникальным изобретением ITIL, так как в других стандартах он либо не выделен отдельно, либо объединен с другими процессами.

Лидерство руководителей критически важно для успеха ITSM проекта по нескольким причинам. Во-первых, без поддержки и участия руководителей сложно принимать оптимальные решения на этапе проектирования процессов с точки зрения достижения целей процесса. Во-вторых, именно благодаря влиянию руководства становится возможным обеспечение беспрекословного выполнения положений процесса на этапе его запуска. Руководители имеют авторитет и полномочия, необходимые для преодоления сопротивления изменениям и обеспечения соответствия новым правилам работы. Без активного участия руководства команды часто сталкиваются с проблемой получения согласований и ресурсов, а также с трудностями в установлении приоритетов, что может привести к провалу всего проекта.

Существуют два принципиальных способа организации взаимодействия линий поддержки. Первый способ: обращение или инцидент остается на первой линии, а на вторую линию назначается задание (так называемое функциональное задание). Второй способ: после обработки на первой линии обращение или инцидент полностью назначается на вторую линию (возможно с использованием заданий для взаимодействия с ресурсными группами, но не как механизма функциональной эскалации).

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

Основная цель практики управления инцидентами по ITIL 4 — минимизировать негативное влияние инцидентов на бизнес и пользователей. Приоритизация способствует достижению этой цели, позволяя определить оптимальный порядок решения инцидентов при ограниченных ресурсах. Правильная приоритизация обеспечивает то, что сначала решаются инциденты с наибольшим негативным влиянием или наиболее строгими требованиями SLA, что в итоге приводит к минимальному общему воздействию на бизнес. Поскольку ресурсы всегда ограничены, а инциденты возникают постоянно, приоритизация является ключевым инструментом для эффективного достижения цели практики.

Критический вывод заключается в том, что ИТ-подразделения часто воспринимаются не как бизнес-партнеры, с которыми нужно строить отношения на основе взаимной выгоды и убеждения (пряник), а как обычная рабочая сила, предназначенная только для выполнения задач (лошадь, которую нужно погонять кнутом). Это свидетельствует о том, что концепция управления ИТ как полноценным бизнесом (IT as a Business) не так широко внедрена, как это пропагандируется. Настоящий бизнес-руководитель должен обладать полномочиями для гибкого стимулирования персонала, участвующего в основных бизнес-процессах, что не всегда реализуется в отношении ИТ-направлений.

Метрика распределяет ответственность за нарушение срока обработки пропорционально доле участия каждой группы в общем времени обработки просроченного инцидента. Для этого используется формула, где для каждого просроченного инцидента (vi=1) вычисляется доля времени группы (ti/Ti), которую затем вычитают из единицы. Чем большую часть общего времени обработки инцидента занимала группа, тем больше ее ответственность за просрочку и тем ниже её KPI. Это позволяет избежать ситуаций, когда 'стрелочником' становится последняя группа, получившая уже просроченный инцидент.