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

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

В ITIL V3 ответственность за координацию изменений формально не закреплена за конкретной ролью. Вместо этого упоминается, что координация является частью процесса управления изменениями в целом и может быть возложена на различные лица в зависимости от ситуации. Это могут быть менеджер процесса, практик изменений или участники CAB (Change Advisory Board). Например, в главе 4.2.5 описываются активности по координации, но не уточняется, кто именно их выполняет. Таким образом, ITIL предоставляет гибкость в распределении ответственности, ориентируясь на особенности организации, но это может привести к неоднозначности при внедрении процесса.

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

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

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

Использование расширенного жизненного цикла инцидента позволяет детально анализировать, на какие этапы уходит время при устранении инцидента. Например, если известно, что инцидент длился 1 час, но непосредственные работы заняли всего 5 минут, становится ясно, что 55 минут ушли на другие этапы — обнаружение, диагностику или восстановление. Это даёт возможность целенаправленно улучшать процессы в этих областях, сокращая общий простой и повышая качество обслуживания.

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

Автоматизация проверки CMDB включает использование сканеров обнаружения CI (например, ServiceNow Discovery, Lansweeper), интеграцию с системами мониторинга (Zabbix, Nagios) для сравнения реальных показателей с записями CMDB, и настройку триггеров на аномальные изменения (например, массовое обновление атрибутов за короткий срок). Для статических данных применяются скрипты сравнения с источниками доверенных данных (активы в финансовой системе). Ключевой элемент — регулярные сверки через API между CMDB и системами управления изменениями, чтобы отслеживать соответствие внесенных изменений утвержденным запросам.

Да, целевые показатели доступности могут быть временно скорректированы на период внедрения безотлагательных изменений. Это возможно при условии, что необходимость такой корректировки действительно обоснована и все заинтересованные стороны согласны с её проведением. Процесс управления уровнем услуг (Service Level Management) отвечает за обсуждение и согласование таких изменений в целевых показателях с заказчиком, обеспечивая прозрачность и управляемость процесса. Важно, чтобы такие временные корректировки не становились регулярной практикой и не снижали в долгосрочной перспективе общее качество предоставляемых услуг.