Case: Uitbesteding van het rekencentrum

Inhoudsopgave:

1. Case uitbesteden van het rekencentrum: Outsourcing van IT en ICT voorzieningen bij financiële instelling
2. Outsourcing van it en ict voorzieningen bij financiële instelling 
3. Service level management: een proces 
4. Inbedding van een demand organisatie vereist meer dan de exploitatie van it systemen 
5. Onderhandelen met de outsourcing aanbieder 
6. Kosten en opbrengsten van outsourcing
   
   

Case uitbesteden van het rekencentrum: Outsourcing van IT en ICT voorzieningen bij financiële instelling

De resultaten van een project beschrijven het project niet. Hooguit geven ze een indicatie van het wel of niet geslaagd zijn ervan, maar zelfs dat is twijfelachtig. Het kan zijn, immers, dat de resultaten pas bereikt werden na budgetoverschrijding en na herhaalde bijstelling van de planning.

Het is onze ervaring, dat ook evaluatierapporten en acceptatienota’s het project niet echt beschrijven. Als men daar aan toe is, is het werk achter de rug, zijn de nieuwe begrippen geaccepteerd en is er, in feite, al overeenstemming over het bereikte. Dat er moest worden gezocht naar de juiste methode, dat er managers en medewerkers moesten worden overtuigd, dat er instrumenten moesten worden ontwikkeld, plannen moesten worden herzien, deskundigheid moest worden ingehuurd – het doet na afloop van het project allemaal niet meer ter zake. Maar het is juist wel datgene dat maakt dat men uit de ervaring iets leert. Zie ook: De outsourcing ICT checklist.
 
Onze uitgangssituatie was er één waarbij in zowel een midrange als een mainframe omgeving enkele tientallen applicaties draaiden, die werden benut vanaf enkele duizenden werkstations. Het betrof een financiële instelling; de ICT applicaties hadden vooral betrekking op financiële transacties en vormden dan ook de basis voor primaire bedrijfsprocessen.
Bij de aanvang van het project waren de strategische beslissingen genomen. Zoals dat hoort (al is het lang niet overal het geval). Er was dus in grote lijnen al voldaan aan het gestelde in de bijdrage: ICT processen uitbesteden vereist een Demand Organisatie, namelijk, dat outsourcing moet worden ingebed in een weloverwogen ICT strategie. Er lag een strategienota, waarin voor outsourcing van de ICT voorzieningen gekozen was; er was geld vrijgemaakt voor het outsourcing project en er lag een ‘master plan’ waarin een route naar de toekomst, nadat outsourcing een feit zou zijn, werd beschreven, een toekomst die zou passen onder de noemer Demand Organisatie.

Service Level Management: een proces

Terugkijkend, is het belangrijkste dat we gedaan hebben: Het ontwerpen en implementeren van een proces dat we noemden: Service Level Management.

Niet zozeer een managementfunctie dus, maar een managementproces. Een proces dat vanuit de projectgroep werd opgezet en gecoördineerd, maar waarin overigens rollen waren weggelegd voor zowel de gebruikersomgeving als de ICT aanbieder bij wie de ICT voorzieningen zouden worden ondergebracht. Zo kreeg de gebruikersomgeving, en dus het business management, de verantwoordelijkheid voor het opstellen van een checklist van Service Level Requirements. De ICT aanbieder kreeg op zijn beurt opgelegd, de gerealiseerde service levels te meten en daarover ook te rapporteren.

Voorbereiding van de exploitatie tijdens het outsourcing project

Al doende zorgden we voor een voorbereid en georganiseerd management proces ten tijde van de exploitatie. Compleet met overlegstructuren en rapportagelijnen. Het is vooral in die zin dat we liever spreken over een managementproces dan over een functie, al bleken er binnen het proces wel functies te moeten worden benoemd. Een voorbeeld vormt het informatiesysteembeheer, een functie die voortaan niet vanuit de ICT maar vanuit de gebruikersomgeving moest worden ingevuld. Dat bleek in de praktijk van ons project nog moeilijk genoeg; hetgeen zorgde voor enige vertraging in het verankeren van het Service Level Management in de organisatie.

SLA ’s en andere afspraken om controle te behouden op outsourcing traject

Wat steeds weer opvalt bij een outsourcing project is dat de projectgroep zich nauwelijks bemoeit met de ICT applicaties. Waar het om gaat zijn afspraken over de applicaties en voorzieningen. Voor ons waren dat Service Level Agreements én afspraken (of zeg maar: procedures) binnen het kader van het Service Level Management. Deze laatste wordt expliciet genoemd, omdat de suggestie nog wel eens wordt gegeven dat als de SLA’s in orde zijn het allemaal wel goed komt, terwijl het toch minstens zo belangrijk is dat je ook afspraken maakt over de naleving daarvan en de organisatie (verantwoordelijkheden, rapportageverplichtingen etc.) daaromheen.

