Verandermanagement is ‘hot', met Prince2 als belangrijkste methodiek voor projectproces beheersing. Maar waarom duren verandertrajecten dan toch langer dan verwacht en brengen ze meer kosten met zich mee? Testen als afsluitend onderdeel in het systeemontwikkelproces is inmiddels gemeengoed. Je bewaakt daarmee dat je dan over een functioneel adequaat opererende applicatie beschikt. Wat is dan de oorzaak dat de opgeleverde it-componenten niet doen wat ze zouden moeten doen? Basile Lemaire probeert hier een antwoord op te geven.
De kern van bovenstaande problematiek is vooral gelegen in onduidelijkheid en inconsistentie in wat er veranderd moet worden en hoe er veranderd moet worden. Je hebt er belang bij dat een systeem of applicatie past binnen de bedrijfsprocessen, of, op een hoger niveau, dat de opgeleverde oplossing aansluit bij de business rationale of business case. Kortom, dat er goed gebouwd is, is één ding. Dat het goede gebouwd is, is echter van veel groter belang.
Consistentie
Wat nodig is voor het beheersen van de verandering, is het borgen van de consistentie over de veranderketen. Iedere stap van het veranderproces moet geverifieerd en gevalideerd zijn tegen de voorgaande en opvolgende stap. Zo moet de veranderbehoefte consistent zijn met de visie en het vastgestelde beleid. Een oplossingsdefinitie of blauwdruk moet ook daadwerkelijk invulling geven aan de veranderbehoefte. De ontwikkelde oplossing moet voldoen aan de gedefinieerde processen en functionele vereisten.
Dit proces is wat ik Acceptatie noem: aantonen in hoeverre een oplossing zal voldoen en uiteindelijk voldoet aan de behoefte, gezien vanuit de bedrijfsvoering. De governance over het proces, het bewaken dat het ook daadwerkelijk gebeurt, is het Acceptatie Management.
Acceptatie gaat uit van een continue toetsing op de bedrijfs- en programmadoelstellingen en de daaruit geformuleerde behoefte. Gebaseerd op best practices in de financiële dienstverlening en rijksoverheid heb ik ten behoeve van de Acceptatie een algemeen toepasbaar model ontwikkeld. De bijgaande afbeelding is een vereenvoudigde weergave van dit Acceptatie Management Model.
Als het gaat om veranderen, laat het Model zien dat er drie niveaus zijn, voorafgaand aan de ontwikkeling van een oplossing.
Beleid
De organisatie stelt in de strategie en de middellange termijnplanningen vast wat de organisatie is, waar de organisatie naar toe gaat en welke doelstellingen daarmee gesteld zijn. De vereisten vanuit beheer- en compliancy optiek alsook de verplichtingen vanuit lopende contracten zijn organisatiebreed voorschrijvend en daarmee integraal onderdeel van Beleid.
De baseline acceptatiecriteria is het levende verzameldocument met daarin de vastgestelde vereisten en de bijbehorende normering. Als ‘operational excellence' onderdeel is van de strategie, staat in de baseline beschreven hoe de organisatie dat gaat meten.
Behoefte
Uit Beleid komen noodzaak en wens tot verandering voort. Deze afgeleide veranderbehoefte leg je vast in een business case én in business requirements. De business case betreft de financiële en kwalitatieve rationalisatie van de verandering. De business requirements beschrijven op hoog niveau wat je beoogt en wat je met de verandering wilt bereiken. De Behoefte is daarmee nog vrij van oplossingen. De directeur die roept: "Ik moet operational excellence bereiken dus ik ga SAP implementeren", zou dus eerst een pas op de plaats moeten maken en zich moeten afvragen: "Wat moet ik nu eigenlijk leveren, gekeken naar het Beleid? Heb ik daar daadwerkelijk SAP voor nodig?"
Wanneer de Behoefte op papier staat, volgt een belangrijke stap: verificatie en validatie van de Behoefte tegen het Beleid. Ieder statement in de business case en ieder business requirement toets je tegen Beleid. Is het consistent? Is deze veranderbehoefte inderdaad een afgeleide van hogere bedrijfsdoelstellingen? Wanneer de antwoorden op deze vragen positief zijn, is het zaak om de acceptatiecriteria van de Behoefte op te stellen. Ofwel: het koppelen van normen, bandbreedtes en meetmethodes aan de business requirements. Als opvolgende stap verifieer je de acceptatiecriteria tegen de baseline van het Beleid: vallen de normen op Behoefte-niveau binnen de context van de normen op Beleid-niveau?
Het op deze manier vastleggen van de Behoefte lijkt zo voor de hand liggend. Helaas, de praktijk is een stuk hardnekkiger. Hoe vaak is de business case niet meer dan een Excel-sheet die "ooit" eens door de financiële controllers is opgesteld? In hoeverre zijn er zuivere business requirements die zich beperken tot de wat-vraag? Laat staan dat er serieuze stappen zijn gezet in verificatie, validatie en normering. Toegegeven, het vergt een serieuze investering. Deze weegt echter ruimschoots op tegen de besparingen die je behaalt – simpelweg omdat je nu de stap hebt gezet om te borgen dat je krijgt wat er werkelijk nodig is.
Blauwdruk
Als het helder is wat je moet leveren, staat de weg open om vast te stellen hoe je dat moet gaan leveren. Uit de Behoefte komt de oplossingsrichting of Blauwdruk voort. Deze beschrijft functioneel wat de oplossing moet gaan doen. Het gaat om de procesontwerpen, gebaseerd op klant-tot-klant processen. Daarnaast gaat het om functionele specificaties, neergeschreven in user- en system-requirements en uiteindelijk in functionele ontwerpen. Ook voor de Blauwdruk is validatie en verificatie essentieel. Alle documenten toets je tegen de business case en business requirements. Stel jezelf de vraag: "Gaat deze oplossingsdefinitie ook daadwerkelijk invulling geven aan mijn veranderbehoefte?" Toetsing van Blauwdruk tegen Behoefte is een intensief en cyclisch proces met de nodige iteraties.
De huidige praktijk laat te vaak zien dat er veel te makkelijk gedacht wordt over verificatie en validatie, zeker op dit niveau. Een informatieanalist maakt een functioneel ontwerp. Hij levert deze ter goedkeuring op aan "de" business. Vanuit "de" business wordt er door een manager naar gekeken. Die manager ziet voor het eerst in zijn leven iets als use cases, en heeft eigenlijk geen idee wat er nu voor hem ligt. Hij denkt vervolgens bij zichzelf: "Ze zijn er lang genoeg mee bezig geweest, het zal wel goed zijn". In het mailtje terug van de manager aan de informatieanalist staat vervolgens: "Ziet er goed uit." En dat is het dan. "De opdrachtgever is er mee akkoord". Wat een waanzin! Als nu de ict-leverancier aan de slag gaat, zullen de bits en bytes aan het einde van de rit vast wel kloppen met het functioneel ontwerp. In hoeverre het stukje opgeleverde it echter past binnen de processen, binnen de Behoefte of binnen Beleid is van heel andere orde. Zie hier de kern van het verschil tussen "goed gebouwd" en "het goede gebouwd".
Het zal je zijn opgevallen dat in het Model de testsets onderdeel zijn van de Blauwdruk. De testsets baseer je op de functionele beschrijvingen en verifieer je tegen de acceptatiecriteria uit de Behoefte. De reden om testsets in dit stadium al op te stellen, is simpel. Als het duidelijk is wat er belangrijk genoeg is voor de vragende partij om functioneel te testen, kan de ict-leverancier hier in de ontwikkeling van de oplossing al rekening mee houden. Toen het duidelijk was hoe Euro NCAP de botsproeven uitvoerde, konden autofabrikanten hier in de ontwikkeling van hun auto's rekening mee houden. Gevolg: over de hele linie veiligere auto's.
De geverifieerde en gevalideerde Blauwdruk is de opdracht voor jouw in- of externe ict-leverancier. Als de keuze voor de leverancier nog moet plaatsvinden, vormt de Blauwdruk de set uitgangsdocumenten voor het RFI/RFP of aanbestedingstraject.
Een voorbeeld
Het afgelopen jaar ben ik direct betrokken geweest bij een grootschalig business proces outsourcingstraject. Alle ingrediënten voor succes waren aanwezig: geld, tijd, inhoudelijke en technische kennis, menskracht. Toen ik aantrad als acceptatie manager, viel me een aantal zaken direct op. Mijn bevindingen in het licht van het Model:
• Op Beleid-niveau miste het outsourcingscontract de essentie: service level afspraken voor de te leveren diensten ontbraken. Wat wel stond vastgelegd was dat de door de insourcende partij te gebruiken hardware van ‘A-kwaliteit' moest zijn (!)
• Op Behoefte-niveau trof ik een pak aan uitgeprinte Excel-sheets die door moesten gaan voor business case. Door de ontoegankelijkheid en onleesbaarheid werd deze ‘business case' op geen enkel moment binnen het verandertraject ter hand genomen. Er waren voorts geen business requirements en geen acceptatiecriteria.
• Op Blauwdruk-niveau bestond uitsluitend een ongeverifieerde en ongevalideerde set aan procesbeschrijvingen. Bij gebrek aan beter werden deze processen in de communicatie als requirements naar voren geschoven.
• Ondertussen was de ict-leverancier, los van requirements en functioneel ontwerp, aan de slag met het opstellen van hun eigen ‘specs' op grond van wat zij dachten dat goed zou moeten zijn. Per slot van rekening hadden ze vooral een deadline gekregen waarop zij klaar moesten zijn…
Het zal je niet verbazen dat, ondanks dat de belangrijkste randvoorwaarden leken te zijn ingevuld, een dergelijke verandering gedoemd is te mislukken. De inhoudelijke grip op de verandering, het bewaken van de consistentie, is de grote afwezige. Er is geen duidelijk geformuleerde veranderbehoefte die zijn grondslag vindt in het bedrijfsbeleid. Het ontbreekt aan een volledige set aan blauwdrukdocumenten die hun grondslag vinden in de veranderbehoefte en die als opdracht fungeren aan de ict-leverancier. De consequentie in deze casus was dat het traject door de outsourcende partij is stopgezet en dat de outsourcing vervolgens is teruggedraaid. Toepassing van Acceptatie Management en het Acceptatie Management Model hadden het traject voor dit falen behoed.
Conclusie
Succes van verandertrajecten begint bij een heldere bedrijfsvisie, toetsbare bedrijfsdoelstellingen en duidelijke beleidslijnen. Toepassing van Acceptatie Management en het Acceptatie Management Model helpen de consistentie over de veranderketen te borgen en om vanuit Beleid te komen tot de verwachte oplossing. In de baseline acceptatiecriteria leg je de normen voor verandering vast. Vervolgens maak je een duidelijk onderscheid tussen Behoefte (wat moet je leveren) en Blauwdruk (hoe lever je dat). De producten op de drie niveaus verifieer je ten opzichte van elkaar: is het ene niveau consistent met het andere? De tweede stap is validatie: is dit ook daadwerkelijk wat ik wil of wat er gevraagd of vereist is? Na de nodige iteraties in de cycli van toetsingen ligt er een solide Blauwdruk op basis waarvan leveranciers de oplossing kunnen ontwikkelen. Een oplossing waarbij er niet alleen goed is gebouwd, maar waarbij vooral het goede is gebouwd.
Basile Lemaire, managing partner Blue Bricks Acceptatie Management
Ik beschouw het model als een goede invulling van prince2 project assurance, waarbij de opdrachtgever het risico op een verkeerd eind product beheerst. Wat ik niet begrijp uit het artikel is waarom dit een beheer topic zou zijn.
Beste Basile,
Kun je me uitleggen waarom je het woord ‘verander-management’ gebruikt en vervolgens geen aandacht geeft aan de menskant. Acceptatie van een ‘wezenlijke’verandering (waarmee ik bedoel: meer dan alleen het invoeren van een nieuw systeem) heeft in grote mate te maken met emotie. Dat vang je niet op met testcriteria, dat vang je op met het aantonen van de noodzaak, het betrekken van de juiste mensen, het realiseren van quick wins, het faciliteren van medewerkers om de verandering te kunnen uitvoeren etc.
Prince2 is (met alle goede eigenschappen die het heeft) voor mij zeker niet het eerste handvat dat bruikbaar is om verandermanagement echt te ondersteunen. John P Kotter (MIT) heeft 8 stappen geformuleerd voor een succesvolle verandering. De bovenstaande door mij genoemde voorbeelden zijn hier onderdeel van.
Met vriendelijke groet,
Michiel Croon
Getronics Consulting
Beste Michiel,
Het model leunt sterk op het managen van verwachtingen en daarmee op de ‘menskant’. Consistentie over de veranderketen betekent dat de verwachtingen in het “voor-traject” vertaald zijn in de uiteindelijk opgeleverde oplossing. Ik ben het zeker met je eens dat dat verder gaat dan louter de ICT-verandering.
Overigens ben ik van mening dat Prince2, Kotter’s 8 stappen en het AM-model elkaar zeker niet bijten. Robert Smit’s opmerking snijdt mijns inziens hout, en het AM-model kun je bijvoorbeeld toepassen om invulling te geven aan de stappen 1 en 3 van Kotter.
Met vriendelijke groet,
Basile