Удельные расходы на единицу операционной нагрузки

Задача и границы показателя#

Удельные расходы отвечают на вопрос: сколько признанных расходов приходится на одну определённую единицу выполненной операционной работы за заданный период. Такой показатель имеет смысл только при явном определении обеих частей отношения. Например, «расходы на обработанную заявку» отличается от расходов на поступившую заявку, активного клиента или рабочий день.

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

Материал не задаёт способ распределения общих затрат. Если для числителя требуется распределение, оно должно быть рассчитано и проверено по отдельному контракту распределения затрат.

Зерно числителя и знаменателя#

Зафиксируйте зерно результата, например: одна строка на юридическое лицо, услугу, центр затрат, тип выпуска и финансовый период. Ключи, период, организационный периметр и версия методики числителя должны быть совместимы со знаменателем. Валюта и basis денежных сумм также должны быть одинаковыми внутри результата либо преобразованы по явно версионированному правилу.

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

Для знаменателя нужны как минимум:

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

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

Полнота, ноль и корректировки#

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

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

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

Агрегация и свёртывание#

Для совокупности групп удельные расходы рассчитываются как отношение итоговых совместимых сумм:

total eligible cost / total eligible volume

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

Пример в целых копейках RUB:

Группа	Расходы, коп.	Обработано заявок	Копеек на заявку
A	1 200 000	800	1 500
B	400 000	200	2 000
Итого	1 600 000	1 000	1 600

Среднее двух групповых отношений равно 1 750 копеек, но совокупное отношение равно 1 600 копеек на заявку. Для консолидированного показателя правильный результат получается из суммы расходов, делённой на сумму заявок. Денежные значения показаны в минимальных единицах, чтобы пример не скрывал округление.

В PostgreSQL 18 sum возвращает NULL, когда входных строк нет, а avg вычисляет среднее по ненулевым входным значениям. Поэтому запросный слой должен отдельно задавать политику пустой совокупности и не превращать неизвестные значения в ноль до проверки полноты. Это описание поведения агрегатов, а не утверждение о выполнении SQL для данной модели.

Критерии допуска#

Публикуйте показатель только если выполнены все условия:

Числитель и знаменатель имеют документированные, совместимые ключи, период, периметр и версии определения.
Денежная сумма имеет согласованные валюту, basis, знаки и правило корректировок.
Единица выпуска и правило её включения однозначны и стабильны для сравниваемого результата.
Контроль источника подтверждает полноту данных за период; пропуск данных не трактуется как ноль.
Нулевой и отрицательный чистый объём обработаны явной политикой, без подмены результата.
При укрупнении показатель пересчитывается из итоговых сумм, а покрытие остаётся видимым.

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

Вопросы для самопроверки#

Если определение выпуска меняется между периодами, используйте контракт сопоставимости версий: он разделяет исходный и пересчитанный ряды и задаёт условия запрета прямого сравнения.

Что является одной единицей выпуска в выбранном показателе и когда она считается завершённой?
Каким контролем подтверждается нулевой объём, и чем он отличается от отсутствующего счётчика?
Если две группы имеют разные объёмы, какой вопрос отвечает среднее их удельных расходов и какой отвечает отношение итогов?

Источники#

GOV.UK: Service Costing in Government - определение стоимости единицы результата и документирование ограничений расчёта.
PostgreSQL 18: Aggregate Functions - поведение sum и avg для входных значений.

The question and the metric's scope#

Unit cost answers a specific question: how much recognized cost belongs to one defined unit of completed operational work during a stated period? The ratio is meaningful only when both parts are explicit. For example, cost per processed application differs from cost per submitted application, active customer, or working day.

This is a measurement contract, not a ready-made efficiency assessment. A change in unit cost alone does not prove a productivity change: the service mix, quality, complexity, perimeter, or cost-recognition rules may also have changed. GOV.UK describes unit cost as the cost of one output unit and recommends documenting the allocation basis, exclusions, and limitations of the calculation.

This page does not define how shared costs are allocated. If the numerator requires allocation, calculate and check it under a separate cost allocation contract.

Numerator and denominator grain#

