Level 1 - Process Flow Diagram

Generally, Level 1 is where Creating the Process Definition Diagrams begins. This first BPD level depicts a Process Flow Diagram. Unlike the Level 0 Diagram, which merely lists Activities, this diagram shows their sequence, or relationship to one another. Accordingly, it is a good place to begin getting stakeholders on the same page.

Most importantly, this is the level which defines the scope of a given Process. In other words, the Activities which appear on this diagram establish boundaries. As a result, those boundaries affect things such as ownership, Analysis & Design, as well as overall Solution scope.

The Process Flow Diagram - Level 1 (L1)

Basically, a Level 1 Diagram defines the scope of a Defined Process. More specifically, it depicts a Process' relationships to other, Related Processes and Entity Types by identifying Activities with which they interact. Of course, these relationships are what make this a process flow diagram.

Comparatively, like the Level 0 - Process Context Diagram, this is also a single-page summary of the Process. However, unlike Level 0, this diagram uses the same format as the lower-level diagrams (Level 2 & Level 3) use. Accordingly, this is the 'Zoom Out' perspective, providing the least amount of Process detail.

Indeed, this form better suits those with an interest in a more informative description of the Process than a Level 0 diagram offers. Accordingly, this format better supports subsequent Solution Definition and Solution Delivery activities.

Diagram Overview

On This Page

Add a header to begin generating the table of contents

Description

Firstly, a Process Flow Diagram (Level 1) depicts the first layer of Process decomposition. Basically, it shows Activities within a given Process, as well as their sequencing, or relation to one another.

Activities are a standardized representation of the decomposed Process. Their design facilitates information gathering and communication. Although, Level 1 diagrams are technology independent. That is, they do not convey application, or Solution, specific information.

Level 1 diagrams also depict interactions between the Activities and specific Entity Types. For instance, banks, suppliers, customers or employees. Indeed, identification of specific Entity Types, as well as the information they provide to, or received from, each Activity is the primary purpose of the Level 1 Diagram.

Significantly, this diagram does not include Swim Lanes. The reason for this is that at this level there is no alternative ownership or responsibility beyond that for the Process itself. In other words, the Business Segment which owns the Process, also owns its Activities. Consequently, this eliminates any perception that multiple Business Segments own the same Process or define its Activities. Further clarification of ownership, participation and responsibility begins in corresponding Activity Flow Diagrams (Level 2).

Purpose / Objectives

Secondly, a Process Flow Diagram (Level 1) serves several purposes, including to:

Graphically depict all Activities within a given Process, along with their sequencing, or relation, to one another.
Identify the general information exchanged between the depicted Activities.
Identify any Related Processes (defined or undefined) which precede or follow, any Activity.
Identify the information exchanged between each Related Process and the Activity(ies) with which it interacts.
Identify all Entity Types (organization, Business constituency, system, etc.) which provide information to, or receive information from, each Activity.
Identify the information exchanged between each Entity Type and the Activity(ies) with which it interacts.
Identify the Report or File Types that provide information to each Activity, or which the Activity generates.
Provide a context with which to decompose each Activity shown into more descriptive detail, using Activity Diagrams (Level 2).
Act as a tool for communicating to, and facilitating discussions with, Business and/or IT SMEs.

Development Guidelines

Thirdly, follow these guidelines to successfully produce a Level 1 Diagram:

Firstly, depict the decomposition of only one (1) Process. The flow may reference other, Related Processes. However, it should never depict any of the Related Process' Activities or other, more detailed, actions.
Give each Activity depicted a unique Activity ID in the form of 'PP.AA', where PP is the parent Process ID, and AA uniquely identifies each Activity within.
A Level 1 diagram does not cross Process boundaries. That is, all depicted Activities must be completely within the scope of the parent Process. Furthermore, the same Activity, with the same 'PP.AA' identifier, cannot belong to more than one Process..
A Level 1 diagram does not cross Solution boundaries. A change from one Solution to another is a natural break when defining a Process. Conversely, a Process may span multiple Components within the same Solution. Although, in many cases, moving from one Module to another is often another indicator for a separate Process.
Interactions depicted with Related Processes appear as an interaction between the Activity shown and the external, related Process. To emphasize, it should never interact with any Activity within the Related Process. Identify the Related Process using the Process icon, along with its Process ID (if a Defined Process) and Process Name (whether defined or undefined). Use Notes to provide additional detail, such as a related Activity or Task ID.
Interactions between Activities and Entity Types must have labels describing information conveyed.
Level 1 does not depict ownership or responsibility for a given Activity. In general, this is to facilitate discussions of potential alternatives, such as outsourcing or the introduction of shared services, without creating prejudice or bias within the diagram (yet).
A Process Flow Diagram generally does not depict:
- Ownership or responsibility. That is, no Swim Lanes.
- Decisions.
- Specific Entities.
- Specific Reports or Files.

Sample Diagram - Level 1 (L1)

For additional, more current information review the template diagram and included instructions available in the BPD: Templates section.

NOTE: Templates will soon be available for self-service. In the meantime, Contact Us with your request and we will provide a template via email.

Diagram Contents

A Process Flow Diagram captures and conveys the following items. In general, Field refers to a column with the corresponding Process Detailing Matrix, while Object refers to items appearing in the Process Diagram. In short, these are two labels referring to the same items.

Subject	Field / Object	Notes / Guidance
Page Setup	Process Name	The Header identifies the Process being described.
	Process ID	Also shown in the diagram Header. 'PP' is the Process ID, and represents the Process portion of each action's unique ID.
