subject: A Practical Framework for Business Process Modeling [print this page] A Practical Framework for Business Process Modeling
A Practical Framework for Business Process Modeling
By Jim Reardan, Principal Consultant
Process1st Consulting, LLC
Process "Levels" vs. Specification Details
When planning a business process documentation effort, the question of process "levels" always comes up. I'm often asked, "To what level do you define processes?" It's a difficult question to answer for a variety of reasons. Because of this, I prefer to answer the question indirectly by shifting the conversation away from a discussion about "levels" and instead, toward a discussion about (a.) an entire portfolio of documentation, and (b.) which specific documents to include or exclude from the model (process specification), and (c.) which details to include or exclude from each document.
Most people equate process modeling with flowcharts, and only flowcharts. The concept of "levels" likely originates from this flowchart-only perspective. People see a flowchart and want to know what "level of process" the flowchart represents. As if there's some universally understood process modeling standard that clearly explains the characteristics of a particular "level" of process detail in a flowchart.
We know there is no standard. There are plenty of noble attempts to clearly define "levels" but nearly all mix process classification with process decomposition. And in nearly every case, it's impossible to look at an isolated flowchart and easily and quickly identify its "level." Therefore, a direct answer to the "How low do you go?" question isn't possible without first setting some parameters and expectations.
A Flowchart Isn't a Complete Model
Rarely do people consider a process model as a full set or portfolio of documentation that collectively specifies process details from a variety of perspectives. To be fair, an easy-to-read, understandable flowchart can convey a lot of useful information. But if thoroughness, completeness, and accuracy are quality attributes required from the modeling effort, more than just a few flowcharts will be needed.
My Level Your Level
The problem with discussing "levels" is that there is no generally accepted standard to define a level. If you do an Internet search on the phrase "process levels," you will find plenty of content where an author attempts to establish definitions. Unfortunately, all of them mix classification levels with decomposition levels.
At the "highest" level of documentation, the flowchart shows a handful of named processes, each of which can easily be identified, or further classified into a set of named, related sub-processes. The set of named sub-processes of a super-process is considered a "lower" level of process. Therefore, a "Level 2" process is the named set of sub-processes that make up "Level 1" processes. Then, "Level 3" processes would be the named sub-processes of "Level 2" processes. And so on, until the organization can't think of any more sub-processes. At that point, the organization unconsciously switches from defining "levels" of classification to levels of procedural decomposition. And then, I usually only see one "level" of procedural decomposition. This is almost always the organization's lowest "level" of process detail.
In this typical taxonomy it's impossible to look at any single flowchart and be able to identify what "level" of detail the flowchart represents. While it's easier to see the difference between the highest and lowest levels of detail, the levels in-between aren't distinctly different enough to identify without a label.
When someone asks, "How low do you go?" what they're really trying to ask is, "To what extent and depth do you model processes?" The answer depends on the purpose of the modeling effort. Generally, most business process modeling projects I get involved with fall into one of the following categories:
Business Process Improvement Projects
IT Service/Operations Management Improvement Projects
Business Systems and Software Requirements
Compliance/Posterity Documentation Projects
Training and Education Documentation Projects
The level of detail required is usually driven by the intended use of the documentation. Regardless of the drivers behind the modeling effort, what Clients usually need is more than just a set of flowcharts. But because modeling processes isn't often a core function in businesses, and modeling project sponsors aren't usually well-experienced in managing that type of project, Client's don't usually have any idea what a thorough and complete specification of a process (or set of processes) looks like. For these reasons, I almost always introduce the concept of a Process Documentation Portfolio of documents.
The Process Documentation Portfolio
The collection of documents in the Portfolio is about identifying and specifying processes from different perspectives or angles.
While I try to stay away from talking about "levels" of models, I can say that "levels" as I think of them are more about inclusion or exclusion of documents (and details within those documents) in the Portfolio. Rather than talk about levels (of a singular document like a flowchart), I discuss the overall extent of documentation. It becomes a discussion focusing on the set of documents that, combined, adequately specify the scope and depth of details about a process.
The Process Documentation Portfolio that I typically propose consists of the following documents:
A. The Enterprise Process Catalog (with Process Classification Framework)
B. BPMN Process/Procedure Flowcharts
C. Data Flow Diagrams
D. Process Definition Documents
E. Business Events (Process Triggers) List
F. Logical Data Model
G. Business Rules Matrix
H. Roles and Responsibilities Matrix
I. Process Language Glossary
J. Process Documentation Repository
With the exception of process/procedure flowcharts, the rest of the documentation rarely involves selective inclusion or exclusion of details within each document. What drives the exclusion/inclusion of documents and their details is the organization's reasons for modeling in the first place. The more thoroughness and completeness required, the more extensive the documentation. Rarely does a flowchart alone satisfy criteria for thoroughness and completeness of process detail.
A. The Enterprise Process Catalog
The Enterprise Process Catalog (EPC) and accompanying Enterprise Process Classification Framework (EPCF) is a process inventory and classification system. The EPC is the list of the organization's processes. The EPCF is the framework the EPC uses for classifying (categorizing) those processes.
Starting out, the arrangement or organization of the ECP usually follows APQC's Process Classification Framework (PCF). The PCF is "organized into 12 distinct categories, including five categories of operatingareas and seven of support areas. Each category contains groups of processesand activities that, when considered as a whole, represent the operations of an organization.[1] The PCF's five categories of operatingareas and seven support areas closely match other process operating/support constructs such as Porter's Value Chain[2], or the Value Chain Group's more detailed Value Reference Model[3].
From some perspectives, this categorized inventory of processes, might represent what people in the organization consider to be the "highest" level of processes. This "high level" model is simply the highest level of a classification hierarchy of named processes.
B. BPMN Process/Procedure Flowcharts
To apply the common (but limiting) perspective of "levels" to flowcharts also implies the inclusion or exclusion of detailed information within the flowchart. But rather than defining "levels" with a confusing mix of process names, classification hierarchy, and performer/task-level details, I prefer to define flowcharts based on the extent of specific notational artifacts used in the illustration, the syntax of language used within those artifacts, and any additional flowchart detail to include such items as Annotations, data objects and their elements.
The first specification involves naming the flowchart modeling notation to be used. Given the scarcity of structured process modeling notation standards, this is an easy specification. I nearly always specify the BPMN. Then, within the notational standards, I'll include or exclude some of the following:
Specific Syntax Used in Activity/Task Descriptions
Activity and Task descriptions strictly follow the Role-Action-Object syntax. If the activity/task is performed by a person, the task description starts with the specific, formal job role name - and never the name of a function or department. If the task is performed by a machine/computer/software, its name is used instead of a job role. Next, an action verb is used to describe the action the Role performs. And finally, the object of that action is specified.
These tasks are the most discrete, individual, sequentially focused activities that can be identified.
Data Flow Objects
One of the artifacts in the Business Process Modeling Notation (BPMN) is the "Data Object" artifact. This artifact is used to represent information flowing through a step ("Task" in BPMN) within a process. When using this artifact, I usually specify the direction of flow based the CRUD model - with one of the following labels:
Create Record
Read Record
Update Record
And sometimes, Delete Record
Annotations
Annotations are used to provide additional information about a process. They can appear anywhere in a BPMN flowchart. I typically use Annotations as placeholders to ask a question or emphasize the need for more information or clarity. Other than using Annotations for containers for my Data Object Element Tables, by the time the final validated flowchart is complete, most of my Annotations have been removed.
Special Annotation: Data Object Element Tables
Data Object Element Tables are not within the BPMN specification. But I often include them with BPMN flowcharts, especially if the flowcharts will be used for things like:
Specification or clarification of data entry rules
To support training and support functions and activities such as the development of training classes, and user manuals
For customer support and instructional/on-boarding materials
Whenever a task involves a performer/user in creating or updating data, I'll usually include Element Tables. While my Data Object Element Tables aren't exactly specified within the BPMN standard, I consider them a derivative of an Annotation artifact.
Intermediate Events
In BPMN there are three types of Events: Start, Intermediate, and End. While I almost always include Start and End events in my BPMN flowcharts, the inclusion or exclusion of Intermediate Events is often a consideration when defining the level of detail to be included in the process model.
Intermediate Events represent things that can occur during the course of process execution. Things like time limits, messages (i.e. E-mail and middleware messaging), exceptions or variations, error handling, and compensatory responses can be represented with Intermediate Event artifacts. Most Intermediate Events are significant within a process. The intra-process responses to these Intermediate Events are often the most risky parts of a process. It's usually where a process involves waste or failure.
Other Artifacts and Output
Regardless of whether a flowchart was produced using a standard notation (like the BPMN or an individual flowcharter's informal notation), the use of Pools and Swimlanes are common. Pools and Swimlanes are best used to show the containment or division of process tasks and responsibilities within a business entity, organizational function, or role. While understanding functional containment is important, I believe most flowcharts use Swimlanes more as a space-saver than anything else. The division of roles and their process responsibilities can be more precisely detailed in other documents in the Portfolio namely the Roles and Responsibilities Matrix. Regardless, the inclusion or exclusion of Pools and Swimlanes is another consideration when defining the extent of process documentation/modeling details.
Levels = Inclusion/Exclusion of Modeling Notation Artifacts
As you can see, the inclusion/exclusion approach to flowchart modeling detail doesn't deal with identifying and naming a distinct hierarchy or a level (as in height) perspective. It doesn't mix classification with decomposition. The only consideration is which artifacts to include or exclude.
C. Data Flow Diagrams
The purpose of the Data Flow Diagram (DFD) is to help focus the specification on the flow of data between participating objects in a process. It illustrates some of the same information that a flowchart does, but less so from a procedural perspective. In other words, the flowchart better describes the "how" where the DFD better describes the "what." Like many things we deal with in life, it's difficult, and often somewhat inaccurate to define something from a single perspective - such as looking at an object only from the front, and not from all sides. Since most "business" processes involve the flow and manipulation of data/information, it's prudent to orient much of the modeling/documentation on the movement and manipulation of that data/information.
D. Process Definition Documents
The Process Definition Document (PDD) includes specific sections such as:
- Definition and Purpose of the Process
- Process Goal and Objectives
- Inputs and Outputs
- Resources (Capital, Equipment, and Human)
- Process Roles and Responsibilities
- Imitating Business Events (Process "Triggers")
- Process Sequence (Process Narrative)
- Process Rules (Business Rules)
- Process Measurements
- Process Controls
- High-Level Process Diagram
- Validation (Process Owner and Stakeholder Acknowledgement and Agreement)
- Process Issues and Risks
- Outstanding Questions and Issues (with detailed Action Items and Statuses)
Most of the time, this is an "all or nothing" document. The extent of detail in this document covers a lot of significant information about both the design and the management and control of a process. On projects requiring only a minimum amount of documentation, the PDD and a procedural-level BPMN flowchart might be the only two types of documentation we deliver.
E. Business Events and Triggers List:
Processes are an organization's response to business events. Therefore, it is prudent to identify all the business events an organization responds to, and match those events with the processes they would possibly trigger or initiate. This cross-referencing exercise is done to further ensure that all processes within the scope of the modeling effort have been identified.
F. The Logical Data Model
The Logical Data Model (LDM) is a spreadsheet listing of all the data objects and associated elements found in a process flow. There can be one Logical Data Model for an individual process and one Logical Data Model for the entire enterprise. All of the individual LDM's roll up to the enterprise-level Logical Data Model. The Logical Data Model is often referenced by software designers and developers when process modeling/documentation projects are sub-projects of larger, software development projects.
G. The Business Rules Matrix
The Business Rules Matrix is a spreadsheet that is used to define relationships between objects participating in processes. It simply helps answer the question of, "For each, individual Object A, how many Object B's can there be?" Defining these relationships is another way of defining the rules for how the objects participate in a process. The BRM is the detailed support of the process rules section of the Process Definition Document. The none-one-many (0, 1, M) notation used in each cell of the BRM directly translates to the more conversational syntax of the business rules statements in the PDD.
H. Roles and Responsibilities Matrix
Even though process performers are identified in flowcharts, Data Flow Diagrams, the Logical Data Model, and the Process Language Glossary, the Roles and Responsibilities Matrix consolidates and summarizes performer and responsibilities data into a single document. People can have one role and responsibilities in one process, and another role and responsibilities in another process. This causes issues with availability and capacity utilization, conflicting priorities, and individual performer's performance appraisals. It's not unusual for one person to "report to" two or more managers, each with separate agendas and priorities. The Roles and Responsibilities Matrix helps expose and resolve these kinds of resource leveling issues.
I. Process Language Glossary
Miscommunication is as big of a process management problem as are misunderstandings about task sequence, data flows, and role responsibilities. People often communicate using real or made-up acronyms, slang, generalizations, and misnomers. This causes plenty of confusion. The Process Language Glossary is intended to serve as THE definitive source of process language, terms, and acronyms. If nothing else, it's used to clarify and confirm all process stakeholders' understanding of the organization's "language of process."
J. Process Documentation Repository
Much of the documentation produced during a process modeling/documentation effort is subject to frequent updates and revisions. These living documents usually need to be accessed by a wide range of process stakeholders during the effort. And, of course, the final documents would be frequently accessed, and updated, by all the different process stakeholders throughout the lifecycle of those processes. All of this drives the need for a well-organized, easily accessible, secure repository of documents. If an organization doesn't already have a content or document management system in place, the modeling/documentation team takes responsibility for developing, implementing, and managing the repository.
Summary
This article addresses the question of "How much detail do you get into when modeling a process?" There are a few important concepts to understand when answering the question. First, it's critical to clearly understand the specific reasons for modeling the processes. In general, this should give you an idea about the potential scope and extent of detail needed. Second, there is a distinct difference between classification levels and decomposition extent. Third, it's unlikely that a flowchart alone can't provide or expose enough information to completely define a process. And since a reasonable process model typically involves more documents than just a flowchart, and those documents will be frequently accessed by a wide range or process and project stakeholders, a document management system should be setup and managed to ensure ease and simplicity of access, while providing controls and security to ensure documentation integrity.
