Buy vs Build

The old argument for buying packaged software, I was reminded by Alan Inglis, is to benefit from industry best practice.  In other words, to benefit from the software author’s experience of solving your problem for other organisations, the benefits of which they have (undoubtedly) built into the package.

The theory goes that you can standardise your back office and equalise your cost per transaction (or whatever the key measure is) with your competitors, then your organisational strategy becomes one of marketing, i.e. differentiate your products with better R & D, advertise them and sell them better, always secure that your cost of delivery/administration etc is no higher than your rivals’.

Hang on a minute?  That doesn’t sound very ambitious!  It also means your costs are no lower than your rivals…

So most companies that buy a package find that, in fact, it doesn’t quite fit their requirements (or they haven’t got the bottle, or money, to change the entire organisation to fit the software).  So begins the awful job of customisation.  Anyone seen SAP extended by ABAPS?

This, in my experience is a more prevalent enterprise decision.  Whilst Alan talks about looking for packages that are different from others on the market (and therefore have low market share), I more often see enterprises choosing the established package then customising it to death in an attempt to differentiate.

I am heading for the same conclusion as Alan “basing business differentiation on a package is a business risk” but for slightly different reasons.

By searching for the “best practice” option there is a risk of achieving the worst of all worlds.  For starters, the modern enterprise needs to be agile and best practice today will almost certainly not be best practice tomorrow.  Even the young vendors in a market who have captured the zeitgeist of “emergent best practice” are sitting on the ticking time bomb of decay.  If you choose the leading package and then customise it, you often create less differentiation than you hoped, but you do subscribe yourself into a miserable future of impossible product upgrades and changes.

For me, the key is flexibility.  Leading software vendors should focus on making their products more open, more flexible, more agile.  This does not necessarily mean following SOA principles but it does mean enabling constant business change without having to write bespoke code extensions.

One Response to “Buy vs Build”

  1. Denis Says:

    I agree – it would be ideal if software vendors focused on making their products more open and flexible – but it will be the customers that must drive this change by looking for this flexibility in software that they purchase.

    My experience of medium sized software providers is that a large proportion of their profit may come from creating and supporting the bespoke changes that are required. Where this is the case the only benefit in making their software more flexible is if their inflexible product no longer sells.

Leave a Reply