MB 600: Microsoft Dynamics 365 + Power Platform Solution Architect – Perform fit/gap analysis

I am currently preparing to take the Microsoft Dynamics 365 + Power Platform Solution Architect certification. Or “MB 600” for short! As I prepare I plan to write revision notes in this post I will cover Perform fit/gap analysis.

Fit gap analysis is a process for identifying and documenting gaps between the customer’s requirements and built-in capabilities.

A Power Platform Solution Architect will typically start the design process with a focus on Dynamics 365 and the Power Platform and only later use a more custom approach to address any gaps. The detailed design will specify customizations to Dynamics 365 apps and any existing apps. The architect will often leverage a fit/gap analysis to help identify gaps between out of the box Dynamics 365 functionality and the required solution.

Determine feasibility of requirements

The feasibility of each requirement should be reviewed and any gaps that prevent the requirement from being feasible filled.

It maybe common to create a spreadsheet that highlights any gaps that need to be filled for each requirement. But equally a section could be added to the user-storys to fulfil this purpose. (Or perhaps the details can be recorded on Azure Dev Ops work items!)

When considering each gap between the requirements and out of the box functionality the Solution Architect may need to consider;

  • Severity of the gap – It may help to categorize each gap as needing configuration, customization or other solutions. The exact categories you decide upon may vary but the goal will be to understand how much custom work is needed.
  • Level of Effort – the size of the task. You can’t always estimate the effort in the early days in exact terms. Often the effort will simply be classified as “low, medium or high”. Or maybe some other form of points scoring system is used. I have seen some teams refer to gaps in terms of t-shirt sizes. (Is this a S, M, XXL etc) However you decide to estimate the effort be consistent so that a comparison between the gaps can easily be made.
  • Priority – it maybe common for the business to set the priority of each gap. But architectural / technical concerns may mean the Solution Architect suggests a higher priority on some items.
  • Implementation approach – in each gap describe at a high level how the customization or configuration change will be achieved. This would not be a detailed design but will give a high level explanation of how the gap might be filled.

Evaluate Dynamics 365 apps and AppSource options to solve requirements

The Solution Architect must be aware of the various Dynamics 365 apps and when they maybe useful. However the Solution Architect cannot realistically be expected to be an expert in all of the applications. But they should have an awareness of the various apps and their primary use.

Dynamics 365 (Customer Engagement / “CRM”) is essentially a set of model-driven Power Platform apps based on the Dataverse (CDS). They have been born out of earlier Customer Relationship Management (CRM) solutions. Included are separate apps for Sales, Customer Service, Field Service and Marketing.

Dynamics 365 Finance and Operation apps are descended from Enterprise Resource Planning (ERP). These include Dynamics 365 Commerce (aka Dynamics 365 Retail), Dynamics 365 Finance, Dynamics 365 Human Resources (aka Dynamics 365 Talent) and Dynamics 365 Supply Chain Management.

3rd party (ISV) solutions can be found in AppSource. Independent Software Vendors (ISVs) can register their solutions in AppSource by going through a certification process with Microsoft. Sometimes leveraging an ISV solution can be useful to reduce custom development efforts. Often partners develop skills with a particular set of ISV extensions that they will reuse in multiple engagements. The Solution Architect may be involved in the evaluation and selection of these solutions. Some common considerations when reviewing an ISV solution include;

  • How long the ISV has been in business?
  • How large the ISV is?
  • Whether they have the ability to support an implementation of your size?
  • How long they have been building for the Power Platform and Dynamics 365?
  • How many other customers are already using their solution?

When you evaluate ISV components consider;

  • Security integration – check the component works with the Power Platform and Dynamics 365 security model.
  • Flexibility for customization – Review what is offered by the component and whether it will fulfil your requirement or need customization. And if that customization is possible.
  • Stays with current Microsoft releases – Assess if the ISV is keeping up with Microsoft releases.
  • ISV roadmap – determine if the ISV has a roadmap for enhancements. And if the component offer “as is” or will your customer receive updates.
  • Data location – If the component stores data then check the data location and any related compliance concerns.
  • Fitting the gap – verify that the components and its licensing do fill the gap and understand what technical debt you might be adding to the solution.
  • Licensing – consider what licenses are needed from the ISV and also what Dynamics 365 licenses might be needed to support the features in the ISV solution.

The solution Architect will need to understand the core capabilities of each of the Dynamics 365 apps. As that will be essential know when looking for gaps that need custom solutions. Also look for cross overs between apps. For example a “case” in Dynamics 365 Customer Service may require onsite work and could become a “work order” in Dynamics 365 Field Service. Often starting with a Dynamics 365 app will be the fasted path towards your go live target. But gaps may still exist which require tailored solutions, spotting and filling these gaps will be an essential task for the Solution Architect.

Dynamics 365 Sales

Dynamics 365 sales enables us to identify leads, qualify them into opportunities and then progress these into quotes, orders and ultimately invoices.

If you wish to add any items into your opportunities, quotes, orders or invoices then a product catalog will need to be created. Additionally price lists and price list items will be created for the items in your product catalog.

When considering gaps … you may need to review;

  • the lead to opportunity processes,
  • product catalog composition,
  • pricing models,
  • lines of business (wholesale / retail),
  • Integration with account systems,
  • Integrations with ERP solutions
  • Etc.

Additionally consider any configuration data requirements. For example, your ALM processes may need to migrate the product catalog data from environment to environment. (FYI: The product catalog does not form part of the solution!)

