Diary of a Fixer: Top 10 Risk Issues that I see on Dynamics AX Implementation after Implementation

Having worked on many AX implementations has taught me to look for certain warning signs. One of my clients on an implementation asked me to give them a top 10 risk issues that I see on implementation after implementation. In other words, for a new implementation, are there some gotcha’s that they should look out for? Yes, there are.. Disclaimer: Please remember that these issues come from my experience and my experience only. Issues in Yellow are considered severe. Issues in Red can bring down an implementation if not accounted for.

Preliminary High Risk Assessment

Item	Issue
Missing Functional Configurations	Single hardest problem to estimate time for and single biggest delay on development time as troubleshooting can take lots of time, involve multiple people, and lead to issues unresolved for weeks or longer.
Manual data refresh process	Often a data refresh is needed to troubleshoot complex problems. Taking a day to do a data refresh is devastating.
2009 Coding Patterns in Dynamics AX	2009 coding patterns ignore many tables that were added in Dynamics AX; thus resulting in extra work from data not going to correct places
Initial first time involvement in AX functional processes	Under estimated delays for how long it takes to train users to carry out the functional AX process and take over the process – results in technical delays
Light requirement gathering	Always leads to more revisions – application is coded based on requirements and it is easy to miss things
Taking over the technical process ( Internal staff versus consulting staff)	While this is normal, it still leads to significant delays because everything must be done the first time – for example, getting approval and explaining to the business why certain roles are needed. It’s not unusual to walk into an internal staff who feels overwhelmed at first.
Inaccurate estimations	Estimations come with experience on that implementation from previous AX projects and every implementation is different. Development in AX is very much based on business users and this presents hidden delays
General Ledger problem solving	The general ledger is the final reporting place for all transactions. Any errors at any place will show up there. No ERP system is immune to troubleshooting General Ledger discrepancies and the amount of time that it takes. However, because the financial process usually comes after operations implementation, everyone seems to disregard the amount of effort it takes to get this right.
Complicated Customizations	Everyone(developers, functional analysis, and business analysts) will experience significant delays as a result of the time taken to understand the customizations. Considerable time will be spent here when onboarding staff.
Many Interfaces	The number 1 determination of difficulty of development within an AX implementation is the number of interfaces exposed. The more interfaces, the more complexity, especially because it becomes harder to debug across interfaces. Expect many hidden problems from this, especially where AX cannot use inbound logic to check issues from other systems