Ten concepts that every ERP Consultant should know.

Many consultants and even SIs approach ERP Implementation as if it is a simple software implementation. The thought seems to be 'Get the data in, get the masters in, do some training, develop a few reports and go live and we are done'. As Brian Sommers points out in his wonderful article, in the era of Cloud ERP, the situation has become worse. Consultants do not even visit the customer to gather the requirements. ERP implementation has become a mechanical activity of porting the data from the spreadsheets, of just transferring the current set of inefficiencies to a newer, exotic and expensive application.

All that the consultants know is to navigate and demonstrate the features of the application. They know how a process cycle, say Procure to Pay, works in ERP. They do not know the implications of each process. For example, they do not know understand the incentive implications of their solutions. The consultants do not add any value. They are just like pharmacists who dole out medications without understanding the effects of the medicines. 

I mentioned incentive implications. Let me give just one example. Let us look at the material management policy. One of the critical decisions is 'Stocking' Vs JIT. In case of stocking approach, the focus is on bulk purchase and stocking to avoid stockout situations. The purchase manager is measured on how much volume discount that she has managed to obtain. The higher the volume, the higher the discount and better are the chances of promotion for the purchase manager. However, bulk purchase of material loads the costs on inventory storage, handling and protection. This directly (and negatively) impacts the performance of the materials manager.

I am not saying that ERP Consultant should provide solution to this issue. This may be a part of the 'Organizational Change Management' initiative. But she should be aware of the incentives impact of most of the solutions that she proposes. 

In my opinion, there are 10 business concepts that an ERP Consultant should know. Knowledge of these concepts will transition her from an average to exceptional consultant. She will add immense value to the implementation by designing the solution in line with these concepts. The ten concepts are shown in the diagram below.

1. Thin GL: Companies maintain two books of accounts. One is called the 'Day Book' where the details of the transactions are entered and the second is the ledger where the end of the period summaries of the transactions are transferred from the day book. In ERP terminology, 'Day book' is termed as 'Sub-ledger' and the ledger is termed as 'General Ledger' or GL. The concept of 'Thin GL' says that original transactions should not be directly entered in GL and only summary should 'Flow' from the Sub-ledgers. Many consultants are unaware of the concept and train the users to enter many original transactions directly in GL as journals. Another bad practice is to transfer the transaction details to GL causing data duplication and multiple sources of truth. Both these actions make the GL 'Fat' and unwieldy and negate the major benefit of an ERP implementation. 

2. Lean ERP: The concept of 'Lean ERP' says that ERP should be designed to eliminate waste. There are many wastes like 'Data Duplication', 'Process Duplication', excessive manual entry and oversight, degradation in performance leading to wastage of time etc that can be eliminated by properly designing the ERP. (Check out my blog post on How ERP can help implement Lean to learn more about this). For example, if you consider the goal of establishing a paperless office, one has to consider many aspects into the application design including data entry, notifications, approvals, digital signature and automated forwarding of critical documents to relevant users. It is important for the consultant to understand the concept of 'Lean' if she has to help the customer achieve it.

3. Maker - Checker: Maker - Checker or 4- eyes concept says that there should be at least two different people involved in any transaction, the creator and reviewer. This concept ensures thorough oversight of every transaction. This can be achieved by process modification like putting in a 'Hold' which can be released only by the checker or by use of Notifications and Approvals. A consultant that designs maker-checker will add significant value to the customer and smoothen audit processes. I have seen many ERPs, in fact almost all of them, including the ones that I have worked on, where this basic concept is not understood and implemented.

