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

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

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

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

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

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

Согласно Good Practice Guidelines 2013 (GPG), процесс управления бизнес-непрерывностью включает шесть основных этапов: анализ организации, определение стратегии обеспечения непрерывности, разработка и внедрение планов обеспечения непрерывности, испытание и оценка планов, менеджмент программы управления непрерывностью бизнеса, внедрение управления непрерывностью бизнеса в организационную структуру. На каждом этапе даются подробные практические рекомендации.

Согласно ITIL 4, SLA (Service Level Agreement) — это документированное соглашение между поставщиком и заказчиком, которое определяет требования к услуге и ожидаемый уровень предоставления этой услуги. SLA фиксирует договоренности между двумя субъектами сервисных отношений, где заказчик должен определить свои требования и ожидания относительно потребляемой услуги, а также требования других стейкхолдеров, таких как регуляторы.

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

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