Risicobeheersing bij IT Splitsing & Integratie

Risicobeheersing bij IT Splitsing & Integratie

Deze scriptie is opgesteld door: PuYi Lin & Robert Brockhoff

Voorwoord

Voorwoord Binnen de publieke sector zien we de laatste jaren de trend waarbij steeds meer gemeenten gebruik gaan maken van een Shared Service Center (SSC). Omdat de opzet, inrichting en gebruik van een SSC voor iedere gemeente verschilt, zullen daarmee de doelen van het gebruikmakende gemeenten uiteenlopen. Een SSC kan hierbij tussen gemeenten of binnen een gemeente zijn. De eerste vorm zien we bij de kleinere gemeenten, waarbij tussen een aantal gemeentes, de gezamenlijke en gemeenschappelijke diensten worden gebundeld. De tweede vorm zien bij de grotere gemeenten, waarbij de verschillende uitvoerende diensten en deelgemeenten/ stadsgewesten hun gezamenlijke en gemeenschappelijke diensten bundelen. Met een dergelijke “samenwerking” kunnen alle deelnemende partij meer effectief en efficiënt werken en meer focussen op hun core-business. In deze scriptie zullen wij ingaan op de vorming van SSC’s, in het specifiek IT SSC’s, en hoe risicobeheersing plaats kan vinden aan de hand van een control framework. Hiermee hebben we onze scope beperkt tot het onderwerp dat goed aansluit bij de REopleiding aan de VU te Amsterdam. Hoewel de scope beperkt is wil dat nog niet zeggen dat de meeste zaken die worden beschreven niet gelden voor en bij de vorming van andere soorten SSC’s. Het tegendeel is waar, veel elementen en zaken zullen overeenkomen! Daarmee zullen de resultaten en hetgeen wat is beschreven ook goed te gebruiken zijn bij de vorming van andere SSC’s, met enig aanpassing. Voordat wij starten met de scriptie willen wij iedereen bedanken die ons hebben ondersteund tijdens het onderzoek en het opstellen van deze scriptie. Speciale dank willen wij uiten aan Rene Matthijsse, die de begeleiding vanuit de VU heeft verzorgd en onze vriendinnen Arinda Brinkman en Alicia Lee die ons gesteund hebben in het scriptieproces.

Amsterdam, april 2011.

Risicobeheersing bij IT Splitsing & Integratie -I-

Inhoud

Inhoud 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7

Inleiding Inleiding en aanleiding Onderwerp Vraagstelling Scope onderzoek Onderzoeksaanpak Begeleiding Opbouw scriptie

2 2.1 2.2 2.3 2.4 2.5 2.6

Theorie en literatuur Inleiding Domeinen IT landschap Shared Service Center Voor- en nadelen van Shared Services tussen organisaties Risicobeheersing Management vraagstukken

6 6 6 10 23 25 26

3 3.1 3.2 3.3 3.4

Case studies beschrijving Inleiding Drechtsteden Rotterdam Bevindingen en conclusies

30 30 30 34 40

4 4.1 4.2 4.3 4.4 4.5

Analyse van bevindingen en conclusies Model Proces Risicobeheersing Operations, Finance, HRM & IT Conclusies

45 45 45 46 46 46

5 5.1 5.2 5.3

Ontwikkeling van de IT Audit Framework Proceslaag Organisatielaag Samenvatting

47 48 53 54

6

Beantwoording onderzoeksvragen

55

7

Reflectie

57

2 2 2 3 3 3 4 5

Bijlage 1 – Literatuurlijst

58

Bijlage 2 – Interviews

59

Bijlage 3 – Vragenlijst

60

Risicobeheersing bij IT Splitsing & Integratie -1-

1 Inleiding

1

Inleiding

1.1

Inleiding en aanleiding

Gemeenten moeten steeds meer centrale taken uitvoeren, onder meer komen de basisregistraties en het overheidsloket er aan.1 Veel gemeenten hebben echter niet de capaciteit om deze veranderingen te managen.2 Daarom worden allerlei oplossingen gezocht, variërend van gemeentelijke fusies of samenwerking tot outsourcing of opzetten van een Shared Service Center.3 Hoewel het voorgaande met name voor de kleinere gemeentes geldt, speelt binnen de grote gemeente hetzelfde af. Bundelen van (algemene en ondersteunende) activiteiten zal op termijn grote kosten en efficiency voordelen moeten opleveren. Tussen gemeenten en binnen gemeenten wordt steeds meer samengewerkt. In verschillende samenwerkingsvormen zoals Dimpact en GovUnited hebben gemeenten zich verenigd voor het ontwikkelen van producten dan wel aanbesteden van software. Ook wordt veel samengewerkt met de verschillende afdelingen. Op belastinggebied bijvoorbeeld zijn verschillende samenwerkingsverbanden. Dit kan als voordeel kostenbesparing opleveren. Wanneer kleinere gemeenten gaan samenvoegen kan dit ook leiden tot de samenvoeging van de IT omgeving. Omdat al deze uitbestedingen van de IT omgeving risico’s met zich mee brengen is besloten hier nader onderzoek naar te doen. In de meeste gevallen wordt bij een samenwerking binnen of tussen gemeenten voor de gemeenschappelijk uit te voeren taken gekozen voor het opzetten van een Shared Service Center. Het opzetten en gebruik van Shared Service Centers zal door schaalvoordelen uiteindelijk resulteren in kostenreductie, bundeling van kennis en meer/ betere management control van de activiteiten.

1.2

Onderwerp

Ons onderzoek heeft zich gericht op de IT splitsing en integratie in de lokale overheid. IT splitsing en integratie vindt op twee niveaus plaatst: 1 Organisatorische IT splitsing en integratie: Hierbij gaat het om de splitsing en integratie van de IT organisatie. 2 Technische IT splitsing en integratie: Hierbij gaat het om de splitsing en integratie van de IT techniek/ landschap.

1

Voor veel overheden geen verschil tussen Outsourcing (BPO) en Shared Service Center (SSC), KPN, Den Haag (2010), 8p. 2 Voor veel overheden geen verschil tussen Outsourcing (BPO) en Shared Service Center (SSC), KPN, Den Haag (2010), 8p. 3 Voor veel overheden geen verschil tussen Outsourcing (BPO) en Shared Service Center (SSC), KPN, Den Haag (2010), 8p.


1 Inleiding

In de praktijk komt het nauwelijks voor bij het opzetten van een ICT SSC wordt gekozen voor èn een organisatorische IT splitsing en integratie èn een technische IT splitsing en organisatie. In de meeste gevallen vindt de organisatorische IT splitsing en integratie bij de opzet/ vorming van de ICT SSC plaats, terwijl de technische IT splitsing en integratie naderhand of ver nadat de ICT een feit is, aan de beurt. Hierbij dient opgemerkt te worden dat de meeste ICT (hardware en software) wel overgaat naar de ICT SSC in de “as is” vorm. Doel van het onderzoek was een control framework te ontwikkelen voor de risicobeheersing bij IT splitsing en integratie.

1.3

Vraagstelling

Centrale onderzoeksvraag:

Op welke wijze kan risicobeheersing invulling krijgen bij IT splitsing en integratie bij de vorming van ICT Shared Services, en kan een control framework hiervoor ontwikkeld worden vanuit het perspectief van IT Audit?

1.4

Scope onderzoek

Het onderzoek heeft zich beperkt tot het IT deel bij de vorming van (ICT) shared services binnen de lokale overheid. Bij de vorming van shared services, in de meeste gevallen via een Shared Service Center, is sprake van meerdere services. Te denken aan financiële services en human resources services. Afgezien van situaties waarbij de generieke zaken met betrekking tot shared services worden behandeld vielen de andere services buiten dit onderzoek. Tevens had het onderzoek niet tot doel een control framework te ontwikkelen die voor alle situaties geldt. Maar een generiek control framework die per situatie of bij toepassing gespecificeerd dient te worden naar de situatie. Wel bevat de control framework de essentiële elementen/zaken die in ieder geval zijn vereist.

1.5

Onderzoeksaanpak

Voor de beantwoording van de centrale onderzoeksvraag waren 3 deelvragen te onderscheiden: – Welke fasen en managementvraagstukken zijn in het proces te onderscheiden? (beschrijvend) – Welke risicogebieden horen daarbij? (analyserend) – Welke elementen moeten in het kader van risicobeheersing worden opgenomen in de control framework? (beschouwend) Risicobeheersing bij IT Splitsing & Integratie -3-

1 Inleiding

Het onderzoek bestond uit de volgende drie delen: 1 Literatuurstudie; 2 Case studie met interviews; 3 Documentatie in de vorm van een scriptie. Ad 1 Literatuur Het eerste deel van het onderzoek bestond uit het bestuderen van de relevante literatuur. Hierbij kon gedacht worden aan literatuur op het gebied van IT Audit, IT strategie management, outsourcing, lokale overheid en shared service centers.

Ad 2 Case studies met interviews Het tweede deel van het onderzoek bestond uit het bestuderen van twee relevante cases. Hierbij waren deze cases nader geanalyseerd met betrekking tot uitbestedingen in de lokale overheid en beoordeeld of de informatie behaald uit de literatuur studie hierin terug kwam. Daarnaast was contact gelegd met twee (samenwerkende) gemeenten en andere betrokken partijen, die de splitsing en integratie traject hadden afgelegd. Hiervoor was een vragenlijst opgesteld die was gebaseerd op de bevindingen uit de literatuur en case studies. Ad 3 Documentatie in de vorm van een scriptie Het laatste deel van het onderzoek bestond uit het documenteren van de bevindingen en resultaten. Ten slotte was antwoord gegeven op de centrale onderzoeksvraag. Het documenteren was in de vorm van een scriptie geschied.

1.6

Begeleiding

Voor de begeleiding was vanuit de postdoctorale studie IT Audit aan de VU expertise en kennis nodig geweest op de volgende gebieden: – IT Organisatie verandering; – IT Strategie; – Informatie Management; – IT Audit; – Overheid (lokaal); – IT analysis and design. De volgende personen hadden zorg gedragen voor de begeleiding in de uitvoer van het onderzoek: 1 René Matthijsse (VU Amsterdam); 2 Guill van den Boom (Ernst & Young IT Risk and Assurance).


1 Inleiding

Opbouw scriptie

1.7

Om tot de beantwoording van de centrale onderzoeksvraag te komen en de deelvragen te beantwoorden is de scriptie als volgt opgezet:

Figuur 01: Opbouw scriptie

H4

H1 H2 H3

IT Splitsing en Integratie bij Shared Service Center vorming

H5

IT Audit Control Framework

Risicogebieden

In de hoofdstukken 1, 2 en 3 wordt ingegaan op de “IT Splitsing en Integratie bij Shared Service Center vorming”. In hoofdstuk 1 wordt onze aanpak, scoping en onderzoeksmethodologie behandeld. Vervolgens wordt in hoofdstuk 2 relevante theorie en literatuur rondom “Domeinen IT landschap”, (vorming en fasen tijdens het opzetten van) “Shared Service Center”, “Risicobeheersing” en “Management vraagstukken” behandeld. Tot slot wordt in hoofdstuk 3 aan de hand van een tweetal cases (Drechtsteden en Rotterdam) bekeken in hoeverre de realiteit afweek van hetgeen wat is beschreven in de theorie en literatuur. In hoofdstuk 4 worden de bevindingen en conclusies die uit de hoofdstukken 2 en 3 vloeien geanalyseerd en worden de risicogebieden geïdentificeerd. In hoofdstuk 5 wordt uiteindelijk een control framework vanuit IT Audit perspectief gepresenteerd, waarin de risicobeheersing invulling krijgt bij IT splitsing en integratie bij de vorming van ICT Shared Services.


2 Theorie en literatuur

2

Theorie en literatuur

2.1

Inleiding

In hoofdstuk 2 zullen de theorie en literatuur die relevant en ondersteunend zijn aan het onderzoek worden behandeld. De theorie en literatuur worden tijdens de case studies gebruikt en toegepast. De resultaten en bevindingen maken onderdeel uit van dit onderzoek. Bij de IT splitsing en integratie bij de vorming van ICT shared services zijn zowel het model/opzet als het proces van belang. Met het model wordt de inrichting bedoeld. Met andere woorden hoe dient de ICT shared services (organisatie) uit te zien. Hierbij ligt de nadruk op informatiemanagement en uitvoer van de diensten met betrekking tot ICT shared services. Met het proces wordt de vorming bedoeld. Met andere worden hoe kan de ICT shared services vorm worden gegeven en welke (essentiële) stappen dienen genomen te worden. Dit hoofdstuk gaat achtereenvolgens in op: 1 Domeinen IT landschap (model); 2 Shared Service Center (proces); 3 Risicobeheersing (control).

2.2

Domeinen IT landschap

De domeinen binnen IT kan het best worden uitgelegd aan de hand van het 9vlaksmodel. Het 9-vlaksmodel, ook wel het Amsterdamse Informatiemanagement Model genoemd, is ontwikkeld door prof. dr. ir. Rik Maes. Het 9-vlaksmodel dient als referentiemodel voor informatiemanagement en is hieronder weergegeven. Onder informatiemanagement wordt verstaan het managen van informatie als bedrijfsresource4. De doelstelling van informatiemanagement is het zorgdragen voor de beschikbaarheid van de gevraagde informatievoorzieningen zodat de organisatie de geplande resultaten kan leveren5.

4R. 5

Maes, Informatiemanagement in kaart gebracht, 2003 M. Nieuwenhuis, The Art of Management, Deel 1 Strategie en Structuur, 2008, 150p



Figuur 02: 9-vlaksmodel Rik Maes

Het 9-vlaksmodel hanteert twee dimensies. Een bedrijfskundige dimensie weergegeven in de horizontale lagen strategie, inrichting en uitvoering. En een informatiedimensie weergegeven in de verticale kolommen bedrijfsdomein, informatie en communicatie domein en technologiedomein. In de paragrafen hieronder worden de twee dimensies verder toegelicht.

Bedrijfskundige dimensie In het 9 vlaksmodel worden drie lagen onderscheiden, namelijk: Strategie (richten), Structuur (inrichten) en Uitvoering (verrichten). De drie rijen van de matrix vertegenwoordigen de besturingsniveaus te weten het strategische niveau (richten), het tactische niveau (inrichten) en het operationele of uitvoerende niveau (verrichten)6. In het hiernavolgende zullen deze besturingsniveaus nader worden verklaard.

Strategie (richten) Het strategisch niveau is normaal gesproken het domein van de managers bovenin het traditionele organisatieschema. De termijn van de te plannen resultaten is hier doorgaans drie tot vijf jaar. De doelstellingen die zich over deze periode uitstrekken worden strategische doelstellingen genoemd en worden vastgelegd in de vorm van een strategisch beleid of beleidsplan7. De volgende vragen kunnen worden gesteld op strategisch niveau:8 – Welke resultaten willen we de komende drie tot vijf jaren gaan leveren aan welke klanten en op welke markten? – Hoe willen we met leveranciers en ketenpartners omgaan en wat moet onze plaats in de bedrijfskolom zijn? – Wat moeten we intern doen om extern de richting te kunnen halen? – Welk soort mensen hebben we hier voor nodig? 6

T.W. Hardjono, R.J.M. Bakker, Management van processen, 2007, 287p T.W. Hardjono, R.J.M. Bakker, Management van processen, 2007, 287p 8 M. Nieuwenhuis, The Art of Management, Deel 1 Strategie en Structuur, 2008, 150p 7



– –

Welke technologische middelen kunnen we inzetten? Hoe moeten we de structuur en cultuur aanpassen?

Structuur (inrichten) Op het structuur (tactisch) niveau vindt een vertaling en concretisering plaats van de lange termijn doelstellingen naar kortere termijn doelen of naar een specifieke onderdelen binnen de organisatie. Bijvoorbeeld de toedeling of allocatie van mensen en middelen aan organisatie-eenheden die bepaalde resultaatverplichtingen hebben gekregen9. Waar het strategisch niveau het domein van de topmanagers is, is het structuur niveau het domein van het middenkader. Hierbij kan gedacht worden aan hoofden van functionele afdelingen of afdelings- en sectormanagers. De termijn is op dit niveau doorgaans één tot drie jaar. De plannen hier worden vastgelegd in een jaarplan of sector of afdelingsplan10.

Uitvoering (verrichten) Op het uitvoerings (operationeel) niveau vindt de dagelijkse besturing van de organisatie plaats. Het gaat hier om de core business en de dagelijkse output benodigd voor de continuïteit van de organisatie. Bestuurders op dit niveau zijn de procesmanagers, proceseigenaren en teamleiders. De termijn op dit niveau is kleiner dan één jaar. Soms hooguit enkele dagen of weken11. In de onderstaande tabel zijn de drie besturingsniveaus opgenomen. Figuur 03: Besturingsniveaus informatiedimensie

Besturingsniveau Strategie Structuur Uitvoering

Focus Richten Inrichten Verrichten

Besturingstermijn Lang Middellang Kort

Gebied Strategische keuzen Organisatie inrichting Processen

