Level 2 - Activity Flow Diagrams

After outlining scope with a Process Flow Diagram, the next level of detail in Creating the Process Definition Diagrams depicts Activity Flow Diagrams. In effect, this second level, or Level 2 Diagram, depicts how an organization chooses to operate.

For the most part, operations are independent of specific applications or technologies. Hence, a Business Analyst can, and should, facilitate production of Level 2 Diagrams even before a supporting application or technology is known.

In fact, Activity Flow Diagrams provide excellent information to support evaluation of alternative Solutions. Moreover, they provide information vital to the Definition and Delivery of any corresponding Solution.

Activity Flow Diagrams - Level 2 (L2)

A Level 2 Diagram provides additional detail for an Activity within the scope of a Level 1 - Process Flow Diagram. Each diagram describes planned business operations, independent of any underlying technology. Additionally, this level introduces Swim Lanes to indicate ownership and participation. In other words, to identify organizational accountability and responsibility.

If envisioning a new Solution, then define Level 2 Diagrams, along with their parent Level 1 Diagram, before selecting a supporting Product or Service. To be sure, Activity Flow Diagrams capture and convey relevant information. Accordingly, they provide valuable inputs into the evaluation of alternative Solutions. Moreover, they help stakeholders select a Solution with the best fit for purpose.

Diagram Overview

On This Page

Add a header to begin generating the table of contents

Description

Firstly, an Activity Flow Diagram (Level 2) depicts a second layer of Process decomposition. Within a Business Process Definition, each Activity on the Level 1 diagram must have a corresponding Level 2 diagram. Basically, each diagram depicts the operational Tasks within the given Activity, as well as their sequencing, or relation, to one another. A Business Analyst facilitates identification of each Task when defining the Process.

Tasks are a standardized representation of the decomposed Activity. Their design facilitates more detailed information gathering and communication. In general, Level 2 Diagrams are technology independent. That is, they do not capture or convey application-, or Solution-specific information.

Additionally, Level 2 diagrams depict more detailed interactions between the Tasks and either Entities or Entity Types. To clarify, these interactions provide more information than the Process Flow Diagram (Level 1) by depicting each type of interaction. For instance, separating sending payment files to a bank vs. receiving lock-box information from the bank.

Further, Level 2 Diagrams also provide more detailed information which relates to Files and Reports. That is, inbound or outbound Data or Data Types. Indeed, each interaction between a Task and an Entity or Data icon indicates a potential Integration.

Moreover, Level 2 diagrams use Swim Lanes to depict action ownership and accountability. If all Tasks are the responsibility of a single Organizational Unit, then the page will have a single Swimlane identifying that unit. Alternatively, if multiple units have responsibility for various Tasks, then each unit will have a corresponding Swimlane. Of course, each Swim Lane will bear the name of the Org Unit, and Tasks for which the unit is responsible appear within the Swim Lane. Generally, Swim Lanes do not apply to icons other than actions - in this case, Tasks. That is, Entities, Data, and other objects may appear anywhere, without regard for Swim Lanes.

Finally, the Level 2 Diagrams also highlight key decision points. These may affect organizational handoffs, the determination of subsequent Tasks or Activities, or termination of the Process.

Purpose / Objectives

Secondly, Activity Flow Diagrams (Level 2) serve a number of purposes, including to:

Graphically depict all Tasks within a given Activity, along with their sequencing, or relation, to one another.
Identify information that is exchanged between Tasks.
Identify Organizational ownership for Task execution, by depicting the Task within an appropriately labeled Swim Lane.
Identify relationships between Org Units, and to identify where ownership or responsibility for information changes from one unit to another, as noted either by the flow crossing from one Swim Lane into another, or from an Entity icon to a Task. These boundaries typically indicate potential Integration points or data standardization opportunities.
Identify all specific Entities - Orgs, Constituencies, Systems - that provide info to, or receive info from, each Task.
Identify the info exchanged between each Entity and the Task(s) with which it interacts.
Identify all specific Files or Reports that provide Data to a Task, or that a Task generates.
Identify major decision points that determine whether to execute a Task, which Task to execute, or the sequence of Task execution.
Identify major decision points that affect a change in organizational responsibility (i.e., organizational handoffs)
Identify Tasks that are predominately manual vs. automated.
Provide a context with which to decompose each Task shown into corresponding Task Flow Diagrams (Level 3) (as necessary).
Provide a reference for communicating to, and facilitating discussions with, Business and/or IT SMEs.

