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

Практика 'Поддержка изменений' (Change enablement) в ITIL4 - это подход к управлению изменениями, ориентированный на быструю и безопасную доставку изменений в эксплуатацию при минимизации рисков. Она фокусируется на обеспечении того, чтобы изменения внедрялись эффективно и безопасно, при этом сохраняя необходимый уровень контроля. В рамках этой практики определен набор процессов, каждый из которых требует управления, а за практику в целом отвечает менеджер изменений как специфическая роль. Цель практики - поддержка бизнеса в адаптации к изменениям среды при сохранении стабильности сервисов.

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

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

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

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

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

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

Для предотвращения деградации CI/CD процесса после внедрения необходимо установить четкие правила, что 'назад пути нет, а половины конвейера не бывает'. Следует договориться, что конвейер работать должен всегда, без исключений, и нет других способов доставки изменений в эксплуатационную среду кроме как через него. Нужно удалить административные права на объекты инфраструктуры у всех, кроме конвейера. Рекомендуется стремиться к полному Continuous Deployment вместо менее совершенных вариантов (CI или CD), чтобы убрать 'волшебный рубильник', когда человек принимает решение о ручном релизе. Это означает, что все изменения, прошедшие через конвейер, автоматически попадают в рабочую среду без ручного одобрения. Такой подход не оставляет места для временного отключения части системы, например, автотестов, и гарантирует устойчивость процесса в долгосрочной перспективе.

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