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

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

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

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

Outcome зависит от субъективного восприятия потребителя и часто выражается в нематериальных или долгосрочных эффектах, которые сложно зафиксировать количественно. В то время как Output обычно имеет чёткие количественные параметры (например, сроки доставки, объём функционала), что позволяет легко его измерять и отчитываться о нём. Для оценки Outcome необходимо собирать обратную связь, проводить опросы удовлетворённости или анализировать поведение клиентов.

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

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

Каталоги услуг в некоторых ИТ-службах строятся на основе сущности «доступ к ресурсам». В таких каталогах услуга определяется как информационная система (программно-аппаратный комплекс), и описываются правила предоставления доступа к этой системе. Например, для учетной системы может быть указано, что доступ к ней гарантируется с определенного времени до определенного времени. При таком подходе поставщик услуг фокусируется только на предоставлении доступа к ресурсу, а то, как потребитель будет использовать этот ресурс, уже не является заботой поставщика. Это упрощает описание услуг и управление ими, особенно когда поставщик не обладает информацией о деталях деятельности потребителя или не желает в нее вникать.

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

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