Waar komt RPM vandaan?

Peter Bootsma: "in 1990 kreeg ik als opdracht om na te denken over hoe het verder moest met TQM binnen Gasunie, destijds een bedrijf met 2000 medewerkers. TQM was een thema met allerlei tijdloze principes, zoals het cyclisch werken aan verbetering, het benutten van kennis van mensen op de werkvloer of het gebruik van regelgrenzen bij procesbeheersing. Maar ook met een hoop modieuze modellen zoals verbeterteams (niet doorgebroken), ISO-certificatie (geslaagd in termen van strategie en marketing maar met veel minder effect op organisatieontwikkeling dan verwacht) en doen alsof we japanners zijn (dat zijn we niet). Ik ben eens gaan praten bij de afdeling Control. Daar wisten ze niet precies wat TQM inhield, maar ze hadden wel wat anders: de 'management control filosofie'. Ook die zat vol met tijdloze principes (cyclisch plannen, verslagleggen en bijsturen) en modieuze modellen (balanced score card). Ook in de literatuur die we toen voor de MBA studie doornamen kwam ik een combinatie van principes en mode tegen. Een vergaarbak van soms onverenigbare modellen die het lastig maakte om tot nieuwe aansprekende beelden te komen waar medewerkers zich mee kunnen identificeren.

Toen maar eens een poging gedaan om het tijdloze en het modieuze uit elkaar te halen, en een klein samenhangend setje van concepten te vinden waarmee het gesprek in de verschillende afdelingen beter gevoerd zou kunnen worden. Geen algemeen model voor alles, maar een onderliggend verbindend patroon, een soort van lego-bouwplaat waarop je in alle afdelingen ander maatwerk kon maken en waardoor de samenwerking tussen afdelingen gemakkelijker zou worden. Een bouwdoos zou je ook kunnen zeggen. Onbegonnen werk wellicht, maar ik vond het toen gewoon een leuke puzzel. Tijden mee bezig geweest op whiteboards. Leidde tot een hoop denkbeelden waar ik later weer van terug kwam. Als ik de iteraties even oversla ging het ongeveer zo.

Ontwerpcriteria

Begonnen met stellen van voorwaarden aan de bouwdoos. Die heb ik destijds nooit uitgeschreven maar ze speelden een belangrijke rol op de achtergrond. Hier de reconstructie:
- Ten eerste continuiteit. Zo vond ik dat de bouwdoos overal in de organisatie en op alle niveaus een praktische toepassing moest hebben, anders krijg je uitzonderingen. Een enkele uitzondering (bijvoorbeeld de top) zou voldoende zijn om overal een modeldiscussie op te roepen en dat wilde ik vermijden. Ik zocht naar iets was wat net zo universeel zou zijn als bijvoorbeeld het gegeven van hiërarchie, het principe van werken in projecten, of het maken van jaarverslagen. Dan zou de bouwdoos gemakkelijker geaccepteerd worden als een onderdeel van de bedrijfscultuur. Wat je met die bouwdoos opbouwt blijft dan gemakkelijker in stand, zo was de gedachte, omdat uitzonderingen buiten de sociale orde vallen. Bovendien ben je dan op termijn minder afhankelijk van adviseurs.
- Een tweede voorwaarde was variëteit. Een organisatie kan immers bijzonder divers zijn en de bouwdoos mag dan geen keurslijf zijn. Dit betekende dat de bouwdoos tamelijk abstract zou moeten blijven. Het zou een aantal universeel belangrijke dimensies moeten aanduiden maar geen uitspraak mogen doen over de gewenste keuze binnen die dimensie.
- Tenslotte moest de bouwdoos geschikt zijn voor stapsgewijze implementatie. Vanuit een pilot beginnen of in delen toepassen bijvoorbeeld. Onderdelen van de bouwdoos moesten daarbij ieder voor zich een praktische meerwaarde hebben en het geheel moest bovendien een toegevoegd synergie-effect hebben. Het mocht in ieder geval geen utopisch construct worden dat alleen in zijn geheel begrepen kan worden en waar je in moet 'geloven' voordat je er mee kunt werken.

Onderdelen van RPM

Toen op zoek naar tijdloze principes te midden van modieuze concepten. Een greep:

Om te beginnen mensen. Die nemen vaak niet deel aan een organisatie omdat de aandeelhouders hen zo aanspreken, maar gewoon om een inkomen te hebben en om met hun vak bezig te kunnen zijn, of om vanuit hun vak met mensen bezig te zijn. Commitment aan bedrijfsdoelen kent dus natuurlijke beperkingen, maar de leiding wil vanwege de concurrentie toch eigenlijk graag een tandje hogere inzet voor klanten en bedrijfsresultaten. Deze interne spanning is van alle tijden en alle markten.

