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

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

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

В тексте выделяются три основные траектории развития отношений между агентом изменений и компанией: 1) Отставание специалиста от скорости изменений компании ("Падшая звезда") - когда специалист не справляется с масштабами и сложностью изменений; 2) Примерно параллельное движение ("Боевой товарищ") - когда агент изменений успешно адаптируется и встроивается в процессы компании; 3) Отрыв специалиста куда-то в светлые дали ("Заряженная пружина") - когда потенциал и возможности агента изменений выше, чем текущие задачи компании.

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

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

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

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

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

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