Vernieuwen IT-systeem  kansloos zonder excellente proceskennis 

Upgraden en vernieuwen van bestaande systemen zijn taken die in de regel zijn belegd bij de IT-afdeling (bijvoorbeeld bij het duo van de functioneel beheerder en applicatiebeheerder) in samenspraak met de IT-leverancier. Doorgaans een logische keuze; niemand weet zoveel van een IT-systeem als een  IT-er. Onderzoeken (Standish Group, Ernst & Young) tonen echter aan dat de meeste IT-projecten niet slagen. Het systeem ondersteunt uiteindelijk niet goed of mist functionaliteiten die cruciaal zijn voor de organisatie. Wat kan een organisatie doen om te voorkomen dat een grondige projectmatige vernieuwing mislukt?  

Van IT-ers  kan niet worden verwacht dat zij een grondige herbezinning doen van de organisatie. Het management zelf moet het voortouw nemen. Met behulp van excellente proceskennis wordt de basis gelegd voor een IT-systeem dat niets te wensen over laat en dat  echt aansluit bij de behoefte van de organisatie. 

Inleiding 

Veel organisaties hebben op een bepaald moment in het verleden de keuze gemaakt om een systeem te implementeren dat op dat moment voorzag in de behoefte aan ondersteuning. Indien goed uitgerold is op dat moment rekening gehouden met de strategische koers van de organisatie. Maar inzichten veranderen, methoden en technieken veranderen, marktvragen veranderen, de maatschappij verandert en als resultante hiervan de organisatie zelf ook. Voor al deze veranderingen wordt gaandeweg op ad hoc basis delen van het systeem geüpdatet. Het patroon dat zich dan aftekent is een soort lappendeken aan functionaliteiten:  

• Een aantal functionaliteiten voorzien in een inmiddels vergeten behoefte 

• Een aantal functionaliteiten zijn goed bedacht en gebouwd maar nooit goed geïmplementeerd 

• Weer andere functionaliteiten zijn prachtig bedacht maar schieten hun doel voorbij door een overdaad aan mogelijkheden 

• Tenslotte zijn er ook functionaliteiten die nog steeds buiten het systeem om worden geregeld (de ‘excel- of access-oplossing’) 

De doorontwikkeling van een IT-systeem lijkt daarmee veel op een ongestructureerde puzzel. De puzzel groeit door, één stukje per keer. Het totaalontwerp van de puzzel (in het gewone leven te vinden op de deksel van de doos) is inmiddels kwijt. Sterker nog, het is soms niet eens duidelijk of de aangebouwde stukjes nog wel bij de puzzel horen. 

Een vaak voorkomend patroon is dat binnen de organisatie de IT-afdeling de opdracht krijgt om het systeem ‘te vernieuwen’. Wat volgt is een beknopte opdracht van twee A4-tjes met algemene doelstellingen waarmee de IT-er aan de slag moet. Vaak ontbreken inhoudelijke sturing, concrete input voor de IT-leverancier en heldere, gedeelde verwachtingen van de resultaten van het project. De uitkomst kan dan niet anders zijn dan dat je gaandeweg de bouw erachter komt dat het project uit gaat draaien op een teleurstelling.  De vermeende vuistregel 2:2:1/2 gaat dan weer op; IT-projecten duren 2x zo lang als gepland, kosten 2x zo veel als gebudgetteerd en leveren de helft op van wat werd verwacht  

_{Figuur 1: integrale procesgerichte aanpak voor IT-projecten} 

In dit artikel wordt ingegaan op een procesgerichte aanpak waarmee in vier integrale stappen een IT-(vernieuwings)project in goede banen wordt geleid. Daarbij is doorlopend aandacht voor het wegnemen van oorzaak voor het falen van IT-projecten de sleutel tot succes.  

Stap 1: Minimaliseer koerswijzigingen door heldere scope-afbakening 

Een van de belangrijkste oorzaken voor het falen van IT-projecten is dat gaandeweg de bouw van het nieuwe systeem het project van koers moet veranderen (met meerkosten en een langere doorlooptijd tot gevolg). Halverwege het project besluiten dat het toch “allemaal even anders moet” is probleem nummer 1 en leidt onder meer bij de overheid tot problemen bij de bouw van IT-systemen. De eerste stap van een succesvolle systeemvernieuwing is het bepalen van de duidelijke scope van het te vernieuwen IT-systeem. Dit door allereerst te bepalen in welke processen het IT-systeem een rol moet gaan spelen. Om in de analogie van de puzzel te blijven: leg de kantstukjes. Tegelijkertijd ontstaat er een eerste beeld van de hoeveelheid stukjes waaruit de puzzel moet bestaan. 

Veel organisaties hebben niet meer scherp voor ogen hoe hun eigen ‘puzzel’ eruit ziet en zijn de kantstukjes al tijden kwijt (in de stofzuiger des tijds). Bosman, Schijff en van de Vliert pleiten in hun White Paper “Vergroot innovatievermogen met BPM” voor gebruik van het INK-model als vertrekpunt voor het opnieuw afbakenen van de scope van de te herontwerpen werkprocessen. Hierbij worden eerst de behoeften van de belanghebbenden (de klant, de eigen medewerkers, het bestuur/financiers en de maatschappij) bepaald, waarna de strategie en het beleid van de organisatie wordt toegespitst op deze belangen.  

