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

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

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

Принцип распределения ответственности между группами при обработке просроченного инцидента заключается в том, что степень ответственности каждой группы пропорциональна её доле в общем времени обработки инцидента. То есть, если группа потратила большую часть времени на обработку просроченного инцидента, её доля ответственности будет больше и метрика KPI покажет более низкое значение. Формула учитывает время ti, которое каждая группа затратила на работу с инцидентом, и общее время Ti обработки инцидента. Таким образом, ответственность за просрочку распределяется более справедливо, чем при традиционном подходе, где вся ответственность возлагается на последнюю группу.

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

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

Многие организации сталкиваются с трудностями при использовании сервисно-ресурсной модели в повседневной работе из-за отсутствия четкого понимания ее практического применения. Несмотря на то, что проекты по созданию модельных примеров требуют значительных усилий, на этапе промышленной эксплуатации часто выясняется, что большинство разработанных «фишек» не используются. Это связано с тем, что изначально модели проектируются с избытком функциональности, без четкого понимания реальных потребностей бизнес-процессов.

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

Задачи процесса управления доступностью пересекаются со следующими процессами: создание плана доступности может быть частью стратегического плана инфраструктуры (SIP) или пересекаться с управлением мощностями; диагностика и решение инцидентов и проблем относится к их специализированным процессам; оценка влияния изменений на доступность является задачей управления изменениями; отслеживание уровня доступности и анализ отклонений входят в зону ответственности SLM. Это вызывает вопрос о уникальности задач управления доступностью как отдельного процесса.

Игра Grab@Pizza демонстрирует, что успешность бизнеса напрямую зависит от эффективной работы связки Business-SLM-Change. Участники учатся понимать, как изменения в системе управления уровнями сервиса (SLM) влияют на бизнес-процессы и как правильно организовать коммуникацию между бизнесом и ИТ для своевременного внедрения необходимых изменений. В ходе игры становится очевидно, что пренебрежение этими аспектами может привести к увеличению числа инцидентов, снижению качества услуг и негативно сказаться на общих бизнес-результатах.