Op basis van de opgestelde Service Level Requirements hebben we een kleine twintig SLA’s opgesteld. We hebben daarbij onderscheid gemaakt tussen een generiek gedeelte (capaciteit, responsetijden etc.) en applicatiespecifieke SLA’s. Je krijgt zodoende een instrument dat zich ook in specifieke gevallen laat hanteren, zonder de greep op het geheel te verliezen. Zie ook: De gevolgen van slecht management bij offshore software ontwikkeling.

Inbedding van een Demand Organisatie vereist meer dan de exploitatie van IT systemen

Een outsourcing project dat betrekking heeft op infrastructurele ICT voorzieningen vormt in 99 van de 100 gevallen een eerste kennismaking van de organisatie met zoiets ingrijpends. Dat wil dan ook zeggen: er is niets geregeld. En dat wil weer zeggen dat het project zich niet kan beperken tot doelstellingen binnen het gedefinieerde domein, maar ook voorbereidingen moet treffen voor het institutionaliseren van de resultaten.

Dat gaat verder dan het voorbereiden van een situatie waarin de exploitatie van de ICT systemen wordt zeker gesteld. Dit kan men nog rekenen tot de ‘eerste lijn’ doelstellingen van het project. De exploitatieorganisatie moet echter ook worden ingebed in de organisatie, en dan nadert men de ‘tweedelijn’ doelstellingen.
Het is tegen deze achtergrond, dat in de bijdrage: Aanpak: Begeleiding en management van outsourcing trajecten nauwkeurig is beschreven welke management groeperingen bij het proces moeten worden betrokken. Als men wil voorkomen dat een outsourced ICT voorziening ‘losraakt’ van de organisatie, dienen verschillende geledingen van het management al in een vroeg stadium bij het project te worden betrokken.
Hieronder volgen enkele voorbeelden uit de praktijk van het onderhavige project:
 
Human Resource functie in de Demand Organisatie

Een voorbeeld vormde reeds de hierboven genoemde functie ‘informatiesysteembeheer’. Als zo’n functie er al is, zal hij beschreven zijn vanuit ICT gezichtspunten en in de beoogde situatie is dat nu juist niet gewenst.
Het is aan de projectgroep om een dergelijke functie opnieuw te definiëren, maar het is aan het HR management om hem te institutionaliseren. Zie ook: Integraal personeelsmanagement: Balans tussen productiviteit, klantgerichtheid en competentie personeel. Daarmee is een voorbeeld gegeven van projectactiviteiten die uiteindelijk projectoverschrijdend blijken. Zoals hierboven genoemd: de ‘tweede lijn’. Wat vanuit het eigen werkterrein van de projectgroep naar voren komt, dient een institutioneel vervolg te krijgen.

Inkoopfunctie in een Demand Organisatie

Een dergelijke grensoverschrijding bleek ook bij het werkgebied van de inkoop. Elke organisatie kent de functie inkoop, maar in een organisatie met een eigen ICT afdeling zijn de ICT inkopen anders gedefinieerd dan gewenst is nadat de ICT voorzieningen outsourced zijn. Het gaat er dan niet meer om dat de zaken worden ingekocht die de ICT afdeling bestelt; het gaat er om dat de leverancier van ICT diensten een georganiseerd inkoopmanagement tegenover zich krijgt.
Ook hier kan men ‘eerste lijn’ en ‘tweedelijn’ onderscheiden. Binnen het eigen werkgebied van de projectgroep vallen zaken zoals het opstellen van een producten/ diensten catalogus, SLA’s, offerte- en verplichtingenadministratie, leveranciersmanagement en dergelijke. Dat is de ‘eerste lijn’. Maar dit alles moet ook nog worden ingebed in wat ik maar het Concern Inkoop Beleid noem. De richtlijnen zijn er hoogstwaarschijnlijk al, maar het is niet zeker dat die richtlijnen onverkort kunnen worden toegepast. Niet onwaarschijnlijk is het dat de nieuwe ICT aanpak inkoopverantwoordelijkheden  en –functies met zich mee brengt die nog niet zijn gedefinieerd.

ICT beleid in een Demand Organisatie

