A Change in the Dynamics/ERP Industry?

Having worked with Navision since 1990 is quite a long time. And it is also quite interesting to look back upon that time. Both for me personally, but also also on the many changes in the industry. When I started most of our Navision customers were small clients with 1-3 users, and back in the early nineties then a client with more than 20 users was considered a large client. Later I worked a lot with customers with more than 100 users, actually some going up to almost 5000 users world wide (but in different databases/companies).

After I was employed by large end-user organizations (first GN and then ISS) as their ERP architects, I have again been self-employed/freelancing since 2009. It’s been a rough period, with a global financial crisis going on. But the last 5-6 months have been very busy with lots of new clients and projects, mostly in Denmark but also internationally. That’s also why I haven’t been THAT active here on my blog and haven’t actually been sending out my newsletter for months.

Clients way to look at ERP

Back in the early days of Navision changes were typically focused on changing reports and forms. It was not that common to get larger modifications done. I remember how everybody kept telling me when I started, “Never change codeunit 80”, or any of the other core codeunits with lots of “complex” code. But it was a good way to start, learning to respect the code. After some years the clients got bigger, and so did the requests to modifications. Many implementations became very heavily modified.

Every client saw themselves as unique and wanted to adjust the whole system to “our way of working”. But the clients got what they asked for, some even got more, as the result typically was that upgrading became a night mare – or at least a "financial night mare” – as they basically had to spend almost as much for upgrading as they had spent on getting the functionality developed in the first place.

The quality of the implementations were also very different from site to site, many times have I visited customers, with “tons” of modifications that nobody really remembers why they were done. And when asking them today “why are you doing this?”, then all they answer is “that’s just the way it works” or “this is how our system was setup”.. Often none or very little documentation were done.

Their ERP system, their Navision system, which once was tailored exactly to their company, has become something they never get updated (because it’s too complex and expensive) and that they really don’t understand anymore. Of course they know what they need to know, and often they have found fine workaround’s to archive what they want. What originally was a system designed exactly to their needs, has now become something that prevents their company from optimizing business processes, they are basically stock with what they have.

Best practice

What I have noticed over the past year or two is that the clients are now looking at the ERP system with different glasses. Instead of asking me to “modify our system to fit our needs”, then the request is to get a system with lower cost of ownership, by asking for “best practice”. A system which easily can be upgraded to new versions. They are more focused on industry best practices, than on what makes their company stand out from the rest. They rather want to adjust their way of working, than adjusting how the system works.

My last three-four projects have all been like that. When I first start working for them, then we typically starts with an upgrade to the newest NAV 2009 R2, where the main target really is to get rid of all the modifications they have gotten done over the years, but no longer knows why they have. Typically I’m able to strip more than half of the modifications, leaving only “the best” modifications. Then everything is documented, including all new requests. Keeping a common “change and request log”, what I always call my “Development Issue List” or the DIL, where all requests are documented, who requested them and why, including how the change was implemented.

Last month I upgraded one client from, which I last year upgraded to NAV 2009 SP1 using the above method, to NAV 2009 R2. The NAV 2009 SP1 upgrade from NAV 4.00, had taken about 80 hours in total. The NAV 2009 R2 upgrade took only 4 hours. There were only 8 objects with I had to look at manually. The rest could be upgraded automatically or where not changed in R2. And the 4 hours included installation of new server and client executables.

Don’t be afraid for modifications

What I almost feel these days are that many clients, who have been over huge Dynamics projects and later expensive and problematic upgrades, are almost afraid to have modifications done. They don’t need to be too afraid of that, if they have a professional Dynamics consultant, who can advise them of what is best practice and what is not such a good practice. And a Dynamics developer who also understands how to use best practice when it comes to designing the new modifications in a manor, so that the system is still easy to upgrade.

In fact I feel that the role-tailored NAV 2009 is easier to upgrade than the classic versions. What always took quite a lot of time on the classic versions was upgrading forms, as they had to be upgraded manually (at least that was my experience and preferred method). Upgrading pages are much easier and can typically be automated, because the source code format is much simpler (no coordinates or control sizes to think about).

“Do it my way” or “Follow Best Practice”?

I feel that this change in the industry, from “Do it my way” to “Follow Best Practice” is very clear here in Denmark and Scandinavia. But is it the same in the rest of the world? Are people still selecting Navision because “it’s easy to modify”, or?

I’ll love to hear your comments to this.

Comment List
  • Hi Erik,

    What you are explaining to me is very similar to what I have seen in the SAP environment ~5 years ago. But is it unique to ERP  , I guess no , its just we (or rather customers) are more concerned on TCO.  

    Customization should be programming or configuration?  In case of NAV we see more programming than configuration.

    Plus what makes the most headaches to me , will the upgrade deliver as much value to the customer then the cost of upgrade. Probably not every release.

    gabor

  • Yes. I actually think that it's more a sign of maturity - the Dynamics market is more mature today. Both the end users (who understands to set the "right" requirements) and the partners, who now knows the product better than before. In Navision especially it's often much quicker/easier to create a new function, than to go around find the right way to do it using either standard or a 3rd party add-on. So having more knowledgeable consultants and project managers will eventually lead to less development and more configuration.

  • Hi Erik,

    I am working in Spain as a Nav consultant. When we are starting a new implementation or re-implementation instead of an upgrade, they normally tell us that what they want is to adapt the maximum to the standard, but once started the project and making the functional design document, they want to adapt everything to make NAV perfectly for their business. I also think that it should be like this. Of course it is very important to document all changes correctly and have a good version control to avoid problems with updates later on.

Related
Recommended