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

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

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

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

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

Другие стандарты подходят к управлению доступностью иначе, чем ITIL. Например, ISO/IEC 20000 объединяет управление доступностью с управлением непрерывностью, COBIT5 и CMMI для сервисов связывают его с управлением мощностями, MOF включает его в функцию надежности вместе с управлением непрерывностью, мощностями и безопасностью. Авторы ISM Method относят управление доступностью к управлению качеством (Quality Management), наряду с другими аспектами, такими как безопасность и непрерывность. Это свидетельствует о том, что в других стандартах управление доступностью не выделено отдельно как самодостаточный процесс.

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

Руководящие принципы ITIL 4 отражают многие другие подходы, методологии, методы, стандарты и философии, в частности Lean, Agile, DevOps и COBIT. Это означает, что принципы ITIL 4 не противоречат этим подходам, а скорее дополняют их и находят в них отражение. Это позволяет организациям, уже использующим эти подходы, легко интегрировать рекомендации ITIL в свою существующую практику без конфликтов между различными системами управления. Универсальность принципов ITIL 4 обеспечивает их применимость в различных контекстах и совместимость с широким спектром современных управленческих практик.

ITIL выделяет три типа поставщиков услуг: Тип I и Тип II (внутренние поставщики) и Тип III (внешние поставщики). Для внутренних поставщиков (Тип I и Тип II) финансовые штрафы обычно отсутствуют, а ответственность выражается в виде уменьшения премий сотрудников ИТ-подразделения. Штрафы могут применяться автоматически или на усмотрение руководства, что делает применение санкций менее однозначным. Для внешних поставщиков (Тип III) предусматриваются реальные финансовые санкции, но их размер и применение часто ограничены. Например, сумма штрафов обычно не превышает 20–30% от суммы контракта, а в некоторых законах, таких как 44-ФЗ, штрафные санкции определены значительно ниже, в диапазоне от 0,5% до 2,5% от суммы контракта.

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