Naast de drie lagen in het 9 vlaksmodel wordt het model in drie kolommen verdeeld, namelijk: Bedrijfsdomein, Informatie / communicatie domein en Technologiedomein. Deze drie kolommen vertegenwoordigen de informatiedimensie en worden hieronder toegelicht.

Business De kolom business vertegenwoordigt het bedrijfsdomein. In deze kolom wordt de inrichting van informatievoorziening belegd. Onder andere de volgende aspecten worden hierin beantwoord12: – In welke business opereert de organisatie? – welke bedrijfsstrategie wordt gevolgd door de organisatie? – hoe is de organisatie ingericht?

9

M. Nieuwenhuis, The Art of Management, Deel 1 Strategie en Structuur, 2008, 150p T.W. Hardjono, R.J.M. Bakker, Management van processen, 2007, 287p 11 T.W. Hardjono, R.J.M. Bakker, Management van processen, 2007, 287p 12 T. Abcouwer, H. Geld, J. Truijens, Informatiemanagement en Informatiebeleid, 2006, 344p 10



Informatie & communicatie In de kolom informatie en communicatie wordt op verschillende niveaus de verwevenheid van de onderneming met informatie en communicatietechnologie zichtbaar gemaakt. Hierin worden de volgende vragen beantwoord13: – Hoe moet de organisatie de wijze waarop wordt geïnformeerd en gecommuniceerd vormgeven? – Hoe moet de organisatie en haar informatievoorziening worden vormgegeven om een en ander mogelijk te maken? Hier vindt dus een vertaling plaats van de vraag vanuit het bedrijfsdomein naar een vraag aan het technologiedomein.

Technologie In het technologiedomein wordt behandeld waarmee het informeren en communiceren technisch moet worden vormgegeven. Deze kolom richt zich dus specifiek op de ontwikkeling en exploitatie van ICT14. Hierin worden de volgende vragen beantwoord15: – hoe is de informatievoorziening binnen de organisatie binnen de organisatie vormgegeven? – hoe wordt de informatievoorziening verder ontwikkeld? – hoe is het management van informatievoorziening ingericht?

Toepassing van het 9 vlaksmodel Het 9 vlaksmodel van Maes wordt in het algemeen als volgt gebruikt16: – Descriptief/oriënterend: In dit geval fungeert het 9 vlaksmodel vooral als gemeenschappelijk communicatiemiddel voor alle bij informatiemanagement betrokken partijen (variërend van business mensen tot harde ICT-ers). De verschillende informatiegerelateerde probleemgebieden worden op de kaart geplaatst en stelt de partijen in staat om over informatievoorzieningen te praten zonder hun toevlucht te nemen tot het ICT-jargon. – Inrichtend/ontwerpend: In dit geval wordt het 9 vlaksmodel gebruikt om de informatiehuishouding opnieuw vorm te geven, ook in het geval dat de ICT-voorzieningen zijn “outsourced”. Hierbij wordt het 9 vlaksmodel gebruik voor het afbakenen van de verantwoordelijkheids- en taakgebieden van bijvoorbeeld de CIO of informatiemanager. – Prescriptief/normatief: In dit geval wordt het 9 vlaksmodel gebruikt als diagnose-instrument. Hierbij wordt aandacht besteed aan de onderlinge relaties van het model en de verschillende elementen. 13

T. Abcouwer, H. Geld, J. Truijens, Informatiemanagement en Informatiebeleid, 2006, 344p M. Nieuwenhuis, The Art of Management, Deel 1 Strategie en Structuur, 2008, 150p 15 T. Abcouwer, H. Geld, J. Truijens, Informatiemanagement en Informatiebeleid, 2006, 344p 16 R. Maes, Informatiemanagement in kaart gebracht, 2003 14



Voor het oprichten van een Shared Service Center zal het 9 vlaksmodel inrichtend/ ontwerpend worden gebruikt. Op deze manier worden de relaties en verschillen tussen de verschillende strategische, structurele en operationele informatiemanagementvraagstukken voor de nieuwe op te richten organisatie in kaart gebracht. Tevens wordt het onderscheid tussen technologie, de betekenis van de technologie en de toepassing ervan in kaart gebracht17.

2.3

Shared Service Center

Steeds meer gemeentes kiezen ervoor om een Shared Service Center (SSC) op te richten opdat gezamenlijke en over het algemeen gelijkende bedrijfsactiviteiten gebundeld en onder één dak gebracht kunnen worden. Voordat überhaupt over SSC verder kunnen gaan dient eerst helder te zijn wat een SSC is. De definitie van een SSC is als volgt: Een SSC is een resultaat verantwoordelijke eenheid, die tot taak heeft het leveren van diensten op een specifieke specialisatie (zoals administratie, personeelszaken, informatietechnologie, inkoop e.d.), aan de operationele eenheden van één of meerdere onderneming (zoals business units, divisies of werkmaatschappijen), op basis van een overeenkomst tegen een verrekenprijs.18 In de definitie zijn een aantal essentiële onderdelen onderstreept, die hieronder nader worden toegelicht: – Een SSC is een resultaat verantwoordelijke eenheid. Dat wil zeggen dat een SSC een eigen eenheid vormt en verantwoordelijk is voor haar eigen resultaten en daarmee haar continuïteit en bestaan. – Een SSC levert diensten op een specifieke specialisatie. Dat wil zeggen dat een SSC diensten levert die voor de afnemende eenheden of ondernemingen aantrekkelijk zijn of worden gemaakt deze bij het SSC af te nemen, door specifieke specialisatie bij het SSC. – Een SSC werkt op basis van een overeenkomst en tegen een verrekenprijs. Dat wil zeggen dat tussen het SSC en de afnemende eenheden of ondernemingen sprake is van een overeenkomst waarbij tevens helder is wat de kosten zijn van de af te nemen diensten. Het gevolg is dat een SSC wordt genoodzaakt haar diensten tegen een zo gunstig mogelijk verrekenprijs aan dient te bieden waarbij zij een sterke focus dient te hebben op het kwaliteitsaspect. Het vereiste hierbij is dat tussen de betrokken partijen een consensus en overeenkomst moeten zijn over minimaal de volgende items: – Inhoud: Wat en welke diensten zal en kan het SSC leveren? – Resultaat: Wat kan worden verwacht? Wat is het eindresultaat? 17 18

T. Abcouwer, H. Geld, J. Truijens, Informatiemanagement en Informatiebeleid, 2006, 344p J. Strikwerda, Shared Service Centers – Van kostenbesparing naar waardecreatie. Koninklijke Van Gorcum BV, Assen (2005), 150p.

Risicobeheersing bij IT Splitsing & Integratie - 10 -


–

Kosten: Wat zijn de kosten van de verschillende diensten?

De balans tussen de te leveren diensten en de kosten die daarmee voor zowel het SSC en de afnemende partijen samenhangen zijn bepalend voor zowel het SSC en de afnemende partijen. Het vinden van de juiste mix van diensten tijdens en na de invoering van het SSC is dus essentieel. De diensten dienen zoveel mogelijk generiek te zijn en zo min mogelijk af te wijken van de wensen en eisen van de afnemende partijen. Hierbij dient ook rekening gehouden te worden met de kosten en de kwaliteit van de (geleverde) diensten. De leden van de projectgroep van het kennisnetwerk identificeren als aanleidingen voor het opzetten van een SSC: kostenreductie, standaardisatie, kwaliteitsverbetering en kwaliteitsbeheersing (tijdigheid, volledigheid, continuïteit).19 Daarnaast kunnen nog meer aanleidingen zijn voor het opzetten van een SSC. Maar de hierboven genoemde aanleidingen zijn de belangrijkste. Met de belangrijkste aanleidingen in het achterhoofd is het niet raadzaam om alle activiteiten in een SSC onder te brengen. Bepaalde activiteiten kunnen zelfs duurder of minder efficiënt zijn door deze in een SSC onder te brengen. De volgende activiteiten worden het meest ondergebracht in al dan niet gespecialiseerde SSC’s: Financiën en Administratie, Management Informatie en Advisering, Juridische en Fiscale Zaken, Personeelsmanagement en -administratie, Verkoop en Marketing, Computer / ICT, Inkoop, Fabricage, Logistiek, Facilitaire Dienstverlening en PR en Communicatie.20 Zoals in hoofdstuk “2.1 Inleiding” reeds is aangegeven ligt de focus in dit onderzoek op het onderdeel “Computer / ICT”, met dien verstande dat een SSC niet louter “Computer / ICT” betreft. Binnen en tussen gemeenten vindt IT splitsing en integratie in bijna alle gevallen via of tijdens het opzetten van een SSC plaats. De focus op “Computer / ICT” wilt niet zeggen dat hetgeen wat is beschreven en de resultaten puur en louter geldt voor de “Computer / ICT” aspecten bij het opzetten van een SSC, maar dat de kans bestaat dat deze voor de andere activiteiten wellicht niet volledig is. Om tot een Shared Service Center (SSC) te komen dient een aantal fasen doorlopen te worden tot de daadwerkelijke oprichting van het SSC. Dit geldt in principe voor alle diensten / activiteiten die de onder SSC (gaan) vallen. Het volgende figuur toont de fasen die van toepassing zijn bij de vorming van een SSC:21

19

V. Kager, J. de Graaf E. Kolthof en M. Hoeksma, Tijdschrift Controlling nr. 12 (december 2004) 58-62. M. Stroucken, R. Douwstra, T. van der Marel en A. de Jong, Shared Service Centra – Van keuze tot aan realisatie. Quint Wellington Redwood, Amsterdam (2004), 22p. 21 Voor de bepaling van de fasen hebben wij een combinatie gemaakt van de fasen zoals deze zijn opgesteld door twee vooraanstaande Advisory / consultancy bureaus namelijk Ernst & Young en Deloitte: - M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. - P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p. 20



Figuur 04: Fasen bij vorming van een Shared Service Center

Hoewel de laatste fase, de optimalisatiefase, officieel volgt na de vorming (implementatie) van een SSC is deze volledigheidshalve opgenomen. De reden hiervoor is dat een SSC na vorming in de meeste gevallen nog niet af is en nog “gemasseerd” dient te worden. Daarnaast kunnen SSC’s ook niet stil blijven staan als zij eenmaal zijn gevormd en met dient deze met hun tijd mee te gaan. In het hiernavolgende zullende verschillende fasen nader worden uiteengezet.

Fasen vorming Shared Service Center Zoals bij alle projecten kunnen bij de verschillende fases meer activiteiten worden gedefinieerd en zijn daarmee de activiteiten bij de verschillende fases zoals deze hierna worden benoemd niet uitputtend. De genoemde activiteiten zijn wel de essentiële activiteiten die horen bij de vorming van een SSC.

Strategiefase In de strategiefase vinden de ideevorming en besluitvorming plaats die leiden tot het oprichten van een SSC.22 Er wordt bekeken wat het object van uitbesteding is en wat het doel is dat moeten worden bereikt.23 Het volgende figuur geeft een overzicht van activiteiten die horen bij de strategiefase:24

22

M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 23 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 24 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p.



Figuur 05: Activiteiten strategiefase bij vorming van een Shared Service Center

In het hiernavolgende zal een aantal de activiteiten nader worden toegelicht: – Formuleren strategie: Volgens het model van Treacy en Wiersma zijn drie strategieën mogelijk: productleiderschap, kostenleiderschap en klantintimiteit.25 Figuur 06: Strategische opties volgens het model van Treacy en Wiersma

–

–

25 26

Hoewel het mogelijk is om een middenweg te zoeken voor de twee of alle drie de strategieën, is het verstanding om voor één van de drie strategieën te kiezen. Keuzes voor en binnen één van de strategieën zullen impact hebben voor de andere strategieën. Formuleren doelstellingen: Doelstellingen betreffen de doelstellingen die bereikt dienen te worden met de op te zetten SSC. Deels zullen deze vloeien uit de eerder gekozen strategie. Voor het andere deel zullen deze nader bepaald moeten worden. Wijze van betrokkenheid OR vaststellen: De ondernemingsraad is de inspraaken medezeggenschapsorgaan binnen het bedrijf.26 De op te zetten SSC zal uiteindelijk veel impact hebben op de bestaande organisatie. Hierdoor is de betrokkenheid van de OR onvermijdelijk. http://www.timbv.nl/timbv/Adviesgebieden/shared-service-centers/strategische-opties-voor-een-ssc http://nl.wikipedia.org/wiki/Ondernemingsraad



–

–

–

–

Uitvoeren omgevingsscan: Bij een omgevingscan wordt gekeken naar de verschillende trends en markten. Deze trends en markten kunnen worden meegenomen in de strategie en doelstellingen bij het opzetten van het SSC. Opstellen en uitvoeren nulmeting: De nulmeting betreft de geschetste situatie zoals deze is indien geen sprake is van een SSC. De “as-is” situatie. Belangrijk is om niet de gehele organisatie te beschrijven maar alleen die onderdelen die relevant zijn bij het opzetten van het SSC. Voorstel voor governance model: Dit model is een eerste opzet voor processen en systemen. Hierbij zal op hoofdlijnen worden geïnventariseerd welke processen en systemen onder het SSC zullen gaan vallen. Daarnaast zal worden bekeken welke nieuwe processen en systemen worden geïntroduceerd en welke (oude) vervallen. Voorstel voor projectorganisatie voor nieuwe inrichting nieuwe organisatie: Op hoofdlijnen dient geschetst te worden hoe de organisatie er uit dient te zien met een SSC. Tevens wordt op hoofdlijnen duidelijk wat eventueel de impact van het SSC is op de organisatie.

Haalbaarheidsfase In de haalbaarheidsfase wordt bekeken of het gewenste doel ook daadwerkelijk behaald kan worden.27 Hier worden de (financiële) voordelen vergeleken met de kosten en de “return on investment” bepaald.28 29 Op basis van de resultaten in deze fase wordt besloten met het project te starten of het (voorlopig) te laten rusten.30 Het volgende figuur geeft een overzicht van activiteiten die horen bij de strategiefase:31 32

27

M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 28 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 29 P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p. 30 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 31 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 32 P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p.



Figuur 07: Activiteiten haalbaarheidsfase bij vorming van een Shared Service Center

In het hiernavolgende zal een aantal de activiteiten nader worden toegelicht: – Ontwikkelen van een gedeelde visie: Voordat überhaupt met de een SSC gestart kan worden dient een gedeelde visie ontwikkeld te zijn die ook wordt gedragen door relevante betrokkenen en stakeholders. Deze visie dient in ieder geval een organisatiebrede visie te zijn. – Opstellen businesscase: In de businesscase dient de huidige situatie, de gewenste situatie en de te ondernemen stappen omschreven te worden. – ICT-analyse, inclusief nieuwe ICT-mogelijkheden: Met de ICT-analyse dient de huidige ICT situatie in kaart gebracht te worden. Tevens dienen nieuwe ICTmogelijkheden, die nieuwe kansen bieden en impact zullen hebben op de totstandkoming van het SSC zoveel mogelijk meegenomen te worden. – Overwegen betrekken externe partijen: In bijna alle gevallen is het opzetten van een SSC voor de organisatie iets nieuws. Om die reden dient tijdens de haalbaarheidsfase overwogen te worden eventuele externe partijen te betrekken die bekend zijn met het opzetten van een SSC of facetten daarvan. – Procesanalyse (bedrijfsprocessen): Relevant zijn die processen die deels of volledig in aanmerking komen om opgenomen te worden in de op te richten SSC. Grenzen dienen gesteld te worden met betrekking tot hoe, wat en wie verantwoordelijk zal zijn voor de verschillende delen. – Benchmark analyse: Eventuele beschikbare benchmarks dienen geanalyseerd te worden. Met de benchmarks dienen ook de benodigde kosten en baten analyses gemaakt te worden. – Communicatiestrategie bepalen: Tijdens de haalbaarheidsfase zullen geluiden/geruchten met betrekking tot de oprichting van het SSC de organisatie bereiken. Om die geluiden voor te zijn en om betrokkenen tijdig op de hoogte te brengen en te betrekken, dient een communicatiestrategie opgesteld te worden. – Go/No Go beslissing: Met de informatie die beschikbaar is en resulteert uit de haalbaarheidsfase kan een go/no go beslissing gemaakt te worden. Dit is ook het moment waarbij de investering nog laag zijn en impact op de organisatie minimaal. Risicobeheersing bij IT Splitsing & Integratie - 15 -


Ontwerpfase In de ontwerpfase wordt er een offerteaanvraag uitgebracht.33 Nadat er een leverancier is gekozen wordt de organisatie- en procesinrichting ontworpen.34 De leverancier(s) kan ook intern zijn. Een SSC hoeft niet persé een externe partij te zijn. De gemaakte afspraken worden vastgelegd in een Service Level Agreement (SLA).35 Deze lange fase is complex en vereist uitstekende aandacht in de detaillering.36 Het volgende figuur geeft een overzicht van activiteiten die horen bij de strategiefase:37 38 Figuur 08: Activiteiten ontwerpfase bij vorming van een Shared Service Center

In het hiernavolgende zal een aantal de activiteiten nader worden toegelicht: – Helder framework opstellen: De framework dient minimaal de volgende elementen te bevatten: een heldere en eenduidige scope en de aanwezigheid

33

