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

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

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

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

При использовании альтернативных механизмов обработки инцидентов, требующих доработки ПО, обязательно должны соблюдаться три условия: 1) оказание помощи пользователю здесь и сейчас, даже если полное решение требует доработки; 2) систематическое информирование пользователя о ходе выполнения доработки; 3) наличие дополнительных контролей за использованием таких механизмов для предотвращения злоупотреблений со стороны групп поддержки, стремящихся избежать штрафов за просрочку. Эти меры обеспечивают баланс между оперативной поддержкой пользователей и соблюдением SLA требований.

Основная идея подхода Tipu заключается в том, что Continual Service Improvement (CSI) нужно организовывать не после внедрения базовых процессов управления ИТ-услугами, а с самого начала, в рамках первых инициатив. Это позволяет постепенно и органично «достраивать» систему управления, отталкиваясь от реальных задач заказчика и используя набор процессных элементов, которые можно внедрить в относительно короткие сроки. Подход предполагает создание не идеальных процессов, а работающих решений с последующим наращиванием уровня зрелости через интегрированный CSI подход.

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

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

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

Руководящие принципы ITIL 4 отражают многие другие подходы, методологии, методы, стандарты и философии, в частности Lean, Agile, DevOps и COBIT. Это означает, что принципы ITIL 4 не противоречат этим подходам, а скорее дополняют их и находят в них отражение. Это позволяет организациям, уже использующим эти подходы, легко интегрировать рекомендации ITIL в свою существующую практику без конфликтов между различными системами управления. Универсальность принципов ITIL 4 обеспечивает их применимость в различных контекстах и совместимость с широким спектром современных управленческих практик.