Choose the Right Processes for Your Dynamics 365 Solution
Process architecture is a shared view of all the business processes your organisation uses to deliver a product or service. It shows how the organisation operates in a logical order and is the first and most important pillar of good solution design. It confirms end-to-end business understanding, provides structure for scope, and serves as the basis for testing and training. Process architecture is also referred to as a target operating model, process library, or catalog.
Why Define Your Processes
Any transformation starts with defining your processes, which is also a good time to revisit and improve them. Defining processes helps you create consistency across locations, teams, and systems; reduce complexity by standardising procedures; eliminate ambiguity by streamlining operations; promote productivity by establishing unified workflows; guarantee quality through predefined optimised methods; boost morale by helping team members master their work; encourage continuous improvement through feedback; and increase user acceptance at each launch.
Dependent Activities in the Processes Pillar
Following the Success by Design framework helps identify important elements of solution design. Process architecture includes several dependent activities:
Scope Management
Defining the scope is the first step. Ideally, you have a baseline process taxonomy with at least three levels of process architecture. Map requirements to it and mark which processes are in scope — you can add or remove processes from the initial library.
Linear and Cross-Functional Process Flows
These flows show input, output, and activities at process and subprocess levels to help determine how to change a process to meet requirements. Details such as assumptions, metrics, timelines, and costs can be added.
Business Analysis
A business analyst bridges the gap between business users (who may not know the application) and the technology partner (who may not understand the business). They gather requirements and link them to processes, while a good process structure drives requirements gathering by prompting the necessary questions.
Requirements Management
Every functional and nonfunctional requirement must be linked to at least one process. If a relevant process does not exist, it must be slotted into the correct section of the process architecture.
Solution Design
With an end-to-end business understanding established, the next step is translating it into system processes. A Microsoft partner works with process leads to develop the solution, often creating process flows that show how processes run in the system — with data as input exchanged between people and applications, and output in the form of documents, analysis, and reports.
Test Management
After design and development, the process architecture establishes a baseline for testing. Testing every process ensures requirements are addressed and the solution is appropriate. See Testing strategy for further guidance.
Training
Process architecture defines and drives training content. Process flows and guides can serve as a first draft for training materials.
Key Deliverables
The Processes pillar produces several key deliverables:
- Process architecture map — a visual presentation of business processes.
- Process catalog/inventory and taxonomy — a sequenced list of processes based on the business process catalog, customised for the project and imported into Azure DevOps Services or similar tools.
- Linear and cross-functional process flows — showing input, output, and activities with supporting detail such as assumptions, metrics, and costs.
- Requirements traceability matrix — linking requirements throughout the validation process, a critical deliverable for requirements management.
- Fit-gap assessment — marking which requirements and processes the system addresses out of the box and which require customisation.
Source: Choose the right processes for your solution – Microsoft Learn