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

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

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

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

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

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

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

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

COBIT5 for Risk (ранее известный как Risk IT) предлагает строгий, структурированный подход к описанию и управлению рисками. Его отличительной особенностью является учет дополнительных параметров при оценке рисков, таких как прогнозируемая длительность негативного влияния, критичность события относительно календарного периода или времени суток. Документ содержит множество практических примеров, размещенных в виде плашек на полях, и включает сотни примеров рисков, классифицированных по 20 категориям – от управления ИТ-инвестициями и проектами до рисков, связанных с поставщиками, вредоносным ПО, атаками и регуляторами. Для каждого риска указаны соответствующие контрмеры.

В HP OpenView Service Desk используется, по мнению автора, более рациональное деление по сравнению с HP SM или BMC Remedy ITSM Suite. В OpenView деление сделано по принципу различия между инфраструктурными инцидентами и обращениями пользователей, в то время как в других системах деление чаще проводится между инцидентами и сервисными запросами. В реальной практике разница в обработке инцидента, поданного пользователем, и сервисного запроса, поданного пользователем, не так велика, как разница между инфраструктурным инцидентом и обращением пользователя. Это подразумевает разную классификацию, разные процедуры выявления/регистрации и разные процедуры закрытия для этих двух основных типов случаев.