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

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

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

Использование DevOps в организации ИТ-процессов позволяет значительно повысить скорость и качество доставки продукта. Благодаря интеграции разработки и эксплуатации устраняются издержки на коммуникацию и согласование между отделами. Самоорганизующиеся команды, работающие по DevOps-принципам, могут быстрее реагировать на изменения и внедрять улучшения. Это также способствует повышению ответственности участников за результат и снижению количества ошибок за счёт автоматизации и непрерывного тестирования. В конечном итоге, применение DevOps приводит к более быстрому выходу на рынок, повышению удовлетворённости клиентов и улучшению морального состояния сотрудников.

Целесообразность применения методик DevOps определяется оценкой их соответствия конечной бизнес-задаче и контексту организации. Необходимо проанализировать, является ли поддерживаемый ИТ-решением бизнес-процесс фактором дифференциации компании. Если нет, возможно, разумнее адаптировать бизнес-процесс под возможности доступных решений, включая коробочные продукты. Также важно учитывать уровень сложности инфраструктуры: в условиях высокой сложности (область 'Сложно' по Cynefin) традиционные методы могут быть неэффективны, и предпочтительнее использовать итеративный подход вместо сложного планирования.

Для управления сложностью микросервисной архитектуры рекомендуется применять два ключевых процесса ITIL: управление проблемами и управление конфигурациями. Управление конфигурациями позволяет сохранять информацию о всех компонентах системы, их параметрах и зависимостях, что помогает поддерживать обзор всей архитектуры. Управление проблемами помогает анализировать и устранять корневые причины инцидентов, что особенно важно при диагностике сложных взаимодействий между микросервисами. Эти процессы позволяют сохранить систему в более детерминированном состоянии и избегать перехода в сложный (Complex) домен, где управление становится значительно труднее.

Шаг Plan (Планируй) в цикле Деминга предполагает разработку плана улучшений, формулировку гипотез и определение метрик для измерения результатов. В то время как шаг Act (Корректируй) сосредоточен на принятии решений относительно дальнейших действий после анализа результатов проверки (Check). Act включает либо внедрение успешных улучшений в постоянную практику, либо игнорирование неудачных результатов, либо запуск цикла заново с учетом накопленного опыта. Таким образом, Plan направлен на планирование изменений, а Act — на определение дальнейшего развития процесса после реализации и оценки этих изменений.

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

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

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