Dé aanpak voor ICT-strategie bestaat niet. ICT-volwassenheid, externe druk en ambitie zijn de bepalende factoren om situatie-afhankelijk een eigen aanpak te kiezen. In figuur 3 hebben wij dit schematisch weergegeven.
Wij hebben vijf ideaaltypische aanpakken onderkend, namelijk:
Maar hoe kies je een op jouw situatie toegesneden aanpak en hoe weet je of je de juiste keuze maakt? Kortom, zijn er instrumenten die kunnen helpen om deze keuze te maken? Jazeker, hiervoor is instrumentarium beschikbaar. Als dat zo is, ligt de volgende vraag in het verschiet: hoe pak je het dan aan? Opnieuw een roep om instrumenten. Instrumenten om van idee tot strategie te komen, met als resultaten bedrijfsprocesmodellen, architecturen en migratieplannen, want die bieden de communicatieve mogelijkheden, het overzicht en het inzicht om beslissingen te ondersteunen en te onderbouwen. En zo bieden de instrumenten als het ware de lego bouwstenen die samen gestapeld worden tot een goed en geschikt ICT-strategiehuis. Toegesneden op de vraag van de specifieke organisatie, haar bestuurders en (ICT-)managers.
Elke ideaaltypische aanpak is een situatiespecifieke inkleuring van het generieke stappenplan voor ICT-strategie. Het generieke plan omvat vier stappen, te weten:
De knelpuntgerichte aanpak vraagt om een andere focus en dus instrumentarium dan bijvoorbeeld de breakthrough-aanpak.
Voor elke stap bestaan er instrumenten die helpen om de ontwikkeling van een ICT-strategie “handen en voeten” te geven. De dominante activiteiten in elk van de vijf ideaaltypische aanpakken bepalen welke instrumenten per aanpak de voorkeur genieten. Elk instrument levert één of meer bouwstenen op voor het eindresultaat: een ICT-strategie klaar voor realisatie.
Er zijn verschillende modellen in de omloop die betrekking hebben op ICT-governance. Wij hebben deze modellen geordend naar strategie en operatie en focus op risico of op effectiviteit.
Een model dat strategisch ingezet wordt om risico’s op het gebied van ICT te bewaken is CobiT. Het is bij uitstek geschikt om aan te tonen of je voldoet aan de strikte wet- en regelgeving zoals bijvoorbeeld door Sarbanes-Oxley(SOX) en COSO (Committee of Sponsoring Organizations of the Treadway Commission) worden gevraagd. Het is een omvangrijke set van 318 beheersdoelstellingen, die zijn gerangschikt naar vier beheerdomeinen:
Weill en Ross [2005] constateren op basis van hun onderzoek "Effective ICT governance is the single most important predictor of the value an organization generates from ICT".
De drie componenten die met elkaar zorgen voor een effectieve ICT-governance zijn:
Bij de welke-vraag gaat het over afgebakende terreinen. In de praktijk zijn dat vijf domeinen. In tabel 10 staan deze vijf weergegeven.
De wie-vraag gaat over wie beslissingen mag nemen en wie daarover mag meepraten. Waar ligt de eindverantwoordelijkheid bij het inzetten van methoden, mensen en middelen? De governance rules gaan dan bijvoorbeeld over de wijze waarop prioriteiten worden gesteld, de aanschaf van hard- en software, de inhuur van mensen of diensten, beveiliging, budgetvaststelling of -doorbelasting.
Bij de hoe-vraag gaat het over de manier waarop een beslissing wordt genomen. Daarbij kunnen verschillende besluitvormingsmechanismen worden onderscheiden. In de onderstaande tabel staan de verschillende governance styles die Weill en Ross onderkennen aan de linkerkant. Aan de rechterkant staan de personen of units die mogen meebeslissen of meepraten. Het gaat erom dat je welbewuste keuzes maakt. In de matrix zijn drie best practices weergegeven.
Capability Maturity Model – integrated (CMMi) geeft de mate aan waarin de IT-processen beheerst en voorspelbaar lopen. Je zou kunnen zeggen dat dit ook een indicatie is van een mogelijk operationeel risico als je een te laag volwassenheidsnivau hebt.
Als we kijken naar de verschillende CMMi levels dan is het zo dat de meeste interne ICT-afdelingen tussen het niveau 1 en 2 hangen. Daar waar het belang van ICT meer is dan een soort infrastructurele voorziening is level 2 vereist. Level 3 zien we in Nederland vooral bij de organisaties die outsourcing als kernactiviteit hebben. Level 4 en 5 kom je in Nederland nauwelijks tegen. De level 5 ICT-organisaties kom je alleen maar tegen in landen als India.
De stap van level 1 naar level 2 is het meest lastig. Het is in feite een basis neerleggen waarop in de volgende levels doorgebouwd kan worden.
Bij elk level horen specifieke processen die ingericht en op orde horen te zijn. Level 2 kent de volgende processen:
Het doel van specificatiemanagement is het beheren van specificaties en inconsistenties tussen specificaties opsporen.
Projectplanning is het opstellen en onderhouden van een projectplan. In dat plan moeten zowel de activiteiten van de ontwikkelaars als die van de opdrachtgever en gebruikers betrokken worden. Een projectplan is een gezamenlijke activiteit van vraag en aanbod. De opdrachtgever en het management moet vooral aandacht geven aan de taken planning, communicatie en risicomanagement. De opdrachtgever moet meewerken aan het opstellen van de specificaties en moet tijd reserveren om de opgeleverde producten van de aanbodkant te integreren in de overige producten. Tevens het testen van de opgeleverde software in de beoogde omgeving, waarbij zoveel mogelijk echte gebruikers worden ingeschakeld.
Projectplanning is het opstellen en onderhouden van een projectplan. In dat plan moeten zowel de activiteiten van de ontwikkelaars als die van de opdrachtgever en gebruikers betrokken worden. Een projectplan moet tezamen met de offshore leverancier tot stand komen. Een projectplan gaat vaak heen en weer tussen de opdrachtgever en de offshore leverancier. De opdrachtgever en het management moet vooral aandacht geven aan de taken planning, communicatie en risicomanagement. De opdrachtgever moet meewerken aan het opstellen van de specificaties en moet tijd reserveren om de opgeleverde producten van de offshore leverancier te integreren in de overige producten. Tevens het testen van de opgeleverde software in de beoogde omgeving, waarbij zoveel mogelijk echte gebruikers worden ingeschakeld.
Een opdrachtgever stelt een overeenkomst op met een leverancier. Daarin moeten concrete werkafspraken worden opgenomen. Het is raadzaam deze afspraken in begrijpelijke termen te beschrijven. Daarnaast zijn juridische contracten vaak zinloos als ze rechtstreeks worden afgesloten met een onderneming in een offshore land. Sluit een overeenkomst af op basis van een vaste prijs, waarbij ook meerwerk alleen voor een vaste prijs wordt toegelaten. Regel de wijze waarop met de offshore leverancier wordt gecommuniceerd goed en regel wie waarvoor verantwoordelijk is. Beschrijf de processen (of hoe die processen tijdens het project worden gedefinieerd) en regel heel precies productintegratie, sub contracting en aankoop van componenten.
Het doel van Configuratie Management is ervoor te zorgen dat de integriteit van het product blijft gewaarborgd. In veel organisaties wordt het ‘versiemanagement’ genoemd. Een leverancier die zijn sources niet onder versiebeheer heeft is geen goede leverancier. Het is één van de lakmoesproeven! De opdrachtgever is volgens CMMi verantwoordelijk voor het configuratie management in eigen bedrijf. De leverancier is alleen verantwoordelijk voor het deel dat wordt gebouwd.
De opdrachtgever moet het configuratiebeheer regelen van bijvoorbeeld: specificaties, ontwerpwijzigingen, interface specificaties, testplannen/testprocedures, testdata, risicomanagement, issues en issuelijst etc.
Het doel van servicelevering is het beoordelen van de service level agreements, het basis daarvan voorbereiden van de service delivery (service delivery plan), het leveren van de dienst wat inhoudt zorgen voor beschikbaarheid, binnen de afspraken oplossen van incidenten, het afhandelen van serviceverzoeken.
Het doel van dit procesgebied is: de kwaliteit van processen en producten waarborgen. Er moeten objectieve, duidelijke criteria worden aangelegd, zoals: vragen binnen een werkdag beantwoorden, wekelijks de status van alle issues controleren, veranderingen alleen doorvoeren met goedkeuring van de projectleider, van testresultaten altijd een issue maken, het opleverprotocol definieert de aanvullingen en wijzigingen, gebruikers mogen pas software testen nadat het projectteam de software heeft geverifieerd en gevalideerd, etc. Het is de taak van iedereen speciaal de projectleider om te controleren of aan de criteria wordt voldaan.
Meten en analyse op CMMi niveau 2 hebben tot doel dat er een meetsysteem word ontwikkeld dat het management informatie verschaft. Op CMMi niveau 4 en 5 worden deze getallen gebruikt om voorspellingen te doen en om de kwaliteit van processen in de organisatie te meten. Op niveau 2 van CMMi wordt de informatie per project verzameld en geanalyseerd. Het is van belang zo spoedig mogelijk te beginnen met meten. Immers, op het moment dat een organisatie klaar is voor niveau 4 moeten er ook historische gegevens beschikbaar zijn. Het allerbeste is dat de meetmethode uitgaat van data die in het kader van een goede projectuitvoering toch worden geproduceerd, zoals urenverantwoording, issuelijst, sources, e-mails en resterende speling.
Met de ICT-opportunityscan krijg je duidelijk welke risico’s je als organisatie wilt nemen met nieuwe technologieën. Nieuwe inzichten en innoverende ICT-toepassingen beïnvloeden op één of andere manier de bedrijfsvoering en de inrichting van iedere organisatie. Daarnaast gaan de ontwikkelingen snel en verschuiven in de tijd. Daarom is het ook nodig om regelmatig een ICT-opportunityscan uit te voeren.
Tijdens de ICT-opportunityscan worden de volgende vragen beantwoord:
Als per relevante technologie alle vragen zijn beantwoord, ontstaat er een risicoprofiel van bestaande trends.
Alle innovatieve technologieën worden op een rij gezet. Informatie over de relevantie van die ontwikkelingen is te vinden bij publicaties in bekende vakbladen en bij gerenommeerde onderzoeksbureaus. Daarnaast kan een innovatieworkshop inspiratie geven voor toepassingen van nieuwe technologieën binnen de organisatie. Het doel van een innovatieworkshop is de ICT innovaties herkennen en vertalen naar bruikbare en werkbare toepassingen voor de eigen organisatie. Onderwerpen die hierbij de revue kunnen passeren, zijn bijvoorbeeld Gamification, BYOD, Big Data, Quantified self, e-Health, Augmented Reality, Virtual Reality en Cloud Computing. Door het beeldend maken van deze nieuwe technologieën en de vertaling te maken naar de branche en/of bedrijf, komen er concrete ideeën voor innovatie uit voort.
Daarna wordt gekeken naar de marktrijpheid van de technologie.
Een technologie bevindt zich (nog) in het onderzoeksstadium als de volgende vraag positief wordt beantwoord:
Om na te kunnen gaan of een technologie volwassen is, dienen de volgende vragen bevestigend te worden beantwoord:
Een technologie is marktrijp als op alle voorgaande vragen bevestigend is geantwoord. Dit betekent namelijk dat het gaat om een volwassen technologie waarin geïnvesteerd wordt.
Op basis van de antwoorden op de vragen kunnen de technologieën in een matrix worden geplaatst. Afhankelijk van het risico dat een organisatie wil lopen, kan gekozen worden voor zekerheid of voor het investeren in een nog niet marktrijpe technologie.
Een organisatie die accepteert dat bijvoorbeeld Virtual Reality nog niet "volwassen" is, maar hiervoor wel veel kansen ziet, kan besluiten het risico bewust te nemen.
Een IT audit is een doorlichting van de IT binnen een organisatie. Hierbij zitten zowel ‘harde’ als ‘zachte’ aspecten. Onder andere de ICT-processen en de ICT-kosten worden hierbij doorgelicht. Het doen van een IT audit heeft een vast patroon en er zijn verschillende instrumenten die dit kunnen ondersteunen.
Bij een IT-audit worden vijf stappen doorlopen, zoals getoond in figuur Risicoprofiel van trends hierboven.
Als eerste is het van belang om de norm te bepalen waarop je gaat toetsen. Wanneer is het goed genoeg? Soms liggen de normen vast in de vorm van een gedragen strategisch plan, soms moet er snel een soort kader opgesteld worden.
De processtap Meten is de kern van het onderzoek. Deze processtap bestaat onder andere uit
Er zijn verschillende instrumenten beschikbaar om te meten aan de IT zoals CMMI, bITa enquête, TCO en ServQual.
Bij het verifiëren worden de feitelijk gevonden gegevens getoetst. Hier wordt dus nog geen waardeoordeel uitgesproken over de gevonden resultaten.
Op basis van de feitelijk gevonden gegevens, de gestelde norm en onze kennis en ervaring wordt een expertoordeel over de situatie gevormd. Deze stap is een logische redenering op basis van de geconstateerde feiten.
Ten slotte worden de resultaten samen gebundeld in een rapportage.
Het uitvoeren van een CMM-(Capability Maturity Model)-assessment heeft tot doel om de volwassenheid van systeemontwikkelingsprocessen te kunnen beoordelen en op basis daarvan deze processen te kunnen verbeteren. Dit verbeteren gebeurt door het geleidelijk invoeren van fundamentele processen (de zogenaamde key-process areas) die het systeemontwikkelingsproces stap voor stap verbeteren. Het model kent een vijftal volwassenheidsniveaus. Ieder niveau kent zijn specifieke key-process areas. Zo evolueert het proces van niveau 1 “Intitial”, via 2 “Repeatable”, 3 “Defined” en 4 “Managed” tot niveau 5 “Optimizing”. Het volgen van deze weg is er uiteindelijk op gericht een betere voorspelbaarheid en grotere effectiviteit van het systeemontwikkelingsproces te realiseren. Hierbij geldt: hoe hoger het CMM-niveau, hoe hoger de mate van volwassenheid.
Om het CMM-niveau te kunnen meten, beschrijven wij hieronder de kenmerken van de vijf niveaus. Daarna schetsen wij in een schema per niveau de key-process areas die gebruikt kunnen worden om een niveau scherper te kunnen definiëren.
Als we kijken naar de verschillende CMMi levels dan is het zo dat de meeste interne ICT-afdelingen tussen het niveau 1 en 2 hangen. Daar waar het belang van ICT meer is dan een soort infrastructurele voorziening is level 2 vereist. Level 3 zien we in Nederland vooral bij de organisaties die outsourcing als kernactiviteit hebben. Level 4 en 5 kom je in Nederland nauwelijks tegen. De level 5 ICT-organisaties kom je alleen maar tegen in landen als India.
bITa staat voor Business IT Alignment. Hieronder verstaan we de best mogelijke inzet van mensen en middelen voor de ondernemingsdoelstellingen. Het is een kwalitatieve meting die zes aspecten meet die relevant zijn voor de alignment. Deze meting is gebaseerd op onderzoek van Luftman “Computering in the information age” 2003.
De volgende aspecten worden onderscheiden:
Deze aspecten worden gemeten aan de hand van een vijftal positief geformuleerde stellingen waar op een vijfpuntschaal gescoord kan worden:
Het resultaat kan uitgezet worden in een spindiagram.
Voor meer informatie over de bITa enquete, kijk hier. Voor het afnemen van de bITa enquete, kijk op onze website.
In de Total Cost of Ownership (TCO) meting, worden de kosten gemeten van de IT-organisatie in vergelijking met het gemiddelde uit de branche. Hiervoor wordt gebruik gemaakt van benchmarkgegevens van Gartner en FACANA onze eigen benchmarkset.
Het uitgangspunt van ServQual is dat kwaliteit van de dienstverlening gedefinieerd kan worden als het verschil tussen verwachtingen en de realiteit. Het kwaliteitsoordeel komt dan tot uiting in het verschil tussen datgene wat men van de dienst verwacht en datgene wat men daadwerkelijk heeft ervaren heeft. Hierbij moet de subjectieve perceptie van de klant centraal staan.
In het ServQual model is kwaliteit het verschil tussen verwachting en ervaring van de geleverde dienst. Kwaliteit = service verwachting - service perceptie. Die formulering van kwaliteit laat zien dat het verschil tussen verwachting en perceptie de feitelijke kwaliteitservaring behelst. Dit verschil wordt onder andere gevormd door persoons- en nietpersoongebonden factoren. Door de aanwezigheid van verschillende factoren komen er ook verschillende kloven tussen de verwachting en de ervaring. Het model identificeert in totaal 5 kloven, wat verder genoemd wordt als ‘gaps’.
De gaps zijn:
De gap die in de kwaliteitsbeleving van consumenten leidt tot de grootste kloof is gap 5. Dit is het verschil tussen de verwachting en de ervaring van de geleverde dienst.
Portfoliomanagement gaat over het beheren van het totaal aan systemen (de applicatieportfolio) en projecten (de projectenportfolio). Met een ‘gezonde’ portfolio kan beter aan de behoeften worden beantwoord, kunnen onderhoudskosten worden verminderd, en kan gemakkelijker worden ingespeeld op de veranderende eisen. Een gezonde portfolio ontstaat door gericht te investeren in bestaande systemen en waar mogelijk oude systemen op te ruimen. Op die manier wordt het voor managers, die wat meer op afstand staan, gemakkelijker om de juiste prioriteiten te stellen.
Voor ICT-projectportfoliomanagement zijn verschillende modellen in de omloop. Ze zijn gericht op verbetering van de kwaliteit, bijvoorbeeld op:
Kersten en Verhoef benadrukken het belang van portfoliomanagement in ICT portfoliomanagement, a Bankers Perspective on ICT (2003, pg 30).
“The greatest challenge lies in software portfolio management. Management and development costs are extremely high, diversity is huge, and many of the complex investment decisions taken by managers concern investments in software. We firmly believe that this is the main area in which successes can be achieved in the coming years with a good portfolio approach.”
Om inzicht te krijgen in de applicatieportfolio ordent Bedell (1985) de systemen op twee assen: kwaliteit en belang. Deze assen zijn het resultaat van het optellen van twee andere matrices:
De kwaliteit van systemen wordt naar twee dimensies in kaart gebracht. Vanuit de dimensie ‘gebruik’ wordt gekeken naar de kwaliteit vanuit het perspectief van de gebruiker. De gebruikers van het systeem wordt gevraagd een oordeel te geven over:
gebruik van de informatie:
controleerbaarheid, gebruik van het systeem:
Vanuit de dimensie ‘beheer’ wordt gekeken naar de kwaliteit vanuit het perspectief van de ICT-discipline. Beheerders wordt gevraagd om de systemen te toetsen aan de hand van de volgende criteria:
Het belang van systemen wordt ook naar twee dimensies in kaart gebracht. Het strategische belang heeft te maken met het onderscheidende vermogen van het systeem in de totale dienstverlening van de onderneming en kan alleen beoordeeld worden door het management. Het operationele belang heeft betrekking op de mate waarin het systeem belangrijk is voor het uitvoeren van de dagelijkse operaties. Denk hierbij aan de consequenties voor de bedrijfsvoering als het systeem uitvalt.
Uiteindelijk wordt duidelijk in welke systemen geïnvesteerd moet worden (hoog belang, lage kwaliteit), welke systemen gezond zijn (hoog belang, hoge kwaliteit), in welke systemen voorlopig niet geïnvesteerd hoeft te worden (hoge kwaliteit, laag belang) en welke systemen genegeerd of met een minimale inspanning vervangen moeten worden (laag belang, lage kwaliteit).
Het zou nog mooier zijn als de systemen met hun kwalificatie gerelateerd worden aan het primaire proces. Dan is goed te zien waar de risico’s liggen en waar volstaan kan worden met passief onderhoud van de systemen.
Om het draagvlak bij het beoordelen van systemen te vergroten is het aan te bevelen er veel verschillende disciplines bij te betrekken. Met een elektronische enquête kan een grote groep bereikt worden, maar het blijft belangrijk om in een workshop nog eens gezamenlijk de resultaten te bespreken, aangezien de resultaten van de digitale enquête dikwijls nuancering behoeven.
