How Process Definitions Relate to Solution Artifacts
Finally, the last perspective on the Purpose & Use of Process Definitions describes how the information captured and conveyed in turn becomes source material for later Solution Definition and Solution Delivery actions. Indeed, Process Definition artifacts are some of the first to produce, as well as some of the most valuable.
The time and effort to develop Process Definitions is a great investment. Process artifacts help organizations in many ways. Firstly, they will help evaluate and select alternative applications. Secondly, they are invaluable when defining Solution Strategy & Architecture. Thirdly, they provide much of the source material that will guide Feature & Story Analysis & Design.
BPD's Place in the Bigger Iterative Delivery Picture
The first steps towards transformative change pose several challenges. Of course, it's one thing to say, 'We want a new ERP' (or CRM, PLM, etc.). However, it's quite another to nail down just what that means. And yet, nailing it down is precisely where things should start.
What are the objectives, and the scope?  Who are the relevant decision makers, customers, and participants?  How much work is involved, how long will it take, and what will it cost?  All valid questions. All require answers.
Process Definitions offer an excellent place to start. In fact, proper Definitions bring focus to all these questions, and more. Indeed, they are one of the few aspects of an implementation in which the organization already has existing knowledge upon which to build.
However, it's not just diagrams and matrices which provide guidance. More important are the discussions and negotiations which occur during their creation. In fact, working through such details early on resolves many questions, clarifies direction, and saves both time and money.
When a change calls for the implementation of a supporting Product, creating Business Process Definition(s) (BPDs) will guide a majority of Solution Definition. Furthermore, they will continue to save time and provide value throughout Solution Delivery.
Solution Definition
Rough Framing
As soon as an organization considers implementing a new business application, work to define affected business processes should begin. This work is not a 'nice to have' or, really, even optional. Instead, it establishes a foundation upon which to properly plan, design, and implement change.
One of the first things to consider is the impact a new Product may have upon the existing Portfolio. Whether this occurs as a stand-alone initiative, or through Portfolio Management, establishing who, what, when and why goes a long way towards ensuring the success of any initiative. Process Definitions drive answers to these, and other, questions.
In most cases, enterprise-level change involves more than one Business Process. For each process, all Definitions begin with Level 1 & Level 2 diagrams. An important aspect of these levels is that they should be technology agnostic.  In other words, there is no need to select an application before these get underway.
In fact, if Product selection has yet to occur, then Level 1 & 2 diagrams provide vital information to help choose an appropriate Solution. Alternatively, even when the target application is known, there are still many questions to answer. For instance, about which module(s) and function(s), to use. For which customers, and so on.
Eliminating Guess Work and Assumptions
Creating BPDs provides vital information an organization requires to evaluate and select appropriate technology. Moreover, their production encourages organizations to delve into, and capture, Business, IT and other requirements. As a result, the initial process artifacts provide sufficient info for an organization to identify key pieces of information, such as:
- Relevant Epic Owners, Business / Process Owners, SMEs.
- Affected Business Segments, Organizations and Customers.
- Epic(s), which help define scope and drive objectives.
- Technology alignment.
- Integrations / Interfaces.
- Reports; and
- Data Stores / Data Migrations.
Thereafter, organizations have the option to choose which items to pursue now or defer until later. Indeed, most Solutions involve multiple processes, or portions thereof. In the aggregate, information across the in-scope Definitions contributes to the initial development of Solution Strategies, Architectural Diagrams, and Solution Approaches. Together, these provide many of the answers Sponsors and other stakeholders will have regarding each upcoming Solution Phase.
Defining What's First (or What's Next)
Once the supporting Product, is known, then Teams can complete Level 3 diagrams. Participants may view this work as either one of the last tasks in Solution Definition, or one of the first tasks in Solution Delivery.
Regardless, Teams must complete Level 3 flows before, or during, Phase Inception. Inception marks the transition from Solution Definition onto Solution Delivery.  At this point, scope and objectives for the first, or next, Phase are set.
Level 3 diagrams map the operational aspirations of each in-scope Process into the functional steps to execute it within the chosen application. Additionally, participants should gain a valuable introduction to future-state functionality.
Completed Process Definitions provide additional detail required to complete the initial Solution Strategy & Architecture. Thereafter, the process artifacts in each BPD become a touchstone for subsequent Solution Delivery.
As shown in the figure, each BPD also contributes scope, context and content with which to plan and estimate subsequent Solution Delivery work.
Each BPD provides information required for Analysis & Design, as well as subsequent Build, Test & Deploy tasks. Together, relevant BPDs help prioritize efforts and drive knowledge-based decisions.
Lacking the foundation BPDs provides, any of these subsequent activities can go easily astray or overlook critical aspects. Both are sources of delay, missed target objectives, and increased costs.
Solution Delivery
Planning
To begin, Process Definitions drive a large part of long-term and medium-term planning. Choosing which Process(es) and Customers to focus upon determines a large portion of a Solution's scope and objectives for each Phase. Thereafter, segmenting in-scope actions - Process, Activities or Tasks - into manageable delivery increments produces an initial Feature set. Sequencing which actions, and hence which Features, to implement in what order determines a large portion of the Solution's Roadmap. Afterwards, process artifacts will also drive a large portions of Release Planning.
Analysis & Design
Similarly, Process Definitions also play a large role in Implementation and Testing. As Teams work through Analysis & Design, process-related content will guide Feature Planning. Definition content will identify relevant participants and decision makers. Conversely, content can also help screen out those whose "opinions" may not be relevant. During related Story Analysis, Definition content will guide many aspects of functional specification. Additionally, the diagrams and matrix content will contribute to a large number of Acceptance Criteria to both Features and Stories.
Build, Test & Deploy
Subsequently, Process Definitions will again become pertinent during Build, Test & Deploy. For instance, Solution leadership will refer to Process Definitions during Feature Release. They will use Definition content to plan delivery and to prepare customers for the rollout of new Features. Likewise, Change Management will rely upon Definition content to identify the organizations and roles pending change will affect. In other words, it will help them identify individuals who should receive communications and training. Moreover, the content will help in the framing and development of training materials.
Finally, Teams will rely upon Definition content to configure and/or develop application functionality. Correspondingly, Definition content will also help them produce related Operating Procedures. Furthermore, Teams will refer to Definition content in order to plan and develop Build-level tests. In similar fashion, Quality Assurance may reference Definition content to plan and develop Candidate-level tests.
From a Portfolio perspective, Business Process Definitions provide the content needed to align Strategy, Capabilities, and efforts across multiple Products and Projects.
This part provided a cursory understanding of the purpose and use of BPDs. The next part describes the Creation & Evolution of a Business Process Definition.