Для эффективного управления проблемами необходимо: 1) Четко отличать проблемы от инцидентов и не смешивать эти понятия; 2) Сформулировать бизнес-ценность управления проблемами и оценить негативное влияние от инцидентов; 3) Сфокусироваться на проактивной деятельности, а не только на реактивной; 4) Обеспечить доступ сервисных команд к базе известных ошибок (KEDB); 5) Регулярно измерять эффективность работы в управлении проблемами; 6) Инвестировать в устойчивость систем и обучение персонала; 7) Постоянно анализировать эффективность обходных решений и оценивать целесообразность применения постоянных решений.

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

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

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

Сочетание ролевой модели управления доступом с системой запросов прав доступа дает несколько преимуществ: 1) Возможность автоматической обработки кадровых событий через связь с кадровой системой, что позволяет автоматически назначать или отзывать роли при приеме, увольнении, переводе сотрудников и других событиях. 2) Возможность определения разумного минимума ролей, которые целесообразно поддерживать, вместо попыток охватить все возможные права в ролях. 3) Закрытие временных потребностей в доступе прав, которые не предусмотрены текущим набором ролей. 4) Выявление часто повторяющихся запросов на доступ, что может стать основой для создания новых ролей и оптимизации системы управления доступом.

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

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

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

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

Разделение ИТ-подразделения на две функции — разработку (Change the business) и эксплуатацию (Run the business) — затрудняет управление ИТ-услугами, так как они управляются разными руководителями, имеют разные правила, точки входа для потребителей и взаимодействуют только через процессы управления изменениями и релизами. Это создает барьер для формирования сквозной ответственности за ИТ-услугу, которая должна охватывать все этапы от разработки до эксплуатации. Операционные взаимодействия, такие как управление инцидентами и проблемами, организуются относительно просто, но создание единой системы ответственности требует глубоких изменений в структуре и процессах.