Для улучшения процесса управления инцидентами с помощью цикла Деминга сначала нужно определить проблему (например, долгие сроки решения инцидентов). На этапе Планируй (Plan) анализируется процесс с использованием инструментов вроде Expanded Incident Lifecycle, выявляются узкие места и разрабатывается гипотеза решения (например, немедленное решение простых инцидентов). На этапе Выполняй (Do) реализуется гипотеза в течение определенного периода. На этапе Проверяй (Check) оценивается эффективность изменений через опросы пользователей и анализ метрик. На этапе Корректируй (Act) принимается решение о дальнейших действиях: если результаты неудовлетворительны, цикл запускается заново с новыми корректировками (разделение персонала на группы для простых и сложных инцидентов), а при успехе улучшения внедряются в постоянную практику.

Между количеством инцидентов и временем их решения существует нелинейная зависимость, усиленная за счет эффекта очереди и неравномерного распределения нагрузки в течение дня. Например, при производительности 20 минут на инцидент теоретически сотрудник может обработать 24 инцидента за день, если бы они поступали равномерно. Но при неравномерном поступлении (всплеск утром) и одновременном начале работы над всеми 24 инцидентами, среднее время их решения возрастает до 4 часов 10 минут. При уменьшении количества инцидентов вдвое (до 12), при прочих равных условиях, среднее время решения падает до 2 часов 10 минут. Это означает, что сокращение количества инцидентов через управление проблемами может дать больший эффект для снижения среднего времени решения, чем оптимизация только производительности персонала.

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

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

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

«Мертвая зона» (низкая отзывчивость и низкая полезность) считается наименее приоритетной, так как клиенты не проявляют активности в предоставлении отзывов, а их редкие замечания не несут ценности для улучшения услуги. Ресурсы, потраченные на анализ такой обратной связи, дают минимальный возврат. Вместо этого рекомендуется сконцентрироваться на оптимизации механизмов сбора отзывов, например, упрощении форм или мотивации клиентов через бонусы, чтобы перевести взаимодействие в более продуктивные сектора, такие как «Hard Candy».

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

Путешествие заказчика по ITIL включает несколько ключевых этапов: Offer (Предложение), Agree (Согласование), Co-create (Совместное создание), и другие. На этапе Offer происходит сбор требований к услуге, на этапе Agree - согласование и фиксация условий услуги и требований к уровню обслуживания (SLA). Этап Co-create связан с непосредственным предоставлением услуги и взаимодействием пользователя с провайдером в процессе использования услуги. Каждый из этих этапов может запускать определенные потоки создания ценности в зависимости от типа взаимодействия и предъявляемого спроса.

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

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