Actions	Actions	Action icons depict each Activity at Level 1 that is in scope of the parent Process.
	Activity IDs	Each Activity icon has a unique identifier. 'AA' represents the Activity portion of each 'PP.AA' Activity ID.
	Activity Names	Each Activity icon has a descriptive name. Use active terms for Activity Names to help distinguish them from passive Process Names. For example, use 'Manage Quote' rather than 'Quote Management'.
	Process Start / End	May be one or more of: a) Events (Trigger / Terminator); and/or b) a colored Related Process.
	Events	Event icons describe other Event(s) that initiate (Trigger) or end (Terminator) an Activity. They may also highlight notable milestones throughout the Process.
	Related Processes	Identify Related Processes with which the given Process interacts, precedes, or succeeds. Provide the Process ID and Process Name which appear in other Process Definitions, or no ID and a descriptive Name for any undefined Process.
Entities	Entities	In general, an Entity is any organization, constituency, or system with which the Process interacts. Use a single Entity icon when only a single Entity, such as a specific 'Bank', applies. Otherwise, use a multiple Entity icon to depict an Entity Type when multiple Entities of a given type apply, such as 'Banks'. Do not depict the underlying core application or Business Function which owns the Process as Entities.
	Entity Interactions	Identify any interactions which occur between any Entity and an Activity. Use Notes (see below) to describe the general content or purpose of each interaction.
Interactions	Precedence or Dependence	Use Connector arrows to indicate the sequence of flow. If there is a main sequence, then the diagram may highlight (i.e., bold) relevant arrows.
	Data In/Out	Data In/Out icons refers to files, reports, messages, or other data sets which an Activity receives (In) or produces (Out). At Level 1, it is most common to depict more general Data In/Out Types, rather than specific Data In/Out objects. For instance, it is better to use a multiple Data In/Out icon to depict 'Financial Statements', rather than using several single Data In/Out icons to depict a 'Balance Sheet', 'Income Statement' and 'Cash Flow'.
	Objects	Object icons identify major repositories, key operational data, or other notable content and/or components in the supporting technology which a Task interacts with. Depicting Objects at Level 1 is optional. That is, only depict individual content or components as Object icons if desired and if space allows.
	Business Rules	Decision icons represent major decisions or alternatives which affect the flow of actions.
	Notes & References	Use Notes to add color commentary, additional information, or references to other materials relevant to the diagram.

Diagram Development & Use

In most cases, a Business Analyst facilitates the creation or update of a Process Definition. However, they should do so in collaboration with the relevant Business / Process Owner and appropriate Subject Matter Experts. Ideally, other Team members participate and support Definition development.

To create the initial version, begin with a BPD Template that includes standardized page layouts and icons to use. Otherwise, to update a Definition for a subsequent Phase, use the most recent version from a preceding Phase. Thereafter, follow the steps below to create, or update a Level 1 - Process Flow Diagram.

Regardless of which Phase the artifact is for, initial development of the current version occurs prior to Phase Inception. As a result, each Level 1 Diagram defines scope, key events, ownership, actions & interactions which corresponding Solution Strategy & Architecture materials use to conclude Solution Definition, and which later guide Solution Delivery.

Overview

For any transformation or implementation affecting business operations, Level 1 Diagrams are some of the first artifacts to produce. Indeed, they are also one of the easiest. In effect, each begins to provide content, context, and structure, at a point when ideas are loosely defined, and may vary according to any individual who floats them. In this respect, a Process Flow Diagram is a great tool to refine ideas, and to place initial stakes in the ground.

Accordingly, a Level 1 Diagram for each Process begins to paint a tangible picture to help guide discussions and align stakeholders. Moreover, initiatives often involve more than one Business Process. Thus, in the aggregate, across several Processes, Level 1 Diagrams begin to define potential scope and scale. Although, appearance on a diagram does not equal approval for implementation. Those decisions come later.

To rephrase it, recognize that Process Definition diagrams define boundaries. Boundaries between processes, systems, entities, constituencies, and ownership. Accordingly, they facilitate more focused, and constructive, discussions. In time, participants use these boundaries to define scope and participation for many subsequent activities.

To summarize, these diagrams are the first artifacts an organization can refer to and say, "We're talking about this. We're not talking about that". Alternatively, that 'This' is in-scope; and 'That' is out-of-scope. As a result, these diagrams provide much of the information to frame individual Solutions. Furthermore, they help identify relevant stakeholders to involve in the definition of a Process.

Solution Definition

From a Portfolio Management perspective, development of Business Process Definitions begin during Ideate. Specifically, the first pass at Level 1 diagrams occurs when Analyzing a Request for Change. Alternatively, if not using Portfolio Management [though you really should - even for a one-off implementation] Level 1 diagrams should still be one of the first artifacts to produce.

Certainly, some organizations choose to define both Current-State (or As-Is) and Future-State (or To-Be) processes. Alternatively, others only focus upon the Future-State. Indeed, the success of any Business Application implementation requires Future-State Process Definitions. Conversely, only define Current-State if the organization feels it's important to do so.

During Solution Definition workshops, meetings or interviews with Business & IT representatives, use the Process Flow Diagram to facilitate discussions and to gather information about the given Process. Through these discussions, the diagram should evolve to better reflect the expected, future-state Process.

Step 1 - Page Setup

