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

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

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

Проектируемый простой услуг (Projected Service Outage, PSO) - это документ, в котором фиксируются все запланированные периоды недоступности услуг, необходимые для реализации изменений. За формирование и актуализацию этого документа в первую очередь отвечает процесс управления изменениями. Однако при согласовании поправок в графике плановых простоев также участвуют процессы управления уровнем услуг (Service Level Management, SLM) и управления доступностью (Availability Management), обеспечивая комплексный подход к планированию и минимизации влияния простоев на бизнес.

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

Из концепции уровней зрелости в COBIT можно сделать следующие практические выводы: во-первых, уровень зрелости процесса следует рассматривать только как иллюстративный инструмент для визуализации текущего состояния или разницы между текущим и целевым состояниями процесса; во-вторых, нецелесообразно ставить в качестве цели проекта достижение конкретного уровня зрелости, аналогично тому, как бесполезно формулировать задачу как «купить продуктов на N рублей» без указания конкретных продуктов; в-третьих, при оценке процессов необходимо фокусироваться на конкретных контролирующих мероприятиях, а не на абстрактных уровнях зрелости.

Автоматизация в управлении изменениями может быть реализована через интеграцию с конвейерами непрерывной интеграции и доставки (CI/CD). Если организация использует CI/CD, модель изменения должна учитывать эти процессы, чтобы автоматизировать этапы тестирования, развертывания и мониторинга. Это позволяет сократить время внедрения и повысить качество изменений за счёт предсказуемости и отсутствия ручных ошибок. Автоматизация особенно эффективна для регулярных, структурированных изменений.

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

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

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