Development Guidelines

Thirdly, follow these guidelines to successfully produce a Level 2 (Activity Flow) Diagram:

Each Activity Flow Diagram (Level 2) decomposes one, and only one, Activity from Level 1. In other words, Level 2 Diagrams do not cross Activity boundaries. That is, all Tasks must be within the parent Activity's scope.
Give each Task depicted a unique Task ID in the format of ‘PP.AA.TT’, where: PP = two-character Process ID; AA = two-digit ID of the parent Activity; and TT = two-digit number that uniquely identifies each Task.
An Activity Flow Diagram is required for each Activity that appears on the parent Level 1 diagram.
A L2 Diagram should depict all Tasks which relate to the Activity, regardless of whether the Task is within scope of planned work or not. Afterwards, identify Tasks deemed out-of-scope using a Task ID of ‘PP.AA.NA’. As with Activities deemed out-of-scope, the Task should remain on the diagram, but be greyed out.
Depict Organizational ownership & handoffs using Swim Lanes shown and interactions between Entities or Entity Types.
Depict major decision points that determine whether: an org handoff occurs; subsequent action(s) (Process, Activity or Task) need occur; or the Process terminates. Identify these decision points and treat them like other Tasks. That is, give these an Object ID, so that further decomposition, metrics, decision criteria, system configuration and other items may reference it.
If multiple Entity Types perform a given action, separate Tasks should be depicted, and each should have a unique Task ID. For example, if BUs, Shared Services & Employees each ‘Update Employee Information’, then there should be 3 unique Tasks and 3 different Task IDs. Show each Task in the appropriate Swim Lane to highlight ownership. Afterwards, each Task is further detailed by Task Flow Diagrams (L3) to highlight any differences. Being specific here helps later Definition & Delivery activities.
Depict interactions with other Processes or their Activities as an interaction between the Task shown and the external Process. Thereafter, add a Note to specify a known, external Activity or Task.
Interactions between Tasks and Entity Types (i.e., Entity Interactions) must have labels which provide a high-level description of the information conveyed by the interaction.
Task Diagrams (Level 2) do not depict:
- Specific Integrations/Interfaces.
- Specific data standardization opportunities.

Sample Diagram - Level 2 (L2)

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

An Activity 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 Diagrams. In short, these are two labels referring to the same items.

Subject	Field / Object	Notes / Guidance
Page Setup	Activity Name	The Header identifies the Activity being described. This should match the Name of the parent L1 Activity icon.
	Activity ID	Also shown in the diagram Header. The 'PP.AA' value should match the ID of the parent L1 Activity icon.
Actions	Actions	Action icons depict each Task at Level 2 that is in scope of the parent Activity.
	Task IDs	Each Task icon has a unique identifier. 'TT' represents the Task portion of each 'PP.AA.TT' Task ID.
	Task Names	Each Task icon has a descriptive name. At Level 2, use internal operational terms where applicable to help align stakeholders with business operations. Otherwise, use active terms for Task Names. For instance, use 'Receive Order' rather than 'Order Receipt'.
	Activity Start / End	May be one or more of: Events (Trigger / Terminator); b) a colored Related Process; and/or c) upstream / downstream Activities defined within the same Process.
	Events	Event icons depict other Event(s) that initiate (Trigger) or end (Terminator) a Task. They may also highlight notable milestones throughout an Activity.
	Related Processes	Identify Related Processes with which the given Activity interacts, precedes, or succeeds. If a specific Activity within the Related Process is known, then use a Note (see below) to allow for easier cross-reference.
Entities	Swim Lane(s)	Swim Lanes depict organizational responsibility for executing Tasks. Organization(s) include those which are, or exist within, the Entity that owns the Tasks depicted. It also includes Entities which execute Tasks, though do not own them. To clarify, those which own Tasks determine each Task's operations and execute the corresponding actions. Alternatively, those which only execute Tasks do not determine operations. Rather, they merely follow the actions as defined by the Entity which owns the Process. Do not represent related systems nor Organizations which do not execute depicted Tasks as Swim Lanes at this level. Rather, these appear as Entities (see below).
	Related Entities	In general, an Entity is any organization, constituency, or system with which the Process interacts. Entities which own depicted Tasks are shown as Swim Lanes. Similarly, those which execute, but do not own, depicted Tasks also appear as Swim Lanes. Conversely, show Entities which interact with Tasks, but do not execute depicted Tasks, as Entity icons. Use a single Entity icon to depict a single Entity of a given type, such as a Bank. Alternatively, use a multiple Entity icon to depict an Entity Type when multiple Entities of a given type apply, such as 'Banks'.
	Entity Integrations	Identify any interactions which occur between any Entity and a Task. Use Notes (see below) to describe the general content of each feed, file, entry, etc. between Entities and Tasks. There is no need for specifics at this point, beyond merely identifying the interaction(s).
