D365 Post-Implementation Performance Optimisation
Is Your D365 Solution Delivering What the Business Actually Needs?
Does Dynamics 365 feel slow?
Does it feel overly manual?
Are users relying on spreadsheets, workarounds and processes outside the system?
Does the solution feel disconnected from the way the business actually operates?
And perhaps most importantly:
Do you know it could be a whole lot better, but you don't know where to start?
There is a structured and practical process for addressing these issues. It starts where the Solution Integrator finishes.
The SI's responsibility is to implement the agreed solution against the contracted scope. Our role begins after that—to take the delivered solution and determine how well it is actually supporting the business.
This is not another D365 implementation. It is a Total Process Optimisation initiative focused on getting the most value from the investment the organisation has already made.
The approach looks at three interconnected areas:
People – Are users working effectively with the system? Do they understand the processes? Are there unnecessary manual activities, workarounds or capability gaps?
Business Processes – Are the processes efficient, consistent and aligned with how the business actually operates? Are there unnecessary steps, duplication, bottlenecks or controls that could be simplified?
Technology – Is D365 configured and integrated effectively? Are there performance issues, configuration limitations, unnecessary customisations, integration problems or functionality that isn't being fully utilised?
The important point is that you cannot optimise one of these areas in isolation. A technology problem may actually be a process problem. A process problem may be caused by a lack of user understanding. A manual activity may exist because the system was designed around the original implementation rather than the way the business operates today.
We therefore start by understanding the current state.
We assess the solution, talk to the people who use it, examine the business processes, review the D365 configuration and integrations, analyse pain points and identify where the greatest opportunities exist.
From there, we prioritise the opportunities based on business value, complexity, risk and available budget.
We don't try to fix everything at once.
We identify the changes that will deliver the greatest return and build a practical roadmap to address them.
The result is a progressive optimisation journey:
Understand → Assess → Prioritise → Optimise → Measure → Repeat
The objective isn't simply to make D365 technically better.
The objective is to make the solution to what the business wants better.
That means reducing unnecessary manual effort, improving process efficiency, increasing user adoption, removing workarounds, improving system performance and ultimately ensuring that the organisation gets the business value it expected from its D365 investment.
The SI delivered the solution. Now it's time to tune the solution to the business.
We are not here to re-implement the solution. We are here to improve, optimise and build on what the SI has already delivered.
That does not mean the SI has delivered a substandard solution. They have delivered against the agreed scope, requirements and contractual obligations they were engaged to fulfil—and that is what a good SI is expected to do.
Our role is different. We need to look beyond contractual deliverables and determine whether the solution is actually delivering the business outcomes, operational efficiencies and user experience the organisation expected when the transformation was initiated.
The opportunity is to identify where the delivered solution can be refined, simplified, integrated or better aligned to the way the business actually operates. That requires us to look at the business processes, people and technology as an integrated whole, rather than simply reviewing the technology in isolation.
This is not about undoing the SI's work or starting again. It is about taking what has already been delivered and making it work better for the business—closing the gap between what was contracted and what the organisation ultimately needs to achieve.
Ultimately, success is not measured by whether the SI delivered everything in the contract. It is measured by whether the organisation is realising the business value, efficiency and outcomes that the transformation was intended to deliver.
1 Secure Budget Allocation
Establish the funding envelope required to undertake the assessment and initial optimisation activities. The budget should provide sufficient flexibility to address the highest-value issues as they are identified.
2 Assess the Business
Conduct a structured assessment of the current solution across business processes, people and technology. Identify pain points, inefficiencies, gaps, risks, workarounds and areas where the delivered solution is not achieving the expected business outcomes.
3 Prioritise Based on Available Budget
Assess the identified issues against business value, risk, complexity, effort and available funding. Determine which issues should be addressed within the current budget and which should be deferred to a later phase.
4 Develop the Scope Document
Produce an initial scope based on the findings and agreed priorities. At this stage, the scope should be treated as fluid rather than fixed, allowing it to evolve as deeper analysis identifies additional dependencies, opportunities or constraints.
5 Develop the Detailed Delivery Plan
Once priorities have been established, develop a detailed delivery plan covering scope, milestones, budget, resources, dependencies, risks and governance. This provides the structure and controls required to move from assessment into execution.
6 Establish and Maintain the Blueprint
Create an As-Is Blueprint where adequate documentation does not already exist. Where documentation has been provided by the SI, validate it against the actual operating environment rather than assuming it is completely accurate. The blueprint then becomes a living document, progressively updated as we discover more about the solution, processes and business requirements.
7. Execute the Project Plan
We then execute the project plan, which covers the complete lifecycle of the project from initiation through to delivery and post-go-live. The plan provides the framework for managing scope, schedule, budget, resources, dependencies, risks, testing, deployment and business outcomes throughout the engagement.
The project plan is integrated with Azure DevOps, rather than maintaining separate project and testing artefacts. This provides a single, controlled delivery environment where requirements, work items, tasks, defects, test cases and results can be linked and tracked throughout the project.
Integrating testing directly into DevOps also makes the creation and management of test cases significantly less time-consuming and more repeatable. Test cases can be linked directly back to requirements and delivery items, providing clear traceability from requirement → development/configuration → testing → defect resolution → acceptance.
It also provides a complete and auditable project history. Once the project is completed, the DevOps environment effectively becomes an archive of the project artefacts and delivery history, rather than relying on disconnected spreadsheets, documents and emails to demonstrate what was delivered, tested and approved.
This approach gives us both greater delivery efficiency and stronger governance, while maintaining traceability across the entire project lifecycle.
