This is a special series that I’m writing over time to share many of my learnings from experience on Dynamics AX implementation. On my site and blog, I mainly focus on technical training and learnings. However, in the consulting world, I often have another role. Sometimes, implementations go bad, and things can get real nasty. When that occurs, recruiters have a short-list of go-to people who are known for handling this sort of thing – such as when a company is about to give up on Dynamics AX altogether. Things are different for a ‘fixer’ – the good faith and optimism that was so prevalent at the beginning is gone, millions of dollars have been spent, the consulting firm may be fired, and nothing seems to be technically working. This is an unfortunate situation, but it does happen – not just in Dynamics AX but for all ERP solutions. However, I’ll share some of my learnings here in hopes of helping others who are in the situation of a failing implementation or looking to implement Dynamics AX the first time.

POINT 1. What is the single biggest technical Reason that Dynamics AX implementations fail from Brandon’s Experience?

This is actually easy to answer – Integrations. Anybody can set up a 10 minute demo with a Fresh copy of Dynamics AX doing all of the good stuff. That has never been the challenge with an ERP system. The challenge with an ERP system lies in getting other systems to conform or integrate into the new system. For example, how do you get a Point Of Sale system to begin copying data into AX while having another sales process use AX functionality for sales? Or perhaps a company has an existing ERP system and needs to start using AX and they need the data. Microsoft, like most ERP vendors, is very careful to warn of the complexities of doing this:

We recommend that you do not import transactional data or historical data to Microsoft Dynamics AX. Instead, close all open transactions before importing, if it is possible. Maintain the database that contained your previous transactional data for reporting and compliance purposes.

Importing data is a complex process that usually requires many iterations

From Microsoft — http://technet.microsoft.com/en-us/library/jj225596.aspx

Okay, that is great and all but that is exactly what many companies have to do. But Microsoft is being responsible by giving a warning. And that is where things become complicated.

So, my first recommendation – understand that complexity goes up exponentially when you decide to take on the integration. You might wonder about why, but I’ll explain:

1. Integrating is a niche skill and hard to find. The integration specialist for Dynamics AX must understand the principles of integration (often understood by data warehouse practitioners), plus they must understand the programming logic in AX. It is not so simple as just putting data in a table. Putting data in one table may cause 10 other tables to update with different values messing up 5 parts of the application. So, you can’t just go out there and get a traditional data warehouse integration practitioner. By the same token, the principles of data cleansing, dimensions of cleaning, master data management, changing history, ect – they are all still there. So a pure programmer will often begin to show numerous bugs in the application as time goes by if they haven’t learned these concepts. Companies often run through many people and are shocked at how hard it is to get this skillset. Some projects never find anyone capable of doing it (often well-known lawsuits that you can google about).
2. Even harder, two groups of people must work together to be successful – the subject matter experts from the other system and from Dynamics AX. If any one of them is not on the ball, you will have problems. The weakest link in the chain will break the entire implementation when doing an integration. An outstanding integration specialist can’t do anything if not getting the information needed from the other system consultants.
3. Time.. Fixing an integration takes time.. I can’t tell you how many companies have passed up on me to consult for them when I told them that the integration would take 6 to 9 months or 9 to 12 months for me to fix as opposed to someone else who told them 2 weeks. And I can promise you that nearly every one of those 2 weeks sales pitches has resulted in failure. Fixing an integration is a step wise process full of iterations and milestones with lots of bug fixing. Figuring out what went wrong, where the system is having problems, if the source system is even accurate, chasing down people who have lost faith in the ERP system and begging them to work with you (when the users lose faith in the ERP situation, it can be devastating). This sort of thing can only be corrected with time and positive results.

In summary, from my experience, always carefully way the real budgetary effects of fully integrating a system into Dynamics AX. There are safer ways to integrate things – such as a data warehouse if it is a matter of integrated reporting only. However, if you do need to truly integrate two systems, never, ever, ever let the users believe that it will be an easy process. Warn them that it will take at least a year. Remind them that an ERP system is often necessary to take an organization to the next level – those business processes need to be unified, but no one ever said it would be easy. Dynamics AX is a great product in that it enables people to be successful, increase productivity, and carry out business processes more efficiently, but no ERP system can replace the human element. An ERP system is only as good as the effort that users put in it. A large integration takes time – but it can be worth it.

Now, conforming AX to act like an old system in some sort of way – that tends to have a higher success rate. But that is a subject for another post. And remember, I am not saying don’t do integrations. I’m just stating that it is wise to be aware of the costs and weigh them carefully.