M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 34 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 35 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 36 P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p. 37 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 38 P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p.



–

–

–

– –

van een PID. De PID dient op een gegeven moment, na planning en voorbereiding, ook goedgekeurd te worden. Initiëren (organisatie) wijzigingsmogelijkheden: De implementatie van een SSC heeft grote impact op de bestaande organisatie, betreft een grootschalige organisatie wijzigingsproject en zal ook die mensen betreffen die geen financiële functie hebben. De uitdaging en rol van de wijzigingsteam is om een uitgebreid plan op te stellen en ten uitvoer te brengen die staff functies zal ondersteunen bij de wijzigingen en de zekerheid biedt dat het project de juiste balans behoudt tussen de mensen, processen en technologieën. Uitwerken organisatorische consequenties en ontwerp organisatie- en procesinrichting: Gevolgen voor het organisatorische vlak dienen uitgewerkt te worden en een ontwerp van de organisatie- en procesinrichting dient gemaakt te worden. Voor het ontwerp van de organisatie-inrichting deelactiviteiten van toepassing: ontwerp een operationeel model, bepaal een accounting aanpak, definieer een structuur/onderdeel waar het SSC onder zal gaan vallen (of een aparte entiteit), beoordeel de bank en treasury afspraken, optimaliseer belastingstructuur (voor internationale organisaties), bouw de team(s)/bemensing voor het SSC en ontwerp infrastructuur. Voor het ontwerp van de procesinrichting zijn vier smaken aanwezig: volgend of best practice processen, “as is” of bestaande processen, standaardprocessen en ERP ondersteunde processen. Uitwerken ICT-consequenties en blauwdruk ICT-systemen: Een nieuw ontwerp voor de ICT-systemen dienen in kaart gebracht te worden. Dit dient voorafgegaan te worden met technische ontwerpen, dataconversie aanpakken en technische infrastructuurontwerpen. Opstellen SLA’s: De afspraken tussen de deelnemende partijen dienen in Service Level Agreements vastgelegd te worden. Vaststellen migratiestrategie: Besluit dient genomen te worden omtrent de migratiestrategie die gehanteerd zal gaan worden: een gefaseerde overgang of één grote overgang naar de nieuwe situatie.

Bouw en Test fase In de bouwen testfase staan de constructie van alle componenten van de nieuwe SSC en het testen van deze componenten om zeker te zijn van een volledige integratie centraal.39 Aan het eind van deze fase dient alles wat nodig is voor het volledig operationeel zijn van het SSC afgerond te zijn.40 Het volgende figuur geeft een overzicht van activiteiten die horen bij de bouw en test fase:41 42

39

P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p. 40 P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p. 41 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 42 P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p.



Figuur 09: Activiteiten bouwen testfase bij vorming van een Shared Service Center

In het hiernavolgende zal een aantal de activiteiten nader worden toegelicht: – Opzetten en testen processen: De volgende deelactiviteiten zijn hierbij van toepassing: creëer gedetailleerde processen(stappen) en ontwikkel gebruikersdocumentatie. – Opzetten en testen technologie: Aan het eind van de ontwerpfase dient gecompleteerde ERP configuratie, een voorbereid ontwerp specificaties voor ontwerp van alle nieuwe programma’s (inclusief interfaces, schermen en rapporten) en ontwikkelen conversiemethoden voor data uit legacy systemen naar de nieuwe ERP systeem te liggen. De keuze voor een ERP hoeft niet persé, maar een degelijke ICT oplossing bij een SSC is onmisbaar. De volgende deelactiviteiten zijn van toepassing: bouw maatwerk programma’s en interfaces, voorbereiding data voor conversie, technisch infrastructuur testen, alle componenten testen. – Opzetten en testen organisatie/HR: De mensen die werkzaam zullen zijn voor of bij het SSC en de lokale instellingen van het SSC zijn essentieel voor het behalen van en de instandhouding van de verandering en het creëren van service cultuur binnen het SSC. Bij een SSC zal een hoog aantal nieuwelingen aangetrokken worden, dat dient te bouwen aan de bewustwording van de business, kennis van de nieuwe processen, technologische vaardigheden en essentiële relatie met de klanten. Een duidelijk succes factor bij de creatie van een SSC is het creëren van een gelijk vertrouwensniveau dat lokale (landen)kantoren genieten van lokaal management. De investering in opleidingen en trainingen en kennismaking met de business zijn essentieel bij de opbouw van het eerder genoemde vertrouwen in een vroeg stadium en het demonstreren van een professioneel eerste impressie naar alle klanten van het SSC toe. De volgende deelactiviteiten zijn van toepassing: Opbouw organisatie en werf SSC personeel, verzorg trainingen, creëer ondersteunende systemen, leg de laatste hand op de relatie tussen SSC en de rest van de business en richt het SSC voorzieningen in.

Implementatiefase In de implementatiefase vindt de vestiging en inrichting van het SSC daadwerkelijk plaats.43 In deze fase dient aangetoond te worden dat al hetgeen wat in de voorafgaande fasen is bedacht, ontworpen en getest ook daadwerkelijk gaat werken en 43

M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p.



de voordelen oplevert.44 Het volgende figuur geeft een overzicht van activiteiten die horen bij de implementatiefase:45 46 Figuur 10: Activiteiten implementatiefase bij vorming van een Shared Service Center

In het hiernavolgende zal een aantal de activiteiten nader worden toegelicht: – Duidelijk migratiestrategie opstellen: De migratiestrategie heeft tot doel de activiteiten van de (huidige) business ordelijk en naadloos over te hevelen naar het SSC. Belangrijk is om een positieve impressie te creëren en te houden van het SSC vanaf het begin. Om die reden dient de communicatie van het migratieplan(ning) naar de belangrijke stakeholders ook in acht genomen te worden. En bij live-gang dient deze communicatie in stand gehouden te worden en eventuele problemen dienen snel opgelost te worden. De volgende deelactiviteiten zijn van toepassing: bepaal de volgordelijkheid en de snelheid van de implementatie, implementeer schaduwwerken en converteer de data. – Inrichten en beschrijven AO/IC: Het belang van een AO/IC is belangrijk omdat de afnemers weten hoe de processen die onder de verantwoording van het SSC (zullen) vallen uit worden gevoerd en in hoeverre deze in control zijn. – Uitvoeren dataconversie: Bij de dataconversie dienen de relevante data van de business overgezet te worden naar het SSC. In sommige gevallen, bij andere of nieuwe systemen, dienen deze data ook geconverteerd te worden. Nadat het voorbereiden en testen van de dataconversie succesvol is afgerond wordt de daadwerkelijke overdracht gedaan. – Beheren/beheersen van de live-gang: De eerste paar maanden na de live-gang is een cruciale periode waarin business kennis en ervaring essentieel zijn. Om de transitie tot een succes te maken en geen verlies van ervaring en kennis van de organisatie te hebben is redundantie en behoud van sleutel personeel voor een

44

P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p. 45 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 46 P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p.



–

–

bepaalde periode (2 maanden) een vereiste. Na deze periode kunnen de redundantie personeel binnen het SSC of organisatie herplaatst worden voor de retentie van kennis en ervaring. Inregelen post live-gang ondersteuning: Na live-gang kunnen op IT gebeid problemen voordoen. De reden hiervoor is dat op grote schaal en met werkelijke processen en gegevens worden gewerkt. De volgende zaken zijn van toepassing: toegewijde IT ondersteuning en complementeer het eerste maandeinde sluiting. Train, motiveer en behoud personeel: Personeel dient geleerd te worden beter en efficiënter om te gaan met systemen en processen en nieuw kennis dient bijgebracht te worden. Daarnaast dient personeel gemotiveerd en behouden te worden. Dit kan een issue zijn na de dynamische implementatie periode.

Optimalisatiefase In de optimalisatiefase vindt een vorm van gestructureerde evaluatie plaats. Hier wordt gekeken naar het functioneren van het SSC en of dit aan de verwachtingen voldoet.47 Tevens dient bekeken te worden of de performance in lijn is de verwachtingen. En of de service(s) die de business afneemt/krijgt ook naar behoren en tevredenheid is. Hier dient onderzocht te worden hoe verdere verbetering mogelijk is en feedback van de business dient verwerkt te worden. Daarnaast zijn andere zaken als optimalisatie, uitbreiding en doorvoeren van verbeteringen net zo belangrijk. 48 Het volgende figuur geeft een overzicht van activiteiten die horen bij de optimalisatiefase:49 50 Figuur 11: Activiteiten implementatiefase bij vorming van een Shared Service Center

In het hiernavolgende zal een aantal de activiteiten nader worden toegelicht: – Review werking Shared Service Center (met o.a. benchmark tegen oorspronkelijke business case): De werking van het SSC wordt hier bekeken en 47

M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 48 P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 49 M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 50 P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p.



–

beoordeeld. De prestaties dienen regelmatig tegen de oorspronkelijke business case te worden gebenchmarkt en gecommuniceerd te worden. Via plan/do/check/act op business case wordt gekeken naar wat er beter kan. Een partnerrelatie met de business onontbeerlijk. SLA’s, KPI’s en klantonderzoek/enquêtes zijn goede hulpmiddelen ter ondersteuning. SLA’s en de uitvoering daarvan dienen doorgelicht te worden. Hier wordt gekeken of de afspraken in de SLA’s worden nageleefd. Optimaliseren effectiviteit en efficiency van Shared Service Center (processen, technologie en organisatie/HR): Naar aanleiding van de review worden hier de aanpassingen gedaan aan het SSC. Aanpassingen geschieden op de volgende drie gebieden: Processen, Technologie en Organisatie/HR.

Groei naar een excellent Shared Service Center Als het SSC eenmaal een feit is dan wil dat nog niet zeggen dat deze ook daadwerkelijk af is. Uit een onderzoek van KPMG is gebleken dat bijna een derde van de respondenten aangeeft dat het SSC de verwachte bedrijfsvoeringvoordelen niet heeft weten te realiseren.51 Het aandeel is hoog te noemen, zeker als het af wordt gezet tegen het feit dat een SSC de kansen en mogelijkheden biedt en in sommige de noodzaak aanwezig is om het werk effectiever en efficiënter te organiseren. Dit betekent dus dat de optimalisatiefase niet een eindstation is maar een blijvende fase. Het SSC dient haar dienstverlening, haar organisatie, haar processen, et cetera continu te verbeteren en deze op de afnemende (interne) klanten af te stemmen om zo optimaal haar taken te kunnen uitvoeren. Een excellent SSC ontstaat niet in korte tijd, het vraagt een groeiproces om te kunnen excelleren.52 Het figuur zoals dit is getekend in figuur 11 is een groeicurve die een SSC kan doorlopen.53 Figuur 12: Groei naar een excellent SSC

51

H. Koevoets en M. van Kaam, Maakt uw shared service center zijn beloftes waar? (2009), 6p. H. Koevoets en M. van Kaam, Maakt uw shared service center zijn beloftes waar? (2009), 6p. 53 H. Koevoets en M. van Kaam, Maakt uw shared service center zijn beloftes waar? (2009), 6p. 52



Meestal worden verbeterprogramma’s ingezet om naar een volgend niveau van volwassenheid te groeien. Opgemerkt dient te worden dat verbeterprogramma’s tools of middelen zijn om je doelen te bereiken, maar de mensen van het SSC of beter gezegd het SSC zelf deze doelen dienen te verwezenlijken. De volgende zes suggesties kunnen het SSC beter laten presteren:54 1

Prestatiemeting maakt resultaat zichtbaar: Door een prestatie te meten kan de waarde van de prestatie worden bepaald. Om prestatie te kunnen meten dienen eerst de KPI’s bepaald te worden. Figuur 13: Het duivelselastiek met kritieke succesfactoren

2

3

54

Via het duivelelastiek zoals dit is gepresenteerd in figuur 13, kunnen de KPI’s worden geformuleerd. Het duivelselastiek geeft een zestal doelstellingen (doorlooptijd, klantgerichtheid, efficiency, flexibiliteit, betrouwbaarheid en innovativiteit) aan die een onderlinge spanningsrelatie hebben. Meer nadruk op één of meerdere doelstelling gaat in alle gevallen ten koste van één of meerdere van de andere doelstellingen. Via inzicht in de in- en output van de processen en de procesgerelateerde risico’s kunnen de juiste en gebalanceerde set van KPI’s en normen worden gedefinieerd. Met de KPI’s en normen kan de prestatiemetingen worden uitgevoerd. Opgemerkt dient te worden dat het SSC voor de gehele organisatie is en niet voor de losse onderdelen/afdelingen. Met dien verstande dat de gehele organisatie(belang) zou moeten prevaleren. Sturing op de procesketen triggert procesverbetering: Prestatiemeting geeft inzicht in verbetermogelijkheden. Verbetering is alleen goed mogelijk als de sturing juist is. Juiste sturing is mogelijk door inzicht te hebben in de hele keten. Wel dient het SSC duidelijk zijn taken en verantwoordelijkheden af te bakenen ten opzichte van de rest van de organisatie. Daarnaast moet het SSC de verwachtingen managen. Hiermee wordt de plaats van het SSC duidelijk voor alle stakeholders. Continue verbetering werkt beter als zij deel uitmaakt van de mindset van de medewerkers:

H. Koevoets en M. van Kaam, Maakt uw shared service center zijn beloftes waar? (2009), 6p.



4

5

6

2.4

Door processen uit te voeren en te ervaren kan zicht worden verkregen in welke punten in processen verbetering mogelijk zijn. Indien de kennis van de ketensamenwerking aanwezig is dan kunnen veranderingen/verbeteringen van strategisch belang zijn. Voorwaarde is wel dat de medewerkers/uitvoerders zijn getraind deze verbeteringen te zien, de cultuur aanwezig is waarbij continue verbetering mogelijk is en continue verbetering deel uitmaakt van de mindset van medewerkers. Investering in mensen prikkelt proactief gedrag: Investering in de carrière van medewerkers zal het aandragen van verbeteringen positief beïnvloeden. Indien minder resources nodig zijn voor uitvoerende taken, kunnen meer hoogwaardige taken worden opgepakt. Hoogwaardige taken betekent in de meeste gevallen meer uitdagende rollen en vraag om andere (nieuwe) vaardigheden. Tevens kan de inzicht in ketenprocessen worden verbetering door medewerkers uit te wisselen tussen de organisatie en het SSC. Hiermee wordt het zoekgedrag naar procesoptimalisaties en verbeteringen ook vergroot. De juiste technologie toepassing ondersteunt de verbetering: Technologie is een belangrijke drijfveer om verder te standaardiseren en de dienstverlening te verbeteren. Niet beschikking over standaardsystemen leidt tot slechte interactie met de rest van de organisatie. Door automatisering van processen kunnen processen snellen en efficiënter doorlopen worden. Wel dient de technologie aangepast te worden naar de organisatievorm en omvang van het SSC. Gebruik van één ERP systeem zal in de meeste gevallen de sleutel tot succes zijn. Een realistische verrekensystematiek geeft uitkomst bij onbalans tussen klantafspraken en interne kosten van het SSC: Meten van klanttevredenheid in combinatie met opvolging van de resultaten creëert een effectief beheerd SSC en een SSC die op termijn zal groeien. Hierbij is inzage in de kosten die benodigd zijn voor de realisatie van of voldoen aan de klantverwachtingen essentieel. Hiertoe dient een goede en vooral realistische verrekensystematiek aanwezig te zijn. Hiermee kan het SSC de klantenwensen omzetten in dienstverlening tegen een kostendekkende prijs.

Voor- en nadelen van Shared Services tussen organisaties

Het concept en de vorming van SSC zijn inmiddels uitvoerig behandeld in het hiervoorgaande. Om de theorie ten aanzien van het SSC af te sluiten zullen de belangrijkste voor- en nadelen worden behandeld.

Voordelen SSC Het grote voordeel van shared services is, in het bedrijfsleven en bij de overheid, dat organisaties schaalvoordelen kunnen creëren, zonder dat dit ten koste gaat van de integrale verantwoordelijkheid van de manager of het politieke bestuur voor de



prestaties of het beleid.55 Deze schaalvoordelen kunnen op velerlei gebieden worden gecreëerd. Zowel het SSC als de (organisatie)onderdelen die gebruiken maken van het SSC kunnen op hun beurt ook steeds meer toeleggen op de zaken waar zijn goed in zijn, hun aandacht op is gericht en waarvoor zij hun bestaansrecht aan lenen. Shared services vergemakkelijken de afstemming en kennisuitwisseling tussen en binnen gemeenten op regionaal niveau.56 Door services en diensten te bundelen in een SSC worden deze indirect op een natuurlijke wijze gedwongen deze zo optimaal uit te voeren en zullen het leereffect bij de verschillende onderdelen (gemeenten, deelgemeenten, diensten, etc.) zeer groot zijn. Shared services leiden tot een grotere transparantie binnen organisaties.57 Doordat de diensten en services van het SSC helder zijn en contracten zijn opgesteld of aanwezig zijn voor de verschillende afnemers, wordt het mogelijk zaken als werkelijke behoeften en kosten inzichtelijk te maken. Hierdoor worden (extra) mogelijkheden gecreëerd voor benchmarking met andere organisaties.

