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

Шестой принцип DevOps по DASA 'Автоматизируйте всё, что можете' охватывает два основных аспекта автоматизации: во-первых, автоматизацию процессов разработки программного обеспечения, включая непрерывную поставку (continuous delivery), которая сама подразумевает непрерывную интеграцию (continuous integration) и непрерывное развёртывание (continuous deployment). Во-вторых, автоматизацию всего инфраструктурного ландшафта, что в современных практиках реализуется через подход 'инфраструктура как код' (Infrastructure as Code). Такой широкий взгляд на автоматизацию позволяет снизить человеческий фактор, ускорить процессы разработки и доставки, повысить надёжность и воспроизводимость систем, а также обеспечить возможность быстрого масштабирования и восстановления систем при необходимости.

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

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

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

Для оценки результатов PIR применяются инструменты бизнес-аналитики (на пример, Power BI, Tableau), которые визуализируют данные по KPI, бюджету и срокам. Также используются опросники (например, SurveyMonkey) для сбора обратной связи от пользователей. В ИТ-сфере активно задействуются мониторинговые системы (Nagios, Zabbix), чтобы оценивать технические показатели после внедрения изменений.

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

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

Формализм предотвращается через постоянный фокус на бизнес-целях, а не на соблюдении процедур. Ключевой приём — ответы на вопрос «Зачем?» для каждого этапа. Также важно вовлекать конечных пользователей в проектирование и обеспечивать их обучение так, чтобы инструменты воспринимались как средство решения рабочих задач, а не как дополнительная нагрузка.

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