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

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

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

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

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

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

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

COBIT5 for Risk (ранее известный как Risk IT) предлагает строгий, структурированный подход к описанию и управлению рисками. Его отличительной особенностью является учет дополнительных параметров при оценке рисков, таких как прогнозируемая длительность негативного влияния, критичность события относительно календарного периода или времени суток. Документ содержит множество практических примеров, размещенных в виде плашек на полях, и включает сотни примеров рисков, классифицированных по 20 категориям – от управления ИТ-инвестициями и проектами до рисков, связанных с поставщиками, вредоносным ПО, атаками и регуляторами. Для каждого риска указаны соответствующие контрмеры.

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

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