Process Structure Diagram (PSD): History and Origin

Proving the structural correctness of a process

“Process Structure Diagrams” (PSD) for rugged Business Processes

I (Arno Koch) started to use Process Structure Diagrams in 1996 when I was challenged to develop a methodology to design and test solid, loss-free business processes to be applied in manufacturing industry. By then, the consultancy bureau that employed me was mainly focused on improving the physical conversion processes on the shopfloor of factories.

Equipment losses…

By measuring the losses occurring on the equipment and machinery, I discovered how the majority of the losses (like reduced speed, breakdowns, waiting etc.) found their origin somewhere in an office!

…originating in Offices

Digging into those offices I was amazed about the cluttered and unstructured way those ‘office processes’ where performed, even at top-ranking (and maybe particularly) multinational companies.

3 Pillars to attack office losses

The methodology I developed had 3 pillars:

What should be achieved (the output) and what is the way to get there (basically the structure of meeting several criteria or milestones to build up a value stream).
How should that process in day to day life be executed; who is doing what activities when to achieve what?
How should the physical environment be developed to support the earlier 2 steps at best?

Step 3 is being done by the 5S workplace organization methodology.

Step 2 can be done by a Value Stream Map, but even better by a Makigami Process Analysis

Step 1 is realized through a Process Structure Diagram

Origin of the Process Structure Diagram (PSD)

The Process Structure Diagram is a direct descendant of the Program Structure Diagram, also known as a Nassi-Shneiderman diagram. This is a technique originating from computer programming.

It was first developed in 1972 by Ben Shneiderman.

Preventing Spaghetti code

As a graduate student he attended a workshop about ‘Jackson Structured Programming’, where Jackson promoted a technique that imposed a logical structure on the writing a computer program. Large routines are broken down into smaller, modular routines. Jackson specifically wanted to discourage the use of the GOTO statement, since it easily led to ‘spaghetti code’. Shneiderman elaborated on the idea with his fellow graduate student Isaac Nassi and in 1973 the original Flowchart Techniques for Structured Programming, was published (SIGPLAN Notices 8, August, 1973).

Example of a Process Structure Diagram

DIN and NEN norms

In Germany these diagrams are widely used and known as Struktogramme, standardized by DIN 66261 (November 1985), INFORMATION PROCESSING; NASSI-SHNEIDERMAN FLOWCHART SYMBOLS. In Holland it is described in the “NEN 1422 voor PSD’s” norm

Software Program versus Business Process

In a software program a process is being performed –in some cases– in a million fold per second, preferably in a predictable, reliable and stable manner. What is the difference with a business process? Basically the only difference is the frequency and speed of the activities.

The occurrence of unexpected situations

Due to the high frequency in which the steps and decision are being made in software, the occurrence of unusual or unexpected situations are more likely to show up rapidly (and thus also more often) when there is a structural mistake in the software. Although business processes are millions of times slower, it does not mean they are less vulnerable to the same structural design flaws!

If it works for Software, it does for Business Processes!

Where a weakly designed business process may still keep running, buggy software quickly becomes useless. Therefore it became more common to design stable software processes than stable business processes…

My conclusion therefore was not so strange: Why not approach a business process in the same way as a software process to design it predictable, stable and reliable?

Nassi and Shneiderman developed their diagram in a way it simply does not allow unstructured processes to be described. In fact a lot of the criticism towards this technique is based this issue!

My course participants more than once said: ‘It is not possible to describe my process in a PSD’. Right! This is precisely the problem! You just discovered to have an unstructured process, which is revealed by the use of the PSD!