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

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

Для правильной организации процесса по определению требований к системе мониторинга необходимо: начинать анализ с уровня ИТ-сервиса, а не с отдельных ресурсов; определять критические ресурсы и их параметры, которые влияют на качество предоставления услуг; устанавливать пороговые значения для этих параметров; разрабатывать требования на основе потребностей бизнеса и конечных пользователей; предусмотреть не только реакцию на возникновение событий, но и на их отсутствие, когда это критично для работы системы.

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

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

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

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

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

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

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