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.
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.
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.
Gregor Polančič 