Чтобы преодолеть проблему "последней мили", необходимо отстроить поток создания ценности end-to-end от непрерывного потока требований со стороны бизнеса до быстрой и равномерной поставки решений. Следует уйти от релизных циклов и организовать непрерывную поставку на основе DevOps, объединяя группы разработки и эксплуатации в единую команду. Можно также категоризировать задачи по стоимости задержки и рисков, чтобы определить, какие функции можно доносить непрерывно, не задерживая их до релиза. Кроме того, важно выстроить регулярные циклы обратной связи с бизнесом и установить четкий "финишный флажок", который определяет, когда задача считается выполненной, чтобы избежать ситуации, когда готовые задачи задерживаются на финальных этапах.

Управление проблемами существенно влияет на сокращение времени решения инцидентов, хотя часто его значение недооценивают. Если уменьшить общее количество инцидентов путем выявления и устранения их первопричин, это приведет к снижению нагрузки на персонал поддержки. Даже при одинаковой производительности сотрудников, меньшее количество инцидентов существенно снизит среднее время их решения из-за снижения очереди. Например, при 24 инцидентах в день (при условии их одновременного поступления утром) среднее время решения возрастает до 4 часов 10 минут, а при 12 инцидентах - падает до 2 часов 10 минут. Таким образом, управление проблемами влияет на процесс косвенно, сокращая поток инцидентов, что особенно важно с учетом неравномерного распределения инцидентов в течение дня (пиковой нагрузки в определенные часы).

Процесс Управления инцидентами в ITIL Service Operation включает множество задач, среди которых обеспечение прозрачности процесса является ключевой. В перечне задач процесса явно указано, что необходимо обеспечивать прозрачность деятельности процесса. Также к задачам относится эффективное решение инцидентов в установленные сроки, минимизация негативного воздействия на бизнес, восстановление нормального функционирования услуг в минимально возможные сроки и поддержание согласованных уровней качества услуг. В примерах критических факторов успеха процесса указано: «Улучшать прозрачность и коммуникации в работе процесса», что подтверждает важность коммуникационной составляющей в работе с инцидентами.

Согласование использования статуса 'Ожидание' с заказчиком требует: включения в договор или SLA четкого определения, когда время ожидания не засчитывается в общий срок выполнения; прозрачной системы уведомлений заказчика о переходе задачи в статус 'Ожидание' с указанием причины и предполагаемого срока выхода из статуса; возможности заказчика утверждать или оспаривать основание для перевода в статус 'Ожидание'; предоставления заказчику доступа к отслеживанию задач в этом статусе. Ключевой момент - договоренность о том, какие события позволяют остановить отсчет времени срока выполнения, и как это документально оформляется. Это предотвращает конфликты из-за просрочек, вызванных объективными задержками.

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

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

Владелец услуги (service owner) отвечает за сквозное управление конкретной ИТ-услугой, тогда как менеджер уровня услуг фокусируется на достижении и соблюдении договоренностей об уровне услуги между поставщиком и заказчиком. В ITILv3 есть таблица сравнения этих ролей (Table 6.8 Comparison of CSI manager, service level manager, service owner and business relationship manager roles), но эта таблица скорее порождает вопросы, чем дает четкие ответы о границах ответственности между этими ролями. На практике в большинстве организаций найти достаточно убедительный ответ на вопрос о проведении границы ответственности между этими ролями сложно.

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

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

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