В ITIL 4 риск определяется как возможное событие, которое может причинить вред или убытки, или затруднить достижение целей. Также риск может определяться как неопределенность результата и может использоваться в контексте измерения вероятности наступления как положительных, так и отрицательных результатов. Это более широкое определение учитывает не только потенциальные негативные последствия, но и неопределенность в достижении целей.

Длительность тестирования результативности решения проблемы определяется частотой проявления самой проблемы и не поддается стандартной нормировке. Например, если проблема проявляется ежедневно или регулярно, тестирование можно выполнить за короткий период времени (2-3 дня). Однако если проблема связана с квартальной отчетностью и проявляется только раз в квартал, время тестирования может занять до трех месяцев или до следующего начала квартала (в зависимости от того, когда было применено решение). Для проблем, которые проявляются нерегулярно и не имеют предсказуемой периодичности, определение срока тестирования становится еще более сложным и индивидуальным.

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

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

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

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

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

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

Новый KPI использует плавную шкалу оценки между Tmin и Tmax, где решение ближе к Tmin дает максимальный балл, а приближение к Tmax — постепенно снижает рейтинг. Например, инцидент, устраненный за 30 минут при Tmin = 30 и Tmax = 240, получает 100%, а решение за 230 минут — уже около 4%. Это создает прямую мотивацию решать инциденты максимально быстро, так как каждый сэкономленный час напрямую улучшает итоговый показатель эффективности.

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