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

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

Для предотвращения путаницы необходимо четко определить в договорах и технической документации используемую терминологию. Рекомендуется сопровождать термины пояснениями вида: «Доступность (в смысле ITIL, включая плановые простои)». При работе с российскими стандартами можно указывать: «Готовность (в соответствии с ГОСТ Р 53480-2009)». Также полезно использовать англоязычные оригиналы (availability) с расшифровкой методологии расчета в приложениях.

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

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

Активация аварийного плана восстановления (disaster recovery plan) необходима, если инцидент продолжается дольше установленного срока без признаков решения. Ответственность за принятие решения об активации плана лежит на менеджере major-инцидента. Этот специалист должен знать правила и процедуры запуска плана аварийного восстановления, чтобы оперативно перейти к следующему уровню реагирования при необходимости, сокращая время простоя критически важных сервисов.

Статическое разделение обязанностей (SSD) и динамическое разделение обязанностей (DSD) в RBAC обе добавляют ограничения в систему, но по-разному. Статическое разделение обязанностей вводит ограничения на уровне назначения ролей пользователям - запрещает назначать определённые комбинации ролей конкретным пользователям. Примером может служить ограничение, при котором пользователь не может одновременно иметь роль, отвечающую за формирование заявок на платежи, и роль, отвечающую за заверение этих платежей. Динамическое разделение обязанностей вводит ограничения в процессе работы пользователя - запрещает одновременное использование определённых ролей в одной сессии, даже если обе роли назначены пользователю. Также динамические ограничения могут зависеть от внешних факторов, таких как время суток, местоположение и другие атрибуты.

Good Practice Guidelines (GPG) - это руководство по управлению непрерывностью бизнеса, издаваемое Business Continuity Institute. Впервые выпущенное в 2002 году, в настоящее время доступна пятая версия документа - GPG 2013. Документ полностью согласован со стандартом ISO 22301, использует ту же терминологию и содержит детальные указания по каждому этапу жизненного цикла системы управления непрерывностью бизнеса.

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

В тексте упоминаются следующие категории задач, претендующие на использование рабочего времени: 1. Оперативные, рутинные задачи — текущие вопросы, которые требуют немедленного решения и занимают основной объём рабочего времени 2. Долгосрочные задачи, связанные с развитием себя и компании — которые часто остаются без внимания из-за приоритета оперативных задач 3. Задачи, которые хочется выполнять (интересные проекты) 4. Задачи, которые необходимо выполнять независимо от желания (обязательные функции должности, например, бухгалтерский учёт) 5. Профессиональные задачи, относящиеся к основной работе 6. Личные дела, которые пересекаются с рабочим временем в условиях размытых границ между работой и личной жизнью