Het tweede dat ik een plek wilde geven in de puzzel waren bedrijfsprocessen, het werk wat gedaan moet worden, de routines. Processen zijn een fundamenteler gegeven dan organisatiestructuur, al lijkt het in de praktijk soms andersom. Bovendien was het denken in termen van processen sterk in opkomst, bijvoorbeeld in de ISO 9000 serie. Projecten waren in deze zienswijze ondergeschikt aan processen. Projecten kon je, tamelijk abstract, immers zien als tijdelijke inspanningen om een of ander proces te verbeteren, intern of bij een klant. Een project heeft dus altijd een proces als klant of opdrachtgever. Het idee was dus om eerst een model voor de routines van een organisatie te maken en daar het principe van projecten aan toe te voegen.

Vanwege de gedachte aan een bouwdoos begon ik niet outside-in of top-down, maar met zoeken naar eenheden of cellen. Wat zijn dan de cellen van een organisatie? Ik kon kiezen uit: de mens, de afdeling, de business unit, het projectteam of het procesteam. Het werd het laatste, ondanks het gegeven dat veel processen niet 1-op-1 door ‘dedicated’ teams worden uitgevoerd. Het procesteam definieerde ik als een vergaderbare groep van medewerkers, bijvoorbeeld 7, die gezamenlijk een proces of een processtap voor hun rekening nemen en daarbij voor een zo concreet mogelijk eindproduct of tussenproduct zorgen.
Dat dergelijke werkverbanden niet altijd zouden samenvallen met hiërarchische afdelingen was dus duidelijk. Ook helder was dat je nooit alle mensen die met een omvangrijk proces bezig zijn in één team kunt krijgen. Daar heb je een aparte communicatiestructuur voor nodig, bijvoorbeeld met linking pins. Ik heb voor dat soort structuren geen aparte entiteit toegevoegd aan de bouwdoos. In plaats daarvan heb ik de coördinatielaag boven een aantal parallel en/of serieel geschakelde teams van een groot proces opgevat als weer een procesteam. Coördineren is immers ook een routine. In sociotechniek had ik me in die tijd overigens nog niet verdiept.

Coördineren, overigens, daar heeft Mintzberg eens een model voor aangereikt: coördinatiemechanismen, dat onderscheid maakt tussen zes fundamenteel verschillende manieren om samenwerking tussen mensen te bewerkstelligen, variërend van direct toezicht houden op uitvoering tot zorgen voor gedeelde waarden en normen. Een blikverbreder bij uitstek, die de soms verstarrende aandacht voor standaardisatie van werkprocessen kan helpen ombuigen.

Nog enkele meer technische principes waar ik iets mee wilde doen waren fractals en netwerken. Het boeiende van fractals vond ik de efficiëntie van het hergebruik van simpele formules. Met bijna niks maak je de mooiste dingen. Een belangrijk principe daarin is recursie, zelfherhaling.

Stakeholders pasten ook in het rijtje van tijdloze concepten. Wie het over stakeholders heeft zegt eigenlijk dat je je niet op één partij moet richten, bijvoorbeeld de leiding of de klant, maar dat je met iedereen rekening moet houden. Dat is een andere boodschap dan die van de oude stelregel van unity of command die eigenlijk zegt dat je moet voorkomen dat de werkvloer moet nadenken. Met een stakeholderbenadering maak je het jezelf echter niet gemakkelijk. Als je behalve met je klanten ook met je baas, de leveranciers, andere afdelingen en jezelf rekening moet houden, dan is kwaliteit vaak een compromis. Toch is dat vaak de praktijk. Veel mensen herkennen zich niet in het idealistische doel van overtreffen van klantverwachtingen, maar kennen vooral dilemma's en werkdruk. Kwaliteit is dan het vakkundig schipperen in een lastig belangenveld. Dit gegeven, meervoudige relaties en het balanceren met belangen was dus ook iets om mee te nemen in RPM.

Overeenkomsten tussen teams

Met de keuze voor procesteams als centraal object in het model kon vervolgens gezocht worden naar kenmerken. Vervolgens was het zoeken naar onderwerpen die voor alle procesteams belangrijk zijn, of eigenschappen die je altijd tegenkomt.
- Bijvoorbeeld zelfsturing. De mate van zelfsturing kan van team tot team verschillen, maar ieder team heeft te maken met de vraag wat ze wel zelf beslissen en wat niet. Zelfsturing, of beslisruimte, is dus interessant om in het model een plek te geven.
- Een principe uit de kwaliteitszorg dat een plek moest hebben was het cyclische verbeterpatroon van Shewart (bekend geworden als de Deming cirkel). Uitvoering van werk, zo was het idee, moet periodiek gevolgd worden door evaluatie tegen een voorafgaande planning van kwaliteitsdoelen. Geconstateerde afwijkingen zijn dan aanleiding voor twee soorten acties: repareren en voorkomen. De uitkomsten daarvan zijn weer input voor planning van volgend werk. Dit leek mij van toepassing op alle routinewerk en geschikt voor het model.

