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

Для пересмотра процесса управления конфигурациями следует выполнить следующие шаги: 1) Определить, кто из заинтересованных сторон может получать ценность от информации о конфигурациях. 2) Поговорить с ними о их рабочих процессах и выяснить, какая информация будет для них полезна. 3) Наглядно продемонстрировать, как информация о конфигурациях может быть использована для создания ценности. 4) Пересмотреть политики управления конфигурациями с учётом этой информации. 5) Перепроектировать процесс, чтобы он фокусировался на создании ценности. 6) Убедиться, что CMDB соответствует своей цели. 7) Разработать программу обучения и коммуникации по вариантам использования CMDB. 8) Внедрить мониторинг и отчёты, основанные на реальном использовании системы.

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

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

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

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

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

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

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

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