History and Origin of PSD

The History of “Process Structure Diagrams”

In 1996 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.

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!

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.

The methodology I developed had 3 pillars:
  1. 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).
  2. How should that process in day to day life be executed; who is doing what activities when to achieve what?
  3. 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.

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).

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.

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!

However, a weak designed business process can still operate, where buggy software quickly becomes useless. Therefore it became more usual 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!

Business Process Reengineering (BPR)

Reengineering is about radical change. Business process reengineering (BPR) differs from continuous (incremental) improvement programs that place emphasis on small, gradual changes, of which the object is to improve on what an organization is already doing. This incremental change to improve business performance typically takes one of several forms, e.g., quality (total quality management), automation, reorganization, downsizing, and rightsizing. In contrast, BPR is:

1) Not just automation, although it often uses technology in creative and innovation ways.

2) Not just reorganization, although it almost always requires organizational change.

3) Not just downsizing, although it usually improves productivity.

4) Not just quality, although it is almost always focused on customer satisfaction and processes that support it.

BPR is a balanced approach that may contain elements of more traditional improvement programs with which it is often confused. However, BPR is much more than that. First, BPR seeks breakthroughs in important measures of performance rather than incremental improvements. Second, BPR pursues multifaceted improvement goals, including quality, cost, flexibility, and speed, accuracy, and customer satisfaction concurrently. To accomplish these outcomes, BPR adopts a process perspective of the business, while other programs retain functional (departmental) perspectives. It also involves a willingness to rethink how work should be done, even if it means totally discarding current practices if that should prove necessary. BPR also takes a holistic approach to business improvement, leveraging technology and empowering people, which encompasses both the technical aspects of process (technology, standards, procedures, systems, and controls) and other social aspects (organization, staffing, policies, jobs, career paths, and incentives)

(adapted from Manganelli R.L. and Klein M.M., The Reengineering Handbook, 1994).

a magnificent technique to use is the Makigami Process Analysis