Aan de hand van de strategie en het beleid van de organisatie kunnen vervolgens alle processen worden geïdentificeerd. Hiervoor bestaat een succesvolle methode: het ontwerpen van het bedrijfsprocesmodel. Dit is een overzicht waarin de gehele organisatie is gevat in een totaalverzameling van processen (zie figuur 1). Omdat de organisatie meer activiteiten verricht dan alleen het voortbrengen van een product of dienst, wordt hierbij een onderscheid gemaakt in: 

• Primaire processen: alle activiteiten die direct een product of dienst voortbrengen 

• Ondersteunende processen: de activiteiten die het primaire proces faciliteren/ondersteunen 

• Besturende processen: alle activiteiten die richting of sturing geven aan primaire en ondersteunende processen.
  

_{Figuur 2: Het bedrijfsprocesmodel als rand van de puzzel} 

Het te bouwen IT-systeem speelt een cruciale rol in de informatie-uitwisseling tussen de verschillende geëxpliciteerde processen. Door het bedrijfsprocesmodel is de totale afbakening van de organisatie vormgegeven (in de analogie van de puzzel is de rand gelegd). Is een proces niet geïdentificeerd, dan draagt het ook niet bij aan de doelen van de organisatie. 

Stap 2: Maak de expliciete match van proces met IT 

Een tweede belangrijke oorzaak voor het falen van een IT-project is, dat er te weinig expliciet gemaakt is wat het IT-systeem precies moet kunnen, op welk moment, en voor wie, voor wat en met welke gegevens. De tweede succesfactor is daarom het (her)ontwerpen van elk van de processen uit het bedrijfsprocesmodel en, als afgeleide daarvan, het bepalen van de ideale systeemondersteuning. Het gaat hier om het bepalen van de globale indeling van de puzzel; wordt het een landschap, of toch een stadsbeeld?  

Om de overstap te kunnen maken van een totaaloverzicht van processen naar de invulling van een specifiek proces, kan de Quality Function Deployment Methode (QFD) gebruikt worden. In deze methode worden klantwensen en eisen omgezet in ontwerpeisen voor specifieke processen.  Resultaat is een matrix (zie figuur 2: Het Kwaliteitshuis) waarin de relatie inzichtelijk is gemaakt tussen klantwensen en de processen  in de organisatie.  Met dit inzicht kan op het niveau van individuele processen worden doorgelicht,  verbeterd en geïnnoveerd.  

Figuur 2: Het kwaliteitshuis 

Kroon en Van de Vliert bieden een integrale aanpak om  elk ideale (deel)proces te ontwerpen en vervolgens zorgvuldig te koppelen aan de ondersteunende IT-systemen. Vertrekpunt daarbij is het herontwerpen van elk werkproces in de vorm van een functiestroomschema. Hierin wordt concreet benoemd welke activiteiten idealiter worden uitgevoerd, wie dit doet, welke berichten (input en output van elke activiteit) worden uitgewisseld en welke tijdskaders er aan de orde zijn. Dit functiestroomschema wordt vervolgens uitgebreid met een extra stroom: de ideale IT-ondersteuning. Daarmee ontstaat een geïntegreerd ontwerp van de twee werelden van de ‘business’ en de IT en is een gezamenlijke taal voor verdere samenwerking tot stand gekomen. 

Sidestep: 4 tips bij het maken van een goede proces-IT match 

• Herontwerp de processen vanuit de strategie en beleid van de organisatie (zie ook stap 1). Hierdoor kennen de processen een optimale samenhang en zijn ze klantgericht, waarde toevoegend en toekomstbestendig.  

• Laat de medewerkers zelf hun processen herontwerpen. Zij zijn straks immers ook de gebruikers van het systeem als afgeleide van hun eigen ideale werkproces. Als zij de oplossing bedenken, zullen zij deze ook eerder accepteren. 

• Laat je inspireren vanuit ontwikkelingen in de IT. Was er in het oude systeem al rekening gehouden met alle voordelen die zaken als internetformulieren, smartphones, tablets, bluetooth printers, pocket-beamers, social media, en verbeterde programmeertechnieken kunnen bieden? 

Stel kritische vragen bij het definiëren van de interacties met het ondersteunende IT-systeem. Is er een gegronde business-overweging voor deze interactie? Is dit wat de organisatie echt nodig heeft? Wordt het straks niet te moeilijk/ingewikkeld? 

Stap 3: Verstrek een heldere opdracht aan de IT-leverancier  

