Customization

Years ago, when I didn’t know what consultant was, let alone thought about eventually becoming one, I was sitting in a cafe in Zagreb with then my boss and now my friend Marko, sipping cream with coffee and mostly sharing random thoughts. He then introduced me to a commodity-convenience-solution concept which shaped a lot my customer approach and my work.

Service Providers (or colloquially partners ) often refrain from undertaking organization or process changes during implementation projects of Microsoft Dynamics solutions. And it comes as no surprise: there are many risks related to it, and customizations are taken as a more traditional approach.

One of the biggest absurdities about ERP systems springs from the very word we use so often when describing ERP: integrated . ERP is an integrated system: it integrates all data and processes into a single application. Different modules look over different aspects of data and processes, but a change in one module automatically reflects in all others.

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.

– “We need a report which groups our sales by product components.” – “And we need it broken down by cost centers.” – “And it must show comparison with last month, quarter and year, and with budget and forecast, with indexes and trends. In linear regression.” – “And it must let you choose if it is by posting date or by document date.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” That’s the very first principle of the Agile Manifesto . The problem with ERP is that the first deliveries are all but early: they typically occur only after about twenty months .

In my previous post I’ve (what, again?) shared some statistics about success and failure rates of software projects in general and ERP projects specifically. It seems that ERP projects fare somewhat worse than generic software projects, which I stated might have a lot to do with how requirements are handled.

Implementation is like marriage. For better or worse, you choose a piece of software, take it under your roof and commit to it for a long term, so help you God. And as in marriage, if you want to live happily ever after with your new software, the my way or the highway attitude doesn’t help much—you must be open to compromise.

To customize or not to customize, that is the question. When you see a complex business process far from the standard ERP system, a knee-jerk reaction is to reach for customization tools and do the development. Many ERP theorists say that ERP is only as good as it is an exact match for your processes.

I’d like to have a BMW X6 . A fantastic car. Only, I’d like it to be convertible, because I love the feel of wind in my hair while driving into summer sunset. I could use a glass roof as well, it makes the interior feel much more spacious.