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

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

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

Да, геометрическое среднее легко обобщается на произвольное количество tension-метрик. Для N метрик K = N√(K1 × K2 × ... × KN). Однако на практике случаи с тремя и более tension-метриками встречаются редко, так как сложность балансировки между большим количеством конфликтующих показателей затрудняет управление и анализ. Обычно ограничиваются парой ключевых метрик, которые наиболее точно отражают критические аспекты процесса.

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

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

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

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

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

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