How do you peel an onion in an ERP Implementation: Requirement Gathering

By: V K Ramaswamy

 

There are two similarities between peeling an onion and eliciting customer requirements during an ERP Implementation. One, the deeper you go, you reach the core, the most important customer requirements and two, unless you peel the outer layer, elicit and close the requirements mentioned in the outer layer, you will not have access to the core, the critical requirements.

 

As you peel each layer, the issues identified will become more complex and more relevant to the customer. The earlier in the ERP implementation you peel the outer layers, you close the peripheral requirements, the earlier you will come to know of the real requirements that will add value to the customer. And you will see that the level of people who give requirements go higher as you peel each layer. Let me illustrate with some examples.

 

The topmost layer will relate to requirements that are predictable and mechanical in nature. If you resolve them, the customer is not going to be happy or elated or even mildly interested. These are stuff that any ERP consultant should deliver and it is not a rocket science, the customer knows that, the consultant knows that. These requirements are stated by the junior members of the customer

team.  For example, the customer will say, 'we want a utility to load data from excel'. You can't get a more mechanical requirement than this one. If you meet the requirement in Layer 1, the customer is not going to be elated or excited, at most he will be relieved. But if you do not meet them promptly, they will escalate and will lead to customer dissatisfaction, not with the product, but with the consultant. The result is that consultant credibility is significantly eroded. 'They can't even deliver a simple data upload tool, what kind of ERP implementation are they doing', will be the constant refrain.

 

And they are true.

 

Sadly, many projects get stuck in such simple requirements, the resolution gets delayed and the requirements in the next layer will not come out or even if they do, the will come very late in the implementation cycle for them to be any practical use.

 

Consultants can handle such requirements by being proactive very early in the cycle. For example,   the customer says that they release 100 new products in a week (Jewellery Industry) on an average. You can respond with  'I have seen customers use data load utilities that can directly load data into the application. Let me deliver one for you', Then go back, work on it and deliver.

 

Other requirements of this type include requirement for automatic backup of application and data on every Wednesday, creating user profiles etc. A smart consultant can train the customer how to do these things and then move on to the next layer. I have often seen that once the customer is trained on these tasks, he is very happy to do them.

 

In my 21 years of ERP implementation, I have seen many projects where it took a long time to resolve these mechanical issues. Due this delay, valuable time was lost in understanding and resolving issues of higher layers that could add value to the customer. Such implementations invariably fail or are sub-optimal. I have been in one such implementation (I was not the consultant, by the way), I was an influencer and did not do a good job. That is a nightmare I have to live with.

 

The next layer is related to the process configuration. These requirements are provided by managers in the Organization These requirements will normally be covered in the requirement gathering document. While 70 to 80% of these requirements can be met by the standard application features, there will be few curve balls. A smart  consultant will focus on those 20% and try to provide solution for these. Examples of such requirements will include non-standard approval processes, handling unique customer processes etc. 

 

I have faced a few of these in my ERP implementations. One example of unique work flow requirement was stated as follows. 'While person X is on Vacation, any approval request should be approved by Person Y and if Person Y do not respond in 2 hours of receiving the notification, the request should automatically flow to Person Z. But if person X is not on Vacation, the notification should wait till person X processes it, even if it takes two days'. Another one was related to what is known as 'Circular Reference' in Paper Industry. During the production process of paper, the side of the reams will be cut. These are known as trims and they will be collected and introduced back into the production process. The cost of the ream should adjust accordingly. 

 

To resolve these issues, the consultant should not only have a good idea of application features, but also should understand the business process thoroughly. When customer gives a requirement, he will give them in terms of what I call 'Positions'. The smart consultant should go beyond the 'Positions' to understand the 'Root Requirement' and provide the solution. I have discussed this previously in THIS BLOG POST.

 

While consultant will develop credibility by resolving such issues, note that he is not adding ANY VALUE to the customer by meeting these requirements. Only thing he does is to instill confidence to the customer about the fitment of the product to their process requirements.  Many consultants act as if by meeting these requirements they have done all that is necessary in the project. And with this assumption, they spent a lot of time on these activities that they never move to understanding Layer 3 requirements. While in a strict sense of word their assumption may be true, this approach will not lead to any customer delight. May be customer satisfaction, yes, but delight? Definitely no

 

Only after the consultant develops credibility and trust with the managers by providing solution to Layer 2 requirement will the Senior Management will talk to him and provide him with Layer 3 requirements.These requirements are never stated in a formal environment. Mostly they will be in the form of  'I don't think ERP can do anything about it..',  'I wish....', 'Last Quarter.....', 'These auditors are crazy. In the last audit they asked us for 123 requirements. How in the world can we deliver....' etc. Most of the time, these requirements are provided outside of formal sessions, at the water cooler, in the lift, at the smoking zone or at the cafeteria during lunch. 

 

Let me give you few such requirements that I have heard in informal meet ups.
 