Interactions	Precedence or Dependence	Use Connector arrows to indicate the sequence of flow.
	Data In/Out	Data In/Out icons as reference to files, reports, messages, or other data sets which a Task receives (In) or produces (Out). At Level 2, depict individual Files, Reports, etc. as single Data In/Out icons. Where not practical, use the multiple Data In/Out icon to depict more general Data In/Out Types, such as 'Financial Statements'. Give each Data In/Out icon a descriptive label to identify individual data sets. For consistency and clarity, ensure the same label appears each time the same Object appears, whether on the same page, across all pages within the Process Definition, and across all pages in all Process Definitions for each Solution.
	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. Depict individual content or components as Object icons. Give each Object icon a unique name to identify individual content or component subjects. For consistency and clarity, ensure the same label appears each time the same Object appears, whether on the same page, across all pages within the Process Definition, and across all pages in all Process Definitions for each Solution.
	Business Rules	Decision icons represent both decisions which affect the flow of actions, as well as specific Business Rules.
	Notes & References	Use Notes to add color commentary, additional information, or references to other source materials on the diagram. For instance, Notes can provide direction or a link to relevant Policies, Regulations, or other relevant materials.

Diagram Development & Use

In most cases, a Business Analyst facilitates the creation or update of a Process Definition, including the Process Flow Diagram. 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 the same file containing the Level 1 Process Flow Diagram, which includes standardized page layouts and icons to use. Thereafter, add a single diagram page for each Activity appearing on the Level 1 Diagram. Alternatively, to update a Definition for a pending Phase, use the most recent version from a preceding Phase. Thereafter, follow the steps below to create, or update each Level 2 - Activity Flow Diagram.

Regardless of which Phase these artifacts are for, initial development of their current version occurs prior to Phase Inception. As a result, Level 2 Diagrams define operational Tasks, action ownership or responsibility, and Entity Type & Data Type interactions. Afterwards, Solution Strategy & Architecture use this information to conclude Solution Definition. This content also becomes source material for several Solution Delivery activities.

Overview

To continue, producing Level 2 Diagrams occurs concurrently with their parent Level 1 Diagram. In effect, these diagrams begin to describe how the firm plans to operate, identifying the Tasks to complete within each Activity. Each diagram provides a means for stakeholders to propose ideas, identify dependencies, and work towards new operational standards. Expect varying perspectives, and for participants to 'see different parts of the elephant'.

In this respect, Activity Flow Diagrams are great tools to align participants. Moreover, they can also help formulate a planned future state. Accordingly, a Level 2 Diagram for each Activity begins to depict a desired operating model. In doing so, the diagrams facilitate further discussions, encourage negotiations, and offer opportunities to consider various perspectives. This is helpful when consolidating multiple legacy Processes or systems into a new, enterprise standard.

Level 2 Diagrams introduce ownership for individual Tasks. Moreover, they offer more granular means by which to segment and identify relevant stakeholders. To rephrase it, recognize that all Process Definition diagrams define ever more detailed boundaries. Boundaries between processes, systems, entities, constituencies, and ownership. Accordingly, they facilitate more focused and constructive discussions involving relevant stakeholders. Similarly, they also help exclude those whose input is not particularly helpful or desired.

To summarize, these are some of the first artifacts which say, "We plan to operate this way, not that way". Alternatively, that 'This' is in-scope; and 'That' is out-of-scope. As a result, these diagrams provide much of the content to frame individual Solutions. Indeed, use them to work through alternatives and gain future state agreement. Compiling this information goes a very long way towards clarifying objectives. To emphasize, it is much easier to update these diagrams than to affect similar changes in software.

Solution Definition

Prior to each Solution Phase, use meetings and workshops with representatives of the Business and IT communities, to produce Activity Flow Diagrams (Level 2). To explain, the diagrams facilitate discussions, help explain best practices, and capture information related to the given Process. These workshops should begin during the Ideate stage of Portfolio Management. If not following Portfolio Management processes, then ideally these workshops should occur prior to the selection of any related application or technology.

