The success of a Dynamics 365 Implementation project largely depends on the amount of planning and strategy that goes into the implementation. However, if things aren’t going well after it is launched, the principles of planning can still be applied to turn the implementation around.
In this section, you will learn about Dynamics 365 Implementation for success:
- Planning for User Adoption. Ultimately Microsoft Dynamics 365 is a long-term solution, and in order to get the value out of it, you should work towards effective use of the application. Therefore, this section frames all of the successful ingredients of a project in light of user adoption.
- Business Analysis and Design. Whether using an agile or waterfall approach to implementation, you will have to analyze your business processes and create a CRM design to support those processes.
After reading on these topics, you’ll be ready to make Microsoft Dynamics 365 Implementation successful in your organization.
Planning for User Adoption
The concept of planning for user adoption means that everything you do with your Microsoft Dynamics 365 Implementation is done through the lenses of user adoption. This prevents you from getting overly focused on technology and maintains the focus on how CRM will support the users and meet the overall company goals.
There are 10 major ingredients to successful user adoption:
- Scope and Vision
- Executive Leadership
- Ownership and Support
- System Function
- Data Quality
- Process Alignment
- End-User Motivation
- Training and Reinforcement
Business Analysis and Design
The process of business analysis and design is similar to many Dynamics 365 Implementation. Experts in the business meeting with experts of the technology and they collaborate on the best design of a system to support business processes.
Below are the steps to the successful implementation of Microsoft Dynamics 365. Depending on the size of your organization and project, you may go through these steps quickly, or you may have a lengthier review process at each stage.
1. Identify Critical Success Factors. Often phrased like, “This project will be successful if…,” critical success factors are goals that guide the project along. During the design phase, they help determine whether something should be included or not. At the end of the project, critical success factors are used to determine whether the project was a success. Organizations may identify long-term success factors that can be measured some duration after deployment.
2. Determine Scope. The scope may be most easily understood in terms of teams and processes. Which teams will be using Dynamics 365? Which processes (within a team and across teams) will be supported by Dynamics 365. At the onset, you may also know that certain sub-processes may be completed inside or outside of Dynamics 365, as well.
Many organizations might also call the scoping of a project “requirements gathering” because the scope is phrased in terms of what the application must do in the short-term, and what the eventual functionalities must be in the long-term.
Since the implementation of Dynamics 365 is focused on the design for future-state processes, it is common for organizations to have a business analyst document current processes and pain points before the scoping of a project.
3. Conduct a Future-State Analysis. Comparison of current-state to future-state processes is helpful for incorporating change management into the implementation process. However, the design of Dynamics 365 is focused heavily on the future state processes-what the application will do. Process analysis has three elements to it:
- Measurement. First and foremost, Dynamics 365 must be a system that produces actionable business analysis. Leaders must be able to make decisions based on critical business data coming out of Dynamics 365. Analytics must be surfaced for end-users to help them prioritize customer-facing activities and plan out their next actions. Therefore, the process analysis should drive towards how to best surface this information, as well as how and when it will be consumed.
- Processes. Dynamics 365 must help users complete their jobs. It creates efficiency by centralizing information and providing visibility of the right information at the right times. It must automate processes that can be automated. In order to design Dynamics 365 to do this, you must determine and discuss the future state processes. This is done by discussing the process from the beginning to end and possibly returning to discuss sub-processes in more detail. You must also understand the day in the life of users and how their workflows.
- Data. A big part of designing Dynamics 365 is understanding the specific data elements needed to support processes. The process analysis looks at where data is coming from, how and when it is updated, and if and when it flows to other business applications.
4. Gap Analysis. After processes have been analyzed and documented, a gap analysis is done to determine what can be done with Dynamics 365 out-of-the-box and what may involve custom code or add-ons. Much of this might be visible at the onset from just doing scoping; however, until the detailed process analysis is complete, the final gap analysis can’t be done. The gap analysis can be documented or simply reflected in design and architecture.
5. Architecture and Design. Based on the process analysis, a system design is created demonstrating what built-in features will be configured, as well as how Dynamics 365 will be extended. This will include
- Users and security
- Configuration of CRM entities (fields, forms, and views)
- Configuration of processes (workflows, dialogs, and processes)
- Reports and dashboards
- Data migrations and integrations
- Custom development
This chart explains the process of designing the Dynamics 365 system to match your organizational processes.
Best Practices for Dynamics 365 Implementation
Involve Subject Matter Experts (SMEs)
If you are going to Dynamics 365 Implementation applications at the same time, make sure that subject matter experts (SMEs) are able to allocate time towards both work streams. An SME’s expert knowledge is indispensable to a project – they can provide crucial feedback on the solutions, the implementation, and how the solutions will support the organization. This feedback helps reduce project risk and support user adoption post-implementation.
However, we can sometimes forget that these SMEs also have a full-time job that they need to keep up with. To make sure your leadership team understands the importance of SME involvement in the project, you must communicate to stakeholders and steering committee members the impact that SMEs can have on the project, and, in turn, on the business.
Encourage Cross-Practice Collaboration
Always create collaborative workshops for solutions that might cross one or more practices. (i.e. Finance and Operations, Sales, and SharePoint) This is a follow up on point #1. Be mindful and resourceful in planning ahead with workshops and eliminate duplicate meetings with different consultants by anticipating cross-functional needs. This will help with pre-design and solution plans that will come up further along in the process, and it will ensure the appropriate questions are discussed with the SMEs.
Finish Customization Before Integration
Any integrations between Dynamics 365 for Sales and Dynamics 365 for Finance and Operations should wait until all customizations and migrations are complete, and the Operations (AX) system is up and running. Understandably, this is the best case, and not always possible with timelines and milestones to complete.
Prolonging the exercise of data mapping and data script creation until most or all of Finance and Operations is running, will help you lay the foundation for a smooth integration process. This is because Sales typically won’t take as much time to implement as Finance and Operations, due to application complexities and requirements. Sales is a bit more flexible and agile when it comes to modifications, so adjusting to meet integration needs is a better option.
Determine the “System of Record”
When the time comes to begin integration discussions, it’s important to determine which system will be the “System of Record” or hold the “Master Data.” Dynamics 365 for Finance and Operations is typically chosen for this role, but Dynamics 365 for Sales can sometimes be chosen as the “System of Record,” depending on the data it will need to store. Some businesses may require that when these prospects are converted to “customers,” they are “sent” over to the ERP system, with their information now residing in the ERP system. Making these decisions around a “System of Record” during integration discussions can help with design options, as well as security requirements.
Make Sure the IT Team is Involved in Decisions
Choosing the right integration tools is usually up to the partner or consultant implementing the solution, but that’s not how it should be. Since most complex integrations are done by partners and consultants, it’s important that the IT department of the organization implementing the applications be included in the decision-making process (and aware of which toolsets to use). The reason for this is that when the partner or consultant leaves the project, your organization will need to support the integrated solution and make future updates and modifications. There are many different tools to accomplish integration needs, so it is extra important to make sure your team determines which tools it will be using and that the team will be comfortable using them.
Align Important Implementation and Business Timelines
Another important factor to consider when planning and deciding on an implementation timeline will be the “year-end closing” month for your company. Use this time to back into an agreeable and attainable deployment plan. The year-end closing month is probably the single most important date that can be easily overlooked during initial planning and can cause delays in Dynamics 365 “go live” plans.
Keep Cross-Functional Teams on the Same Page
Dynamics 365 now brings together the two former product lines (CRM and AX); the same needs to be done with implementation teams. One important role that many software providers now use to ensure team alignment is the Enterprise Architect. The Enterprise Architect offers cross-functional team guidance to both the software provider’s team and your team, guiding all team members toward a common goal. Whether or not your organization uses an Enterprise Architect, keep in mind that the most successful implementations occur when cross-functional teams are on the same page at each step of the project.