Adopting implementations, what went wrong?

Throughout my Dynamics NAV years, our team has adopted quite a few implementations that have for some reason gone wrong. We are usually able to straighten the implementation out and get it on the right track. I have often wondered why things went wrong in the first place. There are several different reasons that come to mind. Sometimes it’s the consultant’s fault, sometimes the company’s and sometimes both. In this article, I wanted to focus on a particular type of failure which has to do with the consultant.

ERP consultants can by categorized into two types, functional and technical. In this case, I am not counting the project managers. A technical consultant usually starts out as a programmer with a computer science degree. The functional consultant will usually have a business or accounting degree. When ERP systems are being implemented, you will usually need at least one of each on the consultant’s team. There are very few people that have mastered both sides of the coin. The people that have, I like to refer to as ambidextrous.

Let’s now say that the team at work has expertise in one side but not another. How does that affect the project and what are the dangers?

Functionally oriented team

A team that is comprised mostly of functional consultants, will know the accounting principles and understand a good portion of the application. If they are intelligent and possess a high level of application knowledge, they will find ways to solve issues at hand using the standard package. This is very often possible, but sometimes means that the company has to make compromises. The risk of failure is less, since the original program is not modified and will work more or less out of the box from the manufacturer.

The problem with this approach, even though it involves little risk, is that the company’s incentive to change a system was usually to leverage new features and introduce flexibility. We already have more inexpensive systems in the market that you cannot change. Why go to a more expensive system and still be shackled. You can say the implementation went through and everyone is using the system, but functionality was heavily compromised.

When we enter a scenario like this, the company is usually asking us why things cannot be changed. The previous implementation team, simply said that it cannot, without an explanation.

Technically oriented team

To be able to change an ERP system is a powerful thing. Power needs to be handled with responsibility. A team that has more technical expertise than functional, will know how to change the system. They might think they know the functional side well enough but if they do not, it can be a very dangerous mixture.

When the company has a business process that has to be implemented, and the technical consultants are not aware of it in the standard system, they will simply create it! The consultant might not have deep accounting or supply chain knowledge. But they have the power to change and add to the system, and they use it. This can be very risky. If the change to the program does work, then chances are you have just recreated something that was already there. When upgrades come about, the out of the box functionality gets an upgrade path from the manufacturer, but the modified functionality needs to be handled specifically. There is of course the chance that the modification does not work, or even worse, looks like it works but generates erroneous data.

When a company seeks us out to help with implementations that have gone bad and the team has been too technically oriented, things are usually quite messy. The system could be behaving strangely, locking up regularly and not handling volume. The first thing we do is see how we can strip things down and utilize the system better or in another words, think more like a functional consultant.

I sometimes get asked, “The functionality works, even though it might be a recreation of functionality that is already there, or not properly extending it, why is it bad? It works!” The reason why it is bad, if it is not properly done has to do with upgrades and further extensions. If the development is nicely done extending the system, then every exception can be logically worked out. Upgrades also become straight forward and will, for a lack of a better word, flow. Any consultant which has been tasked with fixing these things, will understand.

Conclusion

I hope I have made the point that a team needs to have solid functional and technical consultants. When a company has had the experience of an imbalanced team, they will on the next go around overcompensate in the other direction. Companies that went through an overly functional implementation, will go development mad and companies that went through heavy technical implementation, will shun away from any development and make big compromises. Like in life, a good balance is the key to success!

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>