Четвертый шаг цикла Деминга (Act) заключается в принятии решений относительно дальнейших действий после проверки результатов изменений. Он включает ответ на вопрос: 'Что делать дальше?'. Это может означать внедрение успешных улучшений в стандартную практику, игнорирование неудачных результатов без дополнительных изменений или запуск нового цикла PDCA с учетом полученного опыта. Act фокусируется на итоговой корректировке подхода и определении дальнейшей стратегии улучшений, что отличает его от этапа планирования, который предваряет непосредственное выполнение изменений.

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

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

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

Для создания каталога ИТ-услуг с применением PCF можно рекомендовать следующий алгоритм действий: сначала проанализировать список процессов в PCF и выделить те, которые явно выражены и имеют место в вашей организации, для чего необходимо глубоко понимать работу компании; затем определить и уточнить владельцев процессов; далее проанализировать вместе с ИТ-специалистами (бизнес-аналитиками, представителями подразделений, сопровождающих ИТ-системы) полученный список процессов и определить, для каких из них имеется специфичная деятельность, выполняемая ИТ-подразделениями; при необходимости объединить несколько процессов в рамках предоставления одной услуги; и, наконец, сконсолидировать полученную информацию и составить описание каждой из сервисов. В результате будет получен каталог ИТ-услуг, составленный "от бизнес-процессов".

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

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

В процессе управления релизами ITIL V3 выделены следующие технические роли: Практик пакетирования и построения релизов, занимающийся сборкой и подготовкой компонентов релиза; Практик развёртывания релизов, отвечающий за внедрение релиза в производственную среду и подготовку документации; Практик первичной (early life) поддержки, обеспечивающий поддержку системы в начальный период эксплуатации после релиза. Эти роли сосредоточены на выполнении конкретных работ, а не на координации процесса в целом. Все они работают под управлением менеджера процесса и обеспечивают техническую реализацию отдельных этапов жизненного цикла релиза.

Для учета различного влияния инцидентов на бизнес при расчете метрики времени реакции можно использовать два подхода: первый - выполнять расчет метрики отдельно для каждого уровня влияния или приоритета инцидента, что позволяет проанализировать эффективность реакции на каждый категорий инцидентов; второй - использовать формулу взвешенного среднего, где весом (Wi) выступает уровень влияния или приоритет инцидента: Rw = (Σ(Ti*Wi)) / (Σ((Ti+Qi)*Wi)). Это позволяет получить более точную оценку общей эффективности процесса с учетом бизнес-значимости каждого инцидента.

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