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

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

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

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

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

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

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

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

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

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