ERP

There is a new book available about ERP business practices. It is titled “ ERP and business processes ” and is written by Hans van der Hoeven, MSc, a senior lecturer in ERP, Business Management and Accounting at Avans University of Applied Sciences in the Netherlands.

When implementing NAV in manufacturing companies, I’ve sometimes heard complaints that the type of manufacturing supported in NAV doesn’t fit the customer needs. And sometimes that’s completely true. NAV supports discreet manufacturing, and it handles it pretty well.

Panorama Consulting Group , the authors of the ERP report , have just made available two interesting tools: ERP Quick Diagnostic, and ERP Readiness Assessment. According to their website, if you are “in the early stages of selecting a new ERP software or if you’ve already completed your project, our ERP Quick Diagnostic will help you benchmark with other ERP projects across the globe”.

Many project management authorities assert that from project management stance all projects are equal. I dare saying that some projects are more equal than others. In my last post , I argued why I believe software (and ERP) projects are different.

“Software projects are no different from other projects”. This statement is being repeated over and over at project management courses and seminars, even endorsed in books. It’s true that software (and ERP implementation, as a subset of software) projects have many traits in common with projects in other disciplines.

This was a part of Chapter 1 in the first draft of my book Implementing Microsoft Dynamics NAV 2009 . It was cut to keep page count down and preserve the environment, but I figure that a few electrons pushed through the optical labyrinths of The Internet won’t hurt anyone, so here you get it, in its original form: The History of Microsoft Dynamics NAV.

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.

How do you eat an elephant? One bite at a time. Swallowing it all at once might be tempting as it has all the potential you need to get into the next edition of Guinness World Records . Likewise, trying it with an ERP implementation has all the potential you need to get into to the next edition of Chaos Report .