Nadelen SSC De invoering van shared services is een proces van organisatieverandering met consequenties voor de deelnemende organisaties, en het personeel.58 Dat gaat tijdelijk ten koste van de externe gerichtheid van de organisatie en kan ertoe leiden dat op sommige onderdelen de politieke ambities tijdelijk moeten worden bijgesteld.59 Een deel van de ambtelijke organisatie komt meer op afstand te staan en is dus niet meer altijd ad hoc beschikbaar.60 Immers het SSC is een centrale organisatie dat werkt voor meerdere (organisatie)onderdelen. Afspraken ten aanzien van kwaliteit, kwantiteit en prijs liggen contractueel vast. Zowel het SSC als de onderdelen die gebruik maken van de diensten en services van het SSC dienen hier rekening mee te houden. Tegenover besparingen staan ook extra kosten.61 Door eventuele hoger loonniveau en coördinatiekosten, die in situatie voor het SSC niet waren kunnen (extra) kosten hoger 55

A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 56 A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 57 A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 58 A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 59 A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 60 A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 61 A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p.



uitvallen. Indien deze goed worden gemanaged zal de eind situatie nog steeds een grote besparing op moeten leveren. Shared services leggen een extra beslag op de tijd van bestuurders.62 Bij intrabestuurlijke shared services is dat extra tijdsbeslag te verwaarlozen.63 In het geval dat gemeenten samen een shared service oprichten ligt dat anders.64 Door bij de opzet van Shared Services duidelijke spelregels te formuleren over besluitvorming, kostenverdelingsvraagstukken en prijsstelling kunnen deze kosten terug worden gedwongen.

2.5

Risicobeheersing

Voor het inzichtelijk maken en beheersen van risico’s na de IT integratie kan gebruik worden gemaakt van de Statement on Auditing Standards number 70 (SAS70). De opvolger van deze internationaal geaccepteerde standaard is de International Standard for Assurance Engagements 3402 (ISAE3402). Deze standaard dient te worden gehanteerd in onderzoeken die eindigen op of na 15 juni 2011.

Overeenkomsten en verschillen In een SAS70 rapportage wordt de effectiviteit van de beheersingsmaatregelen beschreven. Deze rapportage heeft de volgende belangrijkste voordelen65: – Het geeft de gebruikersorganisatie inzicht in en zekerheid over de wijze waarop de serviceorganisatie haar procesbeheersing heeft georganiseerd, waardoor de gebruikersorganisatie beter in staat is haar eindverantwoordelijkheid over de uitbestede processen te dragen; – De gebruikersorganisatie voldoet (indien van toepassing) aan de eisen die de diverse weten regelgeving haar stelt. Tussen de SAS70 en ISAE 3402 zijn enkele verschillen66. Zo kan de auditor bij een ISAE 3402 alleen nog een redelijke mate van zekerheid geven. Ook is het verantwoordelijk management bij ISAE 3402 verplicht een mededeling op te nemen in het rapport. In deze mededeling dient de reikwijdte te zijn opgenomen. Tevens dient te zijn opgenomen dat de beschrijvingen fair zijn en gelden voor de transacties in de periode van onderzoek, waarbij is opgenomen welke services en transacties onderdeel zijn van het rapport. Voorts worden elementen opgenomen zoals de beheersomgeving, het risicobeheerproces, informatie en communicatie alsmede de controle activiteiten. 62

A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 63 A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 64 A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 65 D. Houtekamer, R.W. de Graaf, ISAE 3402: einde van SAS70 in zicht? (2009), 6p. 66 R.Ch.T. Ewals, ISAE 3402: Een nieuw hoofdstuk voor de IT-auditor (2010), 9p



IT splitsing en integratie De uitdagingen, vereisten en risico’s zullen bij de twee vormen van IT splitsing en integratie (organisatorische en technische) anders zijn. In het hier voorgaande is bij de (vorming van de) SSC reeds bij stilgestaan, en zal hier verder niet op ingegaan worden. Wel dient opgemerkt te worden dat de focus van dit onderzoek meer zal liggen op de organisatorisch aspecten van IT splitsing en integratie. Een SAS70 of ISAE 3402 wordt interessant voor de gemeente wanneer het integratie traject is afgerond en het Shared Service Center in gebruik is genomen. Vanuit de principes van goed ondernemingsbestuur blijft de organisatie die de processen uitbesteedt eindverantwoordelijk voor de beheersing van deze processen. Vooral bij processen die een groot (materieel) financieel belang kennen, zal de uitbestedende organisatie (de gebruikersorganisatie) een of andere vorm van toezicht op de partij aan wie wordt uitbesteed (de serviceorganisatie) moeten uitoefenen. De uitbestedende gemeente zal van de serviceorganisatie zekerheid moeten verkrijgen over de mate van beheersing over de processen die daar uitgevoerd worden67.

2.6

Management vraagstukken

IT splitsing en integratie bij de vorming van ICT shared services gaat in het algemeen gepaard met of wordt uitgevoerd in een groot project(en) dat zeker maanden danwel jaren nodig heeft. Om dit allemaal in goede banen te leiden, goed te managen en tot een goed einde te brengen zijn de belangrijkste management vraagstukken/ onderwerpen hierbij: – Services management (infrastructuur): Services (infrastructuur) management gaat over alle infrastructurele inrichtingsvraagstukken. Hoe worden de services en producten worden aangeboden en hoe worden deze in het grotere geheel geïntegreerd (inclusief uitbreidingen)? – Dienst en product management: Diensten en producten management gaat over de diensten en producten pakket wat wordt aangeboden. In tegenstelling tot services management waar de nadruk op de hoe ligt, ligt bij dienst en product management de nadruk op de wat. Welke services en producten (zullen) worden aangeboden en wat zijn de mogelijkheden voor het heden en toekomst? – Relatiebeheer, contractmanagement en helpdesk: Relatiebeheer, contactmanagement en helpdesk betreffen alle communicatie met de klant/ gebruiker. Hoe vindt de communicatie en afhandelingen van de zaken plaats met de verschillende groepen van klanten van de SSC? – Architectuur, advies en strategie: Architectuur, advies en strategie vallen allemaal onder vraagstukken die gaan over hoe de SSC het best ingericht, neergezet, uitgebouwd en ontwikkeld kan worden. Hierbij zijn eventuele aanpassingen van de gebruikmakende organisaties/ gebruikers onvermijdelijk. – Directie en management: Directie en management gaan over de besturing van de SSC. Hoe dienen de SSC(‘s) bestuurd te worden? Voor welk model kan het best worden gekozen? 67

D. Houtekamer, R.W. de Graaf, ISAE 3402: einde van SAS70 in zicht? (2009), 6p.



–

Interne ondersteuning: Interne ondersteuning gaat over alle (rand)voorwaarden die aanwezig dienen te zijn om de (dagelijkse) gang van zaken en projecten te stroomlijnen. Hierbij kan worden gedacht aan zaken als PMO, secretariaat, etc.

Rekening met de hier voorgenoemde management vraagstukken dient gehouden te worden bij het opzetten van de SSC. Bij deze aspecten is reeds stilgestaan in het hier voorgaande (bij de vorming van de SSC). Hier wordt volstaan met het benoemen van de vraagstukken. Als de ICT shared services (organisatie) gevormd is wil dat ook niet meteen zeggen dat deze af zijn en voor de opvolgende jaren gedurende haar bestaan niet meer aangepast of verbetert dient te worden en niet meer voor groei in aanmerking komt. Om gedurende het project en daarna ICT shared services goed te managen dient aan de volgende organisatiegebieden aandacht geschonken te worden: – Operations; – Finance; – HRM; – IT; – Risicobeheersing. Deze vijf gebieden zullen in het hiernavolgende nader worden behandeld. Per gebied zullen de meeste belangrijke management vraagstukken worden belicht. Opgemerkt dient te worden dat de vijf gebieden niet losstaand van elkaar zijn. Wijzigingen of gebeurtenissen in de één van de gebieden zal leiden tot één van de andere gebieden. Tot slot zal deze paragraaf worden afgesloten met de voor- en nadelen van een SSC.

Operations Onder Operations worden de activiteiten, processen en uitvoer van de processen en activiteiten van de (ICT) shared services verstaan. Met betrekking tot Operations zullen de management vraagstukken bij de vorming van shared services vanaf het eerste moment aanwezig zijn. De aandacht voor Operations zal naar mate de shared services meer vorm krijgen steeds groter moeten worden. Zo dient nagedacht en keuzes gemaakt te worden over welke processen/activiteiten onder de shared services organisatie gaan vallen en hoe deze processen onder shared services organisatie vorm gaan krijgen. Aanvullend dient de shared services organisatie vorm te krijgen, opgezet te worden en naar behoefte aangepast te worden. De management of Operations is essentieel. Verkeerde keuzes kunnen uiteindelijk leiden tot ondergang van de shared services organisatie.

Finance Onder Finance worden de financiën van de (ICT) shared services bedoeld. In de eerste instantie zullen de financiën de project financiën/budget zijn die zijn benodigd voor het opzetten van de (ICT) shared services. Deze zullen in principe alleen kosten betreffen. Als de shared services organisatie een feit is dan zullen die de opbrengsten en kosten Risicobeheersing bij IT Splitsing & Integratie - 27 -


van de shared services organisatie zijn. Hierbij is het van belang deze goed te beheersen in relatie met de andere aandachtsgebieden (Operations, HRM en IT). Hiertoe dient de financiële functie vanaf het eerste moment een prominente rol binnen de shared services organisatie te krijgen.

HRM Onder HRM (Human Resource Management) worden alle zaken verstaan die te maken hebben met het aantrekken en behouden van personeel van (ICT) shared services. Bij de vorming van de shared service organisatie zal de nadruk anders liggen als bij een gevormde shared service organisatie. Tijdens de vorming ligt de nadruk op het behouden van personeel en kennis van de verschillende (organisatie)onderdelen waarvoor de shared services zijn bestemd. Daarnaast dient nieuw personeel aangetrokken te worden om de nieuwe shared services organisatie te bemannen. Bestaand en nieuw personeel dient geprikkeld te worden om bij de shared services organisatie te blijven. Dit kan middels beloning, opleiding, uitdagende functie(s), etc.

IT Onder IT worden alle zaken verstaan die te maken hebben met IT voorzieningen en infrastructuur van en voor de shared services. IT dient aanwezig en ingericht te zijn om de activiteiten en processen die de shared services organisatie biedt te kunnen ondersteunen en voorzien. Daarnaast dient de shared services organisatie zelf ook over de juiste IT oplossingen en kennis te beschikken voor en te voorzien aan de verschillende (organisatie)onderdelen waarvoor de shared services zijn bestemd. Hierbij dient de shared service organisatie de juiste afwegingen te maken en besluiten te nemen ten aanzien van aan te schaffen oplossingen. Hoewel IT gedurende het gehele bestaan van de shared service organisatie van belang is, zal extra aandacht besteed moeten worden tijdens de vorming van de shared services organisatie.

Risicobeheersing Onder risicobeheersing worden de maatregelen verstaan die zijn geïmplementeerd om de geïdentificeerde risico’s binnen het Shared Service Center te beheersen. Voor de risicobeheersing bij IT splitsing en integratie dient de shared service organisatie eerst de risico’s te identificeren, een kans en gevolg aan de risico’s toe te kennen. Vervolgens dient de shared service organisatie de maatregelen te beschrijven en implementeren.

Operations, Finance, HRM, IT en risicobeheersing Eerder is geschetst dat de vijf gebieden niet losstaand van elkaar zijn. Wijzigingen of gebeurtenissen in de één van de gebieden zal leiden tot één van de andere gebieden. Risicobeheersing bij IT Splitsing & Integratie - 28 -


Om die reden dient in principe in alle fasen van shared services, ook tijdens de opzetfasen, rekening gehouden te worden met de vijf eerder genoemde gebieden en bij elke keuze een afweging en analyse gemaakt te worden betreffende de impact op de andere gebieden.


3 Case studies beschrijving

3

Case studies beschrijving

3.1

Inleiding

In de Drechtsteden en Rotterdam is onderzoek verricht naar de IT splitsing en integratie. In dit hoofdstuk worden case studie beschrijvingen gegeven voor de Drechtsteden en de gemeente Rotterdam. Beide gemeenten (conglomeratie van gemeenten voor Drechtsteden) hebben in het recente verleden één of meerdere SSC’s opgezet voor hun organisatie(s). Hier zal ingegaan worden op de volgende onderwerpen ten aanzien van de vorming van SSC’s: – Situatieschets; – Model; – Proces; – Risicobeheersing; – Operations, Finance, HRM & IT. Overigens als wordt gesproken over Shared Services bij de overheid is het goed om onderscheid te maken tussen Shared Services binnen één organisatie, bijvoorbeeld een grote gemeente die de financiële administratie van verschillende diensten bundelt, en Shared Services tussen autonome organisaties, zoals het geval is bij gemeenten die besluiten een gezamenlijke inkooporganisatie op te richten. De eerste vorm wordt intrabestuurlijke Shared Services, de tweede wordt interbestuurlijke Shared Services, omdat er meerdere autonome besturen bij betrokken zijn. Voor de Drechtsteden geldt dat sprake is van interbestuurlijke Shared Services en voor de gemeente Rotterdam geldt dat sprake is van intrabestuurlijke Shared Services.

3.2

Drechtsteden

De Drechtstreden gemeenten bestaat uit de gemeenten Dordrecht, Sliedrecht, Papendrecht, Zwijndrecht, Hendrik Ido Ambacht, ‘s Gravendeel en Alblasserdam. Samen vormen de gemeenten een aaneengesloten stedelijk gebied aan de zuidrand van de randstad. De gemeenten bij elkaar hebben rond de 260.000 inwoners en werkten samen op verschillende gebieden zoals sociale zaken en onderwijs (leerplicht en schoolverlaters). De burgers en bedrijven vragen om een overheid die snel, efficiënt en klantgericht opereert. Dit betekent dat de gemeente betere dienstverlening moet aanbieden tegen een mindere prijs. Voor deze doelstellingen heeft de overheid het Nationaal Uitvoerings Programma betere dienstverlening en e-overheid (NUP) opgesteld. Om aan deze doelstellingen te voldoen en om de mogelijkheden te creëren voor vergaande regionale samenwerking werden plannen opgesteld voor het oprichten van een organisatie waar die gezamenlijke uitvoering plaats kon krijgen.



Situatieschets Halverwege 2005 is voor het oprichten van een SSC een bestuursopdracht geformuleerd. De opdracht is geformuleerd voor drie onderdelen: – Instemmen met de verkenning, definiëring, ontwikkeling en realisatie van mogelijkheden voor meer samenwerking in de Drechtsteden die leiden tot voordeel voor de deelnemende gemeenten in termen van doelmatigheid en/of kwaliteit op het gebied van ICT; – Instemmen met de verkenning, definiëring, ontwikkeling en realisatie van mogelijkheden voor meer samenwerking in de Drechtsteden die leiden tot voordeel voor de deelnemende gemeenten in termen van doelmatigheid en/of kwaliteit op het gebied van beleidsontwikkeling; – Instemmen met het uitvoeren van een verkennend onderzoek naar de wenselijkheid van een nadere organisatorische vormgeving c.q. de mogelijke organisatorische opties van de “Shared Services”. Hierbij wordt rekening gehouden met de bestaande samenwerkingsprojecten. De verkenning biedt inzicht in verschillende alternatieven, de kenmerken en de voor- en nadelen In 2006 is het bestuursplan voor het SSC opgesteld. In het bestuursplan zijn de effecten van de SSC vorming beschreven. Daarbij is zowel aandacht besteed aan de kwaliteit als de efficiency van de dienstverlening. Tevens wordt in dit bestuursplan aandacht geschonken aan het huisvesten van het SSC (met voorkeur voor één locatie). Ook de rolverdeling en –invulling binnen de gemeenten is hierin beschreven en de standaardisatie van de werkwijze. Besloten werd dat alle PIOFAH functies (personeel, informatievoorziening, organisatie, financiën, automatisering en huisvesting) in het SSC dienden te worden opgenomen. In juni 2007 is begonnen met het programma Informatievoorziening, Processen & Automatisering (IP&A). Binnen het programma IP&A zijn de volgende vier deelprogramma’s gedefinieerd: – Deelprogramma I: ICT infrastructuur; – Deelprogramma II: informatievoorziening; – Deelprogramma III: lokale projecten; – Deelprogramma IV: Processen.

Deelprogramma I: ICT infrastructuur In dit deelprogramma wordt de regionale ICT infrastructuur geregeld. Zo wordt een regionaal rekencentrum ingericht en wordt het grootste deel van de PC’s vervangen door Thin Clients (met centrale servers in het nieuwe rekencentrum). Hierdoor kunnen medewerkers op elke locatie van de Drechtsteden inloggen en werken en toch toegang hebben tot e-mail, software en bestanden. Doordat het onderhoud efficiënter en het beheer centraal uitgevoerd kunnen worden brengt dit voor de organisatie vooral een kostenvoordeel mee.



