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

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

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

Методика «Пять «Почему?» («5-why») заключается в последовательном задавании вопроса «Почему?» для выявления причин явления (проблемы). Начиная с исходного события, на каждом шаге фиксируется ответ, и к этому ответу снова применяется вопрос «Почему?». Данный подход позволяет, как утверждается в ITIL SO (4.4.4.3), на пятой итерации добираться до корневой причины проблемы. Однако процесс может включать ветвление ответов на каждом этапе, поскольку на вопрос «Почему?» часто существует несколько возможных ответов, что усложняет однозначное определение корневой причины.

В IT4IT Reference Architecture определены четыре основных потока создания ценности (Value Streams): 1) Strategy to Portfolio (S2P) - охватывает процессы от определения бизнес-стратегии до формирования портфеля ИТ-услуг, включая управление портфелем, финансами и инвестициями; 2) Requirement to Deployment (R2D) - описывает процессы от определения требований к услуге до ее развертывания в эксплуатацию, включая разработку и тестирование; 3) Request to Fulfill (R2F) - охватывает предоставление услуг конечным пользователям, включая управление запросами, инцидентами и изменениями; 4) Detect to Correct (D2C) - отвечает за управление эксплуатацией, включая мониторинг, обнаружение проблем и их устранение. Каждый Value Stream представляет собой последовательность функциональных компонентов, которые вместе создают ценность для организации, начиная от бизнес-потребностей и заканчивая предоставлением работоспособных ИТ-услуг.

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

Технологическое развитие может приводить к тому, что некоторые услуги, ранее считавшиеся основными, становятся дополнительными, когда появляются более эффективные альтернативы. Например, электронная почта как канал взаимодействия пользователя с Service Desk, который раньше был стандартным, теперь перестает использоваться повсеместно из-за появления web-порталов. Эти портальные решения обеспечивают более быструю и структурированную обработку заявок, делая почту менее эффективной и более ресурсоемкой, что приводит к ее переводе в разряд дополнительных, премиальных услуг.

Методология формирования ИТ-бюджета по ITIL состоит из пяти основных этапов: получение бизнес-планов через Business Relationship Management (BRM) и Service Level Management (SLM), согласование планов потребления услуг с клиентами (SLM и управление емкостью сервисов), подготовка планов по ресурсному обеспечению включая персонал (Resource Capacity Management), вычисление стоимости ресурсов и услуг с аллокацией косвенных затрат (Financial Management for IT), и окончательный расчет стоимости услуг на основе потребления, приводящий к обоснованному операционному бюджету ИТ.

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

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