Желаемая ценность — это то, что потребители ожидают получить от продукта или услуги до её приобретения. Это их первоначальные ожидания и надежды, связанные с использованием товара. Воспринимаемая ценность — это реальные преимущества, которые потребители обнаруживают после покупки и использования продукта или услуги. Разница между ними может быть значительной: некоторые ожидания оправдываются, другие — нет. Поставщик должен стремиться сблизить желаемую и воспринимаемую ценность, чтобы минимизировать разочарование потребителя и повысить удовлетворенность его продуктом или услугой.

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

Бритва Оккама в контексте использования OLA и SLA означает принцип минимальной сложности, согласно которому не следует умножать сущности без необходимости. В данном случае это подразумевает, что если термин OLA не добавляет ценности к пониманию процессов и фактически дублирует SLA с другой точки зрения, то его можно не использовать. SLA и UC (Underpinning Contracts) достаточно для описания всех необходимых соглашений, поэтому нет необходимости введения отдельного термина OLA. Таким образом, применяя бритву Оккама, можно упростить управление сервисами, убрав избыточный термин, который только вызывает путаницу и усложняет процессы.

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

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

Функциональная спецификация в стандарте RBAC определяет три типа команд: административные, системные и контрольные. Административные команды предназначены для создания и работы с элементами множеств и связями при построении различных компонентов модели RBAC. Примеры: 'AddUser', 'DeleteUser', 'AddRole', 'GrantPermission'. Системные команды обеспечивают работу конструкций в течение пользовательских сессий. Примеры: 'CreateSession', 'AddActiveRole', 'CheckAccess'. Контрольные команды используются для проверки результатов выполнения административных команд. Примеры: 'AssignedUsers', 'RolePermissions', 'UserPermissions', 'UserOperationsOnObject'. Каждая команда имеет свой алгоритм работы и предназначена для выполнения конкретных задач в системе управления доступом.

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

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

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

Основные аргументы против использования методики EVM для построения комплексной системы оценки проектов включают: 1) Некорректность показателя SPI для оценки соблюдения сроков завершённых проектов, так как он автоматически становится равным 1 после завершения работ, скрывая реальное отставание; 2) Отсутствие в классической методике EVM прямого показателя качества проекта, хотя этот недостаток относительно легко устраняется; 3) Система метрик EVM изначально разработана для текущего мониторинга хода проекта, а не для комплексной оценки эффективности завершённых проектов.