Deelprogramma II: Informatievoorziening In dit deelprogramma worden projecten opgenomen die zich richten op de uitwisseling en gebruik van gegevens. Met dit programma wordt de gegevensstroom inzichtelijker binnen de gemeente voor bijvoorbeeld de werkvoorraad. Voor de burger heeft dit als voordeel dat de gegevens worden vastgelegd in de basisregistraties. Hierdoor hoeft een burger niet steeds zijn of haar gegevens opnieuw op te geven.

Deelprogramma III: Lokale projecten In dit deelprogramma worden de lokale projecten opgenomen die niet regionaal zijn. Deze projecten zijn niet regionaal maar kunnen wel gevolgen hebben voor het regionale component. Als voorbeeld wordt genoemd dat deze diensten ook kunnen worden afgenomen in een plus pakket voor gemeenten. Zo heeft niet iedere gemeente in de Drechtsteden behoefte aan parkeervergunningen en hebben zij ook geen parkeervergunningen ondersteuning (bijvoorbeeld softwarepakket) nodig.

Deelprogramma IV: Processen Dit deelprogramma richt zich op de vorming van het SSC en de procesveranderingen. Zo wordt in dit project aandacht besteed aan het standaardiseren van systemen en processen. In het SSC worden onder andere de afdelingen HRM en financiën ondergebracht. In sommige gevallen werd dus gebruik gemaakt van verschillende systemen en processen. Voor het ontstaan van de informatievoorziening en -automatisering waren de volgende stappen opgesteld: 1 Technologie integreren en vervangen; 2 Standaardiseren van de processen en systemen; 3 Lokale initiatieven manager; 4 Regionale informatievoorziening. Op 1 april 2008 is vervolgens het SSC in gebruik genomen. Hierbij werd gekozen voor een Big Bang methode. Van de ene op de andere dag waren de medewerkers (ongeveer 450) in dienst van het SSC. Het SSC voor de Drechtsteden richt zich vanaf 2008 op de volgende gebieden: – Financiële, personele, facilitaire en juridische diensten; – Administratie en (management)informatie; – Informatisering en automatisering; – Communicatie. Deze dienstverlening is in de loop van tijd verder afgestemd op de behoefte van de partners.

Model Als model voor het SSC zijn de Drechtsteden begonnen met het 9 vlaksmodel. Dit model is niet letterlijk gebruikt. Bij de Drechtsteden is gebruik gemaakt van een Ist Soll analyse. Hierbij is gekeken naar de huidige en toekomstige bedrijfsstrategie (links Risicobeheersing bij IT Splitsing & Integratie - 32 -


boven in het 9 vlaksmodel) en naar de huidige en toekomstige informatie huishouding (rechts onder in het model). Vervolgens is een GAP analyse gemaakt en is invulling gegeven aan de Soll posities. Voor het SSC is gekozen voor een gemeenschappelijke regeling. Een gemeenschappelijke regeling is een samenwerkingsverband tussen verschillende bestuursorganen. In dit geval is het een samenwerkingsverband tussen gemeenten. Het SSC van de Drechtsteden heeft een eigen raad, bestuur en directie. De gemeenten nemen een dienstenpakket af en betalen daar een bepaald bedrag voor. In enkele gevallen kan het voorkomen dat niet alle gemeenten dezelfde diensten willen afnemen. De gemeente heeft hier dan de optie tot het afnemen van een plus pakket. In dit pluspakket zitten aanvullende diensten die gemeente specifiek zijn.

Proces Bij de oprichting van de SSC’s binnen de Drechtsteden zijn drie fasen of hoofdprocessen te onderscheiden: I. Inventarisatie; II. Migratie; III. Nazorg migratie. De invulling van de hierboven genoemde fasen zullen voor de situatie van de Drechtsteden in het hiernavolgende nader beschreven worden. Voor het vormen van het Shared Service Center is eerst een inventarisatie gemaakt van wie welke werkzaamheden uitvoert. Dit is uitgevoerd bij alle deelnemende gemeenten. Tijdens deze inventarisatie is gekeken naar welke werkzaamheden bij welke gemeenten worden uitgevoerd. Belangrijk punt hierbij is dat werd gekeken naar welke personen verantwoordelijk waren voor de werkzaamheden. Hiervan zijn personen verantwoordelijk gemaakt voor bepaalde onderdelen in het proces tot het vormen van een SSC. In dit traject worden ook prioriteiten toegekend aan uit te voeren activiteiten. Nadat de verantwoordelijkheden zijn benoemd en belegd en de prioriteiten zijn toegekend is het projectvoorstel opgesteld. Hierin is beschreven wat dient te worden bereikt met het opstellen van het SSC en welke resources hiervoor nodig zijn. Ook wordt hierin beschreven wat het te vormen SSC dient op te leveren en welke afhankelijkheden hier bij komen. I) Nulmeting

Waarbij voor het overgaan van personeel is gekozen voor een big bang (al het personeel ging van de ene op de andere dag over naar nieuwe organisatie) is voor de IT gekozen voor een strategie van gefaseerde overgang. Hierbij is het personeel eerst gefaseerd overgegaan op de nieuwe te gebruiken applicaties. Hierna is de applicatie geïmplementeerd. Qua infrastructuur is gekozen voor twee fasen. Eerst is besloten om het glasvezelnetwerk aan te leggen en vervolgens zijn alle ip-nummers gestandaardiseerd. II) Migratie (geen bigbang)



Het SSC zit nu in de nazorgfase. De in de deelprogramma’s opgenomen projecten verlopen volgens schema. Voor het rapporteren over de voorgang van de projecten wordt gebruik gemaakt van het stoplichtenmodel en wordt gerapporteerd op de onderwerpen tijd en budget. De rapportage vindt eens per kwartaal plaats en wordt gerapporteerd op het huidige niveau en op de te verwachte toekomst. Tevens wordt nu gewerkt met een verplichtingenadministratie. Hier worden de middelen gecommitteerd aan de projecten en is nu de verplichting bekend en geadministreerd. Dit maakt het rapporteren op budgetniveau inzichtelijk. De verwachting is dat eind 2010 één gestandaardiseerde, geïntegreerde en robuuste ICT-infrastructuur is gerealiseerd. III) Nazorg migratie (geen bigbang)

Risicobeheersing Tussen de SSC en de deelnemende gemeenten zijn voor de verschillende diensten die door SSC worden geleverd contracten opgesteld. Geen concrete invullingen zijn aanwezig ten aanzien van de toetsing van deze contracten en de risicobeheersing rondom de dienstverleningen die worden geboden. Een belangrijk aspect is dat, hoewel de SSC een aparte entiteit is, de eigenaarschap berust bij de verschillende/deelnemende gemeenten.

Operations, Finance, HRM & IT De introductie van het SSC voor de Drechtsteden heeft grote gevolgen voor concern en medewerkers68. De belangrijkste zijn: – De medewerkers zijn in dienst gekomen van een andere werkgever, namelijk het SSC Drechtsteden; – Medewerkers kregen te maken met andere loopbaan profielen. In de oude situatie waren er bijvoorbeeld 6 ICT managers aanwezig en dit aantal is gereduceerd. Hierdoor zijn of medewerkers weggegaan (kennis) of op een andere plek in de organisatie terecht gekomen. – De aangesloten gemeenten nu klant zijn geworden en geen eigenaar meer zijn. De gemeenten nemen nu standaard diensten af waarvoor zij een bedrag betalen. Eventuele aanvullende diensten kunnen ook worden afgenomen middels een plus pakket.

3.3

Rotterdam

De gemeente Rotterdam heeft ruim 603.000 inwoners en is na de hoofdstad Amsterdam de grootste stad van Nederland. Deze mensen tezamen met andere belanghebbenden, als bezoekers, werkenden in Rotterdam, etc., maken gebruik van de diensten en voorzieningen die de gemeente Rotterdam aanbiedt. Om haar taken goed uit te voeren heeft de gemeente Rotterdam de beschikking over 23 diensten en 68

http://www.sharedservicesbijdeoverheid.nl/praktijkvoorbeelden?category=Meerdere+terreinen&id=84



bedrijven, 11 deelgemeenten en vele honderden locaties. Bij de gemeente Rotterdam werken zo’n 13.000 ambtenaren. Binnen de gemeente Rotterdam was sprake van decentralisatie betreft de ondersteunende diensten en voorzieningen, waaronder een decentrale ICT.

Situatieschets In Rotterdam heeft het gemeentebestuur gekozen voor een scherpe koers op doelmatigheid. Door het College is in een later stadium professionaliteit toegevoegd, en een kritisch blik op taken.69 De taken betreffen die taken die de gemeente Rotterdam zelf uitvoert alsmede de taken die anderen via subsidieverstrekking voor de gemeente uitvoeren. De professionaliteit en doelmatigheid willen het gemeentebestuur langs vier lijnen verbeteren:70 1 Concentratie en standaardisatie (in ieder geval op gebied van inkoop en ICT); 2 Shared Services; 3 Outsourcing; 4 Regelgeving. Om de werkprocessen beter te stroomlijnen en dienstverlening tegen zo laag mogelijke kosten te kunnen aanbieden is binnen de gemeente Rotterdam voor gekozen om Shared Service Centers op te richten. De oprichting van de SSC’s is een gezamenlijke opdracht van de Bestuursdienst en de Service Dienst, waarbij het programmamanagement onder de verantwoording van de Service Dienst valt en de projectboard zal bestaan mensen van zowel de Bestuursdienst als Service Dienst. Alle op te richten SSC’s zullen onder de nieuwe dienst, Service Dienst, komen te vallen. In 2003/2004 zijn de mogelijkheden voor SSC vorming binnen de gemeente Rotterdam onderzocht. De reden voor dit onderzoek zijn: – Kosten verlaging/besparing geld; – Hoge kwaliteit van diensten/services; – Één concern gedachte met haar ketens (visie zoals deze in de juni 2004 brief is gepresenteerd). In 2004 is besloten om SSC’s voor de volgende vijf gebieden op te richten: – ICT; – Facilitaire Dienstverlening; – Inkoop; – PSA (personeel en salaris administratie en verwerking); – Financiële Administratie. Met betrekking tot ICT is voor gekozen om het functionele deel van de ICT onder de verantwoording van de diensten (of in een later stadium: Deelgemeentes) zelf te laten 69

A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 70 A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p.



vallen en het technische deel, inclusief de werkplekken, onder de verantwoording van de SSC te laten vallen. Ten tijde van bij opzet van de SSC’s speelden ook nog twee andere grote organisatie veranderingsprojecten, namelijk oprichting van (centrale) facilitaire dienst en reorganisatie van ongeveer 17 diensten zelf. Het reorganisatieproject van de 17 diensten had ook raakpunten met de oprichting en opzet van de SSC’s. De Service Dienst van de gemeente Rotterdam is de dienst van het concern. Deze vormt en opereert als een aparte business unit binnen de gemeente Rotterdam. De Service Dienst levert ondersteunende diensten aan de gemeentelijke diensten, deelgemeenten en stadsbestuur.71 De dienst heeft geen eigen openbare beleids- of publiekstaken, maar is uitsluitend werkzaam in opdracht van andere gemeentelijke diensten.72 De Service Dienst valt onder de verantwoording van de Procureur Generaal en Controller. Beiden zijn betrokken, vanuit een adviserende en oriënteerde rol, bij de opzet en aanpak van de SSC’s en hadden zitting in de verschillende projectboards. Naast de projectboard per op te zetten SSC had elke SSC een eigen projectorganisatie die onder andere is opgebouwd uit deelnemers uit de verschillende diensten. De verschillende projectorganisatie hadden ook deelprojectleiders die elke een deel van het project voor haar/zijn rekening nam. De volgende deelprojecten zijn te onderscheiden: 1 Management Control; 2 Service Desk; 3 Infrastructuur; 4 Communicatie; 5 Klant; 6 Huisvesting; 7 Dienst Knip; 8 Migratie Dienst; 9 Inkoop. Voor de uitvoer van de (deel)projecten is gekozen voor een combinatie van best practices, die bestaat uit een mix van Managing Successful Programs en praktische toepassing van PRINCE 2. Hierbij zijn de meest gangbare elementen uit gebruikt/toegepast. De ingeschatte risico’s zijn achteraf gezien van voldoende niveau en bevatte de belangrijkste risico’s. Voor de projectsturing is in een gezonde situatie een goede balans te zijn tussen inhoud, tijd en geld. Bij de opzet van de SSC’s binnen de gemeente Rotterdam was sprake van een oververtegenwoordiging van vakmensen die op inhoud hebben gestuurd. Hierbij is teveel gestreefd naar optimalisatie. Daarnaast werd de stuurgroep op directieniveau geadviseerd door een adviesgroep ICT die voornamelijk bestond uit de hoofden van ICT van de verschillende diensten. 71 72

http://www.rotterdam.nl/Voorziening:Servicedienst_Rotterdam_Gemeentelijke_diensten http://www.rotterdam.nl/Voorziening:Servicedienst_Rotterdam_Gemeentelijke_diensten



Initieel zijn de SSC’s gestart met vijf diensten die bereid waren op vrijwillige basis over te gaan naar een SSC en gebruik te maken van zijn diensten en services. De reden dat niet alle diensten (en eventueel alle deelgemeentes) in één keer overgingen naar de verschillende SSC’s komt door een gebrek aan druk en kracht van bovenaf. De knip tussen diensten en services die overgaan naar de SSC is gezamenlijk gemaakt. Hierbij zijn de criteria indirect aanwezig en betreft het basale zaken.

Model Bij de opzet van de verschillende SSC’s en de aanloop daar naar toe is door de gemeente Rotterdam niet echt gebruik gemaakt van een model voor de informatiemanagement. De gemeente Rotterdam heeft gekozen voor een pragmatisch insteek. Met behulp van COSO zijn de processen beschreven en ingericht. Dit is één bij de uitvoer en implementatie van de SSC’s één project geweest, dat onderdeel uitmaakt van de alle andere projecten en die overkoepelend is geweest. Ten aanzien van de klant - leverancier verhouding en relatie, en de producten en diensten die overgaan naar de SSC’s zijn deze door de Raad van Toezicht vastgesteld. Tevens heeft de Raad van Toezicht de normen voor services vastgesteld. Hoewel de besluiten en verantwoordelijkheden vastlagen, zijn deze uiteindelijk allemaal verzand. Een belangrijk aspect is de business (model) van de verschillende diensten en services die zijn overgegaan naar de SSC’s. Deze is veranderd op een aantal belangrijke gebieden namelijk de afstand met de klant is groter geworden, de geboden diensten en services zijn generieker geworden en de klanten kunnen (voor de medewerkers) andere zijn door een andere verdeling. Met betrekking tot de ICT SSC geldt voor de gemeente Rotterdam dat het gehele generieke deel en een stukje klant specifieke deel overgaat naar de SSC. In veel gevallen blijft altijd een deel apart bij de dienst achter. Een ander belangrijk aspect is dat de gebruikers een hoog verwachtingspatroon hadden. Hierbij kan intern de vraag worden gesteld of de juiste mensen met de juiste competenties aanwezig zijn. En extern wordt de ICT SSC vergeleken met de markt. Door gedwongen winkelnering is de SSC niet scherp zoals de concurrentie wel is. Hier moest de SSC wel alles of zo veel mogelijk leveren. Met betrekking tot de hoge verwachtingspatroon heeft de gemeente Rotterdam voor gekozen deze te temperen middels verwachtingsmanagement.

Proces Voorafgaand aan de uitvoer van de SSC’s is samen met de (nieuwe) directeur Shared Services een Programmaplan opgesteld. Deze zijn de resultaten van de verschillende workshops die hebben plaatsgevonden.



Bij de oprichting van de SSC’s binnen de gemeente Rotterdam zijn vier fasen of hoofdprocessen te onderscheiden: I. Nulmeting; II. Migratie; III. Nazorg migratie; IV. Nazorg. De invulling van de hierboven genoemde fasen zullen voor de Rotterdamse situatie in het hiernavolgende nader beschreven worden. Ten tijde van het besluit voor het oprichten van de SSC’s was genomen en de uitvoer daarvan was gestart, de operationele aspecten nog ingevuld dienden te worden. Zo werden projecten en groepen opgericht en werd op gestuurd volgens “de theorie” de juiste dingen te doen. Het gemis hierbij waren het gebrek aan praktijkervaring en onduidelijkheid ten aanzien van de methodiek. Voorafgaand aan de opzet of uitvoer van de SSC’s is een nulmeting geweest voor de splitsing of afscheiding van de diensten en services naar de SSC’s. Het hoofddoel van deze meting is om het kostenniveau in kaart te brengen. Daarnaast is ook een inventarisatie van gemaakt van het “park” en zijn (toekomstige) contracten. Na het onderzoek zoals dit in “3.3.1 Shared Service Centers“ en de nulmeting zijn ambtelijke discussies geweest, waarna het besluit voor het oprichten van SSC’s is genomen. Tevens zijn spelregels bepaald. Voor iedere SSC/unit is een aparte Plan van Aanpak opgesteld. Contracten zijn opgesteld en vastgelegd in Dienst Verlengingsovereenkomsten (DVO’s). Die DVO’s zijn generiek en gelden voor het gehele concern. Daarnaast zijn specifieke DVO’s opgesteld die dienst specifiek zijn. De uitgangspunten voor de SSC’s zijn continu veranderd vanwege verschillende reden, als nieuw toe te voegen diensten. I) Nulmeting (inclusief PID en realisatie PID)

