Путешествие заказчика в контексте ITIL - это последовательность шагов и взаимодействий, которые проходит потребитель услуги при взаимодействии с провайдером. Оно состоит из этапов, таких как Offer, Agree, Co-create и другие. В рамках этого путешествия потребитель взаимодействует с провайдером на различных уровнях и может запускать определенные потоки создания ценности. Путешествие заказчика помогает понять точки контакта с потребителем и те аспекты его взаимодействия с услугой, которые формируют общий пользовательский и клиентский опыт (CX/UX).

Для эффективного CI/CD необходим переход от редких релизов к частым, возможно, даже непрерывным выпускам. Многие команды традиционно приучены выпускать обновления раз в месяц, квартал или 'как получится', что не совместимо с принципами непрерывной интеграции и доставки. Нужно изменить не только внутренние процессы, но и ожидания заказчиков, которые привыкли к такому режиму обновлений. Это требует пересмотра подхода к планированию и разбивке задач на более мелкие, которые могут быть доставлены независимо. Также необходимо создать инфраструктуру, поддерживающую частые релизы, включая автоматизированное тестирование, что позволяет быстро выявлять и исправлять ошибки. Важно отметить, что переход к частым релизам не возможен без изменения культуры работы команды и установления четких критериев готовности для каждого изменения.

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

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

Основное преимущество метода ORBIT заключается в том, что он меняет подход к планированию ITSM-проектов с фокуса на процессах на фокус на результатах. Традиционный подход часто заключается в формулировании целей как «внедрение процесса такого-то», что не дает четкого понимания реальной ценности для бизнеса. ORBIT же заставляет четко определить конкретные результаты, их ценность для бизнеса и ИТ-департамента, а также возможные риски. Это позволяет избежать ситуации, когда проект «живет своей жизнью» отдельно от бизнес-целей и делает результаты проекта измеримыми и понятными всем заинтересованным сторонам.

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

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

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

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

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