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

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

Высокий процент дефектов в бэклоге (от 50% до 70%) может считаться нормой в некоторых командах из-за искажения восприятия, вызванного изоляцией от внешних стандартов и отсутствием объективных метрик. В таких командах сложилась привычка, что большое количество ошибок — это обычная ситуация, особенно если нет возможности сравнить свою работу с работой других команд или отраслевыми стандартами. Коллективное мнение вроде «бывало и хуже» укрепляет это представление, и сотрудники перестают видеть проблему, так как ежедневно взаимодействуют с этим состоянием и перестают замечать его ненормальность.

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

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

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

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

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

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

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