Процессы EDM01 и EDM05 вызывают вопросы, так как следуют той же структуре практик (оценка, направление, мониторинг), что и процессы руководства системы управления ИТ (EDM02–EDM04), в то время как согласно принципу COBIT 5, эти процессы должны описывать управление системой руководства. Если EDM01 и EDM05 — процессы управления, то их структура должна быть больше похожа на управленческий цикл PDCA. Если же они относятся к руководству, тогда возникает вопрос: кем и на каком уровне осуществляется руководство над самой системой руководства, что представляется избыточным и противоречащим логике разделения функций руководства и управления.

Наличие дефектов негативно влияет как на бизнес, так и на процесс разработки. Со временем дефекты приводят к экспоненциальному росту потерь - в примере из деловой игры 'Проект Феникс' потери составили 2 000 долларов в первом раунде, 26 000 во втором и 39 000 в третьем. Наличие дефектов замедляет разработку новых функций, так как разработчики вынуждены тратить время на исправление ошибок, и создает технический долг, который становится все дороже в исправлении. Для бизнеса это трансформируется в прямые финансовые потери и ухудшение качества продукта, что отражается на удовлетворенности клиентов.

Следует использовать аналогию с безопасностью: если в компании 99% сотрудников носят каски на производстве, а 1% — нет, средний показатель «носят каски» будет 99%, но это 1% может привести к смертельному случаю. Аналогично, даже один проваленный SLA может вызвать остановку бизнеса. Минимальное значение — это «индикатор худшего сценария», который позволяет избежать неприятных сюрпризов. Такой подход повышает доверие руководства, так как демонстрирует прозрачность и внимание к рискам.

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

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

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

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

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

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

CMDB (Configuration Management Database) используется для хранения информации о компонентах инфраструктуры и их связях. Для прогнозирования влияния инфраструктурных инцидентов на ИТ-услуги требуется максимально детальное описание этих связей. Однако на практике это сложно реализовать, так как связи могут быть сложными, динамичными и требуют постоянного обновления. Неполная или неточная информация в CMDB снижает эффективность прогнозов и увеличивает риск ошибок в диагностике.