By: Don Riggs
I’m amazed that an industry that prides itself on improving processes and controlling waste is not more introspective. Having been an implementation consulting for 25+ years, I have observed ERP project implementation methodologies and staffing plans stagnate even as the software, both its capabilities and deployment models, have evolved along with the broader business landscape. The result has been a range of mismatches for customers: in how systems are deployed, how projects are staffed, and how clients and partners foster a productive working relationship.
Here, I am attempting to write about some of these challenges, both for the Microsoft Dynamics AX or Dynamics 365 for Operations consultant and for the user.
Buying habits in the Dynamics AX world
It is interesting to see how companies typically select an ERP system. The journey is undertaken to pick the best software for their needs. That sounds perfectly reasonable, but many things go wrong.
Often the first issue is, how do clients quantify their needs, and the best software for them?
The first process they use is some form of RFP. This is a series of questions with the attempt of culling out software that does not meet the company’s needs. These have become more of a process of test taking skills. A vendor will not go through this process unless they are desperate or believe they have a good chance to win. The less the client is truly invested in understanding the product and company, the greater the prospect of not getting a successful outcome. You cannot abdicate this responsibility to a third party.
They decide based on demos, which are like beauty pageants. When I’ve asked, potential clients regarding another system, “What aspects of the demo specifically solved your unique business needs?”, they could not articulate one. But they felt very good about the demo.
In the Dynamics AX world, it is also interesting to note that consultants often put most of their resource cost in sales and sales-related activities. So, their best resources are ones you will never see again after the sale.
In my opinion, too little emphasis is placed on the quality of the delivery team. The best resources need to be on the delivery side. Further, I do not believe the goal should be the best product, but the best implementation. The product is just a tool. If you cannot effectively use it, that tool is worthless.
Organizations also have a habit of choosing a partner they’ve never even visited. These are people with whom a customer will spend approximately a year working to achieve a successful goal. Based on this lack of attention to the partnership, is it any wonder that so many implementations fail?
Poor knowledge transfer
Within the sales cycle, much valuable information is learned about a company. But how much is transferred to the implementation team?
In my experience, remarkably little. There’s a lack of continuity between the sales and implementation teams. This is largely because the client is not questioning this lack of continuity. No, I am not blaming the client for this, but I am saying that I do not believe this will improve unless it is driven by the client. It is your money.
This collection of information should form the basis for remaining discovery requirements. We need to better use these initial findings collected within the sales cycle.
The role of discovery
Discovery is the process of gathering information about a company for the purposes of integrating its requirements into an ERP system. It is the most expensive element of any Dynamics AX implementation, because it continues through the whole life of the project. It also is the single biggest waste based on current methodology.
First let’s look at what we need to know. Within its vertical industry, how different is the client company? If 80 percent of their processes are the same as those of their peers, or at least similar, then why must 100 percent of requirements be collected?
We need to focus instead on the 20 percent that is unique to that organization. Most companies can articulate that very well: They sell that differentiation every day.
Another problem is the belief that all consultants must be involved in Finance, Trade and Logistics, Manufacturing, WMS, and other meetings. This may help consultants define their paths for personal development, but it costs the client a lot of money. I’m not saying it has no value, but the value to the client is marginal.
Something else that I’ve witnessed is that excessive planning sets a precedent in which people confuse talking about things with producing an outcome. They spend hours talking, then do absolutely nothing with that information. Action produces outcomes. So, all meetings and conversations must have a projected outcome.
So, what to do?
It is my experience that only the business model itself creates the vision of the ultimate solution. An initial computer simulation of the business – setting up standard ERP software – drives the discussion of what is truly missing. Processes such as integrations with Dynamics AX are simulated within this process and further define dependencies and requirements. That visualization of what the system can or cannot do identifies the gaps where consultants need to focus their ti’ idea of consulting me.
Clients, consultant expectations mismatched
Consulting has changed in the Dynamics AX world.
The ideal of a consultant is Jonah, a character in the 1984 business novel The Goal. Jonah helps beleaguered manufacturer Alex Rogo using the Socratic method: Jonah poses questions to Alex which he then uses to come up with solutions.
Jonah’s methods (and Socrates’) are long past. Much of consulting today is a technical exercise. Technicians may be well schooled in Dynamics AX, but lack the experience and the training one used to associate with consulting.
Resultantly, the client and the consultant have very different expectations of the job. Clients expect consultants to guide them to the best methods for using their ERP product. Consultants expect the client to direct them as to what to do next. This in turn leads to the complaint I hear most frequently – that consultants do not understand the client’s business.
It is important to identify this problem where it exists, and to deal with it. If the project team collectively lacks the experience and the skills to deal with the project challenges, take a step back and acquire that experience. Do not proceed, it will only get worse.
It is your money. Take ownership!
Success or failure is defined during the implementation, and you can predict success or failure during the first two months. If within that time you do not have tangible outcomes, you must act.
As a client, not only must you monitor the partner, you must control your own expectations. Controlling scope of the implementation is the responsibility of all parties, not just the partner. Controlling the budget is the responsibility of all parties as well, but falls largely to the owner (you).
Here is a list of things you must actively manage:
- Do you have a good overall plan to start with and a detailed plan for the short term? Time after time the client has no idea what consultants are doing. It is important that you understand the short-term plan and offer feedback on short-term performance.
- Do you have proper budget controls and budget monitoring in place? You must understand how your money is being spent, and if it is being spent effectively. You need not be an expert to understand how much time was budgeted for tasks versus how much time they took.
- As the client, are your people involved in the process from day one? If not, you’ve picked the wrong partner. (I’ve heard of clients never yet touching a new system, three months into a project.) Client involvement is the single most important aspect of successful implementations.
- Do you have a formal process for processing change requests? Customizations are the single biggest reason for cost overruns and project failure. Truly understanding what you have versus what you need is imperative. You must control who can authorize work and define a review process.
With the changing landscape of implementation, the client must be involved in running the project. To abdicate that responsibility is to invite disaster. Control of scope and management of budget is a shared responsibility. If you are not getting these things you need to stop your project.
Lifecycle Services (LCS)
Microsoft is moving toward more computer-modeling scenarios driven by processes like Microsoft Dynamics Lifecycle Services (LCS). How well those processes will perform is unknown, but I applaud Microsoft for its efforts in this area, and for trying to improve the implementation process.
Will it change the current culture? Will this drive improvements or just become another cost layer?
Time will tell. Previous attempts like this have not proven to be wildly successful. That does not mean however, that this industry does not need to take a strong look at itself.
Implementation in the future
Changes in the larger ERP industry will not necessarily change the need for the implementation services in the Dynamics AX ecosystem. There will always be a need for good service providers, but, what does that service model look like in the future? Will it be a monthly fee, and will we have areas of specialty? Or will the model generally stay the same (with hopefully some radical improvements)? This much I know: when any offering becomes fragmented, that means more responsibility for the client. But that situation can also mean significant cost savings opportunities. At enVista we always encourage the client to do as much as possible to reduce overall cost.
Beware of the idea that hosted solutions require less customization. What it does is make customizations much more expensive. This has a positive effect because it makes customizations cost prohibitive. Widespread, poorly-thought-out customizations are the worst possible thing you can do to your project.
Still, at times one needs to make modifications to their processes. The functionality simply may not exist within the ERP to improve the efficiency or quality of process. There will always be a need to extend functionality, and it is still possible to create flexible designs that allow for accessibility and expandability of processes available in Dynamics AX.
Conclusion
In my opinion, Dynamics AX implementation methodologies must improve within the community. The partner channel has done very little to improve implementation efficiency and reduce the cost to customers. There is not enough competition with the current framework to improve it. This improvement is going to have to start with clients demanding efficiency and questioning these processes (and quite frankly, making better buying choices).
When we look at a product like Dynamics 365, future markets may ultimately dictate these changes. It is hard to predict the total impact, but I do know that we must be prepared for the differences. Part of that preparation needs to be how can we improve now.