Continuous Deployment и Continuous Delivery отличаются уровнем автоматизации доставки изменений в продуктивную среду. Continuous Delivery означает, что изменения готовы к релизу в любой момент (вся цепочка тестирования и подготовки автоматизирована), но непосредственный выпуск в производство требует ручного подтверждения. В то время как Continuous Deployment полностью автоматизирует процесс, так что каждое изменение, прошедшее все этапы конвейера, автоматически разворачивается в продуктивную среду без человеческого вмешательства. Continuous Deployment предпочтительнее, потому что устраняет 'волшебный рубильник' — ситуацию, когда решение о релизе принимает отдельный человек, создавая бутылочное горлышко и возможные ошибки. Это приводит к более стабильному и предсказуемому процессу, где нет искушения временно отключать какие-либо части конвейера (например, автотесты) из-за срочных заказов или дедлайнов. Continuous Deployment обеспечивает максимальную скорость и надежность доставки новых функций конечным пользователям.

ISO 22301 представляет собой основной стандарт в области управления непрерывностью бизнеса, на который ссылаются другие документы. Например, Good Practice Guidelines (GPG) от Business Continuity Institute полностью согласованы с ISO 22301 и используют ту же терминологию. ISO 27031 по готовности ИКТ для бизнес-непрерывности также следует требованиям, установленным ISO 22301. Таким образом, ISO 22301 является базовым стандартом, вокруг которого построены другие документы и рекомендации.

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

Типовая (коробочная) система автоматизации представляет собой готовую конфигурацию системы, содержащую элементы автоматизации процессов: схемы workflow, роли и их полномочия, объекты с необходимыми связями и атрибутами, формы ввода данных, правила бизнес-логики и другие компоненты. Однако важно понимать, что такая система сама по себе, даже обладая множеством преимуществ (масштабируемость, безопасность, удобство), не может диктовать процессы или обеспечивать их исполнение и контроль. Система может содержать отдельные элементы, влияющие на процесс (например, статусы запросов на изменение, набор приоритетов, полномочия по ролям), но не решает задачу организации деятельности сама по себе. Типовая система автоматизации — это чистый продукт, требующий от заказчика понимания его возможностей, настройки, необходимой компетенции персонала для сопровождения и управления обновлениями.

Согласно информации из текста, значительная часть ITSM-проектов (от 60% до 80%) являются провальными в той или иной степени. Это подчеркивает важность правильного подхода к управлению изменениями, включая уделяемое внимание обучению и вовлечению сотрудников, чтобы повысить шансы на успешное завершение проекта.

Принцип 'Работать «в полях»' означает необходимость непосредственного наблюдения за процессами для понимания реальной ситуации. Хотя измерения тоже важны, непосредственное наблюдение предпочтительнее, поскольку цифры могут искажаться в зависимости от метода расчета. Например, рекомендуется иногда работать пару дней на Service Desk, чтобы лучше понять проблемы и потребности клиентов из первых рук.

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

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

Учет рабочего времени начался в октябре 2013 года и к моменту написания текста продолжался почти полтора года. Более подробно, первые 13 недель (до конца 2013 года) учет велся по упрощенной системе с тремя цветовыми категориями, а с 1 января 2014 года система была усовершенствована и расширен до 18 категорий с ведением полного листинга затраченного времени.

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