BPR en de Over-engineering van Organisaties

De praktijk en theorie van Business process re-engineering of BPR bestaat al ruim 20 jaar en is nog steeds populair in de grotere organisaties in Nederland. Het idee dat ingenieursprincipes kunnen worden ingezet voor het ontwerpen van processen en organisaties heeft een grote aantrekkingskracht, misschien niet in de laatste plaats als contrast met 'softe' benaderingen, gericht op motivatie, verbinding, zingeving en leiderschap.

De toepassing van BPR richtte zich oorspronkelijk op de verbetering van processen op plaatsen waar men overging van handmatige naar geautomatiseerde verwerking. De resultaten daarvan bleven echter vaak onder de verwachting. Een aantal case-studies toonden aan dat er een revolutionaire verandering nodig was: men moest in feite terug naar de tekentafel om de organisatie een compleet nieuwe vorm te geven. Dit was de re-engineerings-fase, die leidde tot nieuwe bedrijfsstructuren, processen en informatiestromen. Ze was initieel vooral succesvol bij de grote Amerikaanse corporaties.

Business proces management (BPM), wat zijn oorsprong kent in BPR, koppelt hier andere ideeën aan, bijvoorbeeld de meer geleidelijke veranderingsaanpak zoals die met name in Japan werd toegepast bij bedrijven (Kaizen) en de aandacht voor mens en leiderschap in het veranderingsproces. De wetenschappelijke, op harde gegevens en modellen gebaseerde aanpak vormt evenwel nog steeds een belangrijk onderdeel van het gedachtegoed.

Maar als het mogelijk is om organisatie te ' re-engineeren', is een organisatie dan onbedoeld ook te over-engineeren? Welke ongewenste gevolgen kan dat hebben is en zijn die van belang?

Wat is engineering eigenlijk? Een goed Nederlands werkwoord lijkt niet te bestaan, maar het komt neer op het creatief toepassen van wetenschappelijke principes op praktische vraagstukken.

Het Nederlandse Ingenieur komt van het Latijnse ingenium, wat onder meer vindingrijkheidtalent en verstand betekent.

Daar kan je nooit genoeg van hebben zou je zeggen. Soms wordt bij het oplossen van vraagstukken en het bedenken en realiseren van constructies het eindresultaat echter ´over-engineered´ - (ook hier weer geen goed Nederlands gevonden): het komt erop neer dat het product te log, te ingewikkeld, te duur, te onderhoudsgevoelig, kortom: niet in balans is met de doelstelling en de verwachte levensduur van het geheel.

Die levensduur (of in feite de gebruiksduur) van het eindproduct is een belangrijk concept. Duitse ingenieurs bijvoorbeeld overschatten de gebruiksduur van hun tanks in de Tweede Wereldoorlog, waardoor die weliswaar heel sterk waren, maar ook te zwaar en te duur. Dat had weer gevolgen voor de productieaantallen.

Men had blijkbaar geen rekening gehouden op welke termijn het product overbodig (´obsolete´) werd. Aan de andere kant (overigens niet om een punt te maken) staan de goedkope houten wegwerpzweefvliegtuigen waarmee de geallieerden duizenden troepen vervoerden voor de enkele reis naar Normandië op D-Day - goed ge-engineerd voor het doel.

Een gegronde inschatting van de gebruiksduur is daarmee van groot belang om over-engineering tegen te gaan. Indien die niet al bij de tekentafel is gespecificeerd of goed in te schatten is, dan kan het zijn dat de organisatie-ontwerper/ingenieur een aanname doet aan de bovenkant van het spectrum van mogelijkheden. Alle eventualiteiten zullen dan worden voorzien en ingebouwd, met een complex, moeilijk onderhoudbaar eindresultaat tot gevolg. De voordelen van al die ingebouwde ´flexibiliteit´ wegen in dat geval niet op tegen de inspanningen om die te gebruiken of te onderhouden.

In de softwarebouw trad overigens enige tijd geleden ditzelfde knelpunt aan het licht. Dit gaf mede aanleiding tot de Agile-benadering bij systeemontwikkeling. Hierbij wordt continue met de gebruiker afgestemd of het product nog voldoet aan de wens. Het risico op over-engineering is daarmee echter niet helemaal bestreden, omdat ook de gebruikers wel eens de gebruiksduur van software en alle proces- en use case-varianten die zich in die periode zouden kunnen voordoen verkeerd inschatten.

