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

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

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

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

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

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

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

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

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

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