A recent project has brought home to me an important insight: that the suitability of a piece of software for a particular business or need, is often as much dependent on the details of how it does what it does, as on the headline list of “features” it offers. This has important implications for how you buy software.
The example I want to share is an ERP (Enterprise Resource Planning) system. Moving material to allow product to be manufactured is a critical process for the client, but not a value adding one. Their ERP system certainly allows them to move material from stock locations to the line. Then it is moved from the line to the batch so that costs can be allocated. What’s wrong with that?
Unfortunately, the system does not tell you where the material you want to transfer is currently located – the user must drill down through several screens to find this out. Then the user has to go through multiple screens to transact each piece of material from its origin, to its destination. Finally, all sorts of approving and posting of batches, work which produces no obvious real-world value, must be performed before the transfer is complete. Even then, the software vendor has omitted the facility to print out a list of the transfers, so that a Materials Handler can go and quickly execute them in the real world — the only place they actually matter! Instead the user must transcribe the source, destination and quantity for each transfer onto a scrap of paper by hand!
What could be done in 7 clicks of a mouse instead takes 30 to 60. It is so fraught with opportunities for error that only people of Supervisor level or above are allowed to transact the material. What should take a competent Materials Handler or Production Operator seconds consumes a member of the management team for minutes. There are tens of these transactions to process every day! A significant portion of a the time of a highly paid member of staff is spent doing purely clerical tasks. What a waste!
Now let’s put ourselves in the place of the team that bought the software. I have no doubt that they asked the vendor: “Will your ERP system allow us to transfer ‘kits’ of material from stores to the line, and then to our finished product batch?” and I have no doubt the vendor answered “Yes!” Yet, we end up with the situation above where the software is clearly not fit for purpose. Who owns this problem? I’m afraid the purchasing team must raise their hand this time.
As I like to say, “If you want a Porsche, but ask for a car, you’ll get a Yugo!”
How do we fix it? Quite simply: you put a Measure of Quality on each system requirement. In this case, the measure of quality is the number of ‘clicks’ or entries required to complete the transfer of a typical kit of material. Now you know whether you are being offered a Porsche or a Yugo. You can make an informed decision. The Yugo may well turn out to be the right choice for other reasons, but at least you will make that decision knowing the costs involved!