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

DAC-модель менее эффективна для крупных систем из-за следующих причин: 1) Масштабируемость — в DAC разрешения настраиваются для каждого пользователя и объекта вручную (через таблицы доступа), что приводит к экспоненциальному росту сложности при увеличении пользователей и ресурсов. Например, для 100 пользователей и 1000 объектов потребуется управлять 100 000 записей. 2) Высокий риск ошибок — при изменении прав для группы сотрудников администратор должен править каждую запись отдельно, что увеличивает вероятность пропуска. 3) Несогласованность — отсутствие структурирования по бизнес-функциям делает модель неинтуитивной. В RBAC те же права группируются в роли (например, 'Бухгалтер'), что сокращает необходимость ручных настроек в сотни раз.

Метрика помогает предотвратить практику «футбола» за счёт того, что учитывает реальное время, затраченное группой на обработку инцидента, включая время с момента назначения до переназначения. Если группа быстро перенаправляет инцидент без реального анализа и работы, её доля во времени обработки (ti) будет небольшой. Однако, если инцидент в итоге просрочен, суммарная ответственность всех групп пропорциональна их реальному вкладу во время обработки. Кроме того, для предотвращения практики «футбола» рекомендуется использовать не только метрику своевременности, но и дополнительную метрику результативности, которая оценивает, насколько группа реально продвигает решение инцидента при работе с ним.

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

При следовании принципу 'Упрощать' следует отбрасывать все лишнее, что не вносит вклад в создание ценности. Ключевой вопрос определения границ упрощения связан с пониманием, участвует ли элемент (процесс, вид деятельности, документ, метрика, отчет) в формировании ценности. Если нет, то его следует удалить. Следует упрощать до тех пор, пока это возможно, но не более того, чтобы не потерять необходимую сложность, которая важна для предоставления ценности.

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

Компании, придерживающиеся стратегии выживания, выделяют на 'развитие и управление ИТ' 4-8% от общего размера ИТ-бюджета. Это значительно выше, чем в других стратегических группах.

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

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

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