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

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

Стандартное восприятие SLM (Service Level Management) как процесса, который ограничивается подготовкой и актуализацией каталога услуг, SLA и OLA, имеет довольно ограниченное применение. Фактически, создание и поддержка этих документов составляет не более половины содержания SLM как процесса. При этом практика ведения каталога технических услуг и OLA применима лишь к очень небольшой доле компаний, где реализован сервисный подход, а каталог бизнес-услуг с различными уровнями обслуживания востребован преимущественно в сценариях массового обслуживания. Это восприятие важно осознавать, особенно когда процесс управления уровнем услуг сводится только к документированию.

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

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

Business Relationship Management (BRM) и Service Level Management (SLM) служат основой для ИТ-бюджетирования, поскольку через них определяются потребности бизнеса и ожидаемые объемы потребления услуг. BRM обеспечивает понимание стратегических бизнес-планов и целей, а SLM переводит эти цели в конкретные соглашения об уровне услуг с заказчиками. Эти данные являются отправной точкой для всего процесса бюджетирования, обеспечивая, что ИТ-бюджет будет согласован с бизнес-потребностями и направлен на достижение конкретных результатов.

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

Разделение полномочий достигается запретом одновременного использования смежных ролей, которые могут создать конфликт интересов. Например, в финансовой системе запрещено сочетать роли 'Инициатор платежа' и 'Утверждающий платеж' в одном пользователе. Это реализуется через настройки RBAC-модели, где для групп ролей устанавливаются ограничения. Если система поддерживает динамическое разделение полномочий, проверка на запрещённые комбинации происходит при назначении прав, предотвращая потенциальные злоупотребления.

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

Неправильное размещение рисков в SWOT-анализе, например, их включение в квадрант «Слабые стороны» вместо анализа причин, может привести к поверхностному пониманию проблемы. Это создает иллюзию завершенности анализа, тогда как на самом деле упускаются важные корневые причины рисков, которые нужно устранить. В результате разработанная стратегия может не решить реальные проблемы и не предотвратить возникновение рисков, так как фокус смещен на отдельные проявления, а не на системные причины.