Documenting processes

Think beyond swim lanes

Co-authored with Rhys Williams

It’s one of our favourite parts of the job. Arriving at a new client who are about to re-engineer their processes, it inevitably comes to asking how thing get done. Nowadays few admit to having no processes, although you still get some hold-outs! Typical answers include, “we have processes, but haven’t written them down yet”, to, “we had some consultants in last year to capture these. The output is somewhere on the share drive” (possibly gathering electronic dust).

Understanding how clients capture, implement and update processes gives a good insight into their operations. It’s worth noting that software-as-a-service applications have changed the relationship between technology and process. In the on-premise ERP world technology was sometimes customised to fit processes, with SaaS the application often informs process design.

Process documentation sometimes begins and ends with flow diagrams (swim lanes) – the visual representation of who does what and when. Although these are important, it can be beneficial to create corresponding narrative documents. These expand and clarify not just the individual process steps, but also the business context of the process, the process entry and exit points, etc. For example, an HR process narrative may include discussion of the circumstances that determine whether the recruitment or transfer process is used. This narrative is particularly important for process steps as flow diagram “boxes” limit the number of words practically available.

In our experience the discipline of narrative creation facilitates more robust processes and provides a baseline for other documentation, for example related to scenarios, testing and training. Narratives also allow readers without deep operational backgrounds – such as managers – to understand the process and their responsibilities fully.