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

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

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

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

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

Три основных принципа, помогающие интегрировать деятельность по развитию в повседневную работу компании: 1) Деятельность по развитию должна быть обязательной и «встроенной» в обычную ежедневную работу почти каждого сотрудника, поскольку возможности для улучшений появляются каждый день. 2) Время на развитие должно быть чётко определено и выделено явным образом, как часть работы. 3) Необходимо не позволять сотрудникам заменять выделенное время на развитие операционными задачами, поскольку рутина стремится занять всё доступное время.

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

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

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

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