Other Dynamics 365 apps that might come into play when considering sales could include;

  • Customer Insights,
  • Sales Insights,
  • Product Visualize
  • LinkedIn Sales Navigator integration

Tip: If you aren’t familiar with the above apps, I suggest part of your revision should include some research into their capabilities.

Dynamics 365 Customer Service

As the name suggests aimed at managing the services you provide to customers. The key entity in Customer Service is the case. Customer’s maybe entitled to unlimited cases or have restricted entitlements. Cases can be routed to agents who may leverage knowledge articles to resolve the case. Service level agreements may be used to help target the “correct” cases and may aid management reporting.

Capabilities include automatic record created rules, knowledge articles, SLAs and the customer service hub.

FYI: The customer service hub is an app with an interactive experience which enabled agents to manage cases.

Gaps / customizations to consider might include;

  • Case creation logic (email to case etc)
  • Case resolution process steps
  • Case hierarchies (parent / child cases)
  • Entitlements (aka contracts)
  • SLA actions, what happens if an SLA becomes non-compliant
  • Requirements for self-service portals
  • Etc etc.

Other Dynamics 365 apps that might come into play when considering customer service could include;

  • Customer Insights
  • Omnichannel for Customer Service
  • Unified Service Desk
  • Power Virtual Agents
  • Customer Service Insights
  • Portals

Dynamics 365 Field Service

Dynamics 365 Field Service helps deliver onsite service. It combines workflow automation, scheduling plus a mobile application. With mobile being a key component as onsite workers typically need to view jobs and record their progress from remote locations.

The work order is the primary entity in Field Service. This defines who the customer is and what work is required. The work order can be scheduled and an engineer dispatched. The engineer can record their service delivery tasks against the work order. And ultimately the work completed can be reviewed and billed to the customer.

When defining gaps with Field Service you might need to be aware that a Field Service implementation typically involves a lot of configuration work. As to be able to schedule work orders successfully we need to understand many attributes about the jobs and the resources that will complete those jobs. Including resource skills, pricing models, locations, customer agreements and much more. Additionally definitions of how the schedule boards look and various status values will need to be defined. None of this configuration data will form part of your solution. Meaning ALM processes may need to consider how to migrate this configuration data from environment to environment.

Additionally Field Service includes multiple pre-configured workflows and plug-ins out of the box. These aid in the creation, scheduling and billing of work orders. You may need to ensure that any customizations do not clash with these existing automations.

IoT may also be used. Internet of Things (IoT) can be integrated with Field Service to provide a connected Field Service solution. Providing reactive maintenance based on alerts from internet aware devices.

The mobile app of Field Service would also need careful consideration. The use of offline capabilities, for example, will be common in Field Service scenarios.

Universal Resource Scheduling (URS ) is a component of Field Service that enables scheduling of work orders. You should be aware that URS can also schedule other entities and may be used as a standalone scheduling engine.

Dynamics 365 Marketing

Dynamics 365 Marketing is a marketing-automation application that helps turn prospects into business relationships. The app is easy to use, works seamlessly with Dynamics 365 for Sales, and has built-in business intelligence. Use Dynamics 365 Marketing to create graphical email message, share information across sales and marketing teams, and more.

Dynamics 365 Marketing implementations may include requirements to implement a Dynamics 365 Portal to host marketing forms, unsubscribe pages etc. Or a custom CMS can be deployed as an alternative if required.

Dynamics 365 Marketing implementations may focus on a single communication channel, for example email marketing. But they could include many other channels. (Such as social media channels.)

Leads generated in the Marketing application can be scored and ultimately marked as “sales ready”. You may therefore need to consider how and when leads transition from being owned by the marketing team into a lead that is progressed in Dynamics 365 Sales app.

Dynamics 365 Marketing also includes a comprehensive event management system. Defining and running events can be a complex task!

Address functional gaps through alternate solutions

Several additional products and services maybe used;

  • AppSource – Independent Software Vendors ISVs) build products and services that are available through AppSource. AppSource contains products and services which have been verified by Microsoft and may help to reduce the work needed to deliver a solution.
  • Azure DevOps – allows the formerly siloed roles of Development and IT operations to coordinate and collaborate in the process of creating products / solutions.
  • Dynamics 365 Customer Insights – a customer data platform used to unlock insights. Unify all customer data across a range of sources to provide a single customer view.
  • Dynamics 365 Fraud Protection – Help protect your e-commerce business, and your customers, against fraud
  • Dynamics 365 Layout – Design spaces more efficiently. Dynamics 365 Layout helps you make informed decisions before you build.
  • Dynamics 365 Remote Assist – Can run on HoloLens, Android, or iOS devices to empower technicians to collaborate more effectively.
  • Forms Pro (Now called Dynamics 365 Customer Voice) – create surveys to capture, analyse and act on feedback.
  • Mixed Reality – blends the physical and digital worlds. The next level of human, computer and environment interaction.
  • And maybe more!!

Determine scope

The scope could be considered a statement of the assets to be created in the project or the requirements to be delivered. The gap analysis will go a long way in identifying that everything to be delivered has been included in a scoping statement.

It maybe important for the scope statement to clearly explain all of the functional and non-functional project deliverables.

Importantly, I always like to accompany my scope statement with an “out in scope” statement. Any items that have been considered, referenced or even just mentioned in passing that deliberately aren’t going to be developed should be explicitly mentioned in an out of scope statement. Why?? Well, it helps make clear to the customer what they aren’t going to get. Doing this can help manage their expectations.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s