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

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

Важно, чтобы инцидент возвращался именно той группе, которая предоставила решение, потому что только эта группа может исправить свои собственные ошибки и доработать инцидент корректно. Если же инцидент возвращается на обработку другой группе (например, Service Desk), то теряется ответственность за качество решения, и создается риск некачественной доработки, так как вторая группа может не обладать полным пониманием проблемы. Это также искажает метрику результативности, делая её менее точной.

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

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

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

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

Стандартное восприятие SLM (Service Level Management) как процесса, который ограничивается подготовкой и актуализацией каталога услуг, SLA и OLA, имеет довольно ограниченное применение. Фактически, создание и поддержка этих документов составляет не более половины содержания SLM как процесса. При этом практика ведения каталога технических услуг и OLA применима лишь к очень небольшой доле компаний, где реализован сервисный подход, а каталог бизнес-услуг с различными уровнями обслуживания востребован преимущественно в сценариях массового обслуживания. Это восприятие важно осознавать, особенно когда процесс управления уровнем услуг сводится только к документированию.

Метрика естественным образом масштабируется: если представить ситуацию, когда группа поддержки представляет собой весь персонал поставщика услуги (то есть единственная группа), то время обработки группой (ti) становится равным общему времени обработки инцидента (Ti). В этом случае формула упрощается до вида: Кгруппы = (1/N) * Σ(1-vi), то есть представляет собой привычную метрику «доля инцидентов, решённых в срок». Таким образом, метрика применима как к отдельным группам, так и к оценке эффективности всего процесса управления инцидентами в целом.

В ITIL за разные аспекты процесса отвечают следующие роли: 1. Дизайнер (технолог/проектировщик процессов): определяет назначение процесса – его базовую функцию в общей процессной модели. 2. Владелец процесса: формирует и актуализирует цели процесса в формате SMART, привязанные к конкретным периодам времени. 3. Менеджер процесса: определяет задачи процесса, обеспечивающие выполнение назначения и достижение целей, и отвечает за оперативное управление процессом. Каждая роль фокусируется на своём уровне детализации: дизайнер на стратегическом, владелец на тактическом, менеджер на оперативном.