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

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

Для демонстрации отделения сервисного и процессного подходов можно взять компанию, оказывающую два вида услуг: услуги эксплуатации информационных систем (ИС) и услуги заказной разработки программного обеспечения (ПО). Для этих видов услуг производственные процессы могут серьезно различаться: в разработке ПО лежит процессная модель ALM (или RUP, MSF и другие), а в эксплуатации ИС - операционные процессы ITIL. При этом управленческие процессы, такие как SLM (Service Level Management), будут общими для обоих видов услуг.

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

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

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

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

Метрики, которые помогают оценить предсказуемость выполнения задач в DevOps, в основном связаны с регулярностью и стабильностью работы команды. Ключевая метрика предсказуемости - это последовательность выполнения взятых на себя задач за определенные отрезки времени. Если команда регулярно выполняет запланированный объем работы в установленные сроки, это говорит о высокой предсказуемости. Дополнительно могут анализироваться показатели отклонения от плана, частота срывов сроков, стабильность velocity (скорости выполнения задач) и улучшение точности оценок. Предсказуемость является важным компонентом качества работы DevOps-команды, так как позволяет более точно планировать релизы и управлять ожиданиями заинтересованных сторон, что в конечном итоге способствует уменьшению времени выпуска продукта (lead time).

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

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