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.

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]

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]

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.