Voor de migratie van de ICT alsmede de overgang naar de SSC(’s) is niet voor een big bang scenario gekozen. Binnen de gemeente Rotterdam is voor de ICT gekozen voor een zwart-wit benadering. Hierbij is een knip gemaakt voor de SSC, hetgeen resulteert in een deel dat wel overgaat naar de SSC en een deel dat niet overgaat naar de SSC. Met betrekking tot het deel dat naar de SSC overgaat, geldt dat een deel van de ICT altijd over moet. Dit betreft de generieke zaken als: netwerk, service, Office toepassingen, infrastructuur. En een deel van de ICT dat niet persé over moet, hierbij ligt de keus bij de cliënt (dienst of deelgemeente). De reden dat de gemeente Rotterdam voor deze benadering heeft gekozen, komt door het feit dat aan het begin van de SSC-vorming bij de gemeente Rotterdam zo’n 2500 applicaties in gebruik waren. Initieel en als politiek doel is wel gesteld om de applicaties te integreren, want een eerdere inventarisatie heeft een resultaat van 500-800 applicaties opgeleverd. Voor zo’n groot aantal dat boven inventarisatie zat, zou een rationaliseringsslag nodig zijn. Gezien de tijdspad heeft dit niet plaatsgevonden. Dit zou later, als de SSC’s operationeel zijn, in worden gevuld. II) Migratie (geen bigbang)

Als uitgangspunt is gekozen om het deel van de ICT dat overgaat “as is” over te laten gaan. In de eerste instantie betreft het de werkplekken, budgetten en de medewerkers. Risicobeheersing bij IT Splitsing & Integratie - 38 -


Hiermee zou per dienst één separate omgeving binnen de SSC beschikbaar zijn. Het plan was om op een later moment over een nieuw infrastructuur, integratie van applicaties, centralisatie etc. na te denken. In 2008 is uiteindelijk de nieuwe infrastructuur opgezet. Hoewel de nieuwe infrastructuur is opgezet, is deze zeker nog niet af. Tijdens de migratie en integratie waren voor de gemeente Rotterdam de volgende problemen van toepassing: – Het proces was zeer tijdsintensief. Het verliep moeizaam en kostte veel tijd en geld. – Technisch gezien waren applicaties aanwezig die lastig te migreren zijn. – Er was sprake van oude infrastructuren. – Veel data dienen geconverteerd te worden. – Sprake van veel nazorg. De overgang van de migratiefase naar de nazorg migratiefase vindt plaats tijdens de overdracht van de activiteiten aan de SSC organisatie. Onder de nazorg van de migratie vallen alle aspecten die te maken hebben met het oplossen van eventuele problemen en finetunen van de uitgevoerde migratie. Voor alle meldingen wordt gebruik gemaakt van Service Desk Tool. Hierin worden dienen alle calls aangemeld te worden en worden deze vervolgens ook gelogd. III) Nazorg migratie (geen bigbang)

Voor het managen van de SSC is een nieuw management team in het leven geroepen. Daarnaast zijn bestaande medewerkers uit de bestaande dienstorganisatie overgeplaatst van de betreffende dienste naar de verschillende SSC’s, waarbij de uitwisselbaarheid binnen de SSC, door de verscheidenheid aan en verschil tussen de infrastructuren niet altijd mogelijk was. Hoewel de structuur wel aanwezig is zijn de mensen pas op een later moment op de juiste plekken gezet, inclusief aanwas via externen en sollicitanten. Voor de bestaande medewerkers kan de vraag worden gesteld of de juiste mensen met de juiste competenties aanwezig zijn. Tot slot zijn diensten en services van de betreffende diensten overgegaan naar de verschillende SSC’s. Hierbij dienen de diensten ook hun eigen processen zodanig aan te passen dat deze aansloten op de diensten en services die aangeboden worden door de verschillende SSC’s. IV) Reorganisatie

Risicobeheersing Bij Rotterdam is de gemeente zelf eigenaar van de SSC’s. Tussen de deelnemende diensten (en deelgemeentes) en de SSC zijn Dienstverleningsovereenkomsten (DVO’s) opgesteld. In deze DVO’s zijn de afspraken vastgelegd tussen de diensten en de SSC. Een concrete invullingen ten aanzien van de toetsing van deze DVO’s en de risicobeheersing rondom de dienstverleningen die worden geboden is niet aanwezig.



Operations, Finance, HRM & IT De introductie van de SSC’s heeft grote gevolgen voor concern en medewerkers73: – De structuur van de organisatie zal veranderen: In de oude situatie hadden vrijwel alle diensten bijvoorbeeld een eigen ICT. Deze zullen voor het grootste deel “verplaatst” worden naar de SSC’s. De dienstverlening van de dienst blijft echter wel op peil, waarbij die wel anders georganiseerd dient te worden. – De SSC’s zorgen voor een andere rol- en taakverdeling binnen het concern: De diensten zijn allen de eigenaar van de SSC’s. In die rol sturen zij de vraag welke dienstverlening op de verschillende gebieden geboden gaan worden vanuit de SSC’s. De dienstverlening is zoals eerder gemeld vastgelegd in zogenaamde DVO’s. Daarnaast zijn de diensten ook de opdrachtgevers/klanten van de SSC’s voor het gebruik van hun diensten en services. Overigens is veel tijd en energie besteed aan de individuele medewerkers. Dit is veroorzaakt door het feit dat van bovenaf te weinig aandacht en draagvlak aanwezig was van het management. Hoewel de SSC’s voor de diensten grote gevolgen voor het concern en medewerkers hadden en waren bestemd voor het concern (en haar diensten en deelgemeentes) waren de diensten bij de opzet weinig betrokken. En waren deze ondervertegenwoordigd in de verschillende projectgroepen. De SSC(‘s) heeft als eindresultaat een positief effect op concernniveau. Op dienstniveau verschilt dit per dienst. Met name voor de kleinere dienst heeft de SSC een positief effect gehad. Voor de grote diensten heeft de SSC weinig tot geen effect gehad. Waarbij in sommige gevallen zelfs sprake is van negatief effect. De reden hiervoor is dat de (directe) besparingen onzichtbaar zijn en de kwaliteit vooral in het begin niet veel verschilt van de oude situatie, door de “as-is” situatie.

3.4

Bevindingen en conclusies

De belangrijkste bevindingen met betrekking tot de Shared Service Center vorming per case (Drechtsteden en Rotterdam) worden weergegeven. De bevindingen zijn geconstateerd tijdens de uitwerkingen van de case studies.

73

http://www.sharedservicesbijdeoverheid.nl/praktijkvoorbeelden?category=Meerdere+terreinen&id=84



Drechtsteden In het besluitvormingsproces is alleen een business case opgesteld voor het personeel. Voor de overige gebieden zijn geen business cases opgesteld. Gedurende het traject is de business case aangevuld met de overige onderdelen die in het SSC terecht kwamen. Bij het opstarten van het SSC bij de Drechtsteden is in eerste instantie gekeken naar hoe het SSC gerealiseerd diende te worden. Hierna kwam pas de vraag wat gaat worden aangeboden in het SSC. De aandacht ging dus te veel uit naar de organisatiestructuur en de functies daarin en te weinig naar de inhoud van het SSC (wat wordt aangeboden aan de klanten). Tevens was geen aandacht besteed aan hoe te komen tot het eindproduct (operationeel SSC). Een regie was niet aanwezig evenals de bekostiging. Het ontbrak binnen de Drechtsteden aan projectvoorstellen. Deze zijn pas gedurende het traject opgesteld. Dit had ook als gevolg dat investeringsbesluiten niet formeel waren. Deze zijn pas gedurende het traject opgesteld en geformaliseerd. Bij de Drechtsteden heeft men het inhoudelijke traject op het gebied van personeel niet goed gemanaged. Voor het personeel betekende de overgang naar het SSC voor sommige een ontwikkelsprong. Voor andere werknemers betekende het een gevaar voor de baan. Hierdoor werd bij sommige afdelingen op veel weerstand gestuit. Managers verzetten weinig werk en in de overleggen kwam vaak geen besluit. Dit is opgelost door op een gegeven moment besluiten hard door te duwen in de overleggen. Tijdens het opzetten van het SSC is geen exit strategie gehanteerd. Dit is een bewuste keuze geweest in het proces. De eigenaarrol van het SSC diende goed te zijn ingericht. De gemeenten zijn alleen mede eigenaar plus klant geworden.

Rotterdam Hoewel de resultaten van het initiële onderzoek een positieve conclusie had, was het onderzoek van een te abstract niveau en had dit concreter gemoeten. Tijdens de uitvoer en de implementatie van de SSC’s is de gemeente Rotterdam gestuit op weerstand bij medewerkers die een andere functie hebben gekregen als gevolg van de invoering van het SSC, dat betrekking op hen had. De belangrijkste redenen om een SSC’s op te richten binnen de gemeente Rotterdam zijn de centralisatie en kostenbesparing. Deze twee redenen, en met name kostenbesparing zouden ook langs andere wegen bereikt kunnen worden. De gemeente Rotterdam is een complexe organisatie met een zware politieke (macht) tint. De governance zoals deze voor de SSC’s is, is gebaseerd op het Trias Politica principe. De Trias Politica bestaat uit de volgende drie groepen: hoofd (CIO), uitvoer (SSC zelf) en de opdrachtgever(s) (diensten). Hiertussen dient evenwicht aanwezig te zijn.



Voor de opzet en inrichting van de verschillende SSC’s is geen gebruik gemaakt van een bestaand model met betrekking tot informatie management. In plaats daarvan is gekozen voor een pragmatische benadering. Veel problemen en issues hadden naar alle waarschijnlijkheid voorkomen kunnen worden als gebruik gemaakt zou zijn van een op de gemeente Rotterdam van toepassing zijnde model met een praktische invulling daarvan. Bij de overgang en aansluiting van de verschillende diensten (en eventueel alle deelgemeentes) op de verschillende SSC’s ontbrak de druk en kracht van bovenaf. Wel werden de zaken van bovenaf opgelegd. Dit werd tevens versterkt voor het feit dat enerzijds niet echt één baas aanwezig of aangesteld was en de “tijdelijke” hoofden continu aan verandering onderhevig waren. Dit bemoeilijkt de uitvoer van het project en maakt het project ingewikkelder. Alle genomen belangrijke besluiten moesten via commitment doorgedrukt worden. Ten tijde van bij opzet van de SSC’s speelden ook nog twee andere grote organisatieveranderingsprojecten, namelijk oprichting van (centrale) facilitaire dienst en reorganisatie van ongeveer 17 diensten zelf. En ten tijde van het besluit voor het oprichten van de SSC’s waarna de start kort daarop volgende, diende de operationele aspecten nog ingevuld te worden. De insteek was volgens “de theorie” de juiste dingen te doen. Het gemis hierbij waren het gebrek aan praktijkervaring en onduidelijkheid ten aanzien van de methodiek. Hierdoor waren de plannen te expliciet en uitgewerkt en hadden deze achteraf gezien pragmatischer ingestoken moeten worden. Tevens waren de besluiten en verantwoordelijkheden, hoewel deze allemaal vastlagen, uiteindelijk allemaal verzand. De verandering in business ten aanzien van een grotere afstand met de klant, de generiekere geboden diensten en services en andere verdeling van de klanten (voor de medewerkers) is onderschat en heeft tot issues geleid. Hier bovenop komt nog de gedwongen winkelnering bij de SSC. Waardoor de SSC niet op scherp is gezet en SSC voor heeft gekozen zo veel mogelijk te leveren. Bij de opzet van de SSC’s waren de diensten bij de opzet weinig betrokken. Hierdoor begrepen de gebruikers het niet meer of raakten de weg kwijt. Daarnaast was het ook zo dat de bij het opzet proces de gemeente Rotterdam iets te intern gekeerd was en weinig buiten de gekeken is. De meeste diensten/onderdelen die in de eerste instantie meededen met de overgang naar de SSC’s waren cynisch. In bijna alle gevallen was de verandermanager, die belast is met het besluit tot ontmanteling, tevens de initiële of zittende afdelingshoofd/hoofd I&A. Hierdoor is het risico aanwezig dat een negatieve sfeer ontstaat met een slecht perspectief. Tevens wordt dit in sommige gevallen versterkt door het feit dat medewerkers bij de verschillende diensten, die potentiële kandidaten zijn voor de SSC’s, voelen dat zij in een onzekere situatie terecht komen. Voor de gemeente Rotterdam is de overstap naar SSC’s een cultuuromslag. Voor de verschillende diensten is dit een overgang van autonomie of autonome Risicobeheersing bij IT Splitsing & Integratie - 42 -


eenheid/eenheden naar een onderdeel in de keten. Hoewel dit helemaal in de concerngedachte pas van de gemeente Rotterdam, hoeft het niet op die manier door de verschillende diensten ervaren te worden. Bij het opstellen van de DVO’s zijn zaken te goed vastgelegd, hierdoor zijn de DVO’s onnodig dik en uitgebreid geworden. Hierin is de gemeente Rotterdam te ver doorgeschoten. Op een later moment heeft de gemeente Rotterdam deze zowel in aantal als in inhoud teruggebracht met behoud van de één organisatie gedachte. Zo zijn de DVO’s geen doel meer op zich, zoals deze in de eerste instantie wel waren, maar een middel geworden. Binnen de gemeente Rotterdam is in de eerste instantie gekozen voor aparte infrastructuren. Met andere woorden de infrastructuren zoals deze bij de verschillende diensten stonden werden “as is” overgenomen. Hoewel dit weinig risico met zich meebracht, zou het idealiter handiger geweest zijn om alvast één doel infrastructuur ingericht te hebben en vervolgens de migratie stap voor stap uit te voeren. Per dienst of voor alle diensten dient de voor de aanwezige applicaties de rationaliseringsslag gemaakt te worden. Vervolgens dient netwerk/infrastructuur voor netwerk overgezet te worden. Hoewel de “as is” insteek voor de hand lag en op het eerste gezicht de meeste simpele vorm van transitie is, heeft deze insteek toch tot issues geleid. De reden hiervoor is dat “as is” aan de ene kant niet altijd mogelijk is en aan de andere kant is de “as is” ook niet in de sommige gevallen ook niet goed vast te stellen. Tot slot heeft de “as is” situatie, die voor de betreffende dienst goed en probleemloos functioneert, bij de SSC geleidt tot een duurder en minder goed voor de dienst werkende situatie. Het in lagen overzetten van de “as-is” situatie naar een nieuwe infrastructuur zou in principe een beter optie zijn geweest, maar de kosten zullen dan wel beduidend hoger hebben gelegen. Een ander bijkomend nadeel van de “as is” overzetting is dat de medewerkers, die initieel bij de verschillende ICT werkzaam zijn en uiteindelijk onderdeel van de SSC werden moeilijk uitwisselbaar zijn binnen de SSC, door de verscheidenheid aan en verschil tussen de infrastructuren. Immers is elke infrastructuur nieuw voor hen. En de “as is” overzetting wordt soms “rommelig” met personeel, door bijvoorbeeld redundantie en ongestructureerdheid. Want de nieuwe (SSC) organisatie is opgebouwd uit een samenraapsel van ex-medewerkers van de verschillende diensten. Hoewel de structuur wel aanwezig is zijn de mensen pas op een later moment op de juiste plekken gezet, inclusief aanwas via externen en sollicitanten. Voor de bestaande medewerkers kan de vraag worden gesteld of de juiste mensen met de juiste competenties aanwezig zijn. Vele van de hierboven genoemde punten hebben uiteindelijk voor de SSC’s geleid tot een lage acceptatie van het implementatie proces en een verslechtering van het imago. Bij de opzet van de SSC’s en tijdens en na de “as is” overzetting is weinig sprake van management van verwachtingen. Dit heeft uiteindelijk negatief effect gehad voor de start van de verschillende SSC’s. In 2009 is dan ook een rapport van de Rekenkamer verschenen met twee belangrijke bevindingen: Risicobeheersing bij IT Splitsing & Integratie - 43 -


– –

De ICT SSC ontbrak aan beleid en structuur/kader. Dit heeft geleid tot het aanstellen van een CIO. De ICT SSC is in onvoldoende mate van grond gekomen. Dit heeft geleid tot een aparte directeur voor ICT.


4 Analyse van bevindingen en conclusie

4

Analyse van bevindingen en conclusies

Uit het vorige hoofdstuk is gebleken dat de vorming van ICT Shared Services niet zonder horten en stoten kan verlopen. In beide gevallen is gekozen voor een “as is” overzetting van de ICT Services en systemen. De voornaamste reden hiervoor is dat hiermee de ICT Services en systemen intact blijven en zorgt voor een zo stabiel mogelijk situatie voor verschillende gebruikersgroepen. Op een later moment zal dan worden nagedacht over een nieuw doel architectuur met behoud van bestaande services en diensten. Aan de andere kant zou naar alle waarschijnlijkheid het risico te groot en ook te veel werk zijn om die zaken te combineren (overgang van de diensten en services naar de ICT SSC gecombineerd met overgang naar een nieuwe doelarchitectuur). In het hiernavolgende zal een algemene analyse volgen voor de theorie, de case studies van Drechtsteden en de gemeente Rotterdam.

