Для агрегации различных показателей доступности (суммарное время простоев, максимальный разовый простой, количество нарушений) в единую метрику можно применить следующий подход: 1) Нормировать каждый показатель относительно целевого значения или максимально допустимого уровня. 2) Назначить веса каждому показателю в соответствии с их значимостью для конкретного бизнес-процесса. 3) Выполнить взвешенное суммирование нормированных показателей. 4) Преобразовать результат в процентную шкалу или иную удобную для восприятия форму. Например, можно определить, что для данного бизнес-процесса максимальный разовый простой имеет вес 50%, суммарное время простоя - 30%, а количество нарушений - 20%, и рассчитать итоговую метрику на основе этих весов и отклонений от целевых значений.

Итоговый рейтинг руководителя рассчитывается на основе процессных метрик, которые отражают эффективность работы его подчиненных в различных процессах. Все метрики должны быть приведены к сопоставимому виду (шкала от 0 до 1) и иметь одинаковое направление оценки (чем ближе к 1, тем лучше). Формула расчета итогового рейтинга может быть различной в зависимости от предпочтений организации: это может быть простое арифметическое среднее всех метрик, геометрическое среднее, взвешенное среднее (если некоторые метрики важнее других) или среднее по доле от целевых значений. Например, если используются метрики К1 (доля заданий, выполненных в срок), К2 (доля инцидентов, принятых в работу своевременно), К3 (доля инцидентов, решенных в срок и с первой попытки) и К4 (коэффициент обновления по проблемам), то итоговый рейтинг R может быть рассчитан как (К1 + К2 + К3 + К4)/4 (арифметическое среднее) или как произведение метрик в степени веса каждой метрики (взвешенное среднее).

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

SLM (Service Level Management) и каталог услуг выполняют разные функции в ИТ-менеджменте. Каталог услуг фокусируется на определении и структурировании предоставляемых услуг, их ценности для заказчика и необходимых ресурсах. Он может быть построен задолго до организации SLM и используется для формирования нового отношения к ИТ-деятельности и улучшения взаимодействия с бизнесом. SLM же является контрольным механизмом, обеспечивающим оценку качества услуг через сравнение результатов с обязательствами. SLM представляет собой более продвинутую стадию развития, следующую за созданием каталога услуг.

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

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

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

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

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

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