Of course, producing Level 2 Diagrams offers a great opportunity for a Team to begin working together. The Business Analyst should facilitate many of the workshops, with support from their Solution Analyst and Test Analyst team members. Moreover, the workshops provide initial opportunities for the Team to begin working with Process Owners, Subject Matter Experts and other stakeholders with whom they will work throughout the subsequent implementation.

In addition to defining how the organization plans to operate, Level 2 workshop discussions and individual interviews often drive other useful outcomes. For instance, working towards a desired future-state will raise new requirements. Additionally, they also drive negotiations and decisions, as participants narrow down alternatives into objectives. Furthermore, soliciting multiple perspectives, ultimately leads to better Solutions. Accordingly, for each Activity appearing on the Level 1 Diagram, follow these steps.

Step 1 - Pages & Setup

To begin, the first step in producing Level 2 Diagrams is to provide locations for each diagram:

Add a page / tab in the BPD Diagrams file for each Activity appearing in the Level 1 Diagram.
Place these pages / tabs immediately after the page depicting the Process Flow Diagram.
Label each page / tab to indicate the level and Activity ID the diagram depicts. For example, 'L2:PP.AA', where PP is the two-character Process ID, and AA is the unique two-digit sequence number from the parent Level 1 Diagram.
Update the Page Header to show 'Level 2 | [Activity ID] [Activity Name] Activity Flow'.

Ensuring that each Activity is broken down on its own, a dedicated page helps everyone understand where to place and locate relevant information. Indeed, a BPD's one-page-per action structure offers several benefits. In short, it enables stakeholders to capture and convey relevant information in both summary and detailed form. Moving up or down in levels of detail helps everyone understand important aspects of each Process.

For more information, refer to BPD Pro-Tips.

Step 2 - Actions

Secondly, the next step in producing Level 2 Diagrams is to depict all relevant actions. In other words, identify the Tasks within each Activity.

Diagram Level Actions - Tasks

The first actions to depict are those which further define the parent Activity. These actions, called Tasks at Level 2, occur within the scope of each specific, parent Activity. In the same way Activities define the scope of a Process at Level 1, here Tasks define the scope of an Activity at Level 2.

Moreover, the Tasks define business operations to occur with each Activity. Accordingly, add an action icon for each Task. Give each Task a brief, descriptive, active name and, eventually, a unique ID. At this level, use Operational terms common to the Business for Task names.

However, leave the ID until after the review of sequencing below. Identify actions by either validating predefined Tasks or adding new Tasks specific to each Activity. To clarify, predefined Tasks can often be found in places like existing Policy & Procedures, or in previously described Process or Activity flows.

Related Actions

After adding Tasks within an Activity's scope, now add other, Related Actions to appear on an Activity Flow Diagram. Related Actions include any immediately upstream and/or downstream Activity and/or Process. Related Actions come in two flavors. Firstly, there are Related Actions that are also defined within the same Process Definition. Secondly, there are Related Actions defined in another, related Process Definition.

For Related Actions defined within the same Process Definition, use actions one level up for these off-page references. For example, since Tasks are the level the diagram depicts, upstream / downstream actions defined within the same Process Definition should depict an Activity. That is, at Level 2, Related Actions should not depict Tasks which occur within other Activities, but rather only the related Activity itself.

Alternatively, use a Process icon to depict any Related Action defined in a different Process Definition. To clarify, it is always permissible to depict a Related Process at any level. Moreover, it is good practice to add a Note specifying which action (Activity, Task, etc.) to reference in a Related Process. Furthermore, color upstream Related Actions green, indicating a start on the page. Color downstream Related Actions red.

Related Actions provide context and continuity for Tasks appearing on the page. To emphasize, depict only the immediately prior or next Related Action(s). In other words, avoid any further actions because the current diagram should not attempt to define anything beyond its parent Activity's scope. Rather, these Related Action icons direct consumers to a corresponding definition where they may find additional detail.

Reference Notes

The reason Related Actions use levels above the detail depicted, Tasks at this level, is to reinforce that these are off-page references. Furthermore, doing so discourages including detail on the current page which belongs elsewhere in a Definition. 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 action, that other action should also include a corresponding reference to the action depicted here.