This is an example of a requirement stated in 'I don't think ERP can do that... ' form

 

"We are struggling with customer disputes and delay in receivables. I guess it is our internal operational issue. I don't think ERP can do anything for that", says the CFO in the cafeteria during lunch. This is the problem statement. A smart consultant will immediately probe it with 'What is the Operational Issue?' and a detailed probe will show that the customer disputes are caused due to a communication gap between the collections team, the customer and the accounts department. The solution is to configure smart notification and work flow linking all the three entities coupled with a daily report of collections due in the next five days. 

 

And then close the issue with a mail referencing our 'discussion that we had during lunch' about the 'Customer Disputes' issue.

 

Take it from me. This will definitely delight the customer. He will even be ready to pay for your additional efforts.

 

Another example, this time of 'Last Quarter...' type.

 

"Why are you looking worried?", you ask CFO while you are in the smoking area (I do not smoke. This is an example that happened to one of my consultants)

 

"Last quarter we had 10% more than normal of Vendor payments. I do not know why this happened? I joined only 4 months ago and I have no idea how to handle it. I don't think we procured anything more than normal and all our purchases are based on fixed price purchase agreements"

 

On review it was found that there were many open 'Credit Notes', where supplier is supposed to pay us money for material returned and the vendor invoices were not set off against the credit notes. Once the process change was initiated, the vendor payments CAME DOWN by 15%. Along with that a report was delivered showing the pending invoices and credit notes against each vendor. Before making any Vendor Payment, the accountant was asked to check if credit notes are available and if they were, to set off the invoice and credit notes and pay the remaining.

 

That is significant value add, right there

 

Another one, this related to 'Auditors have asked...' type.

 

"Auditors are not trusting our inventory valuation. They feel that our inventory is over valued. They feel there is a lot of obsolete inventory and have asked us to strengthen our inventory write off process.", says the CFO.

 

Here the root cause is that there is no clear process for identifying the obsolete inventory. The solution is first to define 'obsolete inventory', then to put in some stock control options like 'Lot Control and Tracking' and to ensure that all the inventory have start date and the shelf life clearly defined, automatically making the obsolete inventory disabled from being transacted and finally send a weekly report to all the stakeholders on the inventory that is going to become obsolete in the coming month or two so that they can run a promotion to push the inventory out of the system.

 

As you can see, the solution to Layer 3 requirements are not simple. They involve considering various facets and ensure that activities are coordinated. The example of obsolete inventory given in the earlier paragraph, for instance, involve process definition (what is 'obsolete?'), configuration (Lot control and tracking), process control (ensuring right location for obsolete inventory, moving the obsolete inventory to this location and making it not available) data conversion (all the inventory items should have values for Creation Date and Shelf life) etc to name a few. However, Layer 3 requirements are the ones that add a lot of value to the organization and will end up in delighting the customer.

 

In my experience, hardly any project reaches Layer 3 of requirement gathering. Most of the consultants spend their entire project duration talking to managers about how to configure this tax or how to differentiate between Local and Import Purchase accounting. That is Layer 2 at best.

 

Then there is Layer 4 requirements provided by the CEO. This will mostly relate to reducing IT costs and improving utilization and ROI. Some example of these requirements include 'User Optimization', 'User Access and Security Controls', 'IT Governance', Organizational Performance Review Reports, Branch Performance Benchmark reports etc. 

 

Another example is the one that a Senior VP in a leading Organization recently asked me. We had just completed moving the customer to Cloud. His question was "now that we have moved to Cloud, what are the process and behavioural changes that we can incorporate so that the CEO experience the benefits of ERP on Cloud?"

 

Good question. What would you suggest?

 

Only about 0.1% consultants reach this Layer. 

 

That is it. The idea is to identify and meet the Layer 1 and 2 requirements early and completely and wait for Layer 3 requirements (and Layer 4, if you are very lucky) to pour in so that you can delight the customer.

 

Happy implementing....

 

About the Author

 

V K Ramaswamy (Ram) is a senior ERP Consultant and Advisor with over 21 years of experience in all areas of ERP Implementation starting from Product Selection, Vendor Evaluation an Selection, Presales, Implementation, Upgrade and Support and Stabilization. A graduate in Mechanical Engineering from Calicut University in Kerala, India, Ram did his MBA from Kolkata University and Post Graduate Diploma from the prestigious IIM Bangalore.

 

Ram worked in manufacturing, academia and ERP Implementation. He has implemented ERP Solution in all business areas including Procurement, Inventory, Manufacturing, Costing, Order Fulfillment, Financials and Budgeting. He has also worked as a CIO of a Food Product Company and has experienced ERP from both sides of the spectrum.

 

Currently he is working as a Freelance Consultant working as Project Manager / Solution Architect for ERP Implementations, mostly in Oracle Fusion Cloud Implementations 

He can be contacted on LinkedIn, Twitter, Email (vkrama01@gmail.com) and Phone (+919880179317)