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

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

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

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

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

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

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

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

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

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