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

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

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

Различия в описании критических факторов успеха (CSF) между ITIL v3 и IT4IT заключаются в уровне детализации и фокусе. В ITIL v3 критические факторы успеха и ключевые показатели эффективности (KPI) определены для каждого из 26 процессов, что предоставляет очень детализированные рекомендации по управлению отдельными функциональными областями. В IT4IT же CSF и KPI описываются на уровне Value Streams (потоков создания ценности), а не на уровне отдельных функциональных компонентов. Это означает, что IT4IT делает акцент на том, что необходимо для успешного создания ценности через весь поток деятельности, а не только через его отдельные элементы. Хотя в ITIL v3 есть упоминания о критических факторах успеха для фаз жизненного цикла услуги (в последних главах каждой книги), это описание менее структурировано и детально по сравнению с фокусом IT4IT на Value Streams. Таким образом, ITIL v3 предоставляет более операционный, процессно-ориентированный взгляд на CSF, тогда как IT4IT предлагает более стратегический, потоко-ориентированный подход.

DevOps-метрики, которые можно соотнести с элементами Causal Loop Diagram, включают: Lead Time (Time to Market), Process Time (Process Time), Deploys per day (Release Rate), процент успешно реализованных изменений (% changes successfully implemented), процент полных и точных изменений (%C/A – percent complete and accurate), PIR Coverage Index, Mean time between release implementation, Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases, Number of defects per release, Average number of release units per release, Emergency Change Rate, Percentage of Changes Registered.

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

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

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

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

Процесс EDM05 «Обеспечение прозрачности для заинтересованных сторон» отвечает за формирование отчетности и обеспечение прозрачности системы руководства ИТ. Объектом этого процесса также выступают процессы руководства (EDM02–EDM04), а его задача — обеспечить доступность информации о руководстве ИТ для заинтересованных сторон. Практики процесса EDM05 включают оценку требований к отчетности со стороны заинтересованных лиц, определение направления действий в сфере информирования и мониторинг эффективности предоставления отчетности.