Blog

Procesverbetering wordt vaak toegepast om problemen in een organisatie structureel aan te pakken en blijvend op te lossen. Ik heb succesvolle (proces-) verbetertrajecten begeleid, maar ook projecten gezien waar de verbeteraanpak de problemen initieel juist groter maakte. Door alert te zijn op signalen, en tijdig actie te ondernemen werd het verbetertraject daarna alsnog succesvol afgerond.

Valkuilen bij de implementatie van procesverbetering zijn:

• Onvoldoende inzicht in de resultaten, geen Business Case & Commitment
• Beperkingen in tijd en geld, onvoldoende beslissingen t.a.v. wat gedaan moet worden
• Modellen (zoals het CMMI) verkeerd toegepast
• Onvoldoende kennis van en vaardigheid met het implementeren van verandering
• Organisatie onvoldoende stabiel om verandering te kunnen absorberen

Onvoldoende inzicht in de resultaten, geen Business Case & Commitment

Het is moeilijk om te onderbouwen wat procesverbetering op kan leveren. Men wil een business case hebben, eerder is er geen steun om te veranderen (en geen steun betekent geen verandering). Industriedata is vaak niet bekend, en men heeft geen eigen data om de business case te maken. Het verzamelen van data is duur en ingewikkeld, en dat wil men niet gaan doen totdat zeker is dat het wat oplevert; dan zit je vast in een cirkelredenering.

Wat helpt om dit te doorbreken is:

1. Zichtbaar maken dat er een groot probleem/crisis is, waardoor men wel moet veranderen (de kosten zijn dan niet meer relevant voor de beslissing)
2. Een leider met visie die onderbouwt waarom het nodig is, zonder direct keihard op kosten/resultaat te sturen
3. Inhaken met je verbetering in een traject waarvoor al steun is, of waarvoor je niet direct een business case nodig hebt (b.v. als de investering beperkt is of alleen uren van indirecte medewerkers)

Beperkingen in tijd en geld, onvoldoende beslissingen t.a.v. wat gedaan moet worden

Er is altijd beperkt tijd/geld beschikbaar, daardoor kunnen niet alle veranderingen gedaan worden. Vervolgens wil men een keuze maken wat dan wel te doen, maar dat is lastig als men niet weet welke verbeteringen het meeste opleveren (zie ook 1e valkuil, de business case). Vaak blijft men hangen, omdat niemand de knoop door kan/wil hakken, en wordt er niet beslist, en dus ook niet verbeterd.

Mogelijke oplossingen zijn:

1. Gewoon een verbetering kiezen en ermee te beginnen, waarbij je meteen “oefent” om te meten wat de verandering oplevert en hoeveel tijd en geld het kost. Met die ervaring ben je beter in staat om voor de nog uit te voeren veranderingen schattingen te doen, en dan te beslissen welke verbetering het meest interessant is om te gaan doen. Het is vergelijkbaar met een project planning, de 1e keer zul je er ook naast zitten (accepteer dat!), al doende wordt men beter.
2. Focus je verbetering op enkele procesgebieden waar in jouw organisatie vermoedelijk de meeste winst op korte termijn (Quick Win) te behalen is. Het is immers eenvoudiger om een business case te maken van een kleinere, afgebakende verbetering. Deze aanpak is beschreven in de CMMI Roadmaps.

Modellen (zoals het CMMI) verkeerd toegepast

Het CMMI is een model om processen in een organisatie te assessen, en verbeteringen door te voeren. De doelgroep van dit model zijn dus professionals in kwaliteits- en proces functies, en managers. Het model is niet bedoeld voor ontwikkelaars, testers, projectmanagers, etc. Wat helaas nog te vaak gedaan wordt is het model direct te implementeren, in plaats het te gebruiken om een passend proces te definiëren en dat dan in te voeren. De reactie die je dan vaak krijgt is dat men “niet wil werken volgens CMMI”, of “doen omdat het in CMMI staat”. Terechte reactie, en dus niet doen; gebruik het CMMI om samen met de stakeholders (kwaliteit, processen en management) af te spreken hoe het proces eruit moet zien, en hoe je  het invoert. Dat is waar het voor bedoeld is, het CMMI is geen kant en klaar proces!

