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

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

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

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

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

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

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

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

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

Книга рекомендует даже в ситуациях, когда ИТ-подразделение находится внутри компании, рассчитывать стоимость услуг и управлять ИТ-подразделением почти как бизнесом (more like a business), даже если фактических взаиморасчетов с бизнес-подразделениями нет. Это позволяет ИТ-руководству более четко обосновывать затраты, выстраивать сервисные отношения с бизнесом, определять приоритеты развития и доказывать ценность ИТ для компании. Учет стоимости услуг помогает в принятии решений о развитии или закрытии тех или иных сервисов и делает ИТ-менеджмент более прозрачным и понятным для бизнес-руководства.