throughput

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

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