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

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

Для успешного внедрения изменений важно, чтобы: 1) Предоставлялась возможность протестировать новое до окончательного принятия решения (например, через пробные периоды); 2) Сохранялась возможность возврата к прежним практикам; 3) Новые методы были похожи на уже существующие, с минимальными отличиями; 4) Изменения развивались на основе предыдущих проектов, а не начинались с чистого листа; 5) Новые практики соответствовали общему направлению развития организации. Эти условия снижают сопротивление изменениям и делают их более приемлемыми для сотрудников.

Управление доступностью и управление непрерывностью тесно связаны, так как оба процесса ориентированы на обеспечение бесперебойной работы ИТ-услуг. В некоторых стандартах, таких как ISO/IEC 20000, они объединены в один процесс. Это обусловлено тем, что оба процесса направлены на предотвращение сбоев и минимизацию их последствий. Управление доступностью фокусируется на обеспечении требуемого уровня доступности услуг, а управление непрерывностью — на восстановлении услуг после инцидентов, связанных с непредвиденными простоями.

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

На этапе Act цикла Деминга возможны три основных варианта действий: 1) Внедрение успешных улучшений в постоянную практику, если результаты проверки показали положительный эффект; 2) Игнорирование изменений и остановка цикла, если результаты проверки показали, что изменения не привели к улучшению или улучшения незначительны; 3) Запуск нового цикла PDCA с учетом полученного опыта, если результаты посредственные или требуют дальнейших изменений. Этот этап служит точкой принятия решения относительно дальнейшего развития процесса.

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

Конфигурационная единица (CI) — это любой компонент, который необходимо управлять для предоставления услуги. Определение того, что является конфигурационной единицей в рамках предоставляемой услуги, помогает установить границы ответственности. Если CI, например, стиральная машина, включена в соглашение, то её поломка будет считаться инцидентом. Если же она не включена, то это не является нарушением уровня услуги. Таким образом, понятия CI и границы ответственности тесно связаны между собой

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

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