Для нормирования задач сопровождения CMDB можно использовать несколько методов. Первый метод - ведение полного или выборочного учета трудозатрат («списание часов»), что позволяет накапливать статистику и на ее основе устанавливать нормативы для аналогичных задач в будущем. Второй метод - консолидация внешней статистики с портала REALITSM.RU, где можно найти данные и наработки других организаций по оценке трудозатрат. Третий метод - детальная разбивка задач по группам конфигурационных единиц (ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений, инфраструктура) и ролям специалистов с учетом различной стоимости рабочего времени и требований к компетенциям. Четвертый метод - разработка внутренних стандартов и нормативов для каждой из задач сопровождения CMDB (первичная регистрация, обновление статусов, аудит, инвентаризация и т.д.) на основе оценки их сложности и требуемых ресурсов. Пятый метод - регулярный пересмотр и корректировка нормативов на основе анализа фактических трудозатрат и изменений в процессах работы с CMDB.

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

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

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

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

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

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

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

В области IT разница между товаром и услугой часто более очевидна благодаря распространенной модели 'as-a-Service'. Когда речь идет о программном обеспечении, клиенты интуитивно понимают разницу между покупкой лицензии (товар) и использованием SaaS-решения (услуга). В случае покупки лицензии клиент получает программный продукт и сам несет все риски и затраты по его установке, обновлению и поддержке. При использовании SaaS клиент получает доступ к функциональности без необходимости заботиться об инфраструктуре - эти риски и затраты берет на себя поставщик. Эта модель хорошо структурирована и часто приводится в примерах, что делает концепцию более наглядной для ИТ-специалистов, чем в других сферах, где границы между товаром и услугой могут быть менее четкими.

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