Throughput accounting for hybrid SaaS + consultancy

throughput-accounting.md

Throughput Accounting

https://chronologist.com/blog/2012-07-27/theory-of-constraints-and-software-engineering/

Measures

• Throughput: TE is the rate of cash generated through delivery of working code into production. It is computed as sales price minus direct costs, such as packaging, delivery, installation, training, support, and networking.

• Investment: I is all money invested in software production systems plus money spent to obtain ideas for client-valued functionality. This does not apply to time spent by staff (that's Operating Expense). It does apply to the money spent on by-the-hour contractors.

• Operating Expense: OE is all money spent to produce working code from ideas. It is primarily direct labor of software engineers, but it also includes selling, general, and administrative costs. So, our fixed overheads.

• To repeat, Throughput: T = Revenue - Totally Variable Expenses

• Net Profit: NP = T - OE

• Return on Investment: ROI = NP / I

To make the correct decision, you need a positive answer to one of these three questions:

• Does it increase throughput T?
• Does it reduce operating expenses OE?
• Does it increase the return on investment ROI?

Favour, in order:

1. Increase in T
2. Decrease in I
3. Decrease in OE

As a software product team

Throughput = capability delivered to production (assuming they meet demand). this includes adding new capability, as well as improving existing capability.

Inventory / WIP = undelivered capability.

Investment = nothing; it's all covered by OE.

Operating expenses = all our overheads, including our time (salaries).

Capability = an ability to do something one either requires far more effort to perform via some other more manual means, or some entirely new ability.

Production = the environment where the capability produces value.

A more optimal software product team system

1. Increase T: Deliver more capability in the same timespan.
2. Decrease I: Impossible; it's already zero.
3. Decrease OE: Reduce the cost of software and services. Have less people on the team. (Both are counterproductive to 1. above.)

As a learning program consultancy

Throughput = new programs in use by paying users.

Inventory / WIP = new programs not yet in use by paying users.

Investment = nothing; it's all covered by OE.

Operating expenses = all our overheads, including our time (salaries).

A more optimal consultancy system

1. Increase T: Delivers more new programs in the same timespan. Do projects that earn more. Charges more for projects.
2. Decrease I: Impossible; it's already zero.
3. Decrease OE: Reduce the cost of software and services. Have less people on the team. (Both are counterproductive to 1. above.)

As a SaaS business

Throughput = access granted to paying users

Inventory / WIP = paying users not yet granted access.

Investment = what we spend on granting access to paying users. time spent processing the data. also a small fraction of the total infrastructure spend.

Operating expenses = everything else we spend. all the non-access-granting-specific costs. all other overheads.

A more optimal SaaS business system

1. Increase T: Grants more access in the same timespan.
2. Decrease I: Impossible; it's already zero.
3. Decrease OE: Reduce the cost of software and services. Have less people on the team. (Both are counterproductive to 1. above.)

Forms of demand

Value Demand: all the demand that eventually produces Throughput.

Failure Demand: demand created by a failure to produce value for a previous demand.

E.g.

• Repeatedly answering the same questions instead of writing an FAQ. Not consulting the FAQ and asking the question anyway.
• Redoing work due to missing information, misunderstanding the need, or producing poor quality.

Forms of waste

The Investment into Inventory that never completes Throughput.

Any effort beyond the necessary Investment to complete Throughput, either due to having to redo things more than once (failure demand due to poor quality), or because the process itself is too complex or arduous (failure demand, or extra mandatory effort, due to presence of debt).

What is 'debt'?

Technical debt is within the code and/or data in our software systems. E.g. half-finished features, or an architecture that prevents adding new capability.

Knowledge debt is within our documentation / support materials. E.g. missing or incorrect FAQs.

Process debt is within our system of work. E.g. doing things because of tradition, rather than because they provide value.

It reduces Throughput: we have to apply extra effort when delivering.

It generates Failure Demand: we do things incorrectly, or more than once. We distract people with things they can't succeed at (like asking them to do something without providing all the necessary information).

It creates Inertia: we are unwilling to pursue new capability due to the high debt associated with the area in which the capability would/does exist.

Notes from @tendon:

Throughput T = R - I = 80 is not quite right. TVE is not equal to investment.

If you are in a SaaS situation, you need some sort of "periodisation." Either by time periods (quarters) or better by releases.

First: make a distinction between Operational Throughput (think "User Stories") and Financial Throughput (Think $$$). In SaaS you need to relate number of subscribers, their Live Time Revenue and periodic/release Sales, and features/stories in period/release.

This post is wrong, it assumes time from salaried people is Investment; it's not. Need to rework the whole doc.

Salaries are typically Operating Expenses in Throughput Accounting.

So I updated it, @tendon, and the conclusion I've reached is that from a TA perspective, due to a 'zero' Investment (all costs are OE), we have two choices: become more effective/efficient(do better things / do things better), or do cost-cutting exercises (which we're far away from needing to do).

I've got Logical Thinking Processes by Dettmer, I'm going to take a swing at mapping our value-stream out with that and see how it aligns with my intuitions about where our constraint is and how we'll apply the focusing steps to it.

Refrain from thinking about "cost cutting" - usually it leads to making the situation worse.

The whole point of constraints management is to figure out where to invest. For instance, get the developers new computers to cut down build times is an Investment. You would consider this when comparing investment alternatives. Does buying a Dell XPS 13 give more than a T460 from an Throughput perspective? Always reason in terms of deltas.

If you need to become more "effective/efficient" beware: if you act on anything that is not the constraint, you are not going to improve the situation; and possibly even lose money. Before you act, learn to identify the Constraint!

Also, there are many low hanging fruits in focusing on improving Flow Efficiency rather than increasing Operational Throughput. Do the former first; and the latter later when there are no more gains in Flow Efficiency.

Never - and I mean NEVER - trust your intuition about where the Constraint might be. Don't even formulate an hypothesis. Either you measure with metrics, or you observe, or you infer with logic (Dettmer helps in this last case).

Besides, for more precise notation, I suggest using the following abbreviations.

• TH to indicate Financial Throughput (the one you have written about above)
• TP to indicate Operational Throughput (widgets/hour or user stories/day).