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

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

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

Участники игры Grab@Pizza выносят несколько ключевых уроков: понимание важности эффективного взаимодействия между бизнесом и ИТ; осознание того, что ИТ-инициативы требуют серьёзного обоснования бизнес-ценностью; необходимость активного позиционирования технической поддержки в процессах коммуникации; использование финансов как общей системы координат для бизнеса и ИТ; понимание того, что успех компании зависит от правильной выстроенности связки Business-SLM-Change. Также участники получают представление о процессах ITSM и учатся на практике применять эти знания в реальных условиях.

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

"Fit for use" - это термин, который описывает характеристику Warranty (Гарантия) услуги. Он означает, насколько услуга находится в том состоянии, чтобы пользователь мог ею пользоваться без проблем. "Fit for use" определяется четырьмя компонентами: доступность (может ли пользователь получить услугу, когда это необходимо), мощность (достаточно ли ресурсов для удовлетворения запросов), безопасность (защищена ли услуга от несанкционированного доступа) и непрерывность (насколько услуга устойчива к перебоям). Например, если свет в комнате мигает, то при его высокой полезности (способности помочь читать в темноте) он имеет низкую пригодность к использованию из-за нестабильности работы.

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

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

Удовлетворенность пользователей важна в системе оценки работы ИТ-подразделения, потому что ИТ существует для обслуживания бизнеса и предоставления качественных услуг конечным пользователям. Хотя некоторые считают опросы удовлетворенности субъективными и ненадежными (мнение может зависеть от настроения пользователя), на практике это один из самых важных факторов оценки эффективности ИТ. Если пользователи недовольны, это напрямую влияет на продуктивность бизнеса. Большинство ИТ-процессов направлены на обеспечение стабильности, скорости, качества и удобства предоставления услуг конечным пользователям. Поэтому игнорирование этого аспекта при построении системы KPI может привести к измерению технических показателей, которые не имеют реальной ценности для бизнеса. Оценивать работу ИТ только через объективные технические метрики (например, данные из Service Desk) без учета мнения пользователей — значит упускать ключевой аспект успешности ИТ-услуг, который в конечном счете определяет их ценность для организации.

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