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

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

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

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

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

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

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

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

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

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