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

Некоторые компании используют отдельные инструменты для учёта активов и экономических расчётов, потому что их программное обеспечение изначально разрабатывалось как разделённое — например, HP имеет отдельные продукты для ITSM (HPSM с CMDB) и для управления активами (HP Asset Manager с AMDB). Также некоторые разработчики продуктов не хотят, чтобы их инструменты зависели от наличия развитых ITSM-решений у заказчиков, поэтому они делают свои системы независимыми. Однако это обусловлено программно-архитектурными ограничениями конкретных решений, а не общими рекомендациями или лучшими практиками. Такие решения не всегда отражают наиболее эффективный подход к совмещению функциональности.

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

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

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

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

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

Основная цель домена руководства (EDM) в структуре COBIT 5 заключается в обеспечении того, чтобы система управления ИТ эффективно поддерживала достижение целей организации, учитывая интересы заинтересованных сторон. Для этого домен EDM обеспечивает оценку текущего состояния системы управления ИТ, определение направления её развития и мониторинг результатов. Конкретно это выражается в управлении ценностью, рисками и ресурсами в области ИТ, а также в поддержании системы руководства и обеспечении её прозрачности для заинтересованных лиц.

Стандарт INCITS 494-2012 представляет собой расширение основного стандарта INCITS 359-2012, разработанное для устранения критики 'чистого' RBAC за его негибкость в условиях изменчивого окружения. В то время как INCITS 359-2012 описывает базовую модель RBAC с её компонентами, INCITS 494-2012 расширяет возможности RBAC в части обработки динамических ограничений. Он позволяет внешним политикам и правилам создавать ограничения на уровне ядра RBAC, которые могут применяться к базовым множествам (пользователям, ролям, операциям, объектам и правам доступа). Стандарт 494-2012 вводит обработку не только разделения обязанностей, но и других типов ограничений, таких как время суток, местоположение и т.д.

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