To begin, the first step in producing a Level 1 Diagram is to place it in the proper location.

If one does not already exist, then add a page / tab to the BPD Diagrams for the Level 1 depiction.
Place this page right after the Level 0 Diagram. That is, it should be the second page to view.
Label this page / tab to indicate the level and and Action depicted. For example, 'L1:[Process ID].00'
Update the page Header to show 'Level 1 | [Process ID] [Process Name] | Process Flow'.
The page left heading should read 'Process Activities, Inputs, Outputs & Entities'.

The Level 1 Diagram always appears on just a single page. It is a definition of scope, and clarity is important. Having to look over multiple pages reduces that clarity. If the page contents seem too crowded, try ensuring that Entity Types and Data Types appear rather than individual Entities or Data Objects. Alternatively, if still too crowded, drop Data icons and depict only Entity icons.

For additional guidance and insights, look to BPD Pro-Tips.

Step 2 - Actions

Secondly, the next step in producing a Level 1 Diagram is to depict all relevant actions.

Diagram Level Actions - Activities

Actions are the single most important aspect of each Level 1 Diagram. Indeed, they determine everything else the diagram depicts. Actions at Level 1 are Activities. Moreover, a Level 1 Diagram only depicts Activities. That is, this level should not depict any lower-level Tasks or Steps. Rather, for consistency and clarity, leave these other actions for definition at their appropriate level.

The primary reason for their importance is that Activities define the scope of each Process. Accordingly, add an action icon for each Activity. On the one hand, they indicate the portion of work to occur within a given Business Segment. On the other hand, their appearance also determines related items, like Entities and other Processes, which interact with them.

These two simple beginnings - actions, plus what relates to actions - offer the means to organize and orchestrate a vast amount of subsequent implementation work. Activities, and their related items, guide Solution Definition. Furthermore, they will play an important role later in Solution Delivery.

Reasonable Scope

Regardless of the scope and scale of any proposed initiative, one of the more important reasons to produce Process Definitions is to facilitate a progression - from a general idea, on to definable objectives, then through to implementing tangible results.

Accordingly, a key aspect of Process Definition is to begin breaking down something too ill-defined, too large, or too complex to adequately comprehend, into clearer, smaller, manageable pieces. With that in mind, it is important to limit the number of Activities a Process may contain.

To reiterate, Activities define the scope of each Process. If there are too few Activities, then question whether the Process must exist. For instance, could an Activity (or few Activities) align to a different Process, thereby allowing for fewer Processes to define and manage?

Conversely, if there are too many Activities, then question whether the Activities define a single Process. For example, it may be better to align several Activities with one Process, and several other Activities with a different Process. Indeed, several smaller Processes are often better than fewer, larger Processes.

If scope is broad, then multiple Processes, and hence multiple Level 1 Diagrams (and BPDs), may be appropriate. Fortunately, there are some helpful indicators for defining what is, and is not, in a Process.

Natural Process Boundaries

Indeed, there are several types of natural break points by which to separate one Process from another. Specifically, scope boundaries typically occur where hand-offs occur between one of the following:

Owning Business Segments;
Supporting applications or technologies;
Solution Component Modules; and
Similar but Different Actions.

Process Boundaries - Business Segments

The first type of natural boundaries to segment Processes is by Business Segment. Indeed, every Process has a single, owning Business Segment. Accordingly, the person who leads that segment, or their delegate, is the Process Owner. In other words, they can define the Process, as well as all actions within it - Activities, Tasks and Steps. That is, they have the final say as to what a Process will, and will not, do.

Specifically, Business Segment process boundaries refer to action ownership and control, not execution. For instance, consider an Activity within a Process HR owns. HR's ownership does not preclude Employees in other Business Functions from executing some or all of an Activity, like submitting Timesheets for Payroll. If HR determines what information an Employee provides, and how an Employee executes the action, then the action is owned by HR.

Conversely, if each Business Segment can determine what information to provide and how to do so, for instance Annual Reviews, then the action corresponding to each Business Segment is unique. That is, Org Unit 1 may define a review process different from Org Unit 2. In this case, these are different actions, likely within different Processes.

Process Boundaries - Supporting App or Tech

The second type of natural boundaries to segment Processes is by supporting Application or Technology. To explain, if several Activities use Application A, while several others use Application B, then separating Activities which align to Application A in to one Process, and Activities which align to Application B into a different Process, may be wise.

To explain, consider selling goods to a consumer. If part of the progression involves converting a Quote in a CRM system, into an Order in an ERP system, then where the CRM system ends is a good place to end the Quote process. Similarly, where the ERP system begins is a good place to start the Order process.

Avoid situations where a process spills over from one system to the next. In this example, no portion of the Quote process should involve the ERP system, and vice versa. Even a small amount of cross-system overlap can introduce many more complexities than need be.

Indeed, system-to-system boundaries are best addressed as Integrations, external to individual Processes. Otherwise, the number of Process Definition participants, particularly those supporting various technologies, can become much larger. As a result, this can introduce significant, but avoidable, difficulties.

Process Boundaries - Application Modules

The third type of natural boundaries to segment Processes is by Application Module. This is like segmenting by application or technology, except in this case the boundaries occur within a single Solution.

In many cases, individual Solutions involve both procurement of an application or technology, as well as licensing various modules. For example, an organization may select a CRM. Furthermore, they may choose to license the Sales module, but may or may not choose the Service module.

