Tag Archives: Customization

What is your ERP, a commodity or a solution?

imageYears 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.

You might be a customer of an ERP. Or you might be a company offering implementation services to customers. In any case, this post is for you—how you think about your ERP implementation project(s).

Continue reading What is your ERP, a commodity or a solution?

Sure Step in action: business process change

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.

Customizations are easy to predict, they do come at risk, but at least the risks are known and often easily managed entirely within service provider’s organization and reach, while organizational change is unpredictable, and often exceeds consultants’ knowledge, experience and expertise.

However, with or without intention or consent, organizational change will always happen. No solution has ever been 100% fit, and since the customer must do their business with the solution, the remainder from fit to 100% will always and without exception be satisfied with an unmanaged, unintentional, but evolutionary process change.

Instead of leaving it all to chance, Sure Step offers much better ways.

Continue reading Sure Step in action: business process change

5th rule of agile ERP: interface where possible

imageOne 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.

A fantastic concept. When it was invented, it streamlined processes, boosted productivity and eliminated overhead and error.

So, whenever a new functionality is needed by a company, it should be integrated into the ERP, to benefit from the integrated system. Right?

Wrong.

Continue reading 5th rule of agile ERP: interface where possible

4th rule of agile ERP: avoid heavy customizations

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.

Continue reading 4th rule of agile ERP: avoid heavy customizations

3rd rule of agile ERP: focus on value

image – “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. Or by shipment date. Maybe some other date as well.”

– “And it must exclude returns, and include only those re-shipments that were linked to original returns in the shown period.”

And it must be a disaster if you agree to half of these.

Continue reading 3rd rule of agile ERP: focus on value