Blog

You can’t avoid customizations. Vanilla ERP is a great first step, and a valuable tool for establishing common language between the customer and the consultant. But in the long run? Probably not. Pristine uncustomized ERP won’t be sufficient, because of the gaps between your way and ERP’s way. Sooner or later, gaps will have to go.

Two most common ways of closing functionality gaps are customizing the software, and changing the processes. You can almost always touch general processes, optimize them, twist them, bend them, make them more efficient or even eliminate them. But when it is about industry specifics that add true value or contribute to company’s competitive edge, customization is the answer.

Even though majority of ERP systems can be customized to your heart’s content, and Microsoft Dynamics products are advertised as highly customizable ones, you should approach customizations carefully.

First, make sure you understand the effect customizations have on the system. Also, check if you are customizing for the right reason; Mariano Gomez wrote a fantastic column about this on MSDynamicsWorld.com. Finally, make sure your customization will add value.

Now you are good to go.

As stated in Agile Manifesto, agile approaches strive for continuous delivery of valuable software, and aim to deliver working software frequently. How do customizations play along these principles?

Not too well. With the customizations we see real difference between software development, and development as a part of ERP implementation. When you are developing software from scratch, you start with a blank screen and code away, and simply keep putting code into the same pile.

With ERP, you have hundreds of thousands lines of code already in place, written by the ERP vendor—the code base. ERP vendors frequently change the code base. With every upgrade, hotfix or version release the likelihood that your customization will simply stop working or start producing errors is huge. Enormous.

To put it simply: every minute you invest into customization might need to be repeated every time the ERP vendors releases a new version, because your vendor’s change can cause regression issues with your software, and you might need to redevelop the customized functionality.

Maintenance costs of a customized ERP solution are considerable.

Therefore, you should keep your customizations as shallow as possible. Add new fields or tables, add new forms or reports, generally, add new objects. Be careful about changing existing ones: extending field lengths, or modifying table relations, modifying report or form layouts or changing existing business logic.

There is one things that you specifically should not do: don’t ever restructure existing data model. Changes of this type can cause much more rework than mere programming; they can call for data upgrades, migrations and transformations, which are mini-projects in themselves that require a lot of work, are extremely prone to error, and add absolutely no value.

For all these reasons, heavily customized ERP systems almost always prevent upgrades to new versions. This is very bad from value perspective, because new versions often bring many improvements, and customers who customized heavily miss on many opportunities.

Another important factor from agile perspective is change: how will your customization be able to cope with change in requirements, priorities or project goals? If you dug deeply into the flesh of the system, a change outside the system can also cause a lot of rework that would be unnecessary if you did a shallow customization.

Again, if there wasn’t a base version of the system developed and maintained by the ERP vendor, there would be no difference in effect of external change on the ERP as compared to software developed from scratch. But when you take into account the combined effect of external change (requirements, environment, market conditions, priorities etc.) and internal change (new versions of the base ERP system), deep customizations cause so much rework, that companies simply decide to ignore changed circumstances and do not change the software at all. They consciously go on with a software that is no more fit for their processes.

Add the financial impact of every minute spent on work and rework, and you can quickly see that deep customizations have only two possible long-term outcomes:

• Huge initial development and long-term maintenance costs, that preclude any possibility of return (unless of course your customizations repeatedly achieve total breakthrough in productivity, overhead reduction or waste elimination).
• An expensive, monolithic and inert software, totally immune to any true improvement, which has long ago ceased to be a good match for business needs, that you are most likely already seeking ways to replace with something else.

Which one do you prefer?