I’m a child of the Fifties and Sixties, so one of my favourite entertainers was Danny Kaye, who was undoubtedly a very nice and very funny man. At work recently I’ve been reminded of his take on the H.C. Andersen story, “The King’s New Clothes.”
I was asked by a client to examine productivity for a heavily customised ERP implementation. Suffice it to say productivity was low, 3GL-like, so I set off to find documentary evidence about what we all “know,” – that is, once you customise a package beyond about 30 percent, you cannot consider it to be a package anymore and development productivity falls as a result. The more you diverge from the original the lower the productivity.
In this case the end client insisted in going way beyond the tipping point, to where the great majority of the code was handwritten, while trying to hold the developers to the notion that package development should be much less expensive than hand-cut code. In fact, the changes to the code had gone so far that the software could not be updated to the latest version, hence providing support headaches to rival the development productivity issue.
So, it should be easy to find the evidence to show the effect of extreme customisation on development productivity. Ah, but it isn’t.
No one seems willing to stand up and say, “We customised an ERP package and got really poor development productivity.” Databases only contain the successes, but that’s hardly surprising – nobody likes to look like a failure. There’s a certain amount of indirect evidence, including papers that set out the consequences of customisation, but little or no hard data. So that got me to wondering why there was no data.
The only conclusion that I can come to is that we are unwilling to look unwise. We are like the courtiers in the story, unwilling to look foolish by saying, “This will cost a lot for the software if your business is so complex that we need to heavily customise the code.” The sales pitch is still, “Buy ERP and cut your development and support costs.” The caveats that should be applied are simply not stated because honesty would scupper the sale.
Client technical experts must be honest with their management too. They should stop trying to tick the box, “We use packages to cut development costs.” Unless they too are realistic, they are guilty of sophistry at the very least.
ERP is supposed to solve all our business process needs, and it can do, but with provisos. Clients must either change their business processes to match the solution or live with the fact that to get the business benefit of using ERP they must accept that the total cost benefit of business change comes at a price – the software will be as expensive as writing it yourself.
Is this a disaster for ERP suppliers like Siebel, SAP and others? No, of course not. Their solutions bring quantifiable business benefits associated with standardisation of process development, uniform front ends and powerful portals for business; it’s just that they are not cheap.
Time for the little boy to stand up and say, “The King is in the altogether… he’s altogether as naked as the day that he was born.” A bit of honesty with clients and the setting of correct expectations would save a lot of commercial battles later.
Managing Director, DCG-SMS