In this case, the availability of underlying technology should help determine the boundaries of a Process. Indeed, allowing a chosen application to help guide Process boundaries is an effective means to align people, process, and technology.

Process Boundaries - Similar but Different Actions

A final type of natural boundary is to recognize when similar actions are, in fact, different actions. A common example involves similar actions which occur in different parts of an organization. Again, consider Sales. In a small company, it is possible that everyone follows the same actions regardless of where in the firm they belong, where their customer is located and what products they are selling. In this case, there is likely just one Sales Process.

Conversely, a multinational company likely has different individuals, in different parts of the firm, use somewhat different actions in their "Sales" process. While everyone is, indeed, conducting "Sales" activities, they are not conducting the same Activity. To clarify, what is done for a European sale may be quite different from what is done for a Latin America sale. Things like taxes, regulations, products, and myriad other factors drive divergence in such Activities.

At this point, there are a few options available. Let's take two examples.

Process Differentiation

Firstly, is an example where the Sales activities differ between different parts of an organization. Moreover, this is the way the organization chooses to operate. In this case, then there is not a single Sales Process, but rather several, distinct processes. Such as 'Sales - Europe' and 'Sales - Latin America', or 'Sales - Commercial' and 'Sales - Consumer'

All are sales processes, and hence all carry that part in their name. However, each is different and, hence, needs something to further it in its name differentiate one from another. Furthermore, the Activities with each Process are themselves different. That is, a 'Prepare Quote' Activity in the Commercial Sales process is, in fact, a different Activity than 'Prepare Quote' in the Consumer Sales process.

As a result, since each Activity is different, so is all further detail into which each is broken down. In other words, the Tasks and Steps occurring below 'Prepare Quote' in Commercial Sales are different Tasks and Steps than those which define 'Prepare Quote' in Consumer Sales.

That is not to say there will be many similarities in the Tasks and Steps under each Activity. However, these actions are, in effect, different. Thus, each requires their own definition. Fortunately, such situations offer ample opportunity to copy from one definition and paste / edit into another.

To summarize, for larger organizations, expect many processes to require some combination of Process plus Business Segment. To be sure, each is a separate Defined Process, with a unique Name and unique Process ID. Moreover, each aligns to a separate Business Segment and has a different Process Owner. In many cases, there are also different technologies supporting each Process.

Process Consolidation

Secondly, is an example of an organization looking to consolidate myriad legacy processes into new enterprise-wide processes. Such initiatives often occur following Mergers & Acquisitions, or otherwise correspond to a decision to use a new, enterprise system or service capable of supporting multiple Business Segments. In this situation, process ownership is changing.

Often such change creates additional challenges. Business Segments and legacy Process Owners who were accustomed to the latitude ownership offered, must now coordinate, and cooperate with others who also shared previous autonomy. Furthermore, individuals used to having authority are no longer able to make decisions on their own.

Any time ownership changes, or when several groups come together, expect a certain amount of 'Politics'. For example, a common sentiment is that while everyone recognizes the need for change, they prefer such change to occur in everyone else's group, but not their own. Similarly, expect conflicting perspectives. "Must haves" from one group are often not even requirements to others.

Litmus Test

Whereas the legacy approach allowed different processes to operate in different ways, the new approach forces rationalization. For some, that can be quite difficult. Indeed, one of the most challenging aspects of such transformation is aligning individuals towards the future-state.

This exercise (Process Definition), at this point (Process Scope), can be one of the most challenging stages through which any transformation initiative must pass. In effect, it is also a test. If groups cannot find common ground scribbling on paper to produce simple diagrams, then there is no way they will achieve success trying to implement supporting technology.

In these cases, it is best to enlist the help of the Process Owner. In turn, the Process Owner should enlist the help of Sponsors, Epic Owners, Architects, or other individuals who can help drive alignment. It should be their responsibility to help align stakeholders to the future state, and to address conflicts as they arise. Their leadership is necessary if the organization hopes to define common ground.

In many cases, it is not practical for a Business Analyst, or even an entire Team, to drive alignment. Rather, their role is to facilitate discussions, push for decisions, and capture information. To be sure, they are not empowered to define a Process unilaterally. Accordingly, this step determines whether an initiative has a chance for success or not. A lack of sponsorship, leadership, or even agreement, are all bad omens and indicative of larger problems.

Related Actions

After adding Activities within a Process' scope, now add other, Related Actions to appear on a Process Flow Diagram. On a Level 1 Diagram, Related Actions include any immediately upstream and/or downstream Process(es). In effect, Related Actions provide context and continuity for the Activities appearing on the page.

Use a Process icon to depict Related Actions at this level. Label each icon with the Process Name & Process ID for actions defined in a different Process Definition. Otherwise, simply provide a Process Name, and no ID, for actions not defined in another Process Definition. Moreover, color upstream Process icons green, indicating a start on the page. Similarly, use red for downstream Process icons.

To emphasize, depict only the immediately prior or next Related Action(s). In other words, avoid any further actions or definition because the current diagram should not attempt to define anything beyond this Process' scope. Rather, these Related Action icons direct consumers to a corresponding definition where they may find additional detail.

To clarify, each Related Action is an off-page reference, directing consumers to additional info. Ideally such info is (or will be) defined in another, related Process Definition. However, some Related Actions may have no further definition. In this case, make no attempt to further define any Related Action on this page. Either the Related Action is defined in another Process Definition, or it is not defined at all.

