Defining Throughput

In this second part to my series on Throughput Accounting, I'm going to explore the concept of Throughput, starting with a definition.

Every system has a goal it is trying to achieve. For most business processes this goal is revenue - money given to the organisation by customers due to sales of product or services. Given this, 'Throughput' is simply defined as a measure of the rate at which a system is achieving its goal. It is not a measure of profit or any indicator of efficiency, it is just a measure of flow.

Throughput is often expressed in terms of 'goal units'. In for-profit organisations, these units may be dollars of revenue. For non-profit organisations it may be expressed by another measure, such as patients successfully treated in a hospital emergency ward.

When dealing with monetary goal units, Throughput (T) is often measured as gross revenue from sale of a product (S) minus totally variable costs (TVC), which are only the costs that vary directly with the system output. In a manufacturing setting, TVC is often just the cost of raw materials. Thus T = S - TVC.

In the example from my last post, a company was producing 800 widgets per month. Their TVC, for materials, was $40 per widget. If those widgets were being sold at $50, the throughput per widget would be $10 and the system throughput is $8000 per month, or around $0.18 per minute.

In calculation, this is identical to the cost accounting metric 'contribution margin'. The contribution margin is used to determine the fraction of sales that contributes to offsetting fixed costs and can be used to disambiguate some decisions, such as the purchase price example from my previous post. As Throughput Accounting manages fixed costs separately, it is not required for this purpose - but has a much broader role.

It is important to note that Throughput is measured only as the ultimate achievement of a system, for example it may be the final sale of a product or service. It is not measured in terms of production of assets that will then be processed further to achieve the ultimate goal (eg. assets sold to achieve revenue). This is inventory - which I will discuss in a later post.

A good question is how to define Throughput in the context of a software delivery engagement. Ultimately the software system supports a business process which is in turn producing revenue - so it could be defined in terms of dollars made by the business. Pragmatically, however, it is more useful to define Throughput as the rate at which software additions and/or modifications are delivered into an environment where they can be utilised by the business process.

It is tempting to measure this rate in terms of 'business benefit' (possibly also in dollars), which is the ultimate goal unit of the entire business process. This is an important thing to focus on as often the best improvements can involve organisational changes as well as software changes. However, when the software production process is the organisation's constraint (as it often is) then we are focussed on just this process alone. In which case we need to use a 'goal unit' that is reflective of the amount of the work done to produce some change in software.

In Agile software delivery methodologies there is the concept of 'story point', which is simply a relative measure of the effort required to deliver a particular requirement. Given its relative nature, we can measure it over an arbitrary time period to determine the rate of delivery of story points, which we can use as Throughput. This is effectively the same as the Agile term 'velocity' and this comparison is useful for applying some TA concepts to software delivery. I'll return to this point in future posts...