Date: 27 October 2021
This blog is to provide an overview of the discussion and questions asked, including those by attendees, for quick reference to support your Digital Transformation efforts. The webinar was a discussion on best practices in implementing Microsoft Dynamics D365.
Michele Caminos Executive Strategic Advisor
Russell Ewart Head of Digital Delivery
Rana Gorgees Principal Test Consultant
Shikar Ramchand Principal Consultant
The panelists discussed data migration, implementation and deployment, customisation, the experience of the team, and on-going updates. It was a practical discussion on how to de-risk the initiative for the most success.
Following is an overview of what was discussed in the webinar.
What are the top 3 challenges in implementing and deploying Microsoft Dynamics 365?
- Data Migration is often one of the biggest and most complex challenges specifically when it comes to Microsoft Dynamics 365 F&O ERP transformation
- Understanding Configuration vs Customisation and catering to testing both
- Integrations and Business Process Testing end-to-end. Understanding the different integration points and information flow end-to-end is challenging in large-scale and complex organisations.
Where does data migration factor in the build and deploy? And what are the test requirements?
Our recommendation is that you cater to migration implementation and testing as early in the delivery cycle as possible. We often see delivery delayed as a result of migration or the entire migration approach changing midway through so it is important to start early and allow time for learning and adapting
If the migrated data is not ready, who do you tend to work with at the client site to create data for testing?
If Data Migration is not ready then that is not necessarily a show stopper to testing. Consider creating your own test data (eg Products, Vendors, Customers) and test with newly created data. After all, we recommend testing D365 with existing and newly created data.
Does the level of customisation impact budgets, timing and test requirements?
Customisations do tend to require a greater level of test analysis to ensure that the functionality built meets specified requirements. Test efforts are focussed on high priority requirements and functionality with customisations usually considered high priority. So generally speaking, the greater the number of customisations the greater the budget and/or time requirement.
Taking into consideration many companies are trying to reduce the amount of customisation – where does Customer or Employee Experience fit in? Or does it?
For many organisations, one of the goals of implementing a product such as D365 is to reduce maintenance and operating costs. This is countered by the importance of realising the outcomes of your internal and external customer needs. At Assurity, we recommend Agile practices in delivery with early and continuous demonstrations. This enables the Product Owner to make informed decisions that minimise the customisations to high-value changes as required.
SOFTWARE INTEGRATION & BUSINESS PROCESS IMPACT:
What should companies think about when testing the software supporting a business process? What are the challenges?
One of the things that companies should think about is making sure that the software delivered does support their existing business processes. If it doesn’t support it then they need to think about either changing their business processes which will have an impact on training and change management efforts or customise the software which will introduce a risk to future updates.
Companies should consider getting the business involved in the delivery journey (including testing) as early as possible as that would help understand how close the delivered software is to their actual requirements and day-to-day BAU.
One of the biggest challenges in larger implementations in our opinion is how do you ensure that you have built and tested the solution end-to-end. Most people tend to get focused on building and testing in their own world and forget about the big picture. What has helped us in the past is having a few key people within the project team that champion the end-to-end view. These people can be your Test Manager, BA Lead, Product Owner, Solutions Architect, etc. The effort to understand and deliver an end-to-end solution is very much collaborative but it can help to have a few key people in the project that advocate and drive towards it.
Have you seen phased releases of Microsoft Dynamics 365 Sales (or any module) and if so what are the risks/benefits and things to consider?
Yes. The key consideration is the risk or impact to your organisation’s business of an early release, with subsequent releases of functionality. The key benefit is fast and real feedback from the Production environment which can be channeled into subsequent releases. In this approach, minimise customisations to only essential change and ensure the appropriate support team to facilitate change.
What are the key areas for security testing, importance, and how to identify these areas?
Microsoft Dynamics 365 as a Cloud product is hosted by Microsoft with its associated security assurances. Our recommendation is to be clear in your risk profile to understand the level of security assurance you need. Our security testing focus for most organisations is focused on the integration across their digital ecosystems, rather than the cloud product.
How do you handle observed performance issues (e.g. slowness) on Microsoft Dynamics 365 or any cloud SaaS, given that vendors do not allow performance testing on a multi-tenant environment?
Our experience of performance testing M365 has been positive. Issues are largely identified in the wider ecosystem and its interfaces with Microsoft Dynamics 365. Microsoft does offer a service called FastTrack that is designed to help implementation and go-live. As part of this, the FastTrack architect can advise and guide a customer/implementation team through confirming the performance test scope.
TEST TEAM EXPERIENCE REQUIREMENTS:
How important is it to have a deep understanding of Microsoft Dynamics 365 for testing purposes? And does a deep understanding help to streamline the testing process?
It’s certainly advantageous to have a deep understanding of MS 365 as it results in a lower learning curve and will support the business transition working alongside Product SMEs. Clarity on successful outcomes for the organisation is far more important to streamline the testing process.
What are the tools Assurity recommends for Microsoft Dynamics 365 testing?
The toolsets to support testing is dependent on the organisation and its environment. Assurity has used Opensource frameworks with complimentary use of RSAT to drive tests from MS 365 or verify results in Microsoft Dynamics 365. The toolsets must be part of a wider Test and Automation strategy, to ensure its longevity and return on investment.
Post g0-live with Microsoft Dynamics 365, what should companies consider for a successful roll-out and ongoing maintenance?
An automated regression suite that focuses on customisations built as well as key functionality/workflows for your organisation will allow for a faster, more efficient, and repeatable regression test cycle. Microsoft Dynamics 365 wave updates are rolled out (up to 8 times per year) by Microsoft, so time and cost spend will typically be far better versus a manual regression effort.
At what point should companies think about managing the software updates?
From the outset and as part of the decision to implement Microsoft Dynamics 365. A comprehensive strategy is required to ensure you don’t inherit large-scale business testing of patch releases that impact operations. Assurity has experienced large organisations with multiple cloud products impacted by ‘patch proliferation’. Remediation is far more costly than a robust implementation and operation strategy for patch updates.
Where is Test Automation best placed in Microsoft Dynamics 365 implementations?
Assurity recommends a focus on automation at the border, focussing on end-to-end business tests. Remember you are not testing the working product you have bought but that it’s working in your wider ecosystem.