編集

次の方法で共有

Choose the right processes for your solution

  • [アーティクル]

Process architecture is a shared view of all the business processes that your organization uses to deliver a product or service. It shows how your organization operates, in a logical order.

Process architecture is the first and most important pillar of good solution design. It confirms your end-to-end business understanding, provides a structure for your scope, and serves as the basis for testing and training. It also forms a map for requirements gathering. The processes are organized at different levels to reflect specific areas, functions, locations, and teams. Process architecture is also called a target operating model, a process library, or a catalog.

Any transformation starts with defining your processes, which is also a good time to revisit and improve them. Defining your processes helps you:

  • Create consistency by consolidating and unifying processes across locations, teams, and systems.

  • Reduce complexity by standardizing and simplifying previously complicated and cumbersome procedures.

  • Eliminate guesswork and ambiguity by streamlining operations and improving communications.

  • Promote productivity by eliminating inefficiencies and establishing one workflow for all users.

  • Guarantee quality by maximizing attention to detail and ensuring work is done in a predefined, optimized way each time.

  • Boost morale by helping team members take pride in mastering the process, refining their skills, and avoiding mistakes and missed deadlines.

  • Encourage continuous improvement by giving team members who follow the processes a chance to give feedback on how to improve them.

  • Increase user acceptance by providing a higher-quality experience at each launch.

Dependent activities in the Processes pillar

While we won't go into the details of the business process management lifecycle and capability maturity, following the Success by Design framework can help you identify important elements of your solution design.

Process architecture includes several dependent activities:

  • Scope management: Defining the scope of the solution is the first step of the design. Ideally, you have a baseline process taxonomy with at least three levels of the process architecture. Start by mapping requirements to it and marking which processes are in scope. You can add or remove processes from your initial process library. Learn more in the section Key deliverables related to processes.

  • Linear and cross-functional process flows: These flows show the input, output, and activities at process and subprocess levels to help you figure out how to change a process to meet requirements. You can add details such as assumptions, metrics, timelines, and costs.

  • Business analysis: At first, business users often don't know or understand the application, and the tech partner doesn't understand the business. In those cases, a business analysis helps bring them together. A business analyst gathers requirements and links them to processes. Conversely, a good process structure drives the requirements gathering by asking all the necessary questions.

  • Requirements management: Every functional and nonfunctional requirement needs to be linked to at least one process. If a relevant process doesn't exist, you must slot it into the right section of the process architecture.

  • Solution design: After you have a better end-to-end business understanding, it's time to translate it into your system processes. With the Dynamics 365 solution design, a Microsoft partner works with the process leads to develop the solution. It's often helpful to create process flows that show how the processes can be run in the system.

    As part of the process, data goes in as input exchanged between people and applications, and data goes out as output in the form of documents, analysis, and reports.

    Diagram showing four interlocking circles to illustrate the idea that solution design (the center circle) encompasses people, data, processes.

  • Test management: After the solution is designed and developed, the process architecture establishes a baseline for testing. When you test every process, you ensure that every requirement is addressed and the solution is appropriate. Learn more at Testing strategy.

  • Training: Process architecture also defines and drives your training content. You can use your process flows and guides as a first draft for your training materials. Learn more at Process-focused solution and Success by Design overview.

Process architecture map: A visual presentation of your business processes.

Diagram of a process architecture map in the form of a simplified Kanban board.

Process catalog or inventory and taxonomy: A sequenced list of the processes, uploaded to Microsoft Dynamics Lifecycle Services (LCS) and synchronized with Azure DevOps Services.

A table with no content provided as an example of a process catalog or inventory and taxonomy.

Linear and cross-functional process flows: These flows show the input, output, and activities at process and subprocess levels to help you figure out how to change a process to meet requirements. You can add details such as assumptions, metrics, timelines, and costs.

  • Linear flow**

    Flowchart showing a linear flow.

  • Process flow**

    Simplified diagram of a process flow.

Requirements traceability matrix: Links requirements throughout the validation process, and is a key deliverable for requirements management.

Two overlapping tables with no content, and an arrow pointing from the bottom table to the top table, illustrating a simplified requirements traceability matrix.

Fit gap assessment: At this point, you mark which requirements and respective processes the system will address, and which ones require customization.

A table with no content provided as an example of a fit gap assessment.

Next steps