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

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

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

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

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

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

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

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

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

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