Геометрическое среднее решает проблему компенсации плохого показателя одной метрики высоким значением другой. Например, если оператор быстро перенаправляет все запросы (высокая своевременность K1), но не обеспечивает решения (низкая результативность K2), арифметическое среднее даст завышенную оценку эффективности. Геометрическое среднее в этом случае покажет 0%, так как K2=0%, что честно отражает отсутствие баланса. Таким образом, метод стимулирует сохранение баланса между скоростью обработки и качеством решения инцидентов.

Распределение ролей включает назначение ответственного за управление лицензиями («главного пастуха»), который будет контролировать процесс и принимать ключевые решения. Также определяются функции для технических специалистов (например, инженеров), которые могут вносить данные о новых установках ПО или освобождённых лицензиях. Важно заранее согласовать, какие действия будут автоматизированы, а какие потребуют ручного ввода, чтобы избежать дублирования задач или пробелов в учёте.

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

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

В Service Management Output рассматривается как конечный результат процессов предоставления услуг, тогда как Outcome определяет ценность услуги с точки зрения потребителя. Service Management стремится к созданию и поддержанию услуг, которые не просто технически корректны, но и приносят реальную пользу клиентам. Это означает, что при разработке услуг необходимо учитывать, как output влияет на достижение целевого outcome.

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

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

В опросах по пятибалльной шкале стандартное отклонение обычно ограничено пределами от 0.5 до 1.2, а максимальное теоретическое значение не превышает примерно 1.5 (так как ответы обычно укладываются в диапазон от 2 до 5 баллов). Стандартное отклонение напрямую влияет на ширину доверительного интервала - чем больше стандартное отклонение, тем шире доверительный интервал при прочих равных условиях. Поэтому для опросов с большим разбросом оценок требуется либо увеличение размера выборки, либо принятие к сведению большей погрешности результатов.

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

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