Identify solution components
During the discovery process, some solution ideas should start to become clear. This unit discusses how to identify solution components that might make up the proposed solution for the customer. Because this is still the presales phase of the project, your goal is to illustrate for the customer what the proposed solution will look like after it has been built and then explain how the solution will meet their objectives. It is also a good time to begin thinking about a product roadmap and about how the components will be implemented to show quick value over iterations.
Map needs to functionality
From your meetings with the customer, you should have captured their key needs. To identify components, you should reflect on these needs at a high level and match them to either existing Dynamics 365 apps, to a custom Microsoft Power Platform app, or in some cases, to custom development. For larger projects, you might need to map to multiple apps or all three categories.
Not all projects are starting from the beginning; many have existing systems in place and are simply enhancing or integrating with what already exists. For example, a customer might have Dynamics 365 Customer Service and is adding on some omnichannel features to address a specified need.
Some needs might map to more than one app. You might find that the sales aspect maps to Dynamics 365 Sales, with the commission tracking and payout being enhancements to their existing Dynamics 365 Finance app.
Be careful about mapping or proposing that the customer replaces or adds another app that duplicates something they already have. You might be helping the customer for that reason, which is acceptable. However, if the customer already has a non-Microsoft ERP, and you have proposed that they add Dynamics 365 Finance because it makes your solution deployment easier, your proposal will not be well-received.
For key solution components, we recommend that you highlight where out-of-the-box functionality will be used and where custom aspects are required. For example, you should highlight whether you were using standard sales features for everything except a product configurator. Then, for the product configurator, you would highlight the proposed solution, for instance, having a custom PowerApp embedded in the app or perhaps offering a third-party configurator solution.
Use imagery to explain complex ideas
You can create a single page diagram/picture that describes the solution in way that's easier to understand. Include the different personas who interact with the system so that it's clear how the solution will be used by different people. Avoid adding too much detail, which can make your diagram/picture difficult to look at and could over-complicate your ideas. If you keep your illustration concise and polished, it will become the reference point for future discussions and will set you apart from the competition. In places where more detail is necessary, you can create related diagrams that can focus on certain areas.
Data modeling
Formal data modeling happens as part of the solution's design and usually after a contract is in place. However, during the presales phase, high-level data modeling conceptualization is done constantly to identify the large pieces of data and where they might belong. If a proof of concept is done, this effort is often used to prototype what is demonstrated to the customer. These data model insights are also transferred into the design process to jump-start the data modeling thought process. Consider having a summary and detailed data model to share. The detailed model will be used by those who design and build the system. The summary model will be shared with stakeholders that need an understanding of the solution but don't require specific detail.
Process modeling
During discovery, you should have also learned about the customer's key processes. As you propose a solution, being able to tell the story of how your proposed solution accomplishes their key business processes is essential.
In some cases, your proposed process might be similar to the customer's existing process; however, more often, it will differ. As you identify the solution components, highlighting key differences is important and should include how your proposed process changes will achieve the identified objectives, such as resolving cases 20 percent faster while keeping customers more informed.
User experience
Customers will always focus on the user experience. During discovery, you should have captured details such as whether users are always mobile, sometimes mobile, never mobile, or other unique user experience needs. As you identify the proposed solution components, mapping these needs is important. As necessary, these components should be demonstrated with a proof of concept or wireframe that illustrates your proposed solution.
Wireframes might include the following elements:
Main forms
Dashboards
Mobile experience
Visualizations (for example, Power BI)
The following image shows an example of a wireframe and the actual form that you would build from the wireframe.
Integrations
Most solutions do not exist in isolation and rely on internal or external integrations. As part of identifying the solution components, you should be able to highlight how these integrations will be handled. This process might include defining what tools or services will be used to complete the integrations. In a multi-system solution, you need to define clear boundaries where one system ends and another begins. These boundaries become "contracts" between those responsible for their build and maintenance. Focus on what happens on these boundaries and try to clearly define whose responsibility it is to build interfaces and who will be consuming them. This clarification is especially important where third-party suppliers or internal development teams are involved.
Deployment options
Microsoft provides a subscription-based model of Microsoft Dynamics 365. With this option, you are able to access Dynamics 365 from the cloud without having to further invest in your IT network hardware and software licensing. No local deployment of the application is required, and your users will be able to access Dynamics 365 from multiple browsers. This access can be critical for remote or off-site staff who needs easy access.
However, Dynamics 365 Finance and Dynamics 365 Supply Chain Management (previously known as Dynamics 365 Finance and Operations) can be deployed on-premises, which means an organization can deploy the applications locally.
For the following Dynamics 365 applications, you should use Lifecycle Services for deployment:
Dynamics 365 Finance
Dynamics 365 Supply Chain Management
Dynamics 365 Commerce
For other Dynamics 365 business applications, such as the following list, your primary deployments will be online by using a standard development-test-production set of environments:
Dynamics 365 Sales
Dynamics 365 Customer Service
Dynamics 365 Customer Insights - Journeys
Dynamics 365 Field Service
You are also able to create a trial environment and give it a practice run, which will allow you to get your system up and running in a matter of days rather than weeks or months. You no longer have to contend with ongoing server maintenance or license fees. Additionally, you can purchase your user licenses directly online without going through a vendor, and you can add more users online as you need them and as your business grows.
Dynamics 365 business applications offer multiple types of environments. The type of environment indicates the purpose and determines the environment characteristics:
Trial - Trial environments support short-term testing needs and are automatically cleaned up after a short period of time.
Sandbox - Are non-production environments and, when associated with a Microsoft Dataverse database instance, offer features like reset.
Production - Used for permanent work in an organization. It can be created and owned by an administrator or anyone who is licensed with a Power Apps license.
Default - A non-custom production environment. Each tenant will have a default environment that is created automatically.
Developer - Developer environments are created by users with the Community Plan license. They are only for use by the owner. Sharing with other users is not possible in these environments.
Microsoft Dynamics Lifecycle Services
Microsoft Dynamics Lifecycle Services helps you manage the application life cycle of your Microsoft Dynamics 365 Finance and Microsoft Dynamics 365 Supply Chain Management implementations. Lifecycle Services is a Microsoft Azure-based collaboration portal that provides an environment and a set of regularly updated services. This portal provides a collaborative workspace that customers and their partners can use to manage Finance and Supply Chain Management projects. Lifecycle Services supports you from presales to implementation phase and then to the production environment, either on the cloud or on-premises. With checklists and tools, Lifecycle Services helps you manage the project, including providing prebuilt methodologies to help with implementation.
Lifecycle Services supports greater predictability, collaboration, and structural procedure for the administration of application management. The goal of Lifecycle Services is to move toward predictable, repeatable, and high-quality implementations by simplifying and standardizing the implementation process.
Next steps
Identifying the key solution components will help you determine your next steps. For example, you can determine your next steps based on whether you have demo-ready solutions that you need to tailor to the customer or if you are building a new proof of concept/prototype.
The goal of this process is not to create a detailed design of the full solution. Remember, this is still presales; you want to be able to tell the story of how your proposal will handle your customer's needs and have enough of the solution identified. Having this information in place will help you determine whatever pricing needs to be done so you can reach a signed contract and then proceed to build the solution.
Exercise: Identify common uses among Woodgrove Bank's teams
Review the Woodgrove Bank customer profile, specifically their customer-facing teams that were described. Identify common themes in the teams. Determine whether any teams overlap in needed functionality. Assess if any individual team is so different from the others that it warrants a separate solution.