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

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

eSCM-SP (eSourcing Capability Model for Service Providers) - это сложный подход к построению обобщенных процессных моделей. В тексте отмечается, что этот подход 'слишком сложен' для автора и, вероятно, для многих практиков. Автор видит необходимость в промежуточном уровне между USM и eSCM-SP - что-то ближе к eTOM, но с обобщением на различные виды услуг. eTOM (Enhanced Telecom Operations Map) - это известная отраслевая рамочная модель управления для телекоммуникационных компаний, которую предполагается адаптировать для более широкого применения.

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

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

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

Сравнение показывает, что предполагаемые затраты времени на ведение учета (5-10% рабочего времени) значительно завышены по сравнению с реальными (0,32% за 2014 год). Это доказывает, что распространенные опасения относительно трудоемкости учета времени необоснованны и что введение системы учета не приведет к значительным потерям рабочего времени, как часто предполагают сотрудники и менеджеры.

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

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

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