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

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

В Google у одного менеджера может быть до 30 прямых подчинённых, что значительно больше общепринятой нормы «максимум семеро на одного босса». Такая практика стала возможной благодаря тому, что руководители компании избегают микроменеджмента и делегируют ответственность. Google выяснил, что при наличии хорошего руководителя, который обладает ключевыми качествами, указанными в Project Oxygen, такое количество подчинённых позволяет сохранять высокую эффективность работы команды и минимизировать управленческую бюрократию.

В тексте упоминаются две другие модели управления доступом наряду с ролевой моделью (RBAC). Это мандатное управление доступом (MAC, Mandatory Access Control), при котором доступ к ресурсам контролируется на основе меток безопасности и строгих политик, определенных администратором безопасности, и избирательное управление доступом (DAC, Discretionary Access Control), где владелец ресурса имеет полный контроль над предоставлением доступа к этому ресурсу. Упоминается, что модель RBAC была предложена как альтернатива этим двум моделям, сочетая в себе преимущества контролируемого управления при большей гибкости по сравнению с MAC и более строгом контроле по сравнению с DAC.

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

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

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

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

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

Для определения ПО, требующего лицензирования, необходимо составить список критически важных программ (например, Microsoft Suite, Adobe Photoshop), проанализировать правила лицензирования вендоров (особенно сложные, как у Oracle), и использовать сканеры сети для выявления фактически установленных продуктов. Затем данные следует сопоставить с купленными лицензиями. Важно сосредоточиться на тех продуктах, где наиболее высок риск нарушения лицензионных соглашений или штрафов (например, часто копируемый софт). Серверное ПО обычно менее приоритетно для первоначального учёта.