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

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

Детерминированный контекст характеризуется отсутствием вариативности: все процессы предсказуемы, задачи типовые и хорошо документированы, ресурсы известны заранее, а операции нормированы. В таких условиях дедлайны работают эффективно, так как отсутствуют внешние шоки или непредвиденные изменения. Однако в современном бизнесе такие ситуации встречаются крайне редко, так как рынки часто подвержены VUCA-факторам.

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

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

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

Вспомогательная услуга в ITIL — это услуга, которая может быть незаметна для заказчика, но необходима для предоставления основной услуги. Часто её не различают от поддерживающей (обеспечивающей) услуги, считая оба термина синонимами. Обе они обеспечивают функционирование основной услуги, но не являются её центральной частью. Например, внутренние процессы или технологии, на которые клиент не обращает внимания, но без которых основная услуга невозможна.

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

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

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