Samengevat: - processen - teams - planning en verslaglegging - borging en verbetering

Recursie als naam

Zo dus. Het model moest nog een naam hebben. Dat werd recursief proces management, RPM. Recursie benoemt niet alleen de toepasbaarheid op meerdere niveaus, maar ook het veroorzaken van toepassingen op lagere niveaus, het sneeuwbal effect dus. Proces geeft aan dat het werk centraal staat, en niet de structuur van de organisatie. Management maakt duidelijk dat het niet bij inrichten blijft maar voor een lopende organisatie bedoeld is. Procesmanagement schrijf je in het Nederlands aan elkaar maar dat deed ik maar niet om zowel voor het Engels als het Nederlands op dezelfde afkorting uit te komen. Verder zat er een term in (recursie) die voor het publiek van dit model vreemd was en daardoor wel zou blijven hangen. RPM was nu wel klaar. Dacht ik.

Lessons learned

De eerste implementaties liepen soms moeizaam. De aandacht ging te veel naar hoe de werkvloer met RPM werkte, en te weinig naar wat het management er mee deed. Dat is later omgebogen door een voorbereidingsfase in te voegen waarin vooral de directie en de stafafdelingen iets te doen hebben, en door een strak top-down schema aan te houden waarbij managers hun eigen teams coachen in werken met het model.

In de eerste implementaties werd veel training gegeven en weinig begeleiding in de praktijk. Werken met grotere groepen beperkte weliswaar de kosten van een implementatie, maar ook het effect daarvan. Inlijn met de algemene kritiek op effectiviteit van bedrijfstrainingen is deze route verlaten en vervangen door praktijkbegeleiding op maat voor reguliere teamvergaderingen. Kennismaken met RPM is voor teams nu een kwestie van een jaar lang extra puntjes op de agenda van de teamvergaderingen.

Nog een leereffect heeft te maken met hoe je RPM aanduidt. Is het een model? Of een concept? Of een hulpmiddel, een instrument, een tool, een blauwdruk? Al deze begrippen stuiten vroeg op laat op weerstand. Organisaties zijn moe van steeds weer nieuwe concepten, adviseurs zijn "het instrument voorbij". Met dat RPM ervaring opdeed en er nieuwe ideeen aan toegevoegd werden veranderde echter ook het karakter, de volgorde in implementatie kreeg meer aandacht en het eindresultaat kon steeds meer door de organisatie zelf bepaald worden. Bijvoorbeeld: in de eerste implementaties was de vragenset een vast gegeven, aangereikt door de begeleider. In latere implementaties is dat vervangen door een ontwerptraject in de organisatie waarin een vragenset tot stand kwam. De oorspronkeljke vragenset werd alleen nog als inspiratiebron gebruikt. Door dit soort aanpassingen kan het uit om RPM nu aan te duiden als een methode voor organsatieontwikkeling. Eenmethode reikt een werkwijze aan, een volgorde, checklists, etc., maar geen blauwdruk voor het eindresultaat.

Hoe ga je om met verschillen in opleidingsniveaus, dat is ook zo'n onderwerp waarin RPM een ontwikkeling heeft doorgemaakt. Begin jaren 90 leidde deze vraag tot onderscheid tussen langere en kortere trainingstrajecten, of tot aanvullende begeleiding. In de latere implementaties is de bal meer bij het management gelegd. Managers staan dan voor de keuze of ze een team zelf laten uitzoeken hoe ze met de RPM-vragenset tot een goed verhaal komen, of dat ze team daarin flink begeleiden, bijvoorbeeld door met uitgewerkte voorbeelden te komen die in de teamvergaderingen besproken kunnen worden. Feit blijft dat er altijd een categorie medewerkers is die op voorhand geen affiniteit heeft met het onderwerp management, er ook geen verantwoordelijkheid voor wil dragen maar wel graag aan het werk wil. Als je nieuwe materie dan concreet uitgewerkt op tafel kunt leggen en de voordelen tastbaar kunt maken, bereik je vaak meer.

Unity of command kwam nog een keer terug, in een implementatie van RPM voor een bedrijfsproces dat een hele organisatie doorsneed. De vraag wie nu eigenlijk de baas is van een multidisciplinair deelteam riep voortdurend vragen op en RPM had daar nog geen passend antwoord op. De druk op de ketel van dat moment heeft toen geleid tot het eenvoudige rolmodel dat nu een van de kernen van RPM vormt, en even later tot een paper over Backwards compatible management systems”.