Soms zit het enkel in de communicatie. De organisatie doet een “CMMI project”, of “onze processen zijn gedefinieerd volgens CMMI”. CMMI wordt dan een synoniem voor het kwaliteits- cq processysteem, net als men om Spa vraagt als men een glaasje bronwater wil. Ook hier is het advies: Niet doen! Gebruik CMMI enkel als hulpmiddel en taal voor de professionals in kwaliteit, processen en management, en verveel er de projecten en beheerteams niet mee. Het enige wat ze van CMMI hoeven te zien is een assessment, en de bevindingen. Noem de processen die daaruit volgen niet “CMMI processen”, maar “organisatie xx processen”, zodat duidelijk is dat die specifiek gemaakt zijn voor die organisatie om efficiënt en effectief te werken, en niet uit een (CMMI) boekje komen.

Het enige verplichte deel van CMMI zijn de doelen, voor de rest is het een hulpmiddel!

Onvoldoende kennis van en vaardigheid met het implementeren van verandering

Het invoeren van processen is heel ander werk als het maken van software, of het schrijven van een document of maken van een presentatie. Om een proces in te voeren heb je z.g. “soft skills” nodig, zoals communicatie (daar hoort ook luisteren en feedback geven bij), stimuleren en motiveren, trainen/coachen en ondersteunen, etc.

Een goed inzicht in de psychologische en sociologische processen die bij verandering een rol spelen is essentieel om resultaten te bereiken in een organisatie. Er zijn volop opleidingen op het gebied van communicatie en change management waar men de kennis en vaardigheden op kan doen, een investering daarin verdient zich ruimschoots terug in succesvolle verbeterprojecten!

Alle betrokkenen in een verbetertraject dienen deze kennis te hebben, en zich bewust te zijn hoe delicaat een verandertraject kan zijn. Dus zowel de procesondersteuners, als de managers. Waar veranderingen een grote impact kunnen hebben dient ment vooraf met elkaar de aanpak door te spreken en af te stemmen (deployment plan), om daarna ook met “1 gezicht” naar de organisatie te kunnen communiceren over de verandering.

Organisatie onvoldoende stabiel om verandering te kunnen absorberen

De IDEAL aanpak neemt aan dat een organisatie relatief stabiel is tijdens het doorvoeren van een verbetertraject. Als er tijdens een verbeteringtraject grote veranderingen plaatsvinden in een organisatie, zoals wijzigingen in verwachte resultaten, verantwoordelijkheden, sleutelrollen en -personen, etc. dan dient het verandertraject herijkt te worden. In de praktijk leidt dit vaak tot verminderde acceptatie van de ingezette veranderingen (weerstand) en daardoor vertraging.

Oplossing om dit aan te pakken zijn:

1. Verbeter in kleinere stappen, waardoor je de kans dat een organisatie gedurende het verbetertraject veranderd verkleint. De Agile aanpak, veel gebruikt bij het ontwikkelen van software, is ook prima toe te passen om in kleine stappen te verbeteren.
2. Als al duidelijk is dat er een verandering met grote impact aan staat te komen, is het beter om nu geen verbetertraject te starten, maar eerst de organisatie te laten stabiliseren en vervolgens de verbetering te herijken en uit te voeren.

Zoals al kort genoemd, de aanpak om stapsgewijs continue te verbeteren vertoond analogie met de Agile aanpak die gebruikt wordt voor software ontwikkeling. De aanname van Agile is dat er altijd verandering is, en dat men door in kleinere stappen (iteraties) te ontwikkelen het ontwikkeltraject continue herijkt met de vraag (embrace change). Zie voor meer informatie over de Agile aanpak voor procesverbetering: Process Improvement: The Agile Way!

Conclusies

Tijdig herkennen van problemen bij procesverbetering is een 1^e stap om ze aan te pakken. Daarmee vergroot je de kans op een succesvol verbetertraject, en bruikbare resultaten voor de organisatie.