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

В ITIL Service Strategy упоминаются типы моделей аллокации затрат, такие как cost by service (аллокация по услуге) и cost by customer (аллокация по клиенту), но подробности их построения не рассматриваются.

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

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

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

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

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

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

В тексте указан конкретный пример обязательной задачи, которую необходимо выполнять независимо от желания — погружение в бухгалтерский и налоговый учёт. Автор отмечает, что он занимается этими вопросами время от времени не по доброй воле, но вынужден это делать, поскольку это является частью его профессиональных обязанностей или требований, связанных с управлением бизнесом. Хотя сам автор, судя по всему, не увлечён этой сферой, такие задачи приходится выполнять, так как они являются неотъемлемой частью бизнес-процессов.

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