Een positief te waarderen neveneffect van elk outsourcing traject is, dat de organisatie wordt gedwongen tot een gedetailleerde en precieze omschrijving van de voorzieningen, applicaties en processen waarop de outsourcing betrekking heeft.
Het is onze overtuiging dat de situatie die wij aantroffen geen uitzondering is. Elke grote organisatie die gedurende lange tijd in eigen beheer ICT applicaties heeft ontwikkeld heeft problemen met het beschrijven van wat er precies aan voorzieningen is. En toch moet dat gebeuren. Men kan geen Service Level Requirements, laat staan Agreements, opstellen zonder een beschrijving van het bestaande. En men kan geen effectief leveranciersmanagement voeren als niet heel precies bekend is waar de leverancier zich toe heeft verplicht.
In ons geval bleek dat er weliswaar een Applicatieatlas was, maar dat deze niet de actuele situatie weergaf. Bijwerken was dus nodig. Ook was er een Handboek ICT beleid, maar aangezien er een geheel nieuwe situatie zou ontstaan moest dit min of meer worden herschreven. Iets dergelijks gold voor de gewenste systeemarchitectuur. Daar werden al wel eisen aan gesteld, maar deze waren lang niet altijd expliciet. Naar de nieuwe leverancier moesten ze wel expliciet worden gemaakt, omdat ze zouden doorwerken in de verplichtingen die de leverancier zou aangaan. Nog weer een voorbeeld vormde de projectaanpak. Ons project zou tot gevolg hebben dat alle volgende ICT projecten, werkend met een externe leverancier, een wezenlijk andere, niet vanuit het aanbod maar vanuit de vraag gestuurde aanpak zouden moeten krijgen. Iets dat op institutioneel niveau moet worden bekrachtigd.

Al met al biedt een dergelijk traject een geweldige kans om de parameters op te schonen waar het ICT beleid van uit moet gaan. Dat hebben we dus ook gedaan. En dan weer zie je, dat de activiteiten binnen het eigen werkterrein hun vervolg moeten krijgen op institutioneel niveau. Het ICT beleid moet vanuit de nieuwe parameters opnieuw worden geformuleerd, iets dat ook buiten de projectgrenzen doorwerkt en dus door de organisatie als geheel moet worden opgepakt.

Onderhandelen met de outsourcing aanbieder

Je ziet het nauwelijks terug in de acceptatienota’s en evaluatieverslagen maar het is niettemin een wezenlijk aspect van elk outsourcing traject: onderhandelen met de aanbieder.
Zulke onderhandelingen beperken zich niet tot prijzen, leveringscondities en dergelijke. Zelfs blijven ze niet beperkt tot SLA’s en andere overeenkomsten. Het gaat verder.
In ons geval hadden wij ons verplicht, als klant, een Demand Organisatie op te bouwen. We mochten dus ook eisen van de aanbieder dat deze een, noem het maar ‘spiegelorganisatie’, zou creëren en dat dit voor ons verifieerbaar en controleerbaar zou zijn. Er zijn procedures nodig die aan beide kanten worden nageleefd. Wie spreekt met wie en waarover? Wat is de opvolging als uit benchmarks blijkt dat niet alles marktconform verloopt? Onderwerpen te over dus en het is voor de klant uitermate belangrijk dat degene die de onderhandelingen voert ervaring meebrengt en weet welke onderwerpen prioriteit hebben.

Kosten en opbrengsten van outsourcing

Het is wellicht goed om, aan het slot van dit betoog, een indruk te geven van de omvang van een project zoals dat hier is beschreven. Kort en goed: de looptijd van het project was ongeveer een jaar en de kosten die ermee gemoeid waren bedroegen ongeveer drie miljoen euro.
Een andere, minstens zo relevante indicatie is deze: er waren ca. honderd mensen betrokken bij de reorganisatie. Zij kregen nieuwe functies. Zij moesten worden opgeleid om in die nieuwe functies te kunnen voldoen. Een flink aantal van hen verhuisde zelfs naar de aanbieder.

Met andere woorden: outsourcing is in tijd en geld kostbaar. Voor men er aan begint zal op strategisch niveau moeten zijn vastgesteld of het alternatief dat outsourcing biedt verantwoord is.
In ons geval zouden de projectkosten worden terugverdiend via besparingen op de ICT exploitatie, maar belangrijker was dat er winst kon worden geboekt waar het ging om bedrijfszekerheid en toekomstbestendigheid. Aangezien het hier ging om ICT voorzieningen die essentieel waren voor de primaire bedrijfsprocessen, lag dáár het voornaamste argument om tot outsourcing van ICT over te gaan.

Bij vragen of interesse kunt u contact opnemen via het reactieformulier.