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

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

Количественная оценка эффективности ITSM-процессов возможна через измерение ключевых показателей. Среди основных метрик - время решения инцидентов, которое в примере сократилось на 40% за полгода. Также важны процент автоматизированных обращений (в данном случае достигнуто 90%) и скорость маршрутизации запросов. В коммерческих организациях эти показатели можно дополнительно перевести в денежный эквивалент, учитывая стоимость рабочего времени сотрудников и возможные операционные потери при простоях. Такой подход позволяет обосновать инвестиции в улучшение ITSM-процессов через реальные финансовые выгоды, а не гипотетические расчеты. Другие важные количественные показатели включают уровень удовлетворенности пользователей, количество повторных обращений по одному инциденту и среднее время первого ответа на запрос.

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

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

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

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

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

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

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