При принятии решения об использовании механизма автоматической эскалации инцидентов следует учитывать несколько ключевых факторов: 1) Наличие четкой и фиксированной схемы маршрутизации эскалации, как необходимое условие для работы автоматики; 2) Надежность процедуры фиксации факта приема заявок в работу, так как от этого зависит правильное срабатывание механизма; 3) Возможность возникновения конфликтных ситуаций при одновременной работе нескольких уровней поддержки; 4) Особенности обработки массовых обращений и major-инцидентов, которые могут требовать исключений из правил автоматической эскалации; 5) Влияние автоматической эскалации на мотивацию и качество работы специалистов текущего уровня. Только при учете всех этих факторов можно принять обоснованное решение о целесообразности использования автоматической эскалации.

Совместимость и правильную компоновку компонентов RBAC регулирует стандарт INCITS 459-2011 «Information Technology - Requirements for the Implementation and Interoperability of Role Based Access Control». Этот стандарт описывает допустимые сочетания компонентов (функциональных наборов) и интерфейсы, что обеспечивает правильную интеграцию различных элементов системы RBAC. В то время как INCITS 359-2012 определяет референтную модель и INCITS 494-2012 расширяет её возможностями по обработке динамических ограничений, INCITS 459-2011 отвечает за то, чтобы все эти компоненты могли работать вместе корректно и обеспечивать совместимость между различными реализациями систем управления доступом на базе RBAC.

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

BMC Remedy ITSM Suite оказалась единственным лидером в магическом квадрате Гартнера за 2010 год благодаря оценке ее как надежного и стратегически стабильного партнера, способного поддерживать долгосрочные отношения с корпоративными клиентами. Гартнер оценивает не только технические характеристики продукта, но и способность компании внедрять продукт на предприятиях, поддерживать его развитие и обеспечивать уверенность клиентов в долгосрочной перспективе. В то время как другие компании, такие как HP, IBM и CA, потеряли позиции из-за оценки их маркетинговой и продажной активности, а также стратегического видения развития продукта.

Контроль известной ошибки (known error) в ситуации, когда после диагностики не обнаружено реалистичных решений, имеет свои особенности. В этом случае процесс фокусируется не на устранении проблемы, а на управлении ее последствиями и минимизации влияния на бизнес. В рамках error control (EC) устанавливается срок контроля известной ошибки, который позволяет отслеживать проявления проблемы и оценивать, как она влияет на работу бизнес-процессов в режиме ожидания. Такой подход необходим, когда решение проблемы технически невозможно или экономически нецелесообразно в данный момент, но требуется поддерживать сервис на приемлемом уровне.

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

Предложенная метрика имеет несколько ключевых преимуществ: 1) Справедливо распределяет ответственность за нарушение сроков между всеми участвующими группами, а не возлагает её на одну 'последнюю' группу. 2) Создает правильные мотивации, стимулируя группы обрабатывать инциденты даже при получении их близко к окончанию срока. 3) Является чувствительной к реальному участию группы в решении инцидента, а не только к её месту в цепочке обработки. 4) Обеспечивает естественное масштабирование от уровня отдельной группы до уровня всего процесса управления инцидентами. 5) Легко адаптируется для учёта степени превышения срока. 6) Помогает избежать негативных практик, таких как 'футбол' инцидентов между группами.

Аспект 'Информация и технологии' относится к информационным ресурсам и технологиям, использованным для хранения, обработки и создания информации в процессе предоставления ИТ-услуг. Он включает не только инструменты предоставления услуг (ITSM, совместной работы, инвентаризации, CMDB, анализа), но и передовые технологии вроде искусственного интеллекта, машинного обучения, облачных решений, мобильных платформ. Важно учитывать, какая информация управляется услугами, какая вспомогательная информация необходима, как информация защищается, управляется, архивируется и удаляется. Управление информацией должно быть целостным и соответствовать требованиям законодательства (например, соблюдение ФЗ 'О персональных данных'). Информация и технологии зависят от их использования и архитектуры, включая приложения, базы данных, системы связи и инфраструктуру.

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

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