Events

The final actions to consider are Events which begin or end actions. As with Related Actions above, Events occur before or after a Task. However, unlike Related Actions, BDP Diagrams generally do not attempt to depict anything beyond each Event. Although, it is common to depict an Entity or Data Object if they initiate or complete an Event. In effect, what occurs beyond these icons is a black box.

To explain, any Event which causes a Task to execute is known as a Trigger. In this case, something beyond the scope of the BPD occurs. As a result, some group in the organization acts by executing the Task which immediately follows the Trigger. For example, a 'Customer Submits Request' might be a trigger which initiates an 'Assess Customer Request' Task.

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 Tasks to address the Customer's Request, if the final Task is to 'Close Customer Request', perhaps the Process may then terminate with an 'End Request' Event.

To summarize, the primary difference between Events and Related Actions is whether there is further Process Definition to reference. When there is more definition, 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 Activity Flow Diagrams is to depict all relevant Entities. Accordingly, identify any Entities or Entity Types that interact with each Task.

To start, expect any Entity which interacts with the parent Activity on Level 1 to interact with one or more Tasks at Level 2. Furthermore, in looking at the more detailed Level 2 perspective, it is common to identify additional Entities initially overlooked at Level 1.

Gather data about individual Entities. If listing an Entity Type, such as 'Banks', then add a Note listing applicable Banks. Alternatively, use the Note to reference where such a list of applicable Banks is defined. Such information becomes relevant when defining scope and Features.

In general, there are two basic categories for Entities / Entity Types. Firstly, Entities which execute one or more Tasks appear as a Swim Lane. Secondly, those which merely interact with the Process, but do not execute any depicted Task are Related Entities.

Swim Lanes

On Level 2 Diagrams, Swim Lanes identify the Organization(s), Constituencies, or other groups, responsible for executing individual Tasks.

Action Owning Entities

The first Entities or Entity Types to consider are those which have responsibility to execute one or more Tasks. Use Swim Lanes to represent such responsibility. Label each Swim Lane with the Name of the Entity / Entity Type responsible for the execution of a Task. Then, place the Task(s) which the Entity / Entity Type executes within the appropriate Swim Lane.

Generally, this is the first level at which the Business Segment that owns the Process has a Swim Lane. One may point out that the left page heading on a Level 0 Diagram also depicts the owning Business Segment. However, production of the Level 0 Diagram often occurs after production of Level 2 Diagrams. Alternatively, reference to the Process' ownership also appears as a color coding on the related Solution Context Diagram.

Aside from the owning Business Segment, other Entities / Entity Types which may appear as Swim Lanes are those depicted on the corresponding Level 1 Diagram. For instance, any Entity / Entity Type that is responsible for executing one or more Tasks in the given Activity should have its own Swim Lane. Accordingly, the Swim Lane label should match the name of the Entity / Entity Type. Thereafter, each Task which the Entity / Entity Type executes should appear within this Swimlane.

Action Executing Entities

Some Entity Types depicted on Level 1 may now appear as individual Entities. If those Entities execute Tasks which the BPD depicts, then give each its own Swim Lane. For instance, Entity Types for organizations or constituencies in Level 1 may now identify individual members by their own Swim Lane. As an example, a Level 1 Entity Type of "Customers" may segment into "Retail Customers", "Wholesale Customers" and "Corporate Customers". However, only segment such Entity Types in cases when introduction of the future-state Process may occur segment by segment, or when the Task(s) each segment executes somehow differ. Otherwise, if Task execution is the same regardless of individual Entities, it is better to simply continue using the Entity Type to identify the Swim Lane rather than segments within the type.

Of course, do not create Swim Lanes for any Entity Type not appearing on the Level 1 Diagram. Additionally, do not create Swim Lanes for Entity Types which do not execute any Tasks depicted in the given Activity. Similarly, do not create Swim Lanes for Entity Types whose actions occur external to the Process being defined. For instance, if a Bank provides a file to a Task, but does not execute any Task itself, it should appear as an Entity icon, not a Swim Lane. In other words, if what happens within the Entity is a black box from the BPD's perspective, do not give it a Swim Lane. Finally, do not depict any System supporting the Process as a Swim Lane. Rather, only depict organizations, constituencies, or other Entities which reference individuals or groups to which they belong.

Swim Lane Relevance

