Стереотипы (Юг) в модели Compass Model отражают предвзятость и установки клиента, сформированные на основе его прошлого опыта. Эти ожидания могут быть как положительными, так и отрицательными, но чаще всего они влияют на первоначальное восприятие услуги. Например, стереотип о таксистах тарифа "Эконом": неправильная подача автомобиля, резкое вождение и навязчивое поведение. Чтобы учитывать стереотипы при предоставлении услуг, необходимо: 1) выявить существующие негативные установки клиентов в вашей отрасли; 2) разработать стратегию, направленную на то, чтобы нарушать эти негативные стереотипы; 3) демонстрировать клиенту, что ваша услуга не соответствует негативным установкам. Это помогает изменить восприятие и создать позитивное впечатление.

В качестве альтернативы подходу ITIL предлагаются три подпроцесса: Business Capacity Management (управление бизнес-мощностями), System Capacity Management (управление системной мощностью) и Resource Capacity Management (управление ресурсной мощностью). Это деление более точно отражает уровни, на которых происходит управление мощностями, в зависимости от того, как определены ИТ-услуги (через бизнес-процессы, ИТ-системы или ресурсы).

Конфигурационная единица — это любой компонент, которым необходимо управлять для предоставления ИТ-услуги. Инцидент может быть связан с конфигурационной единицей, если ее сбой влияет на нормальную работу услуги или если этот сбой выходит за рамки определенной нормы работы. Однако не все сбои конфигурационных единиц являются инцидентами. Например, в случае с RAID-массивом, если система спроектирована так, что выход одного диска не влияет на работу массива, такой сбой не будет инцидентом. Важно понимать, какие компоненты включены в управление конфигурацией и как они влияют на конечную услугу.

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

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

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

Приоритет проблемы может изменяться в течение времени, если к ней привязываются новые инциденты. Факт привязки новых инцидентов увеличивает суммарный вес проблемы, что может повысить её приоритет. Это требует постоянного пересмотра приоритетов проблем в ходе их расследования и устранения.

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

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

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