Критичность отклонения оценивается через влияние сбоя на бизнес-процессы. Например, недоступность CRM-системы на час может привести к потере 100 заявок, а простой внутреннего почтового сервера — только к временному неудобству. Рекомендуется создать матрицу, где каждая услуга оценивается по шкале: 1) финансовые потери в час простоя, 2) число затронутых сотрудников, 3) регуляторные риски. Услуги с высокой оценкой по этим параметрам должны получать больший вес в обобщённом отчёте.

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

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

На семинарах будут обсуждаться вопросы измерения и оценки работы ИТ-служб, включая типовое решение, описанное в книге «ITSM. Руководство по измерению». Также будут рассмотрены особенности внедрения системы измерений, выбор ключевых метрик, формализация целей и критериев оценки, а также практические примеры применения подходов для повышения эффективности управления ИТ-службами.

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

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

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

Граница ответственности — это четко определенная линия, которая разграничивает обязанности между поставщиком услуги и её потребителем. Эта граница определяет, какие элементы включены в предоставляемую услугу и за какие аспекты отвечает поставщик, а за какие — потребитель. Например, если речь идет об услуге печати в организации, граница ответственности может включать в себя не только физические принтеры и МФУ, но и инфраструктуру, такую как принт-серверы и системы мониторинга

В контексте оценки качества ИТ-услуг термин 'utility' (полезность) относится к функциональной пригодности услуги для удовлетворения потребностей заказчика, то есть предоставлению необходимых функций и возможностей. Термин 'warranty' (гарантия) касается надежности, доступности, безопасности и других аспектов, обеспечивающих качество выполнения услуги. Таким образом, utility отвечает на вопрос 'делает ли услуга то, что нужно?', а warranty – 'делает ли она это стабильно и безопасно?'

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