An important aspect of Swim Lanes is that they are relevant only to the action(s) appearing within them. To explain, all other icons on the diagram may be placed anywhere on the page, without regard for the Swim Lane in which it appears.

In other words, the appearance of a Task within a Swim Lane indicates that the organization named in the Swim Lane's label is responsible for executing each Task depicted. However, the appearance of a Data Object or Entity in the Swim Lane is not similarly associated with the organization. Rather, any non-action icons are merely taking up page real estate that happens to be within any of Swim Lanes on the page.

Related Entities

The second Entity or Entity Types to consider are those which interact with the Process by exchanging information. Exchanges involve any Entity providing or receiving information (or both). To continue with the Bank example above, a file the Bank provides is one example of an information exchange.

Information exchanges typically involve files or messages, reports, or personal interactions. Look to Data Objects in Step 4 below for more information on files, messages, and reports. Personal interactions simply refer to a User who enters or views information via computer, kiosk, or another device.

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

Use connectors, or line(s), to depict the sequence of objects on the page. The initial connectors to add indicate the permissible sequencing, or flow, of Tasks. Convention is to use an arrow to connect two icons, with the arrow's head indicating the direction of the flow.

All pages should begin from either:

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

Similarly, all pages should conclude to either:

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

Between each page's start(s) and end(s) is the series of Tasks which may occur within the parent Activity. Of course, the order of depicted Tasks affects the number and length of lines to use. Ideally, order Tasks to make the diagram easily readable for consumers.

Give connectors a meaningful label or 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. As a result, there is nothing additional to note within the BPD. Alternatively, some interactions may imply the exchange of a File, Message or Report. In these cases, use a Data In/Out icon to depict each discrete data set. Similarly, if key info is stored in, or retrieved from, some repository, then use an Object icon to depict the data store.

Activity Flow Diagrams may depict either Data or Data Types. For instance, three Data In/Out icons may depict 'Balance Sheet', 'Income Statement' and 'Cash Flow Statement'. Alternatively, one Data In/Out Type icon may depict 'Financial Statements'. On the other hand, there are only Objects, no Object Types. The rule of thumb is to not over crowd or clutter a diagram. If there is space, show the individual elements. Otherwise, show the summary. If space is very limited, then avoid depicting either. They are sure to show up elsewhere in the Process Definition.

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 instance, use a Single Data In/Out icon to depict receipt of a monthly Bank Statement. Conversely, use the Multiple Data In/Out icon to depict receipt of Employee timesheets each week. That is, a multiple icon indicates numerous instances of a specific data set. Use the same approach for Object icons.

Unique 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. Ensure the same object has the same name on every page on which it appears.

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 'Leads' 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 Task(s) occurs next. Alternatively, some determine whether the Process continues or terminates. Regardless, depict major decisions on the Level 2 Diagram using Decision icons.

Give each icon a name unique to the page. Ideally, phrase the name in the form of a short, basic question, which frames the decision. Afterwards, label each exit path with one potential answer to the preceding question. Afterwards, if referencing these decisions in other ITM artifacts, use the Page ID (in this case the Activity ID) along with the question posed.

Depicting Outcomes

Decisions always have at least two possible outcomes; some have many more. For instance, many decisions have simple 'Yes' / 'No' outcomes. In other cases, an "Approval to Proceed?" decision may have outputs of 'Yes', 'No, minor re-work needed' and 'No, major re-work needed'. If there are more than three potential outcomes, then a decision requires a series of outcomes.

Since three (3) is the exit limit from a single Decision icon, there are two basic ways to depict more complex outcomes. Firstly, cascade several related decisions. Basically, this is like a series of If / Then statements, where output of one decision leads to input of the next. Secondly, depict an exit offering multiple paths to different downstream objects. In effect, this is like a Case statement.

For example, a decision which selects from a list of alternatives may depict each option as its own decision, with outcomes either indicating 'Yes' to that option, or 'No' and on to the next option (If / Then form). Similarly, use a series of decisions to narrow down alternatives until only three or fewer outcomes may occur from each decision.

Alternatively, a decision which selects from a menu with six (6) possible choices may depict all choices exiting from the same point of the Decision icon. In this case, six connectors each have a label representing one menu item selection as the outcome, before connecting to the next appropriate task (Case statement form).

Portfolio Management Check Point

To this point, the objective of Level 2 Diagrams is to align stakeholder understanding and expectations of how the Process is to operate. In short, the diagrams should define, Activity by Activity, who is responsible for what. As a result, the initial Activity Flow Diagrams (Level 2) created as a result of Intake & Ideate become the starting point for Solution Design.

Thereafter, workshops are held with Business, IT, and perhaps Vendor representatives, initially identified as the 'who' in who will do what above. An early objective is to validate the Process diagrams. Basically, the intent is to provide orientation for new workshop participants and to gain buy-in, or validation, from all stakeholders before proceeding into greater detail.

Additional workshops for Level 2 diagrams should occur as part of the Elaborate stage, if following Portfolio Management processes, or as the first activity associated with Product Delivery if not. In either case, it is important to complete the Activity Flow Diagrams prior to Solution Phase Inception.

Seek Communications Clarity

Basically, diagrams should depict the potential flow(s) of work. The action flow validates the dependencies, or sequencing, of all Tasks as well as decisions in the diagram. Accordingly, the outcome of decisions introduces various alternatives for sequences to branch off in any number of directions. In some cases, the flow of an Activity will be serial, meaning there is only one action to occur next. Alternatively, the flow may occur in parallel, meaning two or more actions may follow a prior one.

When working through the additional detail of Level 2 Diagrams it is not uncommon for the addition of Tasks, Entities, Data Objects, and decisions to make the diagram too convoluted, or complex. If that is the case, then consider splitting the parent Activity into two or more smaller Activities. If this occurs, clone the overly complex page to create a page for each new Activity. Then, remove some content from each, leaving the remaining content to define the Activity. For more info, look to guidance on validating diagrams.

Thereafter, the validated L2 Diagrams, along with any relevant COTS / SaaS / Vendor processing information, User Guides, instructions, or other materials, will provide the context and guidance for the development of the related Task Flow Diagrams (Level 3). Of course, Activity Flow Diagrams (Level 2) may require further updates during Solution Design to maintain consistency with decisions that occur during development of the more detailed Level 3 Diagrams.

Phase Inception

At some point, an organization may 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 2 - Activity Flow Diagrams.

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 begins.

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 Solution Definition ends, and subsequent Solution Delivery begins.

This BPD version becomes the source for updating the corresponding Level 1 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 Business Features added to the Solution Backlog to achieve stated objectives.

Step 1 - Actions

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

In general, implementations should never add new Tasks 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 Entities and/or Entity Types to ensure they accurately reflect Task interactions. Revisit each interaction to confirm the information, decisions, changes in ownership, and other potentially relevant attributes. Moreover, ensure alignment with Entities depicted on Level 3 Diagrams.

As with Tasks, 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 such Entities may now occur.

Step 3 - Interactions

Thirdly, finalize the relationships among Tasks, Entity / Types, and other items on the page. In many cases, sequencing is not linear. However, if one Task 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 In/Out Types that feed into specific Tasks. Similarly, finalize any Data Types each Task produces. Keep in mind, at this level Data In/Out 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 3 Diagrams. For instance, a Data In/Out Type should not appear on Level 2 unless there are corresponding Data In/Out Types or Data In/Out objects depicted on at least one Level 3 Diagram. However, Business Decisions may appear at a single level, without any corresponding depiction on other levels.

Step 4 - 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 Task names or Task 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 5 - Conclude Solution Definition

After finalizing each 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 2 Diagram may differ from what an initiative plans to deliver next.

For instance, some Tasks may already exist in their desired state. Alternatively, something upon which an Activity or Task 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 Activity Flow Diagrams (Level 2) should represent the desired future-state for each Activity, not some interim, next-state.

Solution Delivery

After their use in Solution Definition, Level 2 Diagrams continue 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 2 Diagrams offer the first definition at which to determine which action(s), or Tasks, 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 2 Diagrams may be the appropriate level at which to define Business Features. If so, then a single Task, or set of Tasks, should have a unique Feature. However, it is important to complete each Feature prior to concluding the Solution Phase.

Note that does not mean all functionality for a Task must be complete prior to Phase end. If an entire Task cannot be delivered within a single Phase, then look to the Level 3 Diagrams, and use Steps 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 Task, then implementation of related 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 Task 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 (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, a Task at Level 2 - 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 3, then it may appear as if such scope bisects the Level 2 Task. 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 Activity 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.

For the third, and lowest, level of detail, next up
are the Level 3 - Task Flow Diagrams.

To review the higher, more summary levels, see
the Level 0 and Level 1 diagram descriptions.