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

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

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

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

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

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

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

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

Прогнозирование потребности в ресурсах ИТ с помощью среднего чека начинается с расчета количества сделок, необходимых для выполнения плана продаж. Например, годовой план в 1440 млн рублей при среднем чеке 10 000 рублей требует 120 000 сделок в год. Зная производительность одного продавца (20 сделок в день), можно определить, что необходимо около 500 продавцов. Это позволяет оценить количество одновременно работающих пользователей, объем операций в ИТ-системах и количество обращений в Service Desk. На основе этих данных строится план необходимых ресурсов: серверная мощность, пропускная способность сети, количество лицензий и персонал поддержки.

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