Home >

Is Santa Buying Software This Year?

An essay on why software is not a regular capital good and why it should be treated differently in outsourcing arrangements.

Posted on December 1, 2014 by Ernesto Garbarino

A pattern that I have repeatedly seen in many outsourcing arrangements is the malinvestment in software (and supporting hardware kit) by the customer for the sole benefit of the supplier.

Outsourcing arrangements vary in nature and scope so let me clarify that I am describing the scenario in which the customer has outsourced most IT capabilities other than core management and enterprise architectural ones. In a nutshell, the supplier is responsible for development, integration, testing, operations and support; however the customer pays for software licences, hardware, and/or cloud fees.

Let’s look into the economics of the described arrangement. The main assumption here is that hardware and software represent capital and the operation of such capital involves an operational expense. Such an operational expense would normally manifest itself in terms of employee wages and supporting infrastructure (office space, HR services and so on). Therefore, if an external supplier is able to provide equivalent services at an equal or lower cost, there might be a potential economic advantage.

It is worth noting than an equal cost and sometimes and slightly higher cost may still yield financial benefits such as reduced liabilities (e.g. the risk of unionisation, applicable labour laws, etc.) plus the the accounting trick of presenting outsourced services as CAPEX (as opposed to payroll OPEX) which renders the organisation more efficient in the eyes of shareholders.

For the sake of the argument’s clarity, let’s assume that all financial benefits and liability calculations have been factored in and that we are in an apples to apples comparison scenario between the cost of paying wages and the cost of outsourcing services.

Observing the presented assumptions, we can make the analogy with a supermarket that owns a float of lorries to ship goods from the central warehouse to its retail shops. If the supermarket’s COO has determined that it is best to outsource the maintenance and driving of the lorries to a third party, then we are in front of a similar scenario to that which occurs in most IT outsourcing deals.

The fallacy in the described outsourcing “strategy” is a misunderstanding of the actual capability whose cost must be addressed. There is the underlying, unquestioned assumption that says “we are a supermarket and hence we own a float of lorries” akin to “we are in IT operation and hence we own a bunch of hardware and software”.

Whether a supermarket owns a float of lorries or not is an inconsequential economic fact. The relevant economic fact is the cost of shipping goods from the central warehouse to the retail shops. How the goods turn up in the retail shops is accidental; they can well be delivered by cycle rickshaws all other aspects (time, safety, integrity, etc) being equal.

By the same token, the ownership of, say, a Siebel licence, is immaterial. What matters are specific CRM capabilities such as whether customer interactions are being properly captured, the number of profitable deals correctly identified and so on. The point here is not whether it is best to buy software as a service (SaaS) or not. The problem is considering software as a conventional capital good when, in reality, only the capabilities that are enabled by the software under consideration are relevant.

The software as capital fallacy typically leads to the following pathological corporate procurement model:

  1. Negotiate licence volume discount with a software supplier. Present 60-80% cost reduction achievement to the CFO.
  2. Run RFP for software operation with 8 suppliers. Shortlist the cheapest three. Further renegotiate to achieve even lower costs. Pick up the cheapest or second cheapest should quality and/or ability to deliver be in serious doubt.

This all works under the auspices of some hypothetical anchor price. For example, the anchored 3-year TCO for a CRM platform would have been £8m in software licences plus £2m worth of payroll expenses (£10m in total) but thanks to the “savvy” procurement strategy, the licences will be reduced down to £2m and payroll will be replaced by an outsourcing deal worth £1m. (£3m in total and hence a hypothetical 70% saving).

The problem is two-fold:

  1. Software is not a conventional capital good and therefore there is no baseline price that establishes how much software should cost. Software only brings economic benefit in so far as it meets requirements that are very specific to the buyer. Hence, a given CRM software licence could be worth £100m for one customer and £10k for another. Expensive software has no “latent value” inside as though it was Scrooge McDuck’s vault.
  2. The outsourcing supplier’s business model relies for survival and growth on the proliferation of software components and consequently in a constant increase in their complexity. In the retail analogy, the third party’s key interest is that the supermarket adds the maximum number of lorries to its float and that they brake often so that more drivers can be deployed and more lorry servicing is performed, respectively.

For a supermarket, owning lorries and outsourcing their driving and maintenance is a terrible strategy. It is much better to outsource the entire shipping operation and be agnostic as to what means are used to deliver the goods. It could well be that for some shops, vans are more efficient than lorries; however, how the supplier optimises its operations is of no concern to the supermarket.

In conclusion, buying software for an outsourcing supplier might be the worst gift an organisation can make to its balance sheet. Investing in determining what the organisation’s required capabilities are is always a worthwhile investment. Last but not least, it is never a good idea to shop for a general domain solution (e.g. “a Billing solution”) but to look for specific, detailed capabilities with no special emphasis to the domain they happen to fit in.