The Boom Years

Given the present ERP market conditions, this narrative may sound like a historical anecdote. But trust me once upon a time, there used to be a lot of greenfield ERP implementations. About two decades ago, the democratization of ERP systems began. Before that, ERPs were considered to be expensive stuff, meant for mega-corps only. Another distinctive feature of the boom compared to the previous one, which "computerized" office documents and spreadsheets, was that computers were already in place. So the change was not as apparent as movement from papers to computers. Most of the customers I dealt with already had a collection of isolated PC-based systems in place. So all of us - my colleagues and I- had to deliver on the ERP's promise of seamless integration and completely floppy-less, as opposed to paperless,offices.The standard ERP sales narrative of those days used to belike this: We give you a pre-built system. That can be made to work for any business scenario by doing the right configurations. Our functional consultants would interact with your business people, understand your requirements, and configure that system. Thenceforth your own businesspeople could take care of future changes,which would be tackled by some more configurations only. Summing up, it boiled down to 1 single system, minimum 10 years of life and 0 lines of code.

Dramatis Personae

So we, the functional consultants, had to carry a lot of burden on our shoulders. Looking back, I would not crib about the "burden" part,though. We used to get paid much more than developers.Also, we only had to interact with the senior business folks on the customer side.The journey would usually begin with a kick-off meeting comprising the CIO and the whole hierarchy below him plus a few hand-picked people from the business. The latter used to be known as superusers or power users.Those were the guys who were supposed to take care of the ERP system collectively after we left at the end of the implementation cycle. After the made-up bonhomie of the kick-off meeting, things would invariably start on a sour note. It turned out repeatedly that none of the stakeholders was actually in a mood to welcome the new system. The reasons were different, though. The IT department folks would fret at their powers being curtailed substantially because of the involvement of the business people. The business guys did not want to come out of the comfort zone of their old,familiar legacy systems–however flawed those were.The power users, sandwiched as they were between the ordinary users and the consultants, did not want to be political scapegoats.

----- ~~~ -----

The Burden of Past

Icebreaking used to be our first assignment, even though an unofficial one. To succeed, one needed to win over his functional counterpart from the business. Otherwise,things would get into infinite bureaucratic loops, and the entire project would eventually fail. So your social skills would be tested to a great extent in this exercise.The first official phase of any ERP implementation to this day is to document the current baseline of customer's existing business processes. Its nickname is the "AS-IS" process. You basically get to know from your powers users how do they conduct their day-to-day business. The key to success in this phase is to interact well and do not,as a rule, refer to either the existing system or the upcoming system. You just talk about processes,sub-processes, their frequencies and the roles and responsibilities of the associated employees. At the end of the AS-IS phase, you document everything that you learnt. You note down every single business process that the future system – the ERP system – would have to take care of. This document defines the scope of the project. During the AS-IS phase, no user – superuser or other – gets to get a glimpse of the ERP system. The idea is to not allow them to be judgemental about a system that they know little about. They may judge the system only after going through a thorough training about its various functionalities.So, naturally, a long training session spanning a few weeks follows the AS-IS phase. During this phase, you only show them the pieces that they will interact with in the future. So you don't go to the setup screens. But you walk them through every transaction screen and report. Another thing to avoid in this phase is to get into solution development mode during training. For solution design, there is an allocated phase. And also you can venture into that activity only after you have the complete picture sufficiently clear on your mind.

A Vision of the Future

The solution design phase is called "TO-BE" or the definition of future processes. Also, this is when things get heated. Superusers finally come to know that the ERP system would never fit into their business processes as snugly as the existing legacy system does.Even if you configure the system well, with all the options pulled out, you could never meet the fitment level of the legacy system. This is where your skill as a functional consultant is tested to the max. Both your product knowledge and the knowledge of the customer's business should be great to achieve a proper configuration. You need to be an excellent negotiator too. Playing hardball and stating that the ERP system in question has been designed after studying the business processes of many world-class companies would take you nowhere. When the power users stonewall, you have but few options left. At the end of the phase, you produce a lengthy document stating how each business process would be implemented in the ERP system. You also create another document informally called the gap analysis document. This would list all the business processes where the ERP system in question failed to provide a satisfactory solution even after negotiations and workarounds.

----- ~~~ -----

The Tech Holdups

With the burden of a reasonably outrageous amount of disagreement, both the parties – the consultants and the power users – prepare for an activity called conference room pilot or CRP in short. You will expose the ERP system, configured specially for your customer, to its end-users for the first time. They will attempt to do their regular transactions on the new system sitting in a conference room. While the superusers go socializing to invite their domain users for the grand event called CRP, you approach your DBA for a fresh instance. The DBA, usually a grumpy fellow, reminds you gruffly that you actually need two instances – CRP1 and SEED. Instead of arguing with him, take his advice seriously. Anyway, in the world we live in, you do not argue with DBAs, managers, cops and your wife. In the SEED instance, you will carefully, cautiously, do all the setups, creating no transaction. You will cross-check all the configurations at least twice before meekly handing over the instance back to your DBA. The DBA will clone it and create the CRP1instance. While the former will be touched rarely, that too only after proper authorizations, the latter would soon turn into a battlefield! On the day of kick-off, make sure that you have your superuser by your side, literally so, before you start addressing the crowd. Also, it would help matters immensely if you can get the CIO as the chief guest. It would be of great help if you somehow kept the AC temperature at about 18 degrees Celsius instead of the usual 25 degrees. Because you will get reactions from users varying over a broad spectrum – from unhappiness to debilitating anger. None of them will feel curious, natural human response when faced with something unknown and not overtly threatening. Before forming a harsh opinion of them, remember that it is the very absence of curiosity that makes them suitable for the low-level desk jobs they do. In fact, it is our socio-economic system that has systematically annihilated curiosity in people, so that when chained to a desk for 8 hours a day, they would not protest. ERP systems are basically transactional. It is but natural that such a system would be used by people who perform routine jobs. Don't reason with them beyond a point. Negotiation makes little sense, as the other party is not skilled enough to evaluate various alternatives that you would propose. It is better to leave the job of managing their respective herds to the superusers and start documenting the gaps meticulously.

----- ~~~ -----

Turning the Table

CRP1 days would invariably be difficult, with long working hours in an emotionally charged environment. If you want to secure your future, you need to stretch yourself beyond the office hours. You use that extra time to find at least one workaround solution for every unresolved gap. On the last day of CRP1, you would announce that the ERP solution you are implementing allows extensive customizations. And with the help of customizations, all the gaps can be resolved. But then each customization would be charged extra based on effort estimate. This last bit requires some acting skill. You should never appear to be a sales agent while selling customizations on behalf of your company – the system integrator. The announcement would lead to a collective sigh of relief. And CRP1 would end on a cheerful note. None of the customer's men would have the slightest clue about the trap they mentally walked into. In the next part of this article, we will see how the game suddenly changes in your favour.