В разделе ИТ-department benefits (нижний правый квадрант) следует описать преимущества проекта для руководства ИТ-департамента. Эти преимущества должны отвечать на вопрос, какие проблемы ИТ-отдела будут решены в результате проекта. Примеры могут включать: «Основания для пересмотра ресурсного плана при превышении согласованных объемов потребления ИТ-услуг», «Сокращение числа аварийных изменений за счет улучшенного процесса управления изменениями», «Повышение эффективности распределения задач между сотрудниками ИТ-отдела». Важно сосредоточиться на тех аспектах, которые напрямую затрагивают работу и проблемы ИТ-руководителей.

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

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

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

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

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

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

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

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

Основная причина неудач ITSM-проектов — недостаточное внимание к изменению поведения сотрудников. Хотя проекты направлены на изменение того, как определяются цели, управляются процессы и взаимодействуют с клиентами, зачастую пренебрегают обучением и мотивацией исполнителей и менеджеров среднего звена. Это приводит к тому, что даже технически успешное внедрение не приносит ожидаемых результатов из-за неготовности персонала адаптироваться к новым условиям.