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

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

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

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

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

В PCF уровень, соответствующий непосредственно исполняемым процессам, обозначается как "процесс". Этот уровень находится третьим в иерархии и обозначается тремя цифрами, разделенными точками (5.2.3, 8.3.4, 11.2.1). Примеры процессов, приведенные в тексте: Управление жалобами клиентов (в рамках группы Планирование и управление обслуживанием клиентов), Ведение финансовой отчетности (в рамках группы Ведение общего бухгалтерского учета и отчетности), Управление связями с правительством (в рамках группы Управление государственными и отраслевыми отношениями). Этот уровень представляет собой конкретные исполнимые процессы предприятия.

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

ABAC не подходит для аудита, потому что в нём отсутствует явное понятие «права», как в RBAC. В ABAC доступ определяется динамически через набор условий на основе атрибутов, что делает невозможным однозначное определение привилегий пользователя без анализа всех текущих контекстных данных (время, место, свойства объекта). Это усложняет проверку и документирование прав, необходимые для аудита.

"Технические услуги для технических услуг" — это базовые инфраструктурные компоненты и услуги, которые обеспечивают работоспособность ИТ-систем (технических услуг). Примерами являются поддержка сетей и каналов передачи данных, систем управления базами данных (СУБД), систем хранения данных (СХД). Эти услуги являются фундаментальными и повторяются для поддержки различных ИТ-систем в организации.

Времени на мастер-классе оказалось недостаточно, потому что объём материала требовал более глубокого погружения. Участникам потребовалось бы минимум три-четыре часа, чтобы подробно обсудить суть и идеи канбана, решать задачи с постепенным повышением сложности и потренироваться не только в проектировании канбан-доски, но и в её практическом использовании в повседневной работе. Ограничение в 45 минут не позволило детально рассмотреть все аспекты метода, что привело к необходимости интенсивно подгонять участников и упрощать некоторые моменты.