В рамках BPO могут использоваться ресурсы, принадлежащие различным сторонам: поставщику услуг, заказчику или третьим сторонам. Однако ключевые управленческие ресурсы, в частности, менеджер процесса, обычно должны находиться в распоряжении поставщика, так как он берет на себя ответственность за реализацию всего бизнес-процесса. Таким образом, заказчик сохраняет контроль через governance, а поставщик управляет процессом и встраивается в систему управления заказчика.

Конфигурационная единица (CI) — это любой компонент, который необходимо управлять для предоставления услуги. Определение того, что является конфигурационной единицей в рамках предоставляемой услуги, помогает установить границы ответственности. Если CI, например, стиральная машина, включена в соглашение, то её поломка будет считаться инцидентом. Если же она не включена, то это не является нарушением уровня услуги. Таким образом, понятия CI и границы ответственности тесно связаны между собой

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

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

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

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

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

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

Да, опыт (experience) может рассматриваться как третья группа характеристик услуги. Опыт заказчика (customer experience, CX) и опыт пользователя (user experience, UX) отражают воспринимаемую заказчиком или пользователем совокупность функционального и эмоционального взаимодействия с услугой и провайдером. В отличие от полезности и гарантии, которые можно измерить объективно, оценка опыта часто требует анализа поведения, мнений и решений потребителей, таких как уровень удовлетворенности, количество обращений за помощью или длительность взаимодействия с услугой.

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