Для оценки выполнения целей процесса в ITIL должны использоваться метрики, которые: - Непосредственно указаны в формулировке цели (например, для цели "увеличить долю решённых инцидентов до 95%" метрикой будет процент своевременно устранённых инцидентов). - Соответствуют критерию измеримости: имеют количественную шкалу и метод расчёта. - Привязаны к временным рамкам (ежемесячные, ежеквартальные отчёты). - Учитывают как количественные показатели (проценты, время выполнения), так и качественные аспекты в операционных задачах. - Связаны с цепочкой ценности: показывают влияние на качество услуг или бизнес-результаты. При этом метрики для задач процесса могут быть статичными (так как задачи редко меняются), тогда как для целей они переопределяются при каждом пересмотре целей.

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

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

Warranty (Гарантия) — это одна из двух основных характеристик услуги в управлении услугами по ITIL. Warranty отвечает на вопрос fit for use - пригодность услуги к использованию, то есть насколько она находится в том состоянии, чтобы пользователь мог ею пользоваться. Warranty характеризуется четырьмя компонентами: доступность (Availabitity), мощность (Capacity), безопасность (Security) и непрерывность (Continuity). Warranty не означает просто гарантийный период в обычном понимании, а определяет, насколько услуга может быть использована потребителями без перебоев и проблем, что позволяет услуге обеспечивать ценность для пользователя.

Текст предлагает ввести практику для руководителей ИТ среднего и высшего уровня на время переходить "работать в бизнес", например, становиться владельцем продукта, зависящего от ИТ. Это означает, что человек должен стать бизнес-владельцем продукта, заинтересованным в его успехе так, что от продукта зависит P&L, а от P&L - личный бонус руководителя. Такой переход должен быть неопределённым по сроку, и возврат в ИТ должен быть возможен только при наличии конкретного и реализуемого плана улучшений. Это позволяет руководителю лучше понять проблемы бизнеса и увидеть интерфейс между ИТ и бизнесом.

Causal loop diagram (CLD) - это инструмент системной динамики, который позволяет отражать влияние разных переменных, характеризующих работу системы, друг на друга для объяснения ее поведения. CLD включает в себя переменные (такие как Market Size, Potential Customers, People Buying Product), связи между ними, которые бывают двух типов: S (same) - прямо пропорциональная зависимость (например, чем больше людей купили продукт, тем больше клиентская база) и O (opposite) - обратно пропорциональная зависимость (например, чем больше людей купило продукт, тем меньше потенциальных клиентов). Также в диаграмме обозначаются циклы обратной связи: R (reinforcing loop) - усиливающие циклы, которые усиливают изменения, и B (balancing loop) - балансирующие циклы, которые стремятся к равновесию и стабилизируют систему. Эти элементы в совокупности помогают анализировать и визуализировать сложные взаимодействия внутри системы и объяснять часто контринтуитивное поведение системы.

Основной фактор, влияющий на сложность организационных изменений в компании - отсутствие сильных лидеров. Крупные организационные изменения требуют не только умения менеджеров "работать по процессу", но и способность лидеров работать в условиях неопределённости, идти на риски, проверять на прочность status quo. Эффективные преобразования требуют лидеров, которые могут создать привлекательную картину будущего и увлечь сотрудников этой идеей, а также последовательно двигаться вперед даже в сложных условиях, когда "пули над головой". Без такой лидерской составляющей изменение масштаба и сложности не достигаются, независимо от количества задействованных ресурсов.

Структура сценария риска в COBIT 5 for Risk включает пять основных компонентов: источник угрозы (Actor), который определяется как внутренний или внешний; тип угрозы (Threat Type), такой как злоумышленные действия, ошибки или природные катаклизмы; событие (Event), включающее раскрытие информации, модификацию, кражу или уничтожение; связанные активы (Asset/Resource), относящиеся к людям, организационным структурам, процессам и ИТ-инфраструктуре; и временной аспект (Time), учитывающий прогнозируемую длительность негативного влияния и критичность события в зависимости от времени суток или календарного периода.

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

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