For anyone wanting more information, they should view the definition of the Related Action. Note that Related Actions are bi-directional. That is, if a diagram indicates upstream or downstream transition to another Process, that other Process should also include a corresponding reference back to this Process.

Events

The final actions to consider are Events which begin or end actions. As with Related Actions above, Events occur before or after an Activity. However, unlike Related Actions, BDP Diagrams do not attempt to depict any action beyond each Event. Although, diagrams may identify and depict Entities to which Events relate.

To explain, any Event which causes an Activity to execute is known as a Trigger. In this case, something beyond the scope of this BPD occurs. As a result, the organization which owns this Process acts by executing the Activity which immediately follows the trigger. For example, a 'Bank Sends Lock-Box File' might be a trigger which initiates an 'Receive Customer Payments' Activity.

Conversely, an Event which occurs following a Task is known as a Terminator. In this case, no further action occurs along the current path of the Process' scope. For instance, after executing Activities to address the Customer's Payment, if the final Task is to 'Notify Customer of Payment Receipt', perhaps the Process may then terminate with a 'Conclude Customer Payment Cycle' Event.

To summarize, the primary difference between Events and Related Actions is whether there is further Process Definition to reference. When there are more actions to define, use a Related Action icon to direct the consumer to the proper off-page Definition location. When there is no further definition, use an Event icon to tell the consumer there is no further BPD information beyond the Event.

Step 3 - Entities

Thirdly, the next step in producing a Level 1 Diagram is to identify and depict all relevant Entities. Accordingly, identify any Entities or Entity Types that interact with each Activity.

At this point, begin to gather data about the individual Entities and the information exchanged between them and each Activity. In general, there are two basic categories for Entities / Entity Types.

Swim Lanes

On one hand, are Entities which somehow participate in the Process. That is, the Entity, or members within it, execute some action(s) within the Process. Lower-level diagrams depict action execution using Swim Lanes to identify specific organizations (Level 2) or roles (Level 3). However, there are no Swim Lanes at Level 1.

Rather, there is simply a single band for the 'Process Activities, Inputs, Output & Entities'. In other words, a summary of the Process and its scope. Avoiding ownership and accountability labels at this point allows for a freer flow of ideas, particularly in situations which may involve outsourcing, organizational consolidation, or other significant changes.

Specifically, Entities do not depict the Business Segment owning the Process, nor any System(s) that automate Process actions. One reason to leave these out is that their identification occurs elsewhere. Moreover, their depiction would require numerous icons, adding unnecessary clutter. Hence, their absence attempts to keep the diagram's focus on more relevant data.

Related Entities

On the other hand, the second Entity or Entity Types to consider are those which interact with the Process by exchanging information, but which do not execute any action(s) within the Process. Exchanges involve any Entity providing information to, or receiving information from, an Activity (or both). Since there are no Swim Lanes at this level, depict all Entities / Types as Related Entities. Information exchanges typically involve files or messages, reports, or personal interactions. Have participants begin to discuss and identify such exchanges. However, in most cases, such detail will appear in lower-level diagrams rather than this one.

Of course, any Entity or Entity Type is a potential provider or recipient of such information. In other words, any Organization, Constituency and/or System is a potential Related Entity. If the Entity / Entity Type is singular. such as a Bank, then use a Single Entity icon. Conversely, if there are (or could be) multiple Entities / Type, such as several Banks, then use a Multiple Entity icon.

Step 4 - Interactions

Fourthly, add line(s) to connect objects on the page representing interactions. When appropriate, add Data Objects and/or Business Rules to clarify interactions.

Action Sequence / Flow

To begin, have participants explore the potential interactions between actions and other actions, as well as between actions and Entities. In time, the sequence with which Activities may execute becomes clear. In many cases, what initially appears as a serial flow can be parallel, when one or more Activities need not apply to all cycles through the Process.

Each Level 1 Diagram page should begin from either:

an upstream, preceding Process (off-page ref).
an Entity, Data or Object icon; and/or
some other type of Trigger Event.

Similarly, each Level 1 Diagram page should conclude to either:

a downstream, subsequent Process (off-page ref).
an Entity, Data or Object icon; and/or
some other type of Termination Event.

Between each page's beginning(s) and conclusion(s) is the series of Activities which may occur within the Process. Of course, the order of depicted Activities affects the number and length of lines to use.

Ideally, order Activities to make the diagram easily readable for consumers. For example, by organizing the Activities from left to right, and/or top to bottom, on the page according to their sequence.

Connectors

Use connectors, or line(s), to depict the sequence objects on the page. The initial connectors to add indicate the permissible sequencing, or flow, of Activities. Afterwards, add connections for each remaining icon appearing on the page.

Convention is to use an arrow to connect two icons, with the arrow's head indicating the direction of the flow. If there is a primary, or predominate path through Activities, consider making those Activity-to-Activity connections bold to highlight the "normal" sequence.

Avoid using bi-directional connectors if space on the page permits. Rather, use two separate connectors each moving in one direction. Similarly, if there are multiple interactions, then consider giving each its own connector. This level of clarity will help consumers better understand the interactions depicted.

Afterwards, give each connector a meaningful label. Alternatively, use Notes to provide a brief description of the information each interaction conveys. Again, the intent is to encourage discussions about each interaction. Afterwards, to then capture and communicate relevant information to consumers.

Data Objects

In most cases, interactions imply hands-on application work or system actions which occur within the Process. In other words, there is nothing additional to note within the diagram.

