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

CAB (Change Advisory Board) - это комитет по изменениям, ответственный за информирование и governance в части проведения масштабных, сложных и многосвязных изменений в гетерогенной, территориально распределенной инфраструктуре. Основная функция CAB заключается в управлении и надзоре над выполнением изменений и проектов там, где в регулярных работах участвуют множество подрядчиков и развит аутсорсинг. В компаниях с использованием ресурсов различных юридических лиц, например, в рамках холдингов, CAB помогает обеспечить стабильность в сложном окружении через планирование, контроль и оценку изменений.

Менеджер ИТ-процесса должен действовать по следующему алгоритму: 1. Идентифицировать и локализовать проблему, определив конкретные факторы, негативно влияющие на процесс 2. Подготовить одну или несколько мер, направленных на устранение проблемы или минимизацию ущерба 3. Найти и обеспечить выделение ресурсов для осуществления плана 4. Проконтролировать реализацию мер и убедиться в их эффективности, при необходимости вернувшись к первому шагу Важно, что на первом этапе необходимо определить, какие изменения произошли в последнее время, проанализировать характер и структуру проблемных обращений, идентифицировать критические точки в процессе. Второй этап включает разработку как временных, так и постоянных решений. Третий этап требует защиты плана и убеждения заинтересованных сторон в необходимости выделения ресурсов. Четвертый этап предполагает постоянный мониторинг и измерение эффективности внедренных мер.

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

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

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

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

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

Ценности «полезности» (основная разработка) и «гарантии» не суммируются, а перемножаются. То есть, даже при высокой ценности «полезности» (эффективное развитие продукта), если «гарантия» (стабильность, доступность) близка к нулю, общий результат будет нулевым. Например, идеальный продукт, который постоянно падает, не приносит ценности пользователям. Таким образом, обе составляющие должны поддерживаться равномерно.

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