Практика ведения каталога технических услуг и OLA не применима ко всем компаниям, потому что сервисный подход вообще реализован лишь в небольшом количестве организаций, и только к очень небольшой доле этих организаций применима именно практика ведения каталога технических услуг и OLA. Это связано с тем, что такие документы и практики значительно влияют на другие процессы, отношения между подразделениями и оргструктуру, и их введение может быть избыточным или неоправданным в компаниях с простой структурой или без четкого сервисного подхода. О необходимости быть осторожнее с внедрением таких практик уже писали Pink Elephant (около 2006 года) и IT Skeptic (около 2011 года).

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

Результаты 67% (зеленый вариант) и 56% (красный вариант) при одинаковом KPI своевременности 95% демонстрируют, что первый сценарий предполагает значительно более быстрое устранение инцидентов. Хотя в обоих случаях 5% инцидентов просрочены, в зеленом варианте большая часть решена вблизи Tmin (30 минут), в то время как в красном — ближе к Tmax (4 часа). Это показывает, что новый метод оценки более точно отражает реальный уровень сервиса и оперативность команды.

Предложенная метрика имеет несколько ключевых преимуществ: 1) Справедливо распределяет ответственность за нарушение сроков между всеми участвующими группами, а не возлагает её на одну 'последнюю' группу. 2) Создает правильные мотивации, стимулируя группы обрабатывать инциденты даже при получении их близко к окончанию срока. 3) Является чувствительной к реальному участию группы в решении инцидента, а не только к её месту в цепочке обработки. 4) Обеспечивает естественное масштабирование от уровня отдельной группы до уровня всего процесса управления инцидентами. 5) Легко адаптируется для учёта степени превышения срока. 6) Помогает избежать негативных практик, таких как 'футбол' инцидентов между группами.

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

В обязанности владельца услуги при управлении жизненным циклом услуги входит: контроль соответствия уровня предоставления и поддержки услуги согласованным параметрам; трансляция требований бизнеса в понятные ИТ-задачи; обеспечение прозрачных коммуникаций с заказчиком по запросам и инцидентам; помощь в разработке модели услуги при работе с процессом управления портфелем услуг; оценка влияния изменений на услугу; обеспечение актуальности сведений об услуге в каталоге услуг; представление услуги в рамках всей организации и на CAB-ах; мониторинг и отчётность по услуге; участие в обсуждении SLA/OLA применительно к его зоне ответственности. Владелец услуги несёт ответственность за услугу на протяжении всего её жизненного цикла, независимо от географического расположения её компонентов и обслуживающего персонала.

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

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

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

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