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

Методика измерения и оценки ИТ-управления, используемая CleverKPI, основана на разработанной и многократно апробированной практике за последние 4-5 лет. Методика проверена на реальных проектах («в бою») и позволяет создавать структурированный подход к оценке эффективности управления ИТ-услугами через KPI. Эта методика легла в основу всех продуктов и услуг CleverKPI, включая обучение, диагностику, консалтинг и программные инструменты.

PCF был разработан в 1992 году Американским центром эффективности и качества (APQC), который продолжает поддерживать и развивать этот стандарт. Текущая версия PCF - 6.1.0, выпущенная в марте 2014 года. APQC является автором и поддерживающей организацией данного стандарта, обеспечивающей его постоянное развитие и адаптацию к меняющимся требованиям бизнеса.

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

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

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

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

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

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

Обобщённые показатели (среднее и минимальное значение) можно использовать для расчёта бонусов по формуле, учитывающей два аспекта: достижение целевого уровня среднего показателя (например, 85%) и отсутствие критических провалов (минимальное значение выше 70%). Например, премия выплачивается на 100%, если среднее ≥85% и минимум ≥70%, на 50% — если среднее ≥85%, но минимум <70%, и не выплачивается при среднем <85%. Это стимулирует не только общее улучшение показателей, но и устранение узких мест.