How to document processes beyond the workflow?

The web is full of guidelines and templates on how to document processes. However the majority of them is partial – related to the description of the workflow-related information only (e.g. process activities, process boundaries, process inputs and outputs, process roles, etc.). Process documentation is more than just a process diagram.

There is process-related information beyond the workflow.

With “Process documentation” I will try to summarize all the process-related information, which is necessary for effective process analysis and improvement. And process improvement is all that matters – in light of BPM as well in light of the company.

How is it done in software engineering?

While having some mileage as a software engineer I know that software requirements form the basis for a valid project outcome, meaning that good requirements are a precondition for a “happy end” – i.e. getting a software that the customer desires. Software requirements are basically divided into two parts, functional and nonfunctional ones. Functional ones are well represented with UML Use-cases and corresponding scenarios, where non-functional ones may be represented in a textual manner. In both parts, standardized templates may be applied (e.g. 830-1998 — IEEE Recommended Practice for Software Requirements Specifications). Other teams or development methods may propose other techniques.

Use Case Diagram
UML use case diagrams demonstrated as an effective technique for representing the functional part of software requirements. This diagram is from a project I was leading in 2015.

But what about process documentation?

Similar to an IT project, the first step in a “process improvement” project is commonly related to obtaining and documenting the current (“AS-IS”) version of a process. In BPM this phase is known as process discovery phase. While specifying an organization’s process is usually related with an AS-IS process diagram, several important process-related information exist beyond the diagram (e.g. process-related metrics, number of instances performed, known problems, etc.).

The workflow part of a process may be defined in a standardized way – with BPMN diagrams.

However, in contrast to software engineering there are no  standardized templates on how to document processes in a holistic way.

Process diagram
Process diagrams represent the workflow-part of process requirements. This diagram is from a process improvement project I was leading in 2015.

What process information exists beyond the workflow?

Process documentation = BPMN diagram ++

My process documentation template (see the photos below) has evolved from past process improvement projects and related templates found on the web. It serves two purposes: at the beginning of process discovery stage it is used to acquire the information from customers, whereas at the end of process discovery stage it used as a basis for delivering precise process documentation to customers.

The template consists of a (1) header page a (2) questionnaire-like page and (3) blank area for sketching a high-level workflow diagram (including a “hello-world” alike BPMN example).

Most essential is the second part of the template, which consists of 25 process properties. They are divided into five sections: (1) basic process information; (2) people and IT support; (3) process-related documentation; (4) process execution and (5) process-related problems.

The template is in Slovenian language, but if you have interest in that matter, contact me.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: