This article will provide guidance on the critical success factors for the journey you are about to undertake.
The project should have clear business outcomes in mind. Examples of good business outcomes are:
- Increase the percentage of perfect orders i.e. fully shipped sales orders on time from 70 to 80%
- Increase billing utilisation of professional services staff from 65% to 75%
- Decrease costs of processing purchase orders from requisition to invoice from $150 to $100
Business objectives help focus the project, particularly if there are requests to change the scope which require additional investment. When changes of scope are raised, a key question should be “will this impact the stated business objectives for the project?”
Change is difficult and depending upon your organisation’s industry, a Dynamics AX implementation can impact almost everyone in your organisation. Change brings about fear and ultimately can derail an otherwise successful project. Enter Change Management. Change Management is simply a strategy to manage the change through an organisation. A Change Management strategy is principally about communication. The communication strategy should aim to clearly articulate there is a change coming and why. It’s your opportunity to sell the project. Communication should commence early and then be at least monthly throughout the project.
The right resources are required to make a project successful. Implementing a business system requires engagement from key business personnel. Typically, the IT Department is used to facilitate the project in terms of project management, data management, reporting, security etc. However, the business people must drive and own the Dynamics AX project. A typical approach is to appoint Subject Matter Experts or (SME) from key parts of the business. These SME need to have the following attributes:
- An agent of change.
- Capable of making decisions.
- Good personal networks within the business.
- Good knowledge of the strategy direction, business policy and procedures of your organisation.
SME should be assigned from key areas of the business such as Finance, Supply Chain, Retail, Sales etc. SME are typically required between 50% to 100% for the duration of the project depending upon size, complexity and number of modules to be implemented. SME will be required to undertake the following:
- Requirements gathering and prioritisation.
- Provide input into design and review of design specifications
- Advocacy of the system
- Documentation of business procedures and processes
- Training of end-users
- Assist with data migration
- Creation of User Acceptance Test (UAT) cases and execution of testing
- End user support during UAT and post go-live
Do not be tempted to hire business analyst externally to be your SMEs. Business analysts have the skills but not the knowledge of the business to be successful. Once the implementation is finished, contract SMEs leave the business with all of the knowledge gained during the project.
The best practice is to hire people to back fill SMEs during the project. Post go-live, the SMEs become the system champions who drive adoption, optimisation and support.
How many SME are required? As a rule of thumb, the number of SME should at least match the number of functional consultants of the implementation partner’s team. For large and complex supply chain projects, this ratio may increase to one to one and a half.
Dynamics AX implementations carry risk along with every other enterprise application or ERP implementation. Risk mitigation strategies should be put in place to manage risk.
The risks for any AX project will be different but there are common themes. The system related risks are:
- Modification of the system: Dynamics AX can be modified to suit the needs of a particular business. Modifications can provide significant business benefits by allowing your businesses to adopt innovative processes which provide competitive advantage. On the downside, modifications to the system can simply be an insistence in incorporating how the old system operated. The trick is to know what business processes can change to meet how the system operates versus changing the system. An observation is innovative processes are more likely to involve the customers. Processes which manage vendor or financial type outcomes are less likely to be truly innovative. Modifications increase risk as they are unique to your organisation thus depend upon a partnership between the project team and the AX partner to be designed and built well. Modifications must then be maintained through subsequence upgrades which can amount up to 30% of the original cost of the modification when taking into account the technical upgrade, documentation, testing etc.
- Interfaces: interfaces facilitate movement of transactions or master data between Dynamics AX and existing third party solution such as payroll (creation or updates of employees), billing (creation and updates of customers and invoices) etc. Interfaces can provide enormous benefits in terms of reduction in data entry, increase velocity of business processes and data accuracy. They are also difficult to design, build and test. The business justification for interfaces must be based upon the volume and frequencies of the intended interfaces.
- Data migration: most Dynamics AX projects have an element of data migration.
The key with data migration is to:
- Start early on data migration and do not under estimate the effort involved.
- Do not be overly ambitious. Never migrate history into AX.
- Data migration should be completed before User Acceptance Testing commences.
Minimum Viable Product (MVP)
MVP is an Agile (more about Agile in a moment) term and approach however some of the principles of MVP can be applied even with Phased implementations.
Simply put, MVP is about implementing the smallest number of features possible into production so that users can use those features “in anger” and provide feedback. Subsequent investment in the product is then focused in the right areas.
The other potential benefit of MVP is the length of the project is shortened. Information Technology projects which run longer the six months increase in risk due to project fatigue, changes in business requirements, reduced stakeholder interest etc. For Dynamics AX projects you may not have a choice but to run over six months, however the longer the project the more likely these risk factors will be realised.
How the MPV approach works in practice is the Dynamics AX can be roll out in terms of modules, integration and modifications wherever possible then have a “release party” before continuing to optimise the system.
There are two main methodologies used to implement Dynamics AX: the traditional Phased (waterfall) and Agile. As a reminder, the Phased methodology has a number of stages from Analysis, Design, Build, Development, Data Migration, User Acceptance Testing etc. Each is completed before the next commences. Most Dynamics AX implementations use the Phased approach and a number of corporate and government environments will not allow an alternative. The Phased methodology is the best approach for small to mid-sized implementations with low complexity.
The Agile methodology starts with an Analysis phase as with the Phased approach then moves to fortnightly or monthly sprints where Design, Build/Development, Data Migration, Test are combined to deliver a slice or group of stories or features rather than the entire product. Stories are delivered from highest business to the lowest business value and are fully functional after each sprint.
The Agile methodology is best for large and complex projects where this methodology is permitted. Complexity is measured by the number of modifications and interfaces. Agile can assist with these projects by delivering completed product early, allowing the project team to learn from what has been delivered and incorporate lessons into subsequent Design as the sprints proceed.
At times Agile can be used to reduce modifications as users immersed in the product early are more likely to change business process than elect to modify the product. Agile can reduce risk by moving the riskier elements of the project to the early sprints such as interfaces and modifications thus allowing the project team more time to solve the more difficult issues.
The Data Migration and Change Management can be handled more progressively by undertaking Data Migration in sprints and demonstrating each delivered product every sprint to the project team and other stakeholders.
Investigate the methodology you will adopt for the project, considering that there are benefits to adopting Agile in certain circumstances.
User Acceptance Testing (UAT)
User acceptance testing is an important part of implementing Dynamics AX and often overlooked. There are various types of testing which can be undertaken in the project such as Functional, Performance, Integration etc. User Acceptance Testing is when the project team and a broader group of users test the system after receiving training. The objectives of User Acceptance Testing are:
- Test a broader number of real life business scenarios than Functional Testing. The real life scenarios should have been developed by SMEs with the assistance of the end users involved in UAT.
- Assess whether end-users have received the appropriate training in Dynamics AX and the new business processes. Do users know what they are doing after the training provided by the SMEs? Can the SME support the end users?
- Test the data migration process
- Test the go-live process
- Test and reconcile migrated data
- Test interfaces
Implementing Dynamics AX
In conclusion, there are various factors which can make a Dynamics AX implementation successful, many of these have been canvassed in this post. Reduce your risk by applying these lessons learned and partnering with the right organisation.
Good luck! Please do not hesitate to contact me should you have questions regarding how to make an implementation successful.