Alternatively, some interactions may imply the exchange of a file, message, or report. In these cases, use a Data In/Out icon to depict discrete data sets. Similarly, if key info is stored in, or retrieved from, some repository, then use an Object icon to depict the data store. Consider both Activities which consume such information, as well as those which produce such information.

Level 1 Diagrams need not depict either Data In/Out or Object icons. However, if space permits - and they help clarify information for consumers - their use is optional. At this level it is preferable to use Data In/Out Types rather than individual Data In/Out items. For instance, it is better to depict a single Data In/Out Type of 'Financial Reports' rather than three Data In/Out icons to depict a 'Balance Sheet', 'Income Statement' and 'Cash Flow Statement'. Conversely, there are only Objects, no Object Types. Keep in mind, the rule of thumb is to not over crowed, or clutter a diagram.

Basically, use the Single Data In/Out icon when a single data set occurs each cycle. Alternatively, use the Multiple Data In/Out icon when multiple data sets occur each cycle. For example, use a Single Data In/Out icon to depict a file received from a Bank. Conversely, use the Multiple Data In/Out icon to depict receipt of multiple files from a Bank, or a single file from multiple Banks. That is, a multiple icon indicates numerous instances of a specific data set. Use the same approach for Object icons. Again, omit these if there is too much on the page. Not to worry, they will appear in lower-level diagrams.

Object Identifiers

Give each Data In/Out and Object icon a short but descriptive name. At this point, the form and format of data sets and stores is irrelevant. Rather, it is merely their identification which is relevant. As a result, there is only one type of Data In/Out icon to represent all data set types. Similarly, one Object icon for all potential stores, whether those are files, tables, or other medium.

Diagrams may, and should, infer Data Sets and Data Stores even before a supporting technology is known. For instance, if defining Processes for a CRM, then it is entirely reasonable to expect to store or report upon 'Customer Contacts' or 'Customer Accounts'. Such identification brings clarity to the Process' Definition. In fact, there are several reasons to identify Data Objects.

Before software selection, this information is helpful in analyzing Requests for Change, and when evaluating Solution alternatives. Following software selection, these items identify content to relevant to the Integration Approach, Data Migration Approach, Reporting Approach and other Solution Strategy & Architecture materials.

During subsequent Solution Delivery, many of these items go on to become Features added to the Solution Backlog. Identification of these items up front helps estimate resource requirements for implementation. Consider that many identified items must undergo Analysis & Design, as well as Build, Test & Deploy, in addition to their use in Release and Sprint Planning.

Business Rules

Workshop discussions and interaction evaluations identify, or validate, decision points along with high-level decision criteria. For instance, some decisions affect which Activity occurs next. Alternatively, some determine whether an Activity occurs at all. Moreover, they can even depict whether the Process continues or terminates.

Regardless, depict major decisions on the Level 1 diagram using Decision icons. In most cases, is it preferable to leave Business Rules to appear in lower-level diagrams. However, if there are major decision points that determine whether an individual Activity executes during a process cycle or not, their depiction is optional.

Portfolio Management Check Point

Up to this point, the objective of the Level 1 Diagram is to establish scope for a Business Process. In other words, use the diagram to place initial stakes in the ground. Afterwards, use those stakes to identify participants and guide discussions. In general, use workshops, interviews, and any other means by which to collect and define information about the Process.

Remember, the purpose of these diagrams is to capture and convey information that ultimately guides Solution Implementation. Glossing over such information, or neglecting to capture it at this point, only means an inevitable return to these topics at some future date. More importantly, not including relevant diagram content represents missed opportunities to define aspects that directly contribute to identifying an initiative's scope, resource requirements, and cost. In most cases, thorough Business Process Definitions, along with later Feature and Story Analysis eliminate the need for Business Requirement Documents (BRDs) and similar artifacts. In this respect, BPDs are an excellent means by which to define the right information at the right time.

Above all, do not try defining all aspects of a Process using a single page, or single page layer. Rather, plan to use each Process Definition layer as designed. Each Process Definition simply has too much detail to define on one page, or page layer. Similarly, each Process is part of a much larger puzzle. Overall, placing the right information, in the right location, helps everyone involved understand the size and complexity of the initiative at hand.

Seek Communications Clarity

Like all BPD Diagrams, a Process Flow Diagram may contain from two (2) up to about fifteen (15) actions. In most cases, the sweet spot for most diagrams is between 4 and 10 actions. To clarify, if a Process requires more than about 15 Activities, then it will be better for all stakeholders to define more than one Process, each with fewer Activities.

Fewer than two, and there is just a 1-to-1 relationship between a parent action and its next level of detail. Aside from eliminating the value that lower-level details provide, conceptually this is a problem. Any action which can appear at multiple levels in a BPD is not well defined. Clearly, some information is missing if there is no change between levels.

In general, real estate on each page limits the upper range. Since the definition of each action, including the Process itself, must occur on a single page, that becomes a limiting factor for the scope of any action. Similarly, if an Activity requires more than about 15 Tasks in its definition, then it is better to segment that work into multiple Activities, each with fewer Tasks.

Bear in mind, diagrams are about both compiling and communicating information. When they become too cluttered, they lose their value on both counts. The action sequence, and number of non-action icons on a page, largely determine how many actions can comfortably fit. Balance these considerations against an objective to have as few pages as possible in a BPD.

Extra Information

