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

Задачи процесса рекомендуется фиксировать в регламенте процесса, так как они меняются реже целей и отражают устоявшуюся технологию реализации процесса. Они определяют конкретные функции, которые процесс должен выполнять для соответствия своему назначению (например, накопление знаний по устранению инцидентов для службы поддержки). Цели процесса, напротив, регулярно пересматриваются (на зрелости уровня 3+), так как привязаны к конкретным временным периодам и бизнес-задачам. Их фиксация в регламенте приведёт к частым изменениям документа, поэтому их размещают в планах управления или картах показателей, где они могут обновляться без переработки основного регламента процесса.

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

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

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

Копировать KPI из книг по управлению ИТ напрямую в собственные процессы не следует по нескольким причинам. Во-первых, примеры метрик, приведенные в таких источниках как ITIL или COBIT, являются иллюстративными и предназначены для объяснения концепции, а не для прямого применения. Авторы этих книг явно указывают, что это примеры (например, в ITIL 2011 представлено 18 примеров KPI для процесса управления инцидентами). Во-вторых, готовые метрики из книг не учитывают специфику конкретной организации, ее целей и потребностей. Для эффективного измерения процессов необходимо разрабатывать собственные KPI, исходя из целей измерения: что конкретно требуется измерять и зачем. Правильный подход заключается в построении цепочки: Назначение ⇒ ключевые практики ⇒ метрики ⇒ целевые и граничные значения ⇒ KPI, а не в поиске готовых решений, которые часто не имеют практической ценности.

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

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

Causal Loop Diagram (CLD) помогает в верификации набора метрик, позволяя визуализировать взаимосвязи между ключевыми элементами системы управления. Анализируя CLD, можно убедиться, что все элементы управления охвачены метриками. Например, при рассмотрении DevOps-процессов, CLD отражает такие факторы, как время выхода на рынок, среднее время обработки, размер очереди изменений, уровень стандартизации, успешность внедрений и другие. Соотнося элементы CLD с предлагаемыми метриками, можно определить, достаточно ли текущих показателей для оценки состояния системы и где есть пробелы.

Основная тема книги - построение каталога ИТ-услуг и организация Service Level Management (SLM) в ситуациях, когда ИТ-подразделение находится в составе компании или группы компаний. Книга подробно рассматривает методы формирования каталога ИТ-услуг, разделения его на каталог для заказчиков (Service Catalog) и каталог для пользователей (Service Request Catalog), а также рекомендации по внедрению ITSM. Авторы предлагают рассматривать бизнес-процессы предприятия как основной источник информации для формирования бизнес-ориентированного каталога ИТ-услуг.