Willem Sprink stelt dat "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."
Volgens Sprink leveren IT-(vernieuwings)projecten vaak niet op waar een organisatie behoefte aan heeft. Hij onderkent hiervoor een vierledige oorzaak (het ontbreken van een duidelijke scope, vage requirements, een slechte afstemming over (on)mogelijkheden en onvoldoende monitoring tijdens de bouw van het systeem) en pleit voor een integrale procesgerichte aanpak voor IT-projecten bestaande uit vier stappen:
-
Baken de scope af.
-
Match proces met IT-systeem.
-
Maak programma van eisen.
-
Monitor tijdens de bouw.
(1) Baken de scope af
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.
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. 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.
-
Besturingsprocessen: alle activiteiten die richting of sturing geven aan primaire en ondersteunende processen.
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.
(...)
(2) Match proces met IT-systeem
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.
(...)
(3) Maak programma van eisen
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.
(...)
(4) Monitor tijdens de bouw
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 directzijn gekoppeld aan specifieke activiteiten in de processen. Een voorbeeld van een eis is: "Bij activiteit x: Het kunnen opvragen van een totaaloverzicht van aanvragen, met onderscheid naar type aanvraag, status en ontvangstdatum".
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.
(...)