In stap 1 en 2 is de organisatie zelf nog de puzzelaar in het project. Pas in de derde stap komt de tweede puzzelaar, de IT-leverancier, in beeld. Een derde belangrijke oorzaak voor het falen van IT-projecten is namelijk dat er onvoldoende wordt afgestemd tussen organisatie en IT-leverancier over de haalbaarheid van de beschreven wensen. Het is de verantwoordelijkheid van de organisatie zelf om zo precies mogelijk te definiëren wat de IT-leverancier moet gaan bouwen en opleveren. In de vorige stap is de interactie tussen proces en systeem al gedefinieerd; nu moet met behulp van de proces-IT interactie zo specifiek mogelijk worden aangegeven wat er verwacht wordt van het op te leveren IT-systeem. In termen van de puzzel worden hier alle losse puzzelstukjes zo concreet mogelijk gedefinieerd in de vorm van een totaallijst van wensen en eisen, die direct zijn gekoppeld aan specifieke activiteiten in de processen. Een voorbeeld van een eis is: 

“Bij activiteit 3.2: Het kunnen opvragen van een  totaaloverzicht van aanvragen, met onderscheid naar type aanvraag, status en ontvangstdatum” 

Om de invulling van alle eisen goed te kunnen bespreken met de IT-leverancier, biedt de MoSCoW-systematiek meer houvast. MoSCoW is een acroniem dat staat voor:  

• Must have – deze eis moet in het eindresultaat terugkomen;  

• Should have – deze eis is zeer gewenst;  

• Could have – deze eis mag alleen aan bod komen als er tijd genoeg is, en  

• Would like to have/Won’t have – deze eis zal nu niet aan bod komen maar kan in de toekomst interessant zijn (wens)  

Door samen met de IT-leverancier alle (beschreven) wensen en eisen langs te lopen, kunnen een aantal zaken gestructureerd worden vastgesteld: 

• welke prioriteit elke eis heeft 

• hoe er tegemoet wordt gekomen aan de beschreven wensen en eisen 

• welke eisen om een verdere verkenning van de organisatie of leverancier vragen 

• of het proces nog moet worden aangescherpt op basis van aangedragen alternatieven 

Op eisniveau wordt daarmee afgestemd over de (on)mogelijkheden, verwachtingen en het belang van elke eis voor de organisatie. Hierdoor ontstaat een duidelijk, realistisch en vooral gedeeld beeld van het systeem dat moet worden gebouwd. Ook heeft de IT-leverancier hierdoor de mogelijkheid om terug te koppelen wat lastige eisen zijn (wat dus kostbaar is om te bouwen), of welke eisen niet of later aan bod zullen komen. Het resultaat van deze afstemming is de blauwdruk voor het nieuwe systeem, in de vorm van te  bouwen eisen en gemaakte opmerkingen, nuanceringen en afbakeningen. In termen van de puzzel is dit de deksel van de doos. De deksel is immers de houvast voor elke puzzelaar; hierop staat wat het eindresultaat van het bouwproces moet zijn.  

Stap 4: Door goede monitoring geen afwijking tijdens de bouwfase    

Nu de deksel van de puzzel is gedefinieerd in afstemming met de IT-leverancier, kan gestart worden met de bouwfase. De puzzel is bekend, de rand ligt er al en alle stukjes zijn in gezamenlijkheid besproken. Nu ligt de bal bij de IT-leverancier om te bouwen wat is afgesproken. In voortgangsoverleggen gedurende de bouw van het nieuwe systeem kan de IT-leverancier in workshops terugkoppelen hoever er is gevorderd met de bouw van het systeem. Daarbij biedt de blauwdruk (de deksel) met daarin de achterliggende eisen (de stukjes) een concreet kader voor bespreking. De IT-leverancier toont de voortgang, terwijl de organisatie kan afvinken welke eisen uit de blauwdruk zijn opgeleverd.  

Door een goede voortgangsmonitoring wordt voorkomen dat er tijdens de bouwfase onduidelijkheid gaat ontstaan over het op te leveren resultaat. Als er een bijstelling moet plaatsvinden, kan de organisatie vanuit het geïntegreerde procesontwerp een werkbare oplossing zoeken die de interne flow van werkzaamheden intact laat.  

Systeemvernieuwing? Gebruik excellente proceskennis    

IT-(vernieuwings)projecten leveren vaak niet op waar een organisatie behoefte aan heeft. Veel voorkomende oorzaken zijn het ontbreken van een duidelijke scope, vage requirements, een slechte afstemming over (on)mogelijkheden en onvoldoende monitoring tijdens de bouw van het systeem. Door het toepassen van bewezen technieken kunnen deze problemen worden voorkomen en kan een organisatie de voorwaarden creëren voor een succesvol IT-project. Hiervoor moet de organisatie haar scope vernieuwen en zich bewust zijn van de eigen verantwoordelijkheid in het scheppen van duidelijkheid over de eisen aan het IT-systeem als integraal onderdeel van elk procesontwerp. Want als de organisatie zelf niet goed weet wat zij nodig heeft, hoe moet de IT-leverancier dit dan wel weten? Daarom is het cruciaal om te weten dat de puzzel klopt; er is immers niets zo frustrerend als een ontbrekend stukje.