Процесс состоит из трёх основных видов деятельности: создание статей для наполнения Базы знаний; проверка статей на актуальность, применимость и корректность; публикация и архивация статей (ввод и вывод из эксплуатации). Дополнительно существует механизм регулярного пересмотра статей по истечении срока жизни (TTL) и триггеры создания новых статей при определённых событиях.

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

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

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

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

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

Для расчета интегрального показателя одной услуги с множеством KPI рекомендуется сначала разделить все показатели на смысловые группы, например: производительность, доступность и поддержка. Для каждой группы рассчитывают индивидуальный интегральный показатель, возможно, используя разные методы агрегирования в зависимости от природы показателей. Например, для показателей доступности, где критично важно поддерживать высокий уровень по всем метрикам, может применяться среднее геометрическое, а для показателей поддержки — среднее арифметическое. После этого полученные групповые показатели объединяют в общий интегральный показатель услуги, используя подходящий метод агрегирования, например, взвешенное среднее.

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

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

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