4.1

Model

Het model is bedoeld om voor, tijdens en na het (vormings)proces inzichtelijk te krijgen hoe de ICT SSC-organisatie vorm dient te krijgen. Hiermee is meteen duidelijk welke delen bij de achterblijvende of uitbestedende organisatie(onderdelen) horen en welke delen onder de SSC zullen gaan vallen. De keuzes die hier worden gemaakt hebben directe impact op zowel het “Proces” als “Operations, Finance, HRM & IT”. Hoewel het gebruik van modellen, als het 9 vlaksmodel, niet heilig en zeker niet verplicht is, biedt dit wel houvast voor en een betere ondergrond bij de vorming en inrichting van ICT SSC’s. Zowel Drechtsteden als de gemeente Rotterdam heeft (zo goed als) geen gebruik gemaakt van enig model. In plaats daarvan hebben zij beide gekozen voor een pragmatisch insteek. De pragmatisch insteek is grotendeels gebaseerd op een IST en SOLL analyse. Het risico hierbij is dat zaken ten onrechte niet of wel worden meegenomen. Gedacht kan worden aan diensten of services die achteraf gezien toch te specifiek zijn en beter bij de achterblijvende of uitbestedende organisatie(onderdelen) hadden kunnen blijven doordat deze te specifiek zijn.

4.2

Proces

Om tot een SSC te komen dient een aantal stappen doorlopen te worden, het proces. Wederom net als het model is het proces ook niet heilig en zeker niet verplicht. Wel biedt dit wel houvast voor en een betere ondergrond bij de vorming en inrichting van ICT SSC’s. Hoewel het proces zoals dit is beschreven in “2.4 Fasen Shared Service Center (vormingsproces)” niet geheel van toepassing is voor zowel Drechtsteden als de gemeente Rotterdam door de overgang van “as is” situatie, zijn die punten die wel in ogenschouw genomen hadden moeten worden voor een deel niet gedaan. Goede voorbeelden hiervan zijn dat:


4 Analyse van bevindingen en conclusie

– – –

4.3

In de eerste instantie de focus lag op de SSC realisatie, in plaats van de invulling van de SSC; Betrokkenheid vanuit de uitbestede diensten en (deel)gemeenten laag is; SSC’s nog steeds niet af zijn, na een proces dat momenteel 3 jaar bezig is.

Risicobeheersing

Bij beide organisaties wordt gebruik gemaakt van contracten (of DVO’s) tussen de leverende en afnemende partij. In deze contracten worden de afspraken vastgelegd. Geen concrete invullingen zijn aanwezig ten aanzien van de toetsing van deze contracten en de risicobeheersing rondom de dienstverleningen die worden geboden. Daarnaast hebben de deelnemende partijen (mede) eigenaarschap of maken deel uit van de zelfde organisatie. Tot slot dient ook nog vraagtekens geplaatst te worden bij de daadwerkelijke invulling, toetsing en afrekening binnen de grenzen van de contracten.

4.4

Operations, Finance, HRM & IT

Op het gebied van operations, finance, HRM & IT is bij beide organisaties te weinig aandacht besteed op het bestuurlijk niveau. Oorzaak hiervoor was dat te weinig aandacht is besteed aan het model en proces voor totstandkoming van het SSC. Wanneer de organisatiegebieden vanuit bestuurlijk niveau voldoende aandacht hadden gehad in het gehele traject waren bijvoorbeeld de verschillende diensten bij Rotterdam meer betrokken geweest bij de opzet. Ook is bij beide organisaties sprake van een sterke cultuuromslag. De medewerkers gingen van een ondersteunende afdeling naar een prestatiegedreven afdeling. Waarbij de organisatie wordt afgerekend op prestatienormen.

4.5

Conclusies

Samengevat hebben beide onderzochte SSC’s tijdens het vormings- en invullingsproces op zowel model, proces, risicobeheersing als operations, finance HRM en IT gebieden tekortkomingen. Deze tekortkomingen hebben aan de ene kant uiteindelijk impact op de SSC en de resultaten van het vorming- en invullingproces gehad en aan de andere kant in de toekomst impact hebben op de SSC zelf en haar afnemers. Om de (belangrijkste) risico’s in een vroeg stadium te identificeren en deze te beheersen dient een control framework opgesteld te worden en aanwezig te zijn. Tot slot dienen zaken die initieel verkeerd/anders zijn gelopen gecorrigeerd te worden aan de hand van het beschikbare control framework.


5 IT Audit Framework

Ontwikkeling van de IT Audit Framework

5

Om de vorming van ICT SSC’s in goede banen te leiden, deze na de vorming zo effectief en efficiënt mogelijk te laten presenteren en in alle fasen in “control” te zijn, dienen de risico’s op alle gebieden en in alle fasen beheerst te worden. Het woord risico dient hier breed geïnterpreteerd te worden. Zo vallen bijvoorbeeld performance improvements kenmerken van SSC’s ook onder de potentiële risicogebieden. Immers, een slecht presterende SSC is ook een bedreiging voor haarzelf alsmede de afnemende klanten en daarmee de overkoepelde organisatie. Ten einde alle risico’s overzichtelijk te bundelen is een control framework voor de IT splitsing en integratie opgesteld. Hieronder is het control framework voor IT splitsing en integratie weergegeven. Het framework bestaat uit twee verschillende lagen te weten Proceslaag en de Organisatie(gebieden)laag. Figuur 14: Model IT splitsing en integratie ICT services (middels Shared Services Center)

Organisatielaag

Proceslaag

Strategiefase

Haalbaarheidsfase

Ontwerpfase

Bouw -en testfase

Implementatiefase

Optimalisatiefase

Risico’s

Risico’s

Risico’s

Risico’s

Risico’s

Risico’s

• Onvoldoende draagvlak stakeholders • Onjuiste strategie en afbakening

• Ontbreken business case • Onvoldoende en/of onjuiste analyse

• Onvoldoende en / of onjuiste ontwerpen / blauwdrukken • Onvoldoende en / of onjuiste SLA’s • Ontbreken migratiestrategie

• Onvoldoende kennis en ervaring voor bouw • Geen/onjuiste teststrategie en onvoldoende testwerkzaamheden

• Onvoldoende testen van implementatie en migratie • Ontbreken AO/IC • Onvoldoende support pre en post implementatie

• Afwezigheid review en optimalisatie actiepunten •Onvoldoende invulling risico beheersing

Maatregelen

Maatregelen Maatregelen





• Draagvlak van stakeholders creëren • Strategie bepalen op basis van doelstelling

• Opstellen realistische business case en afstemming met de betrokken afdelingen • Opstellen van procesanalyse, ICT analyse en risico analyse

• Opstellen van organisatie ontwerp, infrastructuur (inclusief ICT) ontwerp • Bepalen afspraken en vastleggen in SLA’s •Bepalen migratiestrategie

• Opstellen van processtappen en ontwikkelen gebruikersdocumentatie • Vastleggen ontwikkeling maatwerk • Ontwerp teststrategie en ontwikkel testplannen

• Testen van implementatie • Opstellen van AO/IC OA/IC •Voldoende support pre en post implementatie verkrijgen

• Review momenten inregelen en optimalisatie actiepunten opstellen en uitvoeren • Risico’s identificeren en deze beheersen

Operations, Finance, HRM & IT Risico’s

Maatregelen

• Ontbreken Projectmethodologie (acceptatiecriteria) • Ontbreken voortgangsmonitoring (Go / No Go) • Onvoldoende betrokkenheid medewerkers • Onvoldoende beheersing veranderingsmanagement

• Kiezen voor een duidelijke (en praktisch toegepaste) projectmethodologie • Duidelijke en concrete voortgangmonitoring inbouwen • Medewerkers (en eventueel andere stakeholders) in een vroeg stadium betrekken • Veranderingen identificeren, analyseren en beheersen



Proceslaag In de proceslaag is weergegeven welke fasen uitgevoerd dienen te worden voor de totstandkoming van het SSC. Deze fasen zijn achtereenvolgens: – Strategiefase; – Haalbaarheidsfase; – Ontwerpfase; – Bouw -en testfase; – Implementatiefase; – Optimalisatiefase. Per proces in de proceslaag zijn de (belangrijkste) risico’s met de daarbij behorende maatregelen weergegeven. Deze zullen verderop in dit hoofdstuk nader worden uitgewerkt.

Organisatielaag In de organisatielaag zijn de organisatiegebieden weergegeven waarin gedurende en na de vorming van het SSC aandacht aan geschonken dient te worden. Deze organisatie gebieden zijn: – Operations; – Finance; – HRM; – IT. Per organisatie gebied zijn de (belangrijkste) risico’s met de daarbij behorende maatregelen weergegeven. Deze zullen verderop in dit hoofdstuk nader worden uitgewerkt.

5.1

Proceslaag

Binnen de proceslaag zijn per processtap risico’s geïdentificeerd met eventuele maatregelen die daarbij horen. In het hiernavolgende zullen deze nader worden uitgewerkt/toegelicht.

Strategiefase De belangrijkste risico’s die in de strategiefase zijn geïdentificeerd zijn: – Onvoldoende draagvlak stakeholders: Vanaf het begin dienen stakeholders betrokken te worden bij het opzetten en verder uitbouwen van ICT SSC’s. Stakeholders zijn alle belanghebbenden die een rol spelen of zullen spelen in de uiteindelijke ICT SSC. Te denken valt aan onder andere de gebruikers(organisaties), huidige medewerkers in de decentrale Risicobeheersing bij IT Splitsing & Integratie - 48 -


–

ICT organisaties en die uiteindelijk overgaan naar de centrale ICT SSC en eventuele nieuwe eigenaren van de ICT SSC. Onvoldoende betrokkenheid en draagvlak van de stakeholders brengt het risico met zich mee dat de op te richten ICT SSC en de uiteindelijk opgerichte ICT SSC niet de resultaten oplevert zoals men initieel gedacht zou hebben. Deze kunnen zijn ontstaan door onder andere weerstand, verkeerde input en daarmee ook verkeerde output (met en zonder opzet), en onvolledigheid. Draagvlak en betrokkenheid van stakeholders kan gecreëerd worden door: 1. Heldere, eenduidige en continue communicatie over de huidige status en de zaken die nog gaan komen naar de stakeholders; 2. Voorlichtingen en presentaties te geven over gemeenschappelijk belang, het plan en de voordelen van een ICT SSC; 3. Rollen en verantwoordelijkheden “as is” and “to be” helder te hebben en deze uit te dragen en in te vullen tijdens de opzet en na voltooiing van de ICT SSC. Onjuiste strategie en afbakening: Het bepalen van de strategie en vervolgens de afbakening van de gebieden waar en in welke omvang de werkzaamheden zullen liggen zijn essentieel. Essentieel voor het verdere verloop bij het opzetten en onderhouden van de SSC. Door een verkeerd gekozen strategie en daarmee ook een verkeerde afbakening van het project en SSC bestaat het risico dat het uiteindelijke SSC niet aansluit aan de wensen en eisen (behoeften) van de gebruikersorganisatie. Om een juiste/goede strategie te bepalen, dient de strategie bepaald te worden op basis van doelstellingen (zo goedkoop mogelijk, beste producten, meest klantvriendelijk of een mix van de twee of drie genoemde). Als de strategie eenmaal is bepaald dan dienen de doelstellingen geformuleerd te worden en goede afbakening voor de uiteindelijke SSC gedaan te worden.

Haalbaarheidsfase De belangrijkste risico’s die in de haalbaarheidsfase zijn geïdentificeerd zijn: – Ontbreken business case: De business case heeft als doel de huidige situatie, de gewenste situatie en de te ondernemen stappen te beschrijven. Uit de business case moet ook blijken of de investeringen (en veranderingen) opwegen tegen de voordelen die de SSC uiteindelijk met mee zal brengen. Het risico van het niet hebben van een (volledige) business case is dat de uiteindelijke SSC niet aansluit en/of de voordelen oplevert die men in de eerste instantie heeft beoogd. De businesscase dient opgesteld te worden. In de business case dienen ten minste de volgende onderwerpen opgenomen te worden: 1. Huidige situatie en de gewenste situatie; 2. De strategie om de gewenste situatie te bereiken; 3. Geschatte kosten en opbrengsten; 4. HRM beleid. De business case dient te worden voorgelegd aan de verantwoordelijken alle betrokken onderdelen van het te vormen SSC. Risicobeheersing bij IT Splitsing & Integratie - 49 -


–

Onvoldoende en/of onjuiste analyse: Het niet doen of doen van onvoldoende of onjuiste analyse kan uiteindelijke resulteren in verkeerde beslissingen ten aanzien van de op te richten SSC. Het risico is dat aan de ene kant tijdens de opzet van de SSC tegen issues aangelopen zal worden waar geen rekening mee is gehouden en aan de andere kant de SSC wordt opgezet/ingericht met verkeerde veronderstellingen. De volgende analyses dienen te worden uitgevoerd en opgesteld: 1. ICT-analyse: In de ICT analyse dient het huidige ICT landschap in kaart te worden gebracht. Dit dient te worden vergeleken met de nieuwe gewenste ICT situatie. 2. Procesanalyse: In de procesanalyse worden de bedrijfsprocessen in kaart gebracht die worden opgenomen in het SSC. Hierbij dient in kaart te worden gebracht wie waarvoor verantwoordelijk is en hoe de processen lopen. 3. Benchmarkanalyse: In de benchmarkanalyse worden eventuele benchmarks geanalyseerd. Met de benchmarks dienen ook de benodigde kosten en baten analyses gemaakt te worden. 4. Risicoanalyse: In de risicoanalyse dienen de risico’s van het nieuwe SSC te worden geïnventariseerd. Tevens dienen de maatregelen om de risico’s te mitigeren te worden beschreven.

Ontwerpfase De belangrijkste risico’s die in de ontwerpfase zijn geïdentificeerd zijn: – Onvoldoende en/of onjuiste ontwerpen/blauwdrukken: Ontwerpen en blauwdrukken zullen eindelijk de bouwtekeningen voor zijn voor hoe de SSC uit dient te zien. Risico bij ontwerpen/blauwdrukken die onvoldoende of onjuist zijn is dat dit resulteert in verkeerde inrichting en opzet van de SSC. De volgende ontwerpen dienen in ieder geval aanwezig te zijn: 1. Organisatie ontwerp: In het organisatie ontwerp dient te worden beschreven wat de structuur wordt van het op te richten SSC, inclusief de team / bemensing. 2. Infrastructuur inclusief ICT ontwerp: In het infrastructuurontwerp dient (aan de hand van de huidige situatie) beschreven te worden hoe de nieuwe (ICT) infrastructuur uit dient te zien. – Onvoldoende en/of onjuiste SLA’s: SLA zijn de afspraken die gemaakt worden tussen de deelnemende partijen. Essentieel is dat deze voldoende dienen te zijn opdat deze realistisch en voldoende zijn. Het risico bij onjuiste of onvoldoende SLA’s is dat voor de aanbieder een onhaalbare situatie en de voor afnemer een gewenste/ontoereikende situatie wordt gecreëerd. Tussen de deelnemende partijen moeten de gemaakte afspraken worden vastgelegd. Dit dient dan gedaan te worden in een SLA. Hierin worden afspraken over het onderwerp van de overeenkomst, beschrijving van de dienst (inclusief afbakeningen), duur en beëindiging van de overeenkomst, overlegstructuren, eigendom, beveiliging van systemen, financiële vergoeding, geschillen en



–

rapportages. Deze dienen afgestemd en geaccordeerd te worden door zowel de aanbieder als afnemer. Ontbreken migratiestrategie: De migratiestrategie bepaalt in welke mate en hoe de bestaande situatie overgaat naar de nieuwe situatie waarbij sprake is van een SSC. Hierbij dient de migratie breed gezien te worden. Gedacht kan worden aan de organisatiemigratie, infrastructuurmigratie, et cetera. Voor elke migratie dient nagedacht te worden hoe deze beste benaderd en uitgevoerd kan worden. Door het ontbreken van een (goed) migratiestrategie bestaat het risico dat zaken te snel en niet gecontroleerd/beheerst worden uitgevoerd. Als migratiestrategie dient men te beslissen of gefaseerd wordt overgegaan of een grote overgang zal worden gehanteerd. Deze strategie kan verschillen per onderdeel. Bijvoorbeeld voor techniek kan men besluiten gefaseerd over te gaan terwijl voor personeel een grote overgang kan worden gerealiseerd. Tevens dient bij het bepalen van de migratiestrategie ook de randvoorwaarden meegenomen te worden.

