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-инцидентом, следует назначать в группы, ответственные за поддержку соответствующих ИТ-услуг, а не в группу, непосредственно устраняющую инцидент. Такой подход позволяет снизить вероятность ошибок при установлении связей с основным инцидентом, дает возможность решать некоторые обращения через временные обходные решения без ожидания полного устранения инцидента, а также обеспечивает корректную проверку восстановления ИТ-услуг после окончания работы над инцидентом.

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

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

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

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