Customizations to a ERP....
Can a ERP system exist without customizations? Can a Company run its business using a Vanilla ERP product? This is a question which can be debated on and on..
When the ERP products were conceptualized and developed, the best practices across industries were incorporated in the product. As the ERP's evolved, more and more common practices and features were added in them and thus a robust ERP product was built.
When companies implemented ERP, they customized the product to streamline the business process and suit their needs. As business increased, the customizations grew and boltons were created and new functionlities were added in the ERP.
The impact of customizations is realized only when a ERP is upgraded.
Questions like
Why is the retrofit exercise effort so high?
Why is the cost so high?,
Why are the timelines more? are asked.
So the real questions is how much should a product be customized? What are the best practices for customizations?
In general customizations cannot be avoided, but the amount of customizations can be limited and structured. Customization additions can be governed by the following the set of principles
1. Have a set of standards which the IT development team has to follow when implemeting any changes to the system.
2. Before each change, perform a impact analysis and check if the customization is really needed?
3. Have thorough code reviews done internally which will catch and block unwanted code from moving to production systems.
4. Try to use emerging technologies like web services to keep customizations outside the product and call web services to perform validations and reuse the same across different ERP systems.
5. Perform systematic audits of the system to see if any functionality/code can be dropped.
6. Check periodically to see if patches can be applied and customizations can be avoided.
7. During upgrades, try to see if the some of the customization can be deleted/dropped and ERP delivered functionality can be used, thereby keeping the system more vanilla.
The above are just some indicative set of principles which can be followed to avoid/reduce customizations. I would like to hear from you on how you think that customizations can be reduced and a cleaner ERP system can be maintained..
Comments
The most important consideration before jumping for customization, is to have a thorough understanding of what is causing the customization? Rather then starting the impact analysis, first & foremost we should ask ourselves, how we can avoid it. In few cases it is possible to tweak the business process to avoid customization.
In any reputed ERP System, best practices come pre-built and as far as possible, they must be used as such. Otherwise, what is the use of having a world-class ERP system? As a consultant we have bigger role to play than just providing what the client wants? This requires a mindset change and a strong senior management from the client side, who can take up the challenge & does not worry about changing their existing process, if it results in long term benefits.
Posted by: Ashish Namdeo | June 3, 2009 4:26 AM
Ashish,
I completely agree to your point.
The mindset of consultants and developers should change and they need to visualize the impact of customizations on the systems keeping the long term results in picture.
Generally large enhancements and projects go through the senior management and the IT manager. Most of the small time changes get filtered and reach the development team directly. This generally is obliged and developed due to the rapport between the end users and the development team. The IT team should try to push back on the changes and should educate the users on using the product features and rather than customizing the product.
Posted by: Venky | June 3, 2009 2:37 PM
Well change is constant and very frequent.
So also Business Processes change due to changing market conditions. I believe the proportion of the change in the Business Process is much higher to the change that happens to an ERP. So this forces implementors in the market force to perform customizations than these originally coming from the product vendors.
Changes coming from product vendors although comes in as part of newer versions but time is the most important factor which actually forces organizations to move for customizations.
I hope Venkatesh you will agree with me on the same.
Posted by: Ramakrishnan | June 4, 2009 7:00 AM
Absolutely Ramakrishnan, business process changes due to market conditions will always take a preference and the changes to system due to these are inevitable. However, one has to keep in mind the way in which the changes are applied.
Critical changes will always be deployed in patches and major changes would be incorporated in newer releases by the product vendor. If the customizations match with the changes supplied by the product vendor, then they can be retired during version upgrades or while applying patches.
Posted by: Venky | June 4, 2009 11:24 AM