Bouw -en testfase De belangrijkste risico’s die in de bouw -en testfase zijn geïdentificeerd zijn: – Onvoldoende kennis en ervaring voor bouw: Voor de bouw van het SSC is het van belang dat voldoende kennis en ervaring aanwezig is om het SSC te realiseren. De plannen gerealiseerd in de ontwerpfase worden hier gebouwd. Gedacht kan worden aan maatwerk programma’s en interfaces. Wanneer onvoldoende kennis aanwezig is voor de bouw hiervan bestaat het risico dat maatwerk niet goed wordt ontwikkeld en dat interfaces niet betrouwbaar werken. Om dit risico te mitigeren dient de organisatie het maatwerk te documenteren en gebruikersdocumentatie op te stellen. – Geen of een onjuiste teststrategie en het niet uitvoeren van voldoende testwerkzaamheden: Wanneer de organisatie in de testfase is beland bestaat het risico dat onvoldoende testwerkzaamheden worden uitgevoerd. Dit kan uiteenlopen van onvoldoende testwerkzaamheden voor de processen tot het testen van de technologie. Wanneer niet voldoende testwerkzaamheden worden uitgevoerd bestaat het risico dat fouten niet tijdig worden geconstateerd en dat niet wordt voldaan aan gestelde acceptatie criteria. Om te waarborgen dat voldoende testwerkzaamheden worden uitgevoerd dienen de volgende stappen te worden uitgevoerd: 1. Teststrategie: Hierbij dient te worden opgesteld welke onderdelen worden getest, door wie wordt getest en hoe de resultaten worden vastgelegd. Van belang is ook dat acceptatiecriteria worden vastgelegd en dat vastligt wie het besluit neemt van acceptatie. 2. Testplannen: Nadat de teststrategie is opgesteld dient in testplannen te worden vastgelegd welke onderdelen per te testen onderdeel worden getest. Hierbij is het belangrijk om de personen die hier dagelijks mee werken en verantwoordelijk zijn bij het opstellen van de testplannen te Risicobeheersing bij IT Splitsing & Integratie - 51 -


betrekken. Zij kunnen immers aangeven of alle relevante onderdelen zijn geraakt.

Implementatiefase De belangrijkste risico’s die in de implementatiefase zijn geïdentificeerd zijn: – Onvoldoende testen van implementatie en migratie: Bij de overgang van de activiteiten van de huidige situatie naar het SSC is het belangrijk dat de migratiestrategie duidelijk is beschreven en dat deze is getest. Wanneer dit niet is gedaan bestaat het risico dat problemen zich voordoen tijdens de migratie of dat medewerkers niet weten welke werkzaamheden uitgevoerd dienen te worden. Dit kan worden verholpen door duidelijk de migratiestrategie te beschrijven en verschillende proefmigraties te houden. De resultaten uit deze proefmigratie dient te worden vastgelegd en eventuele problemen dienen te worden opgelost voor de finale migratie. – Ontbreken AO/IC: Wanneer de AO/IC niet is beschreven in de organisatie bestaat het risico dat onduidelijk is hoe de processen binnen het SSC worden uitgevoerd en wie verantwoordelijk is. Belangrijk is dus dat de AO/IC wordt beschreven en hierbij de verantwoordelijke worden aangegeven en de controle momenten in de processen worden beschreven. – Onvoldoende support pre en post implementatie: Tijdens het gehele traject van migratie is het van belang om voldoende support te hebben. De support betreft hier zowel de bestuurlijke support, de personele support en de IT support. Indien een van deze drie factoren niet voldoende support levert bestaat het risico dat het implementatietraject te veel tijd in beslag neemt of zelfs wordt geannuleerd. De support kan op de volgende manieren worden behaald: 1. Communiceer het migratieplan en de planning naar de stakeholders. Ook tijdens het traject dient de communicatie in stand te worden gehouden; 2. Train het personeel tijdig om te werken met de nieuwe systemen en processen en informeer het personeel tijdens het implementatietraject; 3. Zorg voor voldoende IT ondersteuning omdat op grote schaal met nieuwe systemen wordt gewerkt.

Optimalisatiefase De belangrijkste risico’s die in de optimalisatiefase zijn geïdentificeerd zijn: – Afwezigheid review en optimalisatie actiepunten: Wanneer het SSC operationeel is, is het belangrijk dat de werking hiervan wordt bekeken en beoordeel. Indien dit niet wordt gedaan bestaat het risico dat de prestaties niet zoals afgesproken of dat de kosten van het SSC meer zijn dan vooraf besloten. Hierdoor is het belangrijk om na de implementatiefase de prestaties van het SSC tegen de business case aan te houden en daar waar nodig aanpassingen te maken.



–

5.2

Onvoldoende invulling risicobeheersing Nadat het SSC in gebruik is genomen wordt volgens de nieuwe processen en met de nieuwe systemen gewerkt. Hierdoor kan het voorkomen dat risico’s die gelden in de oude situatie niet meer van toepassing zijn in de nieuwe situatie en dat nieuwe risico’s aanwezig zijn. Belangrijk is hier om de risico’s in kaart te brengen voor de nieuwe situatie en te inventariseren of voldoende maatregelen zijn geïmplementeerd om de risico’s te mitigeren.

Organisatielaag

De belangrijkste risico’s die in de optimalisatiefase zijn geïdentificeerd zijn: – Ontbreken van projectmethodologie: Bij aanvang van het project dient de organisatie een projectmethodologie te definiëren. Het risico van het ontbreken van een methodologie is dat sturing ontbreekt bij de uitvoering van het project. Hierdoor dient de organisatie vooraf te beslissen welke projectmethodologie wordt gehanteerd. – Ontbreken van voortgangsmonitoring: Voor het opzetten van een SSC is een goede voortgangsmonitoring van belang. Wanneer een organisatie een goede voortgangsmonitoring heeft kan tijdig worden bijgestuurd wanneer planning dreigt te worden overschreden of wanneer kosten te hoog worden. Indien men dit niet heeft bestaat het risico dat geen goed beeld aanwezig is over het gehele project. De organisatie dient een goede voortgangsmonitoring te implementeren waarbij wordt gemonitord op tijd (voortgang) en budget. De resultaten hiervan dienen te worden besproken in een stuurgroep / projectgroep waar beslissingen worden genomen over vervolgacties. – Onvoldoende betrokkenheid medewerkers: Het nieuwe SSC heeft betrekking op veel medewerkers in de organisatie. Hierdoor is het van belang dat deze medewerkers voldoende betrokkenheid hebben bij het nieuw op te richten SSC. Wanneer dit niet wordt gedaan bestaat het risico dat medewerkers dwars gaan liggen en dat het project vertraging op loopt. Betrokkenheid van nieuwe medewerkers kan worden behaald door het personeel tijdig (in beginfase) te betrekken in het project van het SSC. Ook kan de betrokkenheid worden vergroot door trainingen te geven. – Onvoldoende beheersing verandermanagement: Bij de overgang naar een SSC dienen de veranderingen in de organisatie op een voldoende manier worden beheerst. Wanneer dit niet wordt gedaan bestaat het risico dat de veranderingen niet goed worden doorgevoerd. De veranderingen in de organisatie dienen dus te worden geïdentificeerd, geanalyseerd en uiteindelijk te worden beheerst.



5.3

Samenvatting

Het onderzoek had tot doel een control framework vanuit het perspectief van IT Audit op te zetten om invulling te geven aan de risicobeheersing bij IT splitsing en integratie bij de vorming van ICT Shared Services. Het control framework is in dit hoofdstuk gepresenteerd met de belangrijkste risico’s vanuit het perspectief van IT Audit. De meeste risico’s vinden hun oorsprong in de theorie, hierbij is ook gekeken naar de praktijksituaties (in hoeverre de risico’s ook in de praktijk manifesteren en met welk belang/gevolg). Risico’s dienen goed ondervangen en beheerst te worden bij de opzet en gebruik van de SSC om zo tot een excellente SSC te komen.


6 Vraag & antwoord

6

Beantwoording onderzoeksvragen

Voor de beantwoording van de centrale onderzoeksvraag waren 3 deelvragen te onderscheiden: 1. Welke fasen en managementvraagstukken zijn in het proces te onderscheiden? 2. Welke risicogebieden horen daarbij? 3. Welke elementen moeten worden in het kader van risicobeheersing worden opgenomen in de control framework? Deze deelvragen hadden tot doel de volgende centrale onderzoeksvraag te beantwoorden: 4. Op welke wijze kan risicobeheersing invulling krijgen bij IT splitsing en integratie bij de vorming van ICT Shared Services, en kan een control framework hiervoor ontwikkeld worden vanuit het perspectief van IT Audit? In dit hoofdstuk zullen de vragen in het hiernavolgende kort worden beantwoord: 1. Om de risico’s goed te identificeren en goed te beheersen is gekozen voor een elementaire verdeling in fasen en niet voor een generalistisch verdeling over alle fasen heen. Deze zijn benoemd in hoofdstuk 5 “IT Control Framework”, namelijk: Strategiefase, Haalbaarheidsfase, Ontwerpfase, Bouw -en testfase, Implementatiefase en Optimalisatiefase. Deze fasen komen overeen met de fasen die doorlopen dienen te worden bij de vorming van een (IT) SSC, met dien verstande dat de laatste fase een cyclische fase is. Deze heeft namelijk geen eind. Een SSC dient steeds te zoeken naar optimalisatie en daarmee naar verbeteringen. Het SSC dient niet stil te staan en met de tijd mee te gaan en verbeteringen te realiseren op allerlei gebieden. Daarnaast zijn een aantal aspecten dat voor alle fasen geldt. Dit valt onder de organisatielaag. De organisatielaag bestaat uit de volgende elementen: Operations, Finance, HRM en IT. Ook de organisatielaag met haar elementen wordt in hoofdstuk 5 “IT Control Framework” benoemd en verder toegelicht. 2. De risicogebieden die horen bij de fasen/ elementen uit de proceslaag en organisatielaag worden eveneens in hoofdstuk 5 “IT Control Framework” behandeld: – Strategiefase: “onvoldoende draagvlak stakeholders” en “onjuiste strategie en afbakening”; – Haalbaarheidsfase: “ontbreken business case” en “onvoldoende en/of onjuiste analyse”; – Ontwerpfase: “onvoldoende en/of onjuiste ontwerpen/ blauwdrukken”, “onvoldoende en/of onjuiste SLA’s” en “ontbreken migratiestrategie”;


6 Vraag & antwoord

–

– – –

Bouw -en testfase: “onvoldoende kennis en ervaring voor bouw” en “geen of een onjuiste teststrategie en het niet uitvoeren van voldoende testwerkzaamheden”; Implementatiefase: “ onvoldoende testen van implementatie en migratie”, “ontbreken AO/IC” en “onvoldoende support pre en post implementatie”; Optimalisatiefase: “afwezigheid review en optimalisatie actiepunten” en “onvoldoende invulling risicobeheersing”; Operations, Finance, HRM & IT: “ontbreken van projectmethodologie”, “ontbreken van voortgangsmonitoring”, “onvoldoende betrokkenheid medewerkers” en “onvoldoende beheersing verandermanagement”.

3. De elementen die in het control framework opgenomen dienen te worden zijn in de punten 1 en 2 reeds beschreven, de proceslaag met de verschillende fasen en de organisatielaag met de verschillende elementen. 4. Risicobeheersing bij IT splitsing en integratie bij de vorming van ICT Shared Services krijgt invulling door te kiezen voor een elementaire benadering. Hierbij dient bij de vorming van ICT Shared Service de verschillende fasen apart behandeld te worden. Daarnaast dienen de generalistische aspecten, die voor alle fasen gelden, apart geïdentificeerd te worden en afgebakend te worden. Op deze manier kan per gebied aparte risico’s worden geïdentificeerd en worden beheerst. Al deze zaken zijn “gevangen” in een control framework, zie hoofdstuk 5 “IT Control Framework”.


7 Reflectie

7

Reflectie

Het onderzoek had tot doel een control framework vanuit het perspectief van IT Audit op te zetten om invulling te geven aan de risicobeheersing bij IT splitsing en integratie bij de vorming van ICT Shared Service Centers. Aan de hand van theorie en praktijkonderzoek is enerzijds gekeken naar de risico’s, zaken die fout kunnen gaan en de zaken die daadwerkelijk fout zijn gegaan. Aan de andere kant is gekeken naar zaken die goed zijn gegaan en zijn verlopen volgens plan. Hoewel in de eerste instantie werd gedacht dat de uitdagingen met name in de splitsing en integratie van de IT (hard -en software, netwerk, et cetera) zelf lag, bleek al snel dat de daadwerkelijke uitdagingen niet beperkt zijn tot de IT zelf maar veel uitgebreider waren en veel meer aspecten bevatten. De nadruk ligt in de eerste instantie veel meer op organisatorische en procesaspecten, waarbij de IT “as is” overgegaan. Hoewel het in praktijk niet is voorgekomen, is het de vraag of de benadering waarbij de IT bij de vorming ook direct wordt aangepakt een verstandige is en/of dit wellicht niet te ambitieus wordt. Door hetgeen wat in het hiervoor staande is beschreven werd tevens de last/ problematiek meer helder en lag de focus en daarmee de nadruk van de IT Audit Control Framework meer op proces en organisatie. Dit is tevens de afbakening geworden van dit onderzoek en deze scriptie. Het daadwerkelijk technisch splitsen en integreren van IT bij een IT Shared Service Center (en andere soorten Shared Service Centers) dient apart behandeld, onderzocht en beschreven te worden. Dit zal een uitdagend en ook technisch onderzoek worden. Veel verschillen ten opzichte van met een normale IT splitsing en integratie bij fusies en overnames zullen niet aanwezig, wel zullen de belangen anders liggen. Al met al is met de opgestelde IT Control Framework een stevig raamwerk ontworpen. Hierbij worden de belangrijkste aspecten in ogenschouw genomen die relevant zijn bij de IT splitsing en integratie voor nu en naar de toekomst toe! Sprekend voor onszelf hebben wij geleerd om zelfstandig en onafhankelijk onderzoek uit te voeren aan de hand van concrete praktijkstudies.


Bijlage 1 Literatuurlijst

Bijlage 1 – Literatuurlijst Literatuurlijst: 1. Voor veel overheden geen verschil tussen Outsourcing (BPO) en Shared Service Center (SSC), KPN, Den Haag (2010), 8p. 2. A.F.A. Korsten, L. Schaepkens en L.J.M.J. Sonnenschein, Shared Services – Nieuwe vormen van krachtenbundeling bij gemeenten (2004), 100p. 3. D. Houtekamer, R.W. de Graaf, ISAE 3402: einde van SAS70 in zicht? (2009), 6p. 4. H. Koevoets en M. van Kaam, Maakt uw shared service center zijn beloftes waar? (2009), 6p. 5. J. Strikwerda, Shared Service Centers – Van kostenbesparing naar waardecreatie. Koninklijke Van Gorcum BV, Assen (2005), 150p. 6. M. Nieuwenhuis, The Art of Management, Deel 1 Strategie en Structuur, 2008, 150p 7. M. Stroucken, R. Douwstra, T. van der Marel en A. de Jong, Shared Service Centra – Van keuze tot aan realisatie. Quint Wellington Redwood, Amsterdam (2004), 22p. 8. M. Welters, W. Schotman, J. Maan, F. van Brussel en M Boer, presentatie Shared Service Center (2006), 19p. 9. P. Moller en M. Delane, Shared services handbook: A practical guide to implementing shared services (2003), 96p. 10. R.Ch.T. Ewals, ISAE 3402: Een nieuw hoofdstuk voor de IT-auditor (2010), 9p 11. R. Maes, Informatiemanagement in kaart gebracht, 2003 12. T. Abcouwer, H. Geld, J. Truijens, Informatiemanagement en Informatiebeleid, 2006, 344p 13. T.W. Hardjono, R.J.M. Bakker, Management van processen, 2007, 287p 14. V. Kager, J. de Graaf E. Kolthof en M. Hoeksma, Tijdschrift Controlling nr. 12 (december 2004) 58-62. 15. http://nl.wikipedia.org/wiki/Ondernemingsraad 16. http://www.rotterdam.nl/Voorziening:Servicedienst_Rotterdam_Gemeentelijke_dien sten 17. http://www.sharedservicesbijdeoverheid.nl/praktijkvoorbeelden?category=Meerdere +terreinen&id=84 18. http://www.timbv.nl/timbv/Adviesgebieden/shared-service-centers/strategischeopties-voor-een-ssc


Bijlage 2 Interviews

Bijlage 2 – Interviews Tijdens het onderzoek zijn de volgende personen geïnterviewd: Naam

Organisatie

Datum

René Matthijsse Mark Voogd Patrick Groothuis Math Muijres Marco Slegt Toine van Riel

VU Amsterdam Drechtsteden Gemeente Rotterdam Drechtsteden Gemeente Rotterdam Gemeente Rotterdam

16/11/2009 07/12/2009 10/12/2009 25/02/2010 22/03/2010 06/05/2010


Bijlage 3 Vragenlijst

Bijlage 3 – Vragenlijst Interviewvragen/ onderwerpen: 1. Rol binnen het project. 2. Verloop project. 3. Risicobeheersing (positieve en negatieve zaken): − Project; − Fasen. 4. Gebruik van een control framework, eventueel 9-vlaksmodel. 5. Inrichting en totstandkoming IT Shared Service Center. 6. Toekomst/ verdere verloop. 7. Andere punten.


Risicobeheersing bij IT Splitsing & Integratie

Recommend Documents