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

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

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

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

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

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

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

Задачи процесса в ITIL определяют конкретные действия или функции, которые процесс должен выполнять для соответствия своему назначению и достижения поставленных целей. Они отражают технологию реализации процесса. Примеры: - Для управления инцидентами: накопление и организация знаний по устранению инцидентов. - Для управления проблемами: предоставление информации об эффективных решениях для сокращения повторных инцидентов. Задачи: - Менее динамичны, чем цели, и фиксируются в регламенте процесса. - Связаны с метриками для контроля выполнения. - Определяются менеджером процесса с методической поддержкой дизайнера процесса. Они обеспечивают мост между стратегическим назначением процесса и оперативными целями.

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

При наличии нескольких R (Responsible) в RACI-матрице важно четко различать, кто именно отвечает за организацию работы, а кто просто участвует в ее исполнении, чтобы избежать путаницы в обязанностях и ответственности. Если не провести это разделение, может возникнуть ситуация, когда несколько человек считают, что ответственность за организацию лежит на другом, что приведет к срыву сроков или низкому качеству выполнения задачи. Четкое определение организатора работы помогает выстроить правильную иерархию внутри задачи, определить центр принятия решений и точку ответственности за процесс. Это также позволяет руководителю контролировать именно те аспекты, которые критичны для конечного результата, не вникая во все детали исполнения.