Processtructuurdiagram (PSD): geschiedenis en oorsprong
De structurele juistheid van een proces aantonen
“Processtructuurdiagrammen” (PSD) voor robuuste werkprocessen
Ik (Arno Koch) begon Processtructuurdiagrammen te gebruiken in 1996 toen ik werd uitgedaagd om een methodologie te ontwikkelen voor het ontwerpen en testen van solide, verliesvrije bedrijfsprocessen voor toepassing in de productie-industrie. Op dat moment was het adviesbureau waar ik toen voor werkte vooral gericht op het verbeteren van de fysieke conversieprocessen op de werkvloer van fabrieken.
Verliezen op machines…
Door de verliezen te meten die optraden op de machines, ontdekte ik dat de meeste verliezen (zoals verminderde snelheid, storingen, wachttijden, enz.) hun oorsprong vonden ergens in een kantoor!
…afkomstig uit Kantoren
Toen ik in die kantoren ging graven, was ik verbaasd over de rommelige en ongestructureerde manier waarop die ‘kantoorprocessen’ werden uitgevoerd, zelfs bij multinationals van topniveau (en misschien wel in het bijzonder).
3 pijlers om kantoorverliezen aan te pakken
- Wat moet er bereikt worden (de output) en wat is de manier om daar te komen (in principe de structuur van het voldoen aan verschillende criteria of mijlpalen om een waardestroom op te bouwen).
- Hoe moet dat proces in het dagelijks leven worden uitgevoerd; wie doet welke activiteiten wanneer om wat te bereiken?
- Hoe moet de fysieke omgeving worden ontwikkeld om de eerdere 2 stappen zo goed mogelijk te ondersteunen?
Stap 3 wordt uitgevoerd door de 5S-methodologie voor werkplekorganisatie.
Stap 2 kan gedaan worden met een Value Stream Map, maar nog beter met een Makigami procesanalyse.
Stap 1 wordt gerealiseerd door middel van een Processtructuurdiagram
Oorsprong van het processtructuurdiagram (PSD)
Het Processtructuurdiagram is een directe afstammeling van het Programmastructuurdiagram, ook bekend als een Nassi-Shneiderman diagram. Dit is een techniek uit de computerprogrammering.
Het werd voor het eerst ontwikkeld in 1972 door Ben Shneiderman.
Spaghetti programmeercode voorkomen
Als afgestudeerd student woonde hij een workshop bij over ‘Jackson Structured Programming’, waar Jackson een techniek promootte die een logische structuur oplegde bij het schrijven van een computerprogramma. Grote routines worden opgesplitst in kleinere, modulaire routines. Jackson wilde specifiek het gebruik van het GOTO statement ontmoedigen, omdat het gemakkelijk leidde tot‘spaghetti code’. Shneiderman werkte het idee uit met zijn medestudent Isaac Nassi en in 1973 werd de originele Flowchart Techniques for Structured Programming, gepubliceerd (SIGPLAN Notices 8, August, 1973).
DIN- en NEN-normen
In Duitsland worden deze diagrammen veel gebruikt en staan ze bekend als Struktogramme, gestandaardiseerd door DIN 66261 (November 1985), INFORMATION PROCESSING; NASSI-SHNEIDERMAN FLOWCHART SYMBOLS. In Nederland wordt het PSD beschreven in de “NEN 1422 voor PSD’s” norm
Softwareprogramma versus bedrijfsproces
In een softwareprogramma wordt een proces uitgevoerd – in sommige gevallen – in een miljoenvoud per seconde, bij voorkeur op een voorspelbare, betrouwbare en stabiele manier. Wat is het verschil met een bedrijfsproces? Eigenlijk is het enige verschil de frequentie en snelheid van de activiteiten.
Het optreden van onverwachte situaties
Door de hoge frequentie waarmee de stappen en beslissingen in software worden genomen, is de kans groter dat ongewone of onverwachte situaties zich snel voordoen (en dus ook vaker) wanneer er een structurele fout in de software zit. Hoewel bedrijfsprocessen miljoenen keren langzamer zijn, betekent dit niet dat ze minder kwetsbaar zijn voor dezelfde structurele ontwerpfouten!
Als het werkt voor software, dan werkt het ook voor bedrijfsprocessen!
Waar een zwak ontworpen bedrijfsproces nog kan blijven draaien, wordt buggy software al snel nutteloos. Daarom werd het gebruikelijker om stabiele softwareprocessen te ontwerpen dan stabiele bedrijfsprocessen…
Mijn conclusie was dan ook niet zo vreemd: Waarom een bedrijfsproces niet op dezelfde manier benaderen als een softwareproces om het voorspelbaar, stabiel en betrouwbaar te maken?
Nassi en Shneiderman hebben hun diagram zó ontwikkeld dat het eenvoudigweg niet mogelijk is om ongestructureerde processen te beschrijven. Veel van de kritiek op deze techniek is hierop gebaseerd!
Mijn cursisten zeiden meer dan eens: “Het is niet mogelijk om mijn proces in een PSD te beschrijven”. Juist! Dit is precies het probleem! Je hebt net ontdekt dat je een ongestructureerd proces hebt, wat wordt onthuld door het gebruik van PSD!
Een slecht ontworpen bedrijfsproces mag niet (kunnen) worden beschreven!