Plan your support operations
To provide effective support for your Dynamics 365 solution, you need to do more than just design a support model. You also need to plan and practice how you'll operate the support services in real scenarios. This will help you ensure a smooth transition from project mode to support mode and avoid poor user experience, frustration, and delays.
Transition
The transition from project mode to support mode isn't a one-time event. It's a gradual process that requires careful planning and coordination. You should start the transition as early as possible in the project, ideally in the Implement phase, and set intermediate targets for readiness throughout the project. You should also involve the support team members in the project activities, such as design, testing, training, and issue resolution. This will help them gain hands-on experience with the new system and processes.
When to start the transition?
The best time to start the transition depends on the size and complexity of your project, the roles and skills of your support team members, and the level of involvement of your external partner.
For example, if you have subject matter experts (SMEs) who will move into support roles at go-live, they'll naturally learn the new system as part of the project. However, if you have existing SMEs who will support the new system, you need to formalize their involvement in the project earlier and give them more exposure to the system design and functionality.
Similarly, if you have technical roles who will handle custom code or integrations, you need to involve them in shadowing or collaborating with the project team during the build and deployment phases.
How to practice the transition?
One of the best ways to practice the transition is to use the formal support processes during the later stages of testing, such as user acceptance testing (UAT). This way, you can simulate real issues that might arise after go-live and use your support tools and procedures to record, triage, and resolve them. You can also involve the project team as resolving authorities to help train and supervise the support team.
Another way to practice the transition is to create task recordings or task guides in Dynamics 365 Finance or Supply Chain Management or other forms of training documents. These can help your support team learn how to perform common tasks and troubleshoot issues in the new system.
By practicing the transition, you can identify and address any gaps or challenges in your support operations before they affect your users and business. You can also review the effectiveness of your support team and provide feedback and coaching as needed.
If your SMEs don't have regular and extensive exposure to the new system during the build, they might have a knowledge gap that will make them rely more on the partner consultants for support and testing.
Requirements management
New requirements can arise from various sources, such as:
- Minimum viable product (MVP) or phased rollout strategies that defer some features or functions to later stages
- Changes in connected systems or integrations in your enterprise
- Changes in the external market or regulatory conditions
- Incremental functional and technical updates from Microsoft or ISVs
Your support team needs to have the resources and means to keep your solution up to date with these new requirements. They also need to have a way to capture and channel the feedback and requests from the users or stakeholders to the right parties.
Some organizations have a dedicated project team that handles the backlog of new requirements, but others rely on the support team or external partners to deliver them. In any case, you need to have a clear process for reviewing, prioritizing, and approving new requirements.
Change management
Besides new requirements, your support team might also need to deal with other types of changes in your production system, such as:
- Core data changes, such as adding new customers, suppliers, or items
- System parameter changes, such as adjusting settings for data volume or performance
- Configuration changes, such as modifying tax rates or currency codes
- Approval process changes, such as changing the workflow steps or roles
- Bug fixes
Some of these changes can be made within the system itself following the agreed change control process. Others might require approval from business or IT stakeholders or other relevant parties.
You should define the scope of the support team's responsibilities for making these changes and create the appropriate change management boards or committees for overseeing them.
Hypercare
Hypercare is a short period after go-live when you provide extra resources and attention to support your users and business processes. Hypercare helps you make sure that your business can operate smoothly while addressing any initial issues or challenges with the new system.
The role of the support team during hypercare is critical, and you should set clear expectations and plans with all parties involved:
Define a clear exit strategy for the end of hypercare based on meeting specific criteria. For example, you might decide to end hypercare when there are no critical issues, the key processes are running efficiently, the service level agreements (SLAs) are met, or the support team can resolve most issues without extra help.
Decide on an end date for hypercare and have an action plan to meet the exit criteria.
Define the expectations and plan for the project team and partner resources during hypercare so that you can get reliable help from them. Otherwise, they might be busy with the next phase of the project and resist being involved in support issues.
Make sure that the support team gets the necessary documentation and training from the project team and implementation partner during hypercare.
Next steps
- Learn about the roles and responsibilities of your support team
- Review a checklist for implementing your support model
- Read a case study to understand why you need to develop and audit your support strategy in the cloud world