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

В методологии COBIT 5 for Risk влияние риска оценивается по трем составляющим: получение ценности от ИТ (IT Benefit/Value Enablement), исполнение ИТ программ и проектов (IT Programme and Project Delivery) и эксплуатация и предоставление ИТ-услуг (IT Operations and Service Delivery). Для каждого конкретного сценария риска приводится детальное описание того, как негативное событие может повлиять на эти три ключевые области. Такая структурированная оценка позволяет организациям лучше понимать последствия рисков и разрабатывать целевые стратегии их снижения.

Для интеграции данных необходимо создать единую платформу (например, CDP — Customer Data Platform), которая собирает информацию из всех каналов: CRM, веб-аналитики, соцсетей, оффлайн-продаж. Важно устранить «информационные барьеры» между отделами, внедрив процессы обмена данными по стандартам и с использованием API. Также нужно использовать инструменты для обогащения данных (например, геолокация или данные о поведении) и применять машинное обучение для выявления паттернов. Ключевой принцип — данные должны быть доступны в реальном времени, чтобы персонализировать взаимодействие мгновенно.

На уровне отдельного приложения роли определяются как наборы прав на конкретные объекты и операции (системные роли, например, 'Редактор контента'). Для масштабирования до предприятия: 1) Системные роли группируются в бизнес-роли, отражающие функции сотрудников (например, 'HR-специалист' включает роли в ATS, HRM и системе обучения). 2) Вводится иерархия бизнес-ролей по подразделениям (например, 'HR-специалист' может быть 'Рекрутером' или 'Тренером'). 3) Устанавливаются связи между бизнес-ролями и организационной структурой (каждое подразделение имеет свой набор ролей). На предприятии управление сводится к назначению бизнес-ролей пользователям, а системные роли обновляются автоматически при изменениях в приложениях.

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

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

В ITIL V3 ответственность за координацию изменений формально не закреплена за конкретной ролью. Вместо этого упоминается, что координация является частью процесса управления изменениями в целом и может быть возложена на различные лица в зависимости от ситуации. Это могут быть менеджер процесса, практик изменений или участники CAB (Change Advisory Board). Например, в главе 4.2.5 описываются активности по координации, но не уточняется, кто именно их выполняет. Таким образом, ITIL предоставляет гибкость в распределении ответственности, ориентируясь на особенности организации, но это может привести к неоднозначности при внедрении процесса.

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

Для непосредственной оценки удовлетворенности заказчика ИТ-услугами могут быть использованы вопросы, направленные на оценку ключевых аспектов услуги. Примерами таких вопросов могут служить: степень удовлетворенности достигаемой utility услуг, степень удовлетворенности достигаемой warranty услуг, степень соответствия показателей warranty реальным потребностям заказчика. Ответы на эти вопросы оцениваются по шкале от 0 до 1, где 0 означает полное несоответствие, а 1 – полное соответствие ожиданиям.

Характерными признаками процесса управления релизами в подразделении разработки/сопровождения являются: обработка только нестандартных запросов на изменения, самостоятельная авторизация изменений на CAB'е (без участия процесса управления изменениями), работа только с изменениями в приложениях (изменения в инфраструктуре обрабатывает процесс управления изменениями), и определение релиза как набора компонент, которые вместе тестируются и внедряются в продуктив. Такой подход соответствует описанию в BMC Service Management Process Model (SMPM).