Seven Mental Models for an effective ERP Implementation

The Short URL for this post is https://goo.gl/FCXHxx

I am fascinated by the relevance of number seven to ERP. Earlier I had written articles on 'Seven Habits of Highly Effective ERP Consultants' and 'Seven Flows to be Considered in an ERP Implementation'. In this article I am discussing 'Seven Mental Models for an effective ERP Implementation'

Mental models are thought processes that help us make better decisions. They give us perspectives that we otherwise lack. The more the number of mental models that we have the better will be our analysis and decisions. This article gives an exhaustive list of mental models. Here are the seven mental models that every ERP Consultant should have. 

1. Pareto principle: Named for Italian polymath Vilfredo Pareto, who noticed that 80% of Italy’s land was owned by about 20% of its population, the Pareto Principle states that a small amount of some phenomenon causes a disproportionately large effect. This is a very important concept in ERP. A consultant should understand that 20% of the requirements mentioned in RFP will be used in 80% of the transactions. Understanding of this model helps consultant in prioritizing the requirements and asking the right questions. 

2. Murphy's Law: Everyone knows it. The law states that what can go wrong will go wrong. That problem with just 0.1% probability? It is bound to come up sooner or later. That remote access violation that you never thought feasible? Someone has found the loophole and misused the access. An ERP implementation is a ceaseless, incessant fight against Murphy. How does an ERP consultant counter Murphy? Plan your work, circulate minutes of the meetings, document your findings, get email approvals from the stakeholders, close issues quickly.....

3.First conclusion bias: This is a bias in assuming that first solution is the best solution and the consultant stops analysing after the first solution has presented itself. Any ERP application is feature rich and any requirement can be handled in at least three different ways.  As I mentioned in this post, first solution that presents itself will always be sub-optimal.. A consultant has to understand this bias and overcome it through second order thinking and trying to understand the requirements in detail and come up with multiple solution options with their pros and cons.

4. Circle of competence: Early in my ERP career I had this practical and down-to-earth boss. I had done a couple of ERP implementations successfully and was feeling high of myself. I was talking to him about giving some value added inputs to the customer on Chart of Accounts design. He told me, 'Your job is to take the Chart of Accounts that the customer gives you and load it in ERP. Always remember that you are an ERP consultant and not a Business Consultant'. Every time I see consultants crossing that thin line, I remember my boss's words. Understand what you are capable of of and what you are not.Where you lack capability, seek help from experts. 

5. First principles thinking (Root cause analysis): Nothing is what it seems. Always ask questions till you clarify the exact requirements. Remember that requirements are always stated as 'positions' but the solutions are always given for 'issues'. Root cause analysis helps you separate issue from position. Let me give an example. The application suffers significant performance issues during evening hours when most of the Sales Orders are entered. The position is that system is not able to handle peak capacity and hence 'Server Capacity' has to be increased.  Root Cause Analysis shows that one specific code segment in a custom program goes into infinite loop and takes hours to get out of the loop. By making just a single 'word' change in the code, the performance issue has vanished (real case). Always go beyond.

6. Gestalt: This is a German word that broadly mean 'Completeness'. A consultant should understand that every transaction in ERP has an impact on the Balance Sheet of the company. The business users know it intuitively. Most of the questions they ask is coming from that perspective. For example, there is an account called 'RCA' (Resource Control Account) in Oracle. This normally hits the 'Credit' side of the Profit and Loss account. Any value that hits the 'Credit' side of P and L is suspect. If the consultant do not understand the implications of this configuration, he will not be able to explain why RCA is hitting the 'Credit' side, how it is negated by an equal entry on the 'Debit' side and how this entry do not mess up the financials of the company. Understanding of Balance Sheet impact is very important when configuring for transaction errors and reversals. Understanding of this end to end impact accounts for 60% of value that a consultant can add in an ERP implementation.

PS: The sub-optimal solution given to the RCA issue given above is to configure RCA as a Balance Sheet account, so that it does not inflate the revenue side of P and L. But this will not reverse the corresponding impact on the Cost Side and will deflate the profits of the company.

7. Incentives: By its very nature ERP impacts multiple business areas in an Organization. Many a time a configuration that benefits one business area adversely impacts another area. Let me give an example. To handle 'Stockout' situation, companies might want to configure 'Bulk Purchase' and 'Volume Discounts'. Higher the quantity purchased, higher the discount and better will be the performance of the purchase manager who is appraised on the volume discount that he has managed to obtain. However bulk purchases also mean higher inventory carrying costs and higher cost of inventory oversight and hence increases the cost of the materials manager.. So what is good for purchase manager is bad for the materials manager. ERP consultant may not be able to do anything about it, but he has to be sensitive about the incentives impact of his configuration. As another example, excessive control on transactions through tight approval process will transfer the ownership of oversight to the manager leaving the buyer not having any incentives to do transaction due diligence. 

An ERP consultant who understands these incentive structures will make better decisions resulting in a successful implementation. These is not an exhaustive list. There are many others. What are the one's that come to your mind?