4. GIGO: Everyone thinks they know GIGO. It stands for Garbage In, Garbage Out. However, ERP is not usually designed to ensure Garbage do not go in. Duplicate Customers or Vendors (John Smith versus Mr.John Smith), duplicate Items (3" Screw versus 3 Inch Screw) and other duplication abound. Consultants do not put in place a process to handle data duplication since they do not consider GIGO as a part of the application design. Data conversion is a process that is riddled with GI. Usually the data is full of duplication, incompleteness and plain errors which the system validations are not designed to identify. Sometimes the detail data do not match with the values in the Control Accounts in GL. With all this Garbage going in, companies struggle to handle the Garbage that system throws out in the form of unreconciled transactions, period closing errors and delays (Significant delays) and general dissatisfaction with the application. Not handling multiple application holding different views of the same data is another example of not considering GIGO (for example, both CRM and ERP hold customer information with redundant and conflicting information).

5. MOSCOW: This is a concept in requirement gathering that helps the consultants prioritize the requirements based on 'Must Have, Should Have, Could Have' criteria. Without a understanding of this concept, a consultant prioritizes all requirements with the same priority and spends equal time focusing on requirements that affect 98% of transactions and the requirements that affect 2% of the transactions. Even when they realize the concept, they are not able to ask relevant questions like 'How many such transactions occur in a year', or 'Proportion of such transactions' etc. Most of the challenges in an ERP implementation that I have seen is when Consultant struggles to provide a solution to a transaction that occurs once or twice in a year!

6. 4 Layers of requirements: As discussed in my blog post, requirement gathering is like peeling onion. The top layers are simple and mechanical in nature and the earlier you resolve them, you get to understand the critical requirements of a customer that will lead to customer delight. The critical requirements are undocumented ones which the consultant will come to know only after she proves her worth by providing good solutions to the requirements from the earlier layers. Without understanding this concept, the consultant feels happy when she has provided solutions to the second layer of requirements, but then wonder why the customer is not delighted. Operationalizing this concepts means having to transfer most of the mechanical load to the customer team member as soon as possible, providing solution to the top two layers of requirements quickly etc. 

7. Analytical versus Transactional Information (Original Vs Derived Information): The requirements provided by the customer can be resolved in multiple ways. As I discuss in this article, it is very important for the consultant to differentiate the requirements given by the customer into Analytical Vs Transactional information. Transactional information calls for configuring the application for the requisite data entry, while analytical information calls for a reporting solution. As I explain in the article, 'Needing a Depot-wise Trial Balance' can be resolved by configuring each Depot as a 'Balancing Segment' in ERP or by providing reports showing the required information. Converting analytical information into transactional information and configuring the system to capture data is the most frequent issues that I have observed in ERP implementations. 

8. Single Source of Truth (in Master Data Management): Many Organizations that implement ERP has multiple applications in their application landscape. Some of these applications 'Talk to' ERP and some do not. However they may refer common information. It is very important to create an 'Owner Information' matrix to identify the owner of each information. This will help the consultant identify the 'Single Source of Truth' and design her solution accordingly. Remember that this decision has implications to Solution Design. In one of my implementation for dairy industry, there was a 'Milk Procurement' application that had the details of the Farmers. So in ERP, we decided not  to replicate the Farmer information and instead use a 'Dummy' farmer in ERP to raise the consolidated PO for the month on, rather than creating each Farmer as a Vendor in ERP and creating data duplication and thus avoiding the concomitant errors.

 

9. Scalability in Data Conversion (Plan for future requirements by creating flexibility at the stage of data conversion.: When you ask a customer about the data, they will give you information based on the 'Current Data'. It is for the consultant to ask additional questions and consider Scalability and Margin of Safety into data conversion. While the current data may call for 10 Fields of data for example, the consultant might decide to keep four additional fields as 'Spare' and fill it with some default values. This will ensure that as the business grows, the configuration and reports do not have to be significantly modified to handle the new requirements. This will also ensure an elegant solution and convince the customer that consultant has understood their requirements and the expected growth.

 

10. Exception Reporting (humans will make mistakes): I have seen that Data conversion followed by reporting are two areas where the lowest focus is given during implementations. When it comes to reporting, the focus is on transaction reports (PO, Sales Invoice) etc, followed by reconciliation reports (Creditor / Debtor Ledger, Inventory Valuation report etc). One area where no focus is given is the 'Exception Reporting'. These could include Access Violations, Failure of Maker Checker, Process Failures, Incomplete Transactions etc. More than the reports themselves, the value add from these reports is the discussion that precedes their design. This has to be initiated by the Consultant. Sadly, I have not seen a single implementation where Exception Reports were discussed during the project implementation. 

As you can see, most of these are inter-related. For example one of the exception reports will be Maker checker failure. For this report to work, the concept of Maker -Checker has to be incorporated into the design. MOSCOW and 4 Layers of Requirements go together. 

The objective of this article is to present some of the concepts that a Consultant should know. If the consultant knows these concepts, she will add significant value to the customer and ensure a delighted customer.

What more can you ask for?

 

About the Author

Ramaswamy Krishnamurti (Ram) is a Senior Freelance ERP Project Manager and Solution Architect 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.

He has implemented more than 25 highly successful ERP implementations. He has worked on Scala, Peoplesoft, Oracle EBS (11i and R12) and Oracle Fusion Cloud in various roles including CIO, Program Manager, Delivery Manager, Project Manager, Solution Architect, Functional Lead and Consultant. One thing common among all these roles is an average customer satisfaction rating of more than 90% over his over 20 years of ERP Implementation expertise.

In a career spanning more than 30 years, 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. Having done many implementations in India, Ram knows India Localization like the back of his hand.

He loves ERP Implementation and the value that it can add to a customer business and the smile on the face of a delighted customer.

He is currently looking out for opportunities. You can download his latest CV from his LinkedIn Profile www.linkedin.com/in/vkramaswamy. He can be contacted on LinkedIn, Email (vkrama01@gmail.com) and Phone (+919880179317)

Work with him for a perfect, on-time ERP Implementation.