ERP Implementation In A Nutshell: 2/5
A Functional Consultant's Perspective
CRP1 is not always gloom and doom. In process-driven organizations, it can lead to a consensus solution, comprising of a few workarounds and some process changes. While for the differences in business processes you need not do much except noting down the same in the AS-IS document, workarounds need some work. You need to update the TO-BE document if the workaround being used originated from the customer’s side. And then you need to update the SEED instance with modified setups if any.
It is essential to maintain the sanctity of the SEED instance, even though it keeps evolving till you go live. What makes this process a bit difficult is that the strict requirement of the instance not having any transaction at all. Because when you clone the PROD (production) instance from it at a later date, you don’t want to see numerous test transactions throughout its lifecycle. But then without testing with a couple of transactions, how do you make sure that changed setups will work in the production environment?
You need to keep cloning the SEED after any setup change and keep testing all the processes just to make sure everything is fine. It is a tedious process. But if performed religiously, it will save you quite a few sleepless nights before go-live. Things have changed in the last two decades. We did not have the luxury of automated testing during the project execution phase. These days both system integrators and customers give due weightage to repeated, error-free testing – as opposed to superficial manual testing – and allocate resources for the same.
Having put your own house in order, you will prepare for taking the unresolved conflict of CRP1 to a different level. One crucial part of it is to weaponize the gap analysis document. The document, usually a gigantic spreadsheet, has anything between 50 to 200 entries by now. Given its strategic importance, I feel it is better to specify the column heading and hence the data that it should ideally contain.
Do a grand total and hold your breath! If it is more than the sum of hardware cost, licensing cost and implementation cost, you had won the game before it even began.
It is anyway a win-win situation for you. If the customer goes for customization, your company makes money. Otherwise, it has to crack the whip and make its people fall in line.
The third outcome – even though a remote one – is also to be considered. The customer may get into trauma freeze and scrap the whole project. So make sure that you send the sweetest manager from your side to approach the toughest CxO level guy on the customer side. Do not give in to the common temptation of doing it the other way round. You do not need a tough guy as the messenger. The gap analysis document, in itself, should be able to inflict substantial damage. It is full of weapon-grade uranium and plutonium!
To make sense of the ensuing mêlée, you need a bit of cognitive empathy and good knowledge of office politics. Usually, the idea of implementing an ERP system is first mooted by a person at the CxO level, even though the final decision is taken by the CEO.
More often than not, it is the CFO who sets the ball rolling. In that case, the CFO will quickly disentangle himself from the sticky situation that he is obviously in. He will summon all his staff and issue a diktat that the existing finance processes should be changed overnight to match those of the ERP system. No questions asked; no dissent entertained. Surprisingly the CFO’s generally get away with such grossly autocratic behaviour. Used to the twisted labyrinth of the accounting system, the finance staff has typically no issues with further complications. After all, it is the highly abstract maze of general accounting that ensures their survival within an organization. Otherwise, no corporation would pay so much for performing some basic arithmetic operations on a set of numbers with lots of zeros in them.
You would have a tough time if the COO happened to float the idea of ERP implementation in the first place. In him, you have the quintessential “field guy” whose sales and operations staff face the rough reality of the field every day. Aggressive and loudmouth as he is, he would not mince his words while blaming you, the system integrator, for the impasse. He is burdened with a problem he does not have the technical expertise to solve. He would invariably reach out to the ERP vendor whose sales team had approached him at the very beginning.
The nature of the blame game is usually decided by the corporate culture of the customer. If it is a manufacturing firm accusation hover around making false promises and cheating. A service firm often talks about over-promising and under-delivering. A trading organization generally responds by demanding some concessions in future license and support fees. Its people are not terribly upset by the “immorality” associated the first deal. As long as numbers work out, they are not bothered with ethics and all that.
The ERP vendor, predictably and conveniently, shifts the blame to you and your company. The crudest and probably the meanest way of defence is to cast doubts on the capability of the implementation team. What makes this attack indefensible is the fact that a software product company’s people know much better than anyone else about the product they created. It is futile to defend your professional expertise in this case. The vendor in question is exercising its creator’s privilege. A better defence strategy on your part is to revisit the gap analysis document and make it water-tight. Make sure that all the workarounds suggested have their origin in some shortcoming of the ERP product or the other.
The customer calls for a tripartite meeting, ostensibly to reach a consensus and find a way out of the impasse. In reality, it wants to determine in a quick and dirty way who among the system integrator and the ERP vendor can be proved guilty. It needs to convict someone and attach the stamp of justice to the decision. Because the convict, whoever it turns out to be, is supposed to pay for the fiasco.
The best option of both the system integrator and the ERP vendor is to close ranks against the recalcitrant customer. One just needs to prove the customer’s peers do not follow the archaic and non-standard business processes that it does. An ERP application is designed based on the business processes followed by the firms operating in a particular business segment. Creating an ERP system is more about consensus and best practices than following a deviant who in its infinite wisdom, chooses to do things differently for no apparent reason.
But that rarely happens. What you get to see is a prolonged argument, laced with liberal doses of animosity and bitterness, that stretches over two to three days. In the end, the ERP vendor agrees to close a handful of gaps by accepting them as enhancement requests. Some of the enhancements are to be fast-paced to release before go-live. Others would wait till the next rollup patch. The customer would agree to makes its people fall in line in most of the cases. The system integrator agrees to do some customizations at “zero margins”, whatever that means.
It looks like none of the three parties actually won. Everyone partly absorbs some of the costs. However, that is only an illusion; a deliberately created one. Over the next decade, the customer is the only one who loses. The system integrator builds customizations in such a way that it can only maintain. The ERP vendor keeps the customer hooked to enhancements in every release cycle. So the support revenue flows in uninterrupted. Both – the system integrator and the ERP vendor – have effectively locked in the customer for nothing less than the next ten years.
Before I end this part of the multi-part article, I must put a caveat. The kangaroo court proceedings described above do not take place if neither the ERP vendor nor the system integrator feels that the customer in question represents a key account. For every key account, there are tens of not-so-important accounts. What happens to those customers? Or more precisely, how do you deal with them?
Well for the commoners, the best strategy is to allow the customer to get stewed in his own juice. You submit the gap analysis document with some mock ceremoniousness. And then you don’t follow up with the customer about the resolution status of the individual gaps. You wait patiently for the customer to come back. You continue to be on their premises and enjoy their hospitality. The period of idling is undefined. The system integrator obviously incurs a cost for the lost manhours. But you can recover the cost subsequently, in small instalments, from customizations and support.
Also, keep in mind that the waiting period may look undefined in the beginning. But empirical evidence suggests that even the toughest customers break in less than a month.
