Cj и Sj связаны между собой через операнд Nj, который определяется как сумма этих величин: Nj = Cj + Sj. Здесь Cj — количество обращений, обработанных j-той группой и закрытых без рекламаций, а Sj — количество возвратов на доработку в эту группу. Эти два показателя вместе формируют полную картину обработанных обращений, участвующих в расчёте метрики First Time Resolution (FTR), и позволяют корректно отразить качество работы группы.

Альтернативные подходы к определению максимального числа параллельных задач включают использование эмпирических данных (например, анализ собственной продуктивности), методику Top 5-10, фокусирующуюся на самых критичных задачах, и принцип числа Миллера (7±2 элемента). Также практикуется гибкое реагирование на изменения: еженедельная оценка текущей загрузки и динамическое изменение лимитов. Некоторые применяют методы Agile, такие как Scrum, где количество задач определяется объемом спринта.

Термин Service Capacity Management предлагается заменить на System Capacity Management, поскольку понятие «услуга» может быть связано с разными уровнями: бизнес-процессом, ИТ-системой или ресурсом. Если ИТ-услуга определена как обеспечение бизнес-процессов, то управление мощностью должно относиться к бизнесу, а не к услуге как таковой. Аналогично, если услуга ассоциируется с ИТ-системой, то правильнее говорить об управлении мощностью системы, а не услуги.

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

Баланс считается достигнутым, если обе метрики имеют близкие значения, и при этом общая оценка K = √(K1 × K2) находится на приемлемом уровне. Например, при K1=80% и K2=80% K=80%, что показывает сбалансированную работу. Если же K1=90%, K2=70%, то K=79,4%, что сигнализирует о небольшом перекосе в сторону своевременности. Критический дисбаланс (например, K1=100%, K2=10%) даст K=31,6%, явно указывая на необходимость коррекции процесса.

С 1990-х годов подходы к обслуживанию клиентов стали более структурированными и профессиональными. Если раньше предприниматели использовали спонтанные методы, такие как объявления на рынках или в автомобилях с надписями «Доллары куплю», то сегодня компании разрабатывают детальные стратегии, направленные на высококачественное удовлетворение покупательского спроса, что отражается в их официальных формулировках миссии.

ITIL 4 не упоминает приоритизацию в процессе решения инцидента (Incident handling and resolution), потому что она переквалифицирована из отдельного шага процесса в фактор успеха всей практики управления инцидентами. Приоритизация остается важной, но теперь рассматривается как более широкая концепция, которая необходима для достижения основной цели практики — минимизации негативного влияния инцидентов. Поскольку приоритизация может происходить многократно и на разных этапах работы с инцидентами, её нецелесообразно ограничивать одним отдельным шагом в процессе. Вместо этого она представляется как элемент, который требуется для эффективного выполнения всей практики в целом.

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

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

Для корректного учёта параллельных задач важно фиксировать начало и окончание совокупности действий, а затем оценивать реальное распределение времени между ними. Например, если сотрудник ведёт телефонный разговор и составляет документ, общее время разбивается на доли (изначально 50/50), после чего уточняется на основе личного наблюдения. Это позволяет избежать завышенных оценок и получить реалистичную статистику. Ключевой момент — отказ от восприятия одновременной работы над несколькими задачами как полного выполнения каждой из них за отведённое время.