Стандарт ISO 31010 «Risk Management – Risk assessment techniques» подробно описывает метод анализа дерева отказов (FTA), предоставляя более развернутую информацию, чем другие источники. Этот стандарт не только объясняет теоретические основы метода, но и приводит конкретные примеры построения деревьев отказов с использованием булевой логики. В частности, в стандарте демонстрируется, как с помощью логических элементов («и», «или», «исключающее или», «не») можно представить различные пути возникновения конечного нежелательного события, создавая наглядную схему причинно-следственных связей, которая помогает в оценке рисков и принятии решений по их снижению.

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

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

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

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

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

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

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

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

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