Анализ текущего состояния потока создания ценности в ИТ-команде можно провести с помощью картирования потока (Value Stream Mapping, VSM). Это включает создание визуальной карты всех этапов обработки задач, объединение их с информационными потоками и связанными метриками. Анализ должен ответить на вопросы: кто является источником запросов и как они приоритизируются; достаточно ли информации для фокусировки на ценности; как организована передача задач между этапами; где есть завихрения и возвратные движения элементов; все ли этапы и очереди визуализированы; как организована приёмка и подтверждение поставленной ценности.

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

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

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

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

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

Учёт трудозатрат позволяет выявить ключевые статьи расходов и определить направления для оптимизации. Поскольку затраты на персонал составляют значительную долю операционных затрат (40-60%), их анализ помогает ИТ-директору принимать обоснованные решения по сокращению издержек. Без регулярного учёта и анализа трудозатрат невозможно эффективно управлять бюджетом и повышать производительность ИТ-подразделения.

Service Owner активно участвует в обсуждении и разработке SLA (уровней сервиса) и OLA (внутренних уровней сервиса), выступая от имени бизнеса при переговорах. Он обеспечивает, что SLA корректно отражают бизнес-требования и ожидания, а OLA поддерживают достижение внешних SLA. При этом Service Owner контролирует выполнение SLA и OLA и выступает в роли посредника при возникновении расхождений между ожиданиями и реальным уровнем сервиса.

Для определения идеальных качеств менеджера для конкретной компании необходимо провести собственное исследование, подобное тому, что провела Google в рамках Project Oxygen. Это включает в себя проведение интервью с сотрудниками, анализ данных по методу «360 градусов», опросы уходящих сотрудников и оценку эффективности деятельности текущих руководителей. На основе полученных данных можно выявить, какие именно качества и компетенции наиболее влияют на результативность работы подчинённых в вашей организации. Полученный список может содержать разное количество пунктов, от двух до двадцати, и будет уникален для каждой компании, так как зависит от специфики её деятельности, культуры и целей.

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