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

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

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

Для нормирования задач сопровождения CMDB можно использовать несколько методов. Первый метод - ведение полного или выборочного учета трудозатрат («списание часов»), что позволяет накапливать статистику и на ее основе устанавливать нормативы для аналогичных задач в будущем. Второй метод - консолидация внешней статистики с портала REALITSM.RU, где можно найти данные и наработки других организаций по оценке трудозатрат. Третий метод - детальная разбивка задач по группам конфигурационных единиц (ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений, инфраструктура) и ролям специалистов с учетом различной стоимости рабочего времени и требований к компетенциям. Четвертый метод - разработка внутренних стандартов и нормативов для каждой из задач сопровождения CMDB (первичная регистрация, обновление статусов, аудит, инвентаризация и т.д.) на основе оценки их сложности и требуемых ресурсов. Пятый метод - регулярный пересмотр и корректировка нормативов на основе анализа фактических трудозатрат и изменений в процессах работы с CMDB.

Путаница возникает по причине того, что стандарт ITIL V3 описывает процессы и общие подходы к управлению, но не детализирует организационные роли на уровне исполнения. Например, роль "Практик изменений" (Change practitioner) включает обязанности по мониторингу и проверке, но не прямо указывает на необходимость координации действий, которая скорее относится к процессу управления изменениями в целом. Аналогично, в процессе управления релизами координация формально не закреплена за конкретной ролью, хотя в обязанности менеджера процесса входит координация ресурсов и взаимодействие с другими процессами. Это приводит к неоднозначности в реализации процессов на практике и необходимости адаптировать стандарт под внутренние структуры организации.

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

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

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

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

Частые ошибки при аудите CMDB: ограничение проверки только техническими атрибутами (например, IP-адреса) без анализа бизнес-важных связей, использование устаревших методик проверки, игнорирование человеческого фактора (например, не учитываются случаи ручного внесения данных вне системы), чрезмерная фокусировка на количестве расхождений вместо анализа их причин, недостаточная координация с владельцами данных для понимания контекста изменений. Также критична ошибка — проведение аудита без последующего контроля исправления выявленных недостатков.