State the result grain, for example one row per legal entity, service, cost centre, output type, and financial period. Keys, period, organizational perimeter, and the version of the numerator method must be compatible with the denominator. Currency and monetary basis must also agree within a result or be converted under an explicitly versioned rule.

The numerator contract defines eligible costs, reversal and adjustment signs, financial period, currency, and classification version. The denominator contract defines the physical unit, the event that represents it, the perimeter, and the rule for deciding that an output is complete. For example, processed applications cannot be replaced by created applications without changing the metric's meaning.

The denominator needs at least:

an identifier and unit, such as an application, transaction, processed document, or another unambiguous output;
an event inclusion rule, such as accepted and completed operations, with explicit decisions for cancellations and retries;
rules for uniqueness, corrections, reprocessing, and late-arriving events;
period and perimeter coverage, including the date used to assign an operation to a period;
a version of the metric definition and unit conversions when sources count workload differently.

If operations vary substantially in complexity, a simple count combines unlike units. Use the weighted output equivalent contract: it defines the base operation, weight versions, and controls for unknown classes. An equivalent must not be introduced as a technical adjustment to a counter.

Completeness, zero, and corrections#

No counter row does not mean zero workload. Zero is valid only when the source and completeness controls confirm that no operations occurred during the period. The denominator state should therefore distinguish at least: complete data with positive volume, complete data with zero volume, and missing or incomplete data.

With positive costs and zero volume, unit cost is undefined. Do not replace it with zero or infinity. An incomplete denominator also blocks publication, even when the monetary part is fully loaded. Publish coverage status alongside amounts so consumers can see why the ratio is unavailable.

A negative counter correction needs its own business semantics. If removing duplicates or cancellations produces a negative net count, it usually signals a problem with the chosen grain, window, or correction order. Do not silently take the absolute value or discard negative rows. If the domain permits signed volume, that rule must be explicitly approved and the ratio's interpretation reconsidered.

Aggregation and roll-up#

For a set of groups, calculate unit cost as the ratio of compatible totals:

total eligible cost / total eligible volume

Do not average group ratios unless the business question explicitly asks for the average of group-level metrics. An average gives a small group the same weight as a large one and answers a different question. Preserve numerator, denominator, and coverage state for validation and later roll-up, rather than retaining only a rounded unit-cost value.

Example in whole RUB kopecks:

Group	Cost, kopecks	Processed applications	Kopecks per application
A	1,200,000	800	1,500
B	400,000	200	2,000
Total	1,600,000	1,000	1,600

The average of the two group ratios is 1,750 kopecks, while the combined ratio is 1,600 kopecks per application. For a consolidated metric, divide total costs by total applications. Amounts use the smallest monetary unit so the example does not hide rounding.

In PostgreSQL 18, sum returns NULL when there are no input rows, while avg computes the mean over non-null input values. The query layer should therefore define an explicit empty-set policy and must not turn unknown values into zero before completeness checks. This describes aggregate behavior; it does not claim that SQL for this model was executed.

Admission criteria#

Publish the metric only when all conditions hold:

Numerator and denominator have documented, compatible keys, periods, perimeters, and definition versions.
Monetary amounts have consistent currency, basis, signs, and adjustment rules.
The output unit and its inclusion rule are unambiguous and stable for the result being compared.
Source controls confirm data completeness for the period; missing data is not treated as zero.
Zero and negative net volume follow an explicit policy without substituting another result.
On roll-up, recalculate the metric from total amounts and keep coverage visible.

If any condition fails, show the underlying amounts and control status, but do not present the ratio as comparable. The related page on financial aggregation in SQL covers grain and roll-up for monetary calculations; this page adds the separate contract for a physical unit and its coverage.

Questions for self-check#

When the output definition changes between periods, use the version comparability contract: it separates original and recalculated series and specifies when direct comparison must be blocked.

What is one output unit in this metric, and when is it considered complete?
Which control confirms zero volume, and how does that differ from a missing counter?
If two groups have different volumes, what question does the average of their unit costs answer, and what question does the ratio of totals answer?

Sources#

GOV.UK: Service Costing in Government - unit cost definition and documenting calculation limitations.
PostgreSQL 18: Aggregate Functions - sum and avg behavior for input values.