De vraag bij organisatie-engineering is kortom allereerst: voor welke gebruiksduur ontwerpen we een organisatie? Is dit een evolutionair of revolutionair andere versie dan de huidige?  Hoelang -schatten we- duurt het voordat deze nieuwe versie weer obsolete wordt? Worden er op dat moment nog delen van hergebruikt, of beginnen we helemaal opnieuw?

Soms zal het denken in organisatie-versies overigens niet zomaar aanslaan: ´We werken toch al die tijd voor bedrijf Xyz´?

Op zich kan dat waar zijn (al is het logo misschien ook al veranderd), maar lijkt de organisatie nog steeds echt op die van 5 jaar geleden? Qua klanten, producten, diensten, processen?

Als men dat dieper kan onderzoeken dan blijkt er vaak veel verschil te zitten tussen die versie Xyz v1.0 en de huidige versie.

 

Bij bijvoorbeeld auto-modellen is die datering over het algemeen bijzonder duidelijk te zien, met organisaties vaak wat lastiger, vaak ook omdat het verleden niet systematisch wordt vastgelegd.

De uitdaging voor adviseurs in dit veld is meerledig. Ten eerste om de organisatie/klant te helpen begrijpen dat ook aan de volgende versie van de organisatie een beperkte gebruiksduur kleeft. Ten tweede om te herkennen welke delen van de organisatie duurzaam/herbruikbaar en welke vervangbaar moeten worden gemaakt. En ten derde om zodoende over-engineering maar ook under-engineering (i.e. geen juiste structuur, een zwak ontwerp of een simplistische aanpak) te voorkomen, niet alleen in het eigen werk, maar in dat van de gehele organisatieverandergemeenschap.

Een ander idee van de ´echte´ ingenieurs dat ons kan helpen is nu in zwang als value-engineering (waarde-analyse). Hierbij wordt de functie (product, dienst) centraal gesteld. In een team wordt onderzocht hoe die zo goedkoop, efficiënt en eenvoudig kan worden geproduceerd of geleverd. Het proces is in die analyse secundair. Hierdoor komen er meer mogelijkheden in beeld voor alternatieven voor grondstoffen (bv: informatie), toeleveranciers (bv: bronnen en partners) en procesuitvoering (bv: sourcing, bemensing, automatisering). Leanmanagement is hier overigens een uitvloeisel van.

De les die value-engineering daarbij voor ons bevat is om alle onderdelen van het eindresultaat te ontwerpen voor de juiste levenscyclus. Als we na 5 jaar toch een compleet nieuw gebouw neerzetten, dan hoeft geen onderdeel van het huidige ontwerp langer mee te gaan dan dat. Maar willen we onderdelen weer recyclen, up-cyclen of willen we op een andere manier duurzaamheid inbouwen, dan heeft het wel zin te investeren in modulaire maar solide constructies die de tand des tijds goed zullen doorstaan.

Zo ook met organisatieveranderingen - als men incalculeert met welke regelmaat reorganisaties optreden, dan is het vaak onlogisch om voor die nieuwe versie alle processen uitgebreid te gaan beschrijven en te implementeren. Volg een grote lijn en laat iets meer over aan de fantasie van het personeel. Ontwerp daarbij de delen die ook in de volgende organisatieversie bruikbaar zijn modulair, solide en re-cyclebaar.

Wie weet is die volgende reorganisatie dan wel helemaal niet nodig.

Tot slot nog een quote uit een artikel over software-engineering, wat denk ik laat zien wat value engineering zou moeten inhouden: niet alleen het ontwerp en de constructie van een goede oplossing, maar ook de (evolutionaire) weg naar die oplossing.

´To date, our software design literature has focused more on teaching great solutions than teaching evolutions to great solutions. We need to change that. As the great poet Goethe said, "That which thy fathers have bequeathed to thee, earn it anew if thou wouldst possess it." - By Joshua Kerievsky uit Stop Over-engineering! Industriallogic.com, 2002

Ref.: Hammer, M. (1990). ‘Re-engineering work: don’t automate, obliterate’. Harvard Business Review, 68, 4, July-August, 104-112.