To be sure, a Process Flow Diagram does not depict several of the attributes described above. However, taking the time to identify and gather such information now assists when compiling the corresponding Activity Flow Diagrams (Level 2) to delve into greater detail. Moreover, these other topics and discussions are also excellent Process Requirement sources.

Finally, since producing Level 2 Diagrams often occurs at the same time, the Process Flow Diagram should also reflect a summary, or aggregation, of info appearing in the lower level diagrams. Indeed, alignment and consistency from one level to another is one of the checks-and-balances ensuring thorough, and proper, Business Process Definition.

Phase Inception

At some point, an organization will choose a Product, or application, to support a Business Process. Afterwards, Teams can now develop Level 3 Diagrams. In many cases, the alignment of business operations (Level 2) to application functionality (Level 3) often has an impact on the Level 1 - Process Flow Diagram.

Phase Inception marks the transition from Solution Definition on to Solution Delivery. In some cases, Teams may complete the Level 3 Diagrams just prior to Inception. In others, Teams may complete these diagrams as one of the first tasks during Inception. Regardless, Teams must complete a BPD for each in-scope Process before the pending Phase gets underway.

In fact, the BPDs provide valuable, and required, information upon which to complete Solution Strategy & Architecture during Solution Definition. Similarly, they also provide valuable and required information to begin Analysis & Design during Solution Delivery. Thus. the final diagrams must be complete before Definition ends, and subsequent Delivery begins.

This version becomes the source for updating the corresponding Level 0 diagram. Moreover, it is one of the foundational artifacts upon which to establish scope for the pending Phase. To explain, BPDs contribute to objectives of the Epic to which each Process aligns. Similarly, they are the source for Features added to the Solution Backlog to achieve stated objectives.

Step 1 - Actions

Firstly, validate the major Activities within scope of both Process and Phase scope. At this time, edit or remove any as warranted. Leave Activities in-scope for the next Phase as is. Conversely, shade Activities not in-scope, grey. This conveys to all that work on non-shaded Activities is authorized for the current Phase, while further work on the greyed-out Activities is not authorized. If a previously greyed-out Activity is now in-scope, then remove the shading, indicating work on the Activity may now occur.

In general, implementations should never add new Activities during Solution Delivery. Instead, any addition should occur during a subsequent Solution Definition cycle. However, if it must happen, then coordinate with the Solution Manager and/or Project Manager, along with the Process Owner, Epic Owner, and other key stakeholders to resolve potential scope, SOW or resources issues.

Step 2 - Entities

Secondly, finalize the Entity Types to ensure they accurately reflect Entities which interact with Activities. Revisit each interaction, to confirm the information, decisions, changes in ownership, and other potentially relevant attributes. Moreover, ensure alignment with Entities depicted on Level 2 Diagrams.

As with Activities, shade an Entity Type grey if it is out-of-scope for the pending Phase. This conveys to all that further discussion of items which relate to such Entities is not appropriate during the Solution Delivery phase. Those discussions may occur prior to some future Phase when the Entity(ies) are eventually in-scope.

Making such decisions at this point can save significant amounts of time and effort. Indeed, in many initiatives, there are individuals who seek to delay progress (whether knowingly or not), by insisting upon discussions and analysis wholly unrelated to the objectives at hand. For others, it can be an attempt to bring into scope what was previously determined to be out-of-scope.

Similarly, note and shade grey the reference in the corresponding Requirements Matrix. If a previously greyed-out Entity Type will now be in-scope, then remove the shading to indicate further work related to the Entity Type may now occur.

Step 4 - Interactions

Thirdly, finalize the relationships among Activities, Entity Types and other items on the page. In many cases, sequencing is not linear. However, if one Activity is dependent upon another, the independent action must have implementation priority. In other words, action sequencing determines implementation priority.

Additionally, if depicting them at this level, then finalize any Data Types that feed into specific Activities. Similarly, finalize any Data Types each Activity produces. Keep in mind, at this level Data Types, as opposed to specific Files or Reports, are sought. Although, it is fine to use specific examples to identify types.

Also review any Business Decisions which the diagram depicts. In all cases, ensure alignment and consistency with Level 2 Diagrams. For instance, a Data Type should not appear on Level 1 unless there are corresponding Data Types or Data objects depicted on at least one Level 2 Diagram. However, Business Decisions may appear at a single level, without any corresponding depiction on other levels.

Step 5 - Notes & References

Finally, look for opportunities to add clarity to the diagram. Use Notes to label connectors between icons, offering a brief description of info exchanged. Similarly, use Notes to convey related information relevant to interactions, decisions, or icons.

Recognize that the icons shown depict standardized values - Names, IDs, etc. Use these values as reference keys for various Solution tools, deliverables, and other artifacts. Accordingly, avoid modifying Activity names or Activity IDs after Solution Delivery begins. Changes can be made. However, corresponding changes throughout the Process Definition, as well as all related artifacts must also occur. Follow a Change Control process to ensure all relevant changes are made.

Step 6 - Conclude Solution Definition

After finalizing the diagram, ensure alignment with related Solution Strategy & Architecture materials. Just because something appears in the diagram does not mean it will be built. Recall, a BPD describes the future-state of the Process. Of course, reaching any future-state need not occur in a single increment.

In fact, most organizations achieve future-state over several long-term increments. Accordingly, the next Phase of work may seek to implement only portions of the eventual, future-state. Enough to be useful, but not so much as to become overwhelming. Indeed, there are several reasons why the depiction of a Level 1 Diagram may differ from what an initiative plans to deliver next.

For instance, some Activities may already exist in their desired state. Alternatively, something upon which a Process or Activity depends may not be ready. Or perhaps it's simply not a priority at this time. Regardless of what is in-scope for the next Phase, the Process Flow Diagram (Level 1) should represent the desired future-state for the Process, not some interim, next-state.

Solution Delivery

After its use in Solution Definition, a Level 1 Diagram continues to be a source of reference throughout Solution Delivery.

Iterative Planning

In any Iterative Planning cycle, each Process aligns to a single Solution Epic. For each Epic in-scope for the current Solution Phase, the Level 1 Diagram offers the first definition at which to determine which action(s) the pending implementation is to focus upon.

Consistent with an iterative approach, it is rarely the objective to implement an entire Process during a single Phase. Rather, it is best to focus upon enabling some portion(s) now, with the intent of returning to add incremental improvements after receiving user feedback on previously enabled functionality.

Depending upon the scope and scale of individual Activities, the Level 1 Diagram may be the appropriate level at which to define Business Features. If so, each Activity should have its own, unique Feature. However, it is important to complete each Feature prior to concluding the Solution Phase.

Note that does not mean all functionality for an Activity must be complete prior to Phase end. If an entire Activity cannot be delivered within a single Phase, then look to the Level 2 Diagrams and use Tasks to identify individual Features. Completing Features matters; completing all work related to a given action need not matter.

Iterative Implementation

After defining the appropriate action(s) at which to segment each Epic into Features, subsequent Iterative Implementation for the pending Phase begins. The first Implementation Task to undertake is Feature Planning. The primary step within this task involves Analysis & Design of each in-scope Feature. Basically, this involves determining the 'Business Value' each Feature should enable. In other words, each Business Feature describes some increment of 'what does the Business want'.

For example, if a Feature aligns to a single BPD Activity, then implementation of related Tasks (Level 2) and Steps (Level 3) should fit into the Feature's 'Business Value' scope. Conversely, if some lower-level actions do not belong in-scope, then it is likely the BPD Activity is not the best level at which to carve out Features. Rather, look to lower diagrams for a narrower Feature scope. That said, there are also other means by which to segment such work.

For example, it is possible, in fact recommended, to enable subordinate actions (Tasks and Steps) for just a single Business Segment. Afterwards, using subsequent Features, Teams can enable other Business Segments by revisiting an earlier implementation. This offers opportunities to both extend functionality to new segments of the business, while also incorporating improvements identified by those already using existing functionality.

Business Value Increments

To begin determining increments of 'Business Value', look to the BPD for all actions within a Feature's scope. Indeed, it is important to keep individual Feature scope as clean and clear as possible. In most cases, this means setting scope at points which connect various icons. That is, use the connectors which appear on the diagram to identify where scope of one Feature ends, and scope of another Feature begins.

To explain, that does not imply that each diagram connector, or interaction line, is a scope boundary. Rather, only that scope definition of some Business Value increment should pass only through connectors, and not through actions, Entities or Data Objects. For example, if looking at any single BPD page, one should be able to draw a line which encompasses the action(s) within a Feature's scope. That line may encompass one or more actions. Specifically, it should only encompass sequential actions, or a set of actions whose series is not interrupted by some other Feature. Moreover, the line should pass only through connectors which link the in-scope action(s) to other actions, Entities or Data Objects.

Feature Scope & BPD Diagrams

To clarify, this connector delineation of Feature scope applies to a single BPD diagram. There is no circumstance where one Feature's scope should include some actions from one diagram and some actions from another. Rather, it must include one or more actions at the current level, or must look to a lower level of detail at which to select actions.

To put it another way, an action is either in-scope, or not. If an entire action at a given level - in this case, an Activity at Level 1 - does not define scope, then look to lower levels of detail to find a level at which one or more actions define scope. Conversely, if all actions on a page are in-scope, then it is better to use the parent action on the higher-level diagram to define a Feature's scope.

For example, if a Feature's scope is determined using Level 2, then it may appear as if such scope bisects the Level 1 Activity. No worries: this is fine. Any Feature's scope needs only appear on any single BPD page. It is implied that any lower-level definition of the action(s) falls within such scope. To reiterate, Feature scope definition has no implication for any higher-level action(s).

Minimum Viable Product

When setting each Feature's scope it is important that stakeholders understand the concept of Minimum Viable Product (MVP) as it pertains to packaged software. Overall, the scope of work defined for any single Solution Phase represents a Minimum Marketable Product (MMP) or Minimum Loveable Product (MLP). Conversely, each defined Feature's scope represents an increment of Minimum Viable Product (MVP). In other words, many individual MVP increments accrue towards a broader, overall MLP.

Accordingly, this is why it is important to select one or more actions directly related to one another. If one were to try defining a Feature using several actions, or portions thereof, scattered across a BPD Diagram yet not in series or sequence to each other, then one is not defining something that is MVP. Certainly, they may define some increment of functionality. However, it is highly unlikely that such an increment would lead to an increment of a viable product.

Iterative Testing

The final aspect of Solution Delivery which Process Flow Diagrams support is Iterative Testing. Indeed, diagrams convey a substantial amount of information which a Test Analyst, QA member, or other participant designing tests, can use to both plan and develop the Test Scripts, Test Cases, and Test Scenarios that will validate each Business Value increment.

Next up is a description of the Level 2 - Activity Flow Diagrams.