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

Четвертый шаг цикла Деминга (Act) заключается в принятии решений относительно дальнейших действий после проверки результатов изменений. Он включает ответ на вопрос: 'Что делать дальше?'. Это может означать внедрение успешных улучшений в стандартную практику, игнорирование неудачных результатов без дополнительных изменений или запуск нового цикла PDCA с учетом полученного опыта. Act фокусируется на итоговой корректировке подхода и определении дальнейшей стратегии улучшений, что отличает его от этапа планирования, который предваряет непосредственное выполнение изменений.

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

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

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

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

Проектируемый простой услуг (Projected Service Outage, PSO) - это документ, в котором фиксируются все запланированные периоды недоступности услуг, необходимые для реализации изменений. За формирование и актуализацию этого документа в первую очередь отвечает процесс управления изменениями. Однако при согласовании поправок в графике плановых простоев также участвуют процессы управления уровнем услуг (Service Level Management, SLM) и управления доступностью (Availability Management), обеспечивая комплексный подход к планированию и минимизации влияния простоев на бизнес.

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

Автоматизация в управлении изменениями может быть реализована через интеграцию с конвейерами непрерывной интеграции и доставки (CI/CD). Если организация использует CI/CD, модель изменения должна учитывать эти процессы, чтобы автоматизировать этапы тестирования, развертывания и мониторинга. Это позволяет сократить время внедрения и повысить качество изменений за счёт предсказуемости и отсутствия ручных ошибок. Автоматизация особенно эффективна для регулярных, структурированных изменений.

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