Process purpose informs process language
Since you are reading this, I will assume you care something of business processes. Perhaps you are a process professional and go to work every day thinking of ways to make processes better within your organization. Maybe you are a process doer and looking for ways to maximize your personal productivity. You might be an IT professional responsible for automating processes within the business. Or possibly you are an executive looking to build business continuity to hedge against future disruptions.
Regardless, any attempt at process documentation requires a language with which to communicate the process to others. Process language is the portal that transports your process from tacit to explicit. This language can, and often does, take many forms. For example, the most popular standardized business process language is Business Process Model and Notation (BPMN) which is managed by the technology standards consortium, the Object Management Group (OMG). However, many organizations forego this standard and adopt a process language that meets their specific goals and purposes – whether that language be proprietary to a process management tool or uniquely created using objects available within the tool.
Aligning process categories and languages
There are many reasons an organization might choose a particular process language: consistency, adaptability, usability, readability, et cetera. These reasons notwithstanding, I submit the most important factor to consider when selecting the right process language is your purpose for documenting processes. What does your use case demand? Who will be the consumers of the processes? How will they be using them? Who will be building them? Answering these questions, and others like it, will help you better compare process writing languages and the process management tools that employ them.
No one article, certainly not this one, will be able to successfully identify and outline every possible reason or purpose a business might have for documenting their processes. However, I think we can identify some high-level categories that will help us weigh various approaches to process language. In the table below, I have identified three categories along with typical users and use case descriptions.
Category
User
Use Case
Process as a knowledge asset
Front-line worker, process doer
Day-to-day playbook
Training new staff
Blends procedure and supporting documents into process flow
Process as a technical resource
Technical developer/ business analyst
Reference for improvement purposes
Show all possible process exceptions and paths
Produced in a format that is readily executable
Process as a strategic guide
Executive-level decision maker
Macro-level perspective
Focused on the customer
Used for organizational alignment
Acknowledging that there are certain to be some gaps and overlaps in these categories, I still think we can use them as a good starting point for discussion. Below I will make process writing language suggestions for each of the above categories.
It goes without saying, but to be clear, each use case carries with it unique nuances, as well as distinct short and long term considerations. As a result, my suggestions below are not comprehensive, but general, based on the assumptions shown above.
Category
Suggested process language
Process as a knowledge asset
Business-focused language (Detailed Simplicity is an example)
Process as a technical resource
Business Process Model and Notation (BPMN)
Process as a strategic guide
Value Stream Mapping (VSM)
A quick look at each use case
The process as a knowledge asset use case has as its end the blending of a process flow diagram and procedural details – perfect for a process doer playbook. Achieving this requires that you have a simple process structure from which to “hang” various knowledge types (i.e.: forms, guides, policies, links, etc.) at the points where they are referenced within the process. This makes the process eminently usable and helpful to the front-line workers in the business. The language needed to accomplish this must be explicitly business-focused. It must be straightforward, utilize their terminology, layer activity and task level information for rapid comprehension, and place the emphasis on what happens most of the time while addressing exceptions appropriately. I have written previously about this approach to process language and, for the sake of comparison, will label it Detailed Simplicity.
Detailed Simplicity example as built in the process management tool Promapp
Next, leveraging process as a technical resource demands that all possible process exceptions and paths be visualized, creating a process that is readily executable despite its complexity. Since the audience for this use case is more technical than operational, complexity is not seen as a burden to process comprehension, but as a valuable resource for those technical teams tasked with constructing supporting automation. BPMN is viewed as the de facto language for this type of use case. As Bruce Silver comments: the core purpose of process mapping with BPMN is to capture all “the various exception paths … with the semantic precision needed by IT to translate any proposed improvement into a working implementation.”[1]
BPMN 2.0 process orchestration diagram example (source: pg 75 of OMG BPMN 2.0.2 specification: https://www.omg.org/spec/BPMN/2.0.2/PDF)
Finally, using process as a strategic guide necessitates a higher-level view of process and information flow. This macro approach – focused on the customer experience – provides the necessary information and context to leaders as they make strategic improvements to organizational alignment and the flow of work. Value Stream Mapping (VSM) is a great process language (also a technique) for this use case. Karen Martin and Mike Osterling make this observation about the usefulness of VSM within an organization: “…value stream maps provide an effective means to establish a strategic direction for making improvement.”[2] They go on to explain that “the process of value stream mapping deepens organizational understanding about the work systems that deliver value and support the delivery of value to customers, which aids in better decision making and work design.”[3]
VSM example (source: slide 26 of Value Stream Mapping for Non Manufacturing Environments: https://www.slideshare.net/AMEConnect/value-stream-mapping-for-non-manufacturingmartinreplacement/26)
One size does not fit all
It is worth noting that there can be a tension that exists when organizations are deciding upon a process language for their process as a knowledge asset use case. Understandably, an organization may feel compelled to utilize BPMN because it is considered the de facto standard in process mapping. However, I believe that using BPMN in this specific use case is not the correct choice. Rather, a language such as Detailed Simplicity that can blend process flow with process procedure, and surface other knowledge artifacts as they are needed, is better suited for creating and disseminating process knowledge to the front-line of the business.
What makes BPMN great in a strictly technical use case (the vast number of objects available) can serve as a stumbling block for end user engagement in process writing and process consumption – two things that are important in a knowledge asset use case.
Purpose is the point
Committing to a process language is a critical part of any process documentation effort. As with all initiatives, it is best to understand what the purpose is before you begin:
Who will be the end users of the processes?
How will the end users be engaging with the processes?
What conditions must be met for the end users to be satisfied?
Using a process language that compliments your purpose and satisfies end user requirements will certainly make process documentation less painful. Set yourself and your process documentation project up for success by knowing your purpose and selecting the best process language for it.
[1] Bruce Silver. BPMInstitute.org. https://www.bpminstitute.org/resources/articles/bpms-watch-bpmns-three-levels-reconsidered (accessed November 20, 2020).
[2] Karen Martin and Mike Osterling, Value Stream Mapping (McGraw-Hill Education, 2014), 7.
[3] Martin and Osterling, Value Stream Mapping, 8.
