Defining solution in ERP: Ten Commandments - Thy shall not falter on them!
Life is never too simple! And who can know this better than consultants. Consultants have their own reasons to follow an approach for achieving a business need using any COTS solutions. However, in my personal experience I feel that any packages product should be used with utmost care and be modified after following some standard principles. There would be lot of pressure from some members of the client team to customize the product so that it has look and feel of the previous application and which lead to reduction of training needs. On the other hand, the IT teams would like to keep it simple to reduce the upgrade costs and the pains associated with it along with recurring cost of maintenance. The aim is to reduce the overall TCO (Total Cost of Ownership) and the APM(Associated Pain of Management). Well the second acronym is my brainchild.
Of course, there are several factors which do affect the reason to choose the path of customizations. I had some thoughts around this which is available in one of my older blogs entry The “framework” conundrum in ERP/CRM
If we keep these factors on the side; I think there are some basic principles which should be discussed with the client beforehand and whetted before the solution development can happen. This is important to set the broad guidelines for the long match which is going to follow between consultants, business users, IT users and the CXO community at large. Once the base is defined; I have found it easier to discuss the greater details around the solution-design with the stakeholders. Any aberration from the basic agreed upon principals can be “striked-off” by simply referring back to the ‘Commandment’ being violated!
Here is the list of ‘Commandment’ that I personally follow to start with. Depending on client situation this can get modified; but I can assure you that it works well in most of the cases with the clients sometimes coming back to them after some initial modifications when they understand the ramification of not following them in spirit.
So, here goes my personal list (which I call TRY TO GRASP) –
- TRY - The product should be used out of box as much as possible.
- RECOGNIZE - The entity structure and relationships as defined in the product should be modified to the minimum.
- YEARN - ‘Discuss’, ‘Seek Advise’ & ‘Search’ for workaround without compromising on point 1 & 2.
- TOTAL VIEW - Look at the overall process flow (as needed by Client’s Business) in ERP before finalizing the elements / entities. Do not think at ‘module’ level!
- OBSERVE - Just using an entity (because it sounds similar to client needs) is not the right way; there can be hidden issues due to product data model.
- GRIP - Do not try and compromise on the ‘Financial Structure’ in the product; the solution should not interfere ‘with’ it and should be ‘around’ it
- RESEARCH - Look for ‘certified’ solutions available from partners in areas which are gap in the product.
- ADAPT - If nothing work – ‘Customize’. Customizations are a ‘necessary evil’.
- SUSPECTS – Be aware of the usual suspects. Never count the number when seeing customizations; it’s the dimensions of ‘complexity’, ‘risk’ & ‘impact’ that count.
- PEEP - Do not jump on to customizing ‘white spaces’; it could be in the roadmap of the product!
I am sure there are many other things that we follow without formally writing them down in a structure. Please share your thoughts. Are there any additional “Commandments” that you follow?