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

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

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

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

CMDB (Configuration Management Database) играет ключевую роль в оценке влияния major-инцидента на ИТ-услуги. С её помощью можно определить, каким пользователям и сервисам оказывается воздействие и насколько оно критично, что позволяет целенаправленно информировать затронутые группы и правильно оценивать последствия инцидента. Данные CMDB помогают установить причинно-следственные связи между компонентами ИТ-инфраструктуры и конечными сервисами, обеспечивая более точное управление инцидентом и снижение времени реагирования.

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

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

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

Концепция сценария риска в COBIT 5 for Risk включает пять основных компонентов: источник угрозы (внутренний или внешний), тип угрозы (злоумышленные действия, ошибки, природные катастрофизмы и т.д.), событие (раскрытие информации, модификация, кража, уничтожение и т.д.), связанные активы (люди, оргструктуры, процессы, ИТ-инфраструктура и т.д.) и временной аспект, учитывающий прогнозируемую длительность негативного влияния и критичность события в зависимости от календарного периода или времени суток. COBIT 5 for Risk также предоставляет более ста различных сценариев рисков, разделенных на 20 категорий, от управления ИТ-инвестициями до рисков, связанных с поставщиками и атаками, с рекомендациями по снижению рисков, сгруппированными по семи факторам влияния.

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