Заказчик - это лицо или группа лиц, которые покупают товары или услуги. В контексте поставщика ИТ-услуг заказчик определяет и согласовывает целевые показатели SLA (Service Level Agreements). Хотя иногда термин 'заказчик' может использоваться неформально для обозначения конечных пользователей (users), в официальной терминологии ITIL эти понятия четко разграничены. Заказчик также может быть внутренним (подразделение в компании) или внешним (клиент компании).

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

Процесс Управления инцидентами способствует повышению удовлетворенности пользователей через обеспечение не только эффективного решения инцидентов, но и через работу над уровнем прозрачности. Пользователи остаются довольны, когда получают нужную информацию о статусе инцидента в согласованные моменты времени и в удобном для них формате. Это снижает их беспокойство и исключает необходимость многократных запросов о статусе. Организация прозрачной коммуникации, использование подходящих каналов информирования (e-mail, SMS, портал самообслуживания и др.) и минимизация количества повторных обращений по тем же инцидентам напрямую влияют на ощущение качества обслуживания и удовлетворенность пользователей.

Необходимость в CI/CD может быть не столь очевидной для команды, которая разрабатывает программное обеспечение для будущего релиза, MVP или первой версии, который запланирован на значительный срок вперед (например, через полгода-год). В таких случаях основная проблема заключается не в организации процесса доставки изменений, а в самом создании работоспособного продукта. До тех пор, пока нет боевой среды с реальными живыми пользователями, внедрение сложного конвейера развёртывания может оказаться преждевременным и отвлекающим от основных задач разработки. В этой ситуации ресурсы команды лучше направить на создание качественного продукта, а вопросы автоматизации процессов доставки и развертывания можно решать уже тогда, когда будет определенность с пользовательской аудиторией и необходимостью частых обновлений.

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

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

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

Warranty (Гарантия) — это одна из двух основных характеристик услуги в управлении услугами по ITIL. Warranty отвечает на вопрос fit for use - пригодность услуги к использованию, то есть насколько она находится в том состоянии, чтобы пользователь мог ею пользоваться. Warranty характеризуется четырьмя компонентами: доступность (Availabitity), мощность (Capacity), безопасность (Security) и непрерывность (Continuity). Warranty не означает просто гарантийный период в обычном понимании, а определяет, насколько услуга может быть использована потребителями без перебоев и проблем, что позволяет услуге обеспечивать ценность для пользователя.

Руководящие принципы ITIL тесно связаны с практикой постоянного совершенствования, так как они призваны поддерживать постоянное улучшение на всех уровнях организации. Принципы, такие как "Действуйте итерационно, используя обратную связь" и "Оптимизируйте и автоматизируйте", непосредственно способствуют постоянному совершенствованию процессов и услуг. Система принципов ITIL помогает организациям определять направления для улучшения, оценивать текущее состояние и принимать обоснованные решения по внесению изменений. В частности, ITIL 4 включает в себя обновленную модель постоянного совершенствования, которая использует эти руководящие принципы как основу для планирования и реализации улучшений, что позволяет организациям гибко реагировать на внутренние и внешние изменения и непрерывно повышать качество предоставляемых услуг.

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