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

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

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

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

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

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

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

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

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

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