HbR IT Sourcingstrategie

Transcriptie

1 HbR IT Sourcingstrategie 1

2 Inhoudsopgave 1 Aanleiding en inleiding Waarom een IT-sourcingstrategie? Visie Havenbedrijf Rotterdam: stip op de horizon Gewenste situatie IT-dienstverlening in het verlengde van bedrijfsprocessen Randvoorwaarden Clustering van bedrijfsprocessen Verkavelingsopties nieuwe IT-dienstverlening Gewenste verkaveling Leveranciersstrategie Implementatie nieuwe IT-dienstverlening Scenariomodellen: continueren, big-bang of geleidelijk Sourcing stappenplan

3 1 Aanleiding en inleiding 1.1 Waarom een IT-sourcingstrategie? Het Havenbedrijf heeft in november 2011 een nieuwe IT-strategie vastgesteld. Hierin staan vijf doelstellingen centraal: 1. Het bereiken van operational excellence. 2. Het leveren van operationele zekerheid. 3. Een snellere time-to-market van gewenste wijzigingen en vernieuwingen 4. Het leveren van toegevoegde waarde aan de business 5. Het inzetten van informatie als strategische asset voor het Havenbedrijf Om dit te bereiken is een aantal veranderprogramma s gestart die ertoe moeten leiden dat naast het bereiken van businessdoelen ook het achterstallige onderhoud wordt opgelost en de complexiteit van het IT-landschap wordt gereduceerd. Daarna is de weg vrij voor innovatie en groei. Aangezien het Havenbedrijf in 2007 heeft besloten om een groot deel van de IT-dienstverlening uit te besteden aan een beperkt aantal leveranciers is de nieuwe IT-strategie aanleiding om goed na te denken over de levering van de vernieuwde ITdienstverlening. Daarom is IT-Sourcing een van de veranderprogramma s van de IT-Strategie. Vragen als: wat doe ik zelf, wat koop ik in, met wie werk ik samen en voor welke periode staan daarin centraal. Het antwoord op deze vragen wordt gegeven in de sourcingstrategie die voor u ligt. Over de huidige situatie is het volgende vastgesteld: 1. In de huidige situatie zijn gebruikers regelmatig ontevreden over de prestaties van de leveranciers. Te vaak zijn er verstoringen in bedrijfskritische infrastructuur en is er achterstallig onderhoud. Daarnaast wordt er wordt te weinig meegedacht over innovatieve mogelijkheden van informatietechnologie. 2. IT moet wendbaarder worden. Wanneer er plannen vanuit de business zijn, moet IT de wijzigingsverzoeken snel kunnen doorvoeren. Beter nog is het dat IT zelf al meedenkt met de mogelijkheden die de business ziet en IT daadwerkelijk strategisch inzet. Time-to-market is dus essentieel, maar ook een afspraak is afspraak cultuur om te komen tot resultaten die tellen voor de business. 3. Huidige leveranciers zijn contractueel onvoldoende aanspreekbaar op tekortkomingen. Daarnaast belemmeren de huidige één-op-één contracten een goede samenwerking tussen de leveranciers. 4. Een belangrijk deel van de huidige contracten loopt binnen enkele maanden tot een jaar af, of is opzegbaar. 5. De huidige contracten zijn complex, weinig transparant en bieden onvoldoende flexibiliteit om de IT-strategie te ondersteunen. 6. De markt is veranderd en biedt inmiddels andere producten, diensten en leveringsmodellen aan. 7. Uit benchmarks blijkt dat tarieven van de huidige leveranciers gemiddeld 7 tot 10% boven marktconforme prijsniveaus liggen. Deze redenen maken duidelijk dat hercontractering noodzakelijk is. Voorliggend document gaat hier zo concreet mogelijk op in. 3

4 1.2 Visie Havenbedrijf Rotterdam: stip op de horizon De IT-strategie is zodanig opgesteld dat deze de ambities uit het ondernemingsplan van het Havenbedrijf zo goed mogelijk moet ondersteunen. De IT-strategie heeft naast het mogelijk maken van vernieuwing ook duidelijke doelstellingen ten aanzien van het bieden van zekerheid. Vernieuwing en zekerheid moeten dus goed in balans zijn. Duidelijk is dat in alles het businessbelang centraal moet staan. Tegelijkertijd betekent dit niet dat een situatie ontstaat waarbij het principe geldt van u vraagt, wij draaien. Er is duidelijke en consistente regie nodig om vragen uit de business goed te vertalen naar IT-oplossingen, waarbij IT-principes, business cases en prioriteitstelling belangrijke instrumenten zijn om vraag en aanbod bij elkaar te brengen. 4

5 2 Gewenste situatie 2.1 IT-dienstverlening in het verlengde van bedrijfsprocessen Er dient een omslag te komen in denken in toegevoegde waarde van IT voor de bedrijfsprocessen. Informatie is een strategisch asset voor het Havenbedrijf, maar daarvan is de organisatie zich niet in de breedte bewust. Informatie is van essentieel belang voor het leveren van excellente dienstverlening zoals het Havenbedrijf dat heeft uitgedrukt in het ondernemingsplan. Dit betekent dat de IT veel wendbaarder moet worden. Wanneer er plannen vanuit de business zijn, moet IT de wijzigingsverzoeken snel kunnen doorvoeren. Beter nog is het dat IT zelf al meedenkt met de mogelijkheden die de business ziet en IT daadwerkelijk strategisch inzet. Time-to-market is dus essentieel, maar ook een afspraak is afspraak cultuur om te komen tot resultaten die tellen voor de business. Een continu proces van vernieuwing is het gevolg. Daarbij moet altijd in het oog worden gehouden dat bedrijfszekerheid en operationele veiligheid net zo belangrijk zijn. IT-dienstverlening moet met grote betrouwbaarheid worden geleverd, mag vrijwel nooit haperen en minimaal uit de lucht zijn om vernieuwingen te kunnen installeren. Dat staat op gespannen voet met de gewenste vernieuwing. Samengevat moet de toekomstige situatie voldoen aan de volgende uitgangspunten: 1. Het havenbedrijf moet leveranciers (contractueel) kunnen aanspreken op prestatie-indicatoren die verbonden zijn aan de business, zoals gebruikerstevredenheid, beschikbaarheid van bedrijfsfunctionaliteit (in plaats van IT-technische beschikbaarheid), snelheid van oplossen van incidenten en kwaliteit/snelheid van doorvoeren van wijzigingen en projecten. 2. Leveranciers moeten (contractueel) aanspreekbaar zijn op de correcte integrale werking van applicaties, snel oplossen van storingen en incidenten en korte doorlooptijden van wijzigingsverzoeken. 3. Leveranciers moeten (contractueel) aanspreekbaar zijn op het meedenken over innovatiemogelijkheden. 4. Leveranciers moeten (contractueel) aanspreekbaar zijn op samenwerken met elkaar waar dat nodig is (bijvoorbeeld in projecten). 5. Contracten moeten meer flexibiliteit bieden ten aanzien van wijzigingen. 6. Contracten moeten eenvoudiger en transparant in elkaar zitten om deze beter beheersbaar en inzichtelijk te houden (zowel wat betreft scope als de kosten). 7. De nieuwe situatie moet een optimaal aantal leveranciers opleveren (denk aan 4 tot 6). Niet teveel om te voorkomen dat teveel leveranciers moeten worden aangestuurd en niet te weinig om te voorkomen dat er een te grote afhankelijkheid van één leverancier ontstaat. 2.2 Randvoorwaarden Vooraf zijn randvoorwaarden vastgelegd waaraan de nieuwe situatie moet voldoen. IT-dienstverlening moet: niet te versnipperd worden belegd om aanbesteden aan de lopende band te voorkomen; binnen huidige kostenniveaus en maximaal dezelfde regie-inspanning te worden geleverd; helpen om de complexiteit van het landschap te reduceren; de afhankelijkheid van leveranciers verminderen. En uiteraard moet het: in lijn te zijn met de ambities uit de IT-strategie; voldoen aan de IT-principes uit de IT-strategie. 2.3 Clustering van bedrijfsprocessen Om de IT-dienstverlening te laten aansluiten op de hoofdprocessen is een model opgesteld waarin de belangrijkste bedrijfsprocessen herkenbaar zijn in logische clusters. Deze vormen de basis voor de verticale kavels. Ervan uitgaande dat er in de nieuwe situatie verschillende leveranciers vanuit hun specialisme kunnen worden ingeschakeld, is de keerzijde hiervan dat de koppelingen tussen applicaties moeilijker te beheren zijn naar mate hier meer leveranciers zijn betrokken. Het optimum tussen specialisme en beheersbaarheid wordt gevonden door de applicaties zodanig te clusteren dat het aantal interfaces tussen de applicaties zoveel mogelijk binnen zo n cluster en dus bij één leverancier blijft. 5

6 Met onderstaande figuur wordt een clustering van applicaties aangegeven waarbij de koppelingen tussen de applicaties zoveel mogelijk binnen clusters blijven en het aantal koppelingen tussen clusters minimaal is. Verticale verkaveling levert voor de business een veel duidelijker werkwijze op. Zij hebben één aanspreekpunt dat zorgdraagt voor de afgesproken beschikbaarheid, het oplossen van incidenten en het snel doorvoeren van wijzigingsverzoeken. Evengoed gaat er achter deze verticale indeling een technische wereld schuil die ook in technische termen goed moet kunnen worden beheerd. Met andere woorden ergens in de keten van de dienstverlening (van formulering van het probleem tot en met de realisatie van een oplossing) gaan verticale kavels over in horizontale kavels, ook binnen leveranciers. Hierin zijn verschillende mogelijkheden te onderkennen. Deze worden in de volgende paragraaf verder uitgewerkt. 2.4 Verkavelingsopties nieuwe IT-dienstverlening De opties worden afgeleid vanuit het proces van incident tot oplossing. De keten in de as is situatie verloopt nu langs de volgende schakels: 1. De functioneel applicatiebeheerder of key-user is het functionele aanspreekpunt vanuit een bedrijfsproces. Na melding van een incident of probleem wordt deze bij de servicedesk geregistreerd en doorgezet naar technisch applicatiebeheer. 2. De technisch applicatiebeheerder analyseert het incident en definieert acties. Het incident kent vele mogelijke oorzaken. Bijvoorbeeld instellingen van de werkplek, verbindingen, databasekoppelingen, installatie-instellingen, storingen in het serverpark. In veel gevallen is er interactie nodig met één of meer technische beheerders van de componenten die het incident heeft kunnen veroorzaken. 3. Na vinden van de oorzaak worden werkorders uitgezet, het incident verholpen, de oplossing getest en via de technisch applicatiebeheerder terug gemeld aan de functioneel applicatiebeheerder of rechtstreeks naar de gebruiker. Dit proces geeft aan dat zelfs bij eenvoudige storingen er meerdere schakels moeten worden bewandeld. Het is onmogelijk om dit gehele proces bij één persoon te beleggen. Het maakt duidelijk dat wanneer de keten over meerdere leveranciers loopt dit de snelheid van handelen niet ten goede komt. Hoe beter aangesloten de keten, hoe sneller de oplossing en dus hoe tevredener de klant. Dit zou tot een pleidooi kunnen leiden om alle IT-dienstverlening te verticaliseren, waarbij een integrale verantwoordelijkheid genomen wordt voor zowel housing en hosting: applicaties worden geïnstalleerd op servers en maken gebruik van centrale dataopslag. Bij deze dienstverlening is er de keuze om dit als onderdeel van de verticale dienstverlening op te nemen of centraal te beleggen. Besloten is om housing en hosting op te nemen binnen een verticaal kavel. De meeste 6

7 leveranciers van applicatiediensten beschikken ook over eigen rekencentra, waardoor ze ook de housing en hosting voor hun rekening kunnen nemen. 2.5 Gewenste verkaveling Wanneer de voor- en nadelen gewogen worden en de marktontwikkeling daarin wordt meegenomen is de conclusie dat een verkaveling gewenst is waarin housing en hosting onderdeel wordt van de verticale kavelsin onderstaande figuur is de clustering die in paragraaf 2.3 is ingeleid weergegeven in separate kleuren. Daarbinnen zijn de kavels opgenomen. In één figuur ziet dit er dan als volgt uit. In deze figuur zijn ook de kavels opgenomen die door het Havenbedrijf zelf worden geleverd, zoals regie en functioneel beheer, adviesdiensten en Telefonie, Marifonie en Radar. Ter detaillering en verduidelijking geeft onderstaande figuur per kavel een aantal belangrijke applicaties weer: Windows Office Exchange A-Dir Lync E-docs ` Technisch applicatiebeheer Technisch beheer Housing&Hosting Regie en functioneel beheer Sharepoint Dynamics Shareport Online Communicatie RIV DGDialog Autocad IVL Korkad Soqumas Geo Informatie Qinsy Dolomiet Hydrografie Hamis Scheepvaart IVS DHK Journalen Bunkeren IVS Legacy NNI Noodvoorziening Scheepvaart Amethyst Hyacint Hydro / Meteo SAP Business Objects Harmony Zorro DWH BPC ERP+ MX-One Milestone Marifonie en Radar Telefonie Adviesdiensten (IV, implementatie en projecten) 7

8 De beheersbaarheid van verkaveling hangt in hoge mate af van de beheersbaarheid van de koppelingen tussen de applicaties en daarmee kavels. Deze beheersbaarheid wordt vergroot door de aanwezigheid van zogeheten middleware. Dit is speciale software die de uitwisseling van gegevens tussen applicaties netjes regelt, ook als de applicaties later worden aangepast. Bij het Havenbedrijf is middleware aanwezig in een aantal kavels: - Informatieuitwisseling, namelijk het product IBM Websphere (ten behoeve van DOD-Port) - ERP+, namelijk het product SAP-PI - Scheepvaart, het product JBoss (Hamis) - IVS Legacy, het product IBM Webspere (IVS) In het kavel Geo-informatie is specifieke GEO-middleware noodzakelijk. Deze wordt in het programma POI ingericht en is een voorwaarde voor gegevensuitwisseling tussen het kavel Geo-informatie, andere kavels en de buitenwereld. Mogelijk speelt het kavel Informatie-uitwisseling in de vorm van DOD-Port hierin een rol (stippellijn). In het kavel Hydro/Meteo is geen middleware aanwezig. In het vernieuwingsprogramma dat de opzet van dit kavel opnieuw zal vormgeven, zal de noodzaak van een middleware component onderzocht worden. Eindgebruikersbeheer Servicedesk Kantoorautomatisering (werkplek, randapparatuur en applicaties) Telefonie SD BSV OSS OHD Technisch applicatiebeheer Technisch beheer Housing&Hosting Regie en functioneel beheer COM Online Communicatie Haven en Industrieel complex Geo Informatie Hydrografie Nog te ontwikkelen Scheepvaart IVS Legacy JBoss Webspere Scheepvaartverkeer Webspere Noodvoorziening Scheepvaart Informatie uitwisseling Hydro / Meteo Nog te ontwikkelen B&O ERP+ SAP-PI Telefonie Marifonie en Radar Adviesdiensten (IV, implementatie en projecten) IP netwerken De belangrijkste interne koppelingen bevinden zich tussen de clusters Haven en Industrieel Complex (Geo Informatie en Hydrografie) en Besturing & Organisatie (ERP+). Deze beschikken of gaan beschikken over afdoende middleware om gegevens te kunnen uitwisselen. Hiervoor is het gebruik van het kavel Informatie-uitwisseling niet nodig. Verwacht wordt een toenemende informatie-uitwisseling met de buitenwereld voor de clusters Haven en Industrieel Complex en Scheepvaartverkeer. Hiervoor is de middleware van kavel Informatie-uitwisseling voor beschikbaar. Het cluster B&O maakt voor zowel interne als externe gegevensuitwisseling gebruik van SAP-PI. Het kavel Informatieuitwisseling voegt hier geen uitwisselingsfunctionaliteit toe. De koppeling tussen clusters COM en Eindgebruikersbeheer is niet zozeer een systeem-koppeling maar vooral de integratie van de werkplek en het interne Self-Service concept. Hiervoor is geen middleware nodig. Een extra mogelijkheid voor het op corporate niveau beheren van koppelingen is de toepassing van een zogeheten Enterprise Service Bus (ESB). Het gebruik van een ESB is een zwaar middel dat alle koppelingen tussen kavels en clusters kan beheren. De inzet hiervan is in de huidige en toekomstige situatie niet nodig. Redenen daarvoor zijn: Het beperkte aantal koppelingen op dit moment. Er is onvoldoende kritische massa voor het inzetten van zo n zwaar technisch en bovendien kostbaar middel. De mogelijkheden van de huidige tooling kan eventuele toename van het aantal koppelingen opvangen. De integratie van de clusters Scheepvaartverkeer en Informatie-uitwisseling bij één leverancier vangt het huidige en verwachte zwaartepunt van de koppelingen op. 8

9 Mocht toch blijken dat bij de ontwikkeling van Geo Informatie de informatie-uitwisseling van DOD-Port onvoldoende is en niet geschikt gemaakt kan worden, bestaat de mogelijkheid alsnog een ESB in te zetten. Er wordt dan gekozen voor een eenvoudig ESB-type omdat de functionaliteit al in de middleware bij de applicaties aanwezig is en om de looptijd en kosten te beperken. 2.6 Leveranciersstrategie Per cluster van informatiedomeinen (kavels) wordt één leverancier (of eventueel een consortium) verantwoordelijk. Onderstaand overzicht geeft per cluster weer hoeveel leveranciers nodig zijn met daarbij de onderbouwing. Cluster Leveranciersstrategie Onderbouwing Eindgebruikersbeheer 1 leverancier Servicedesk, werkplekken, KA en generieke applicaties worden vaak gecombineerd. Hiermee kan 1 leverancier worden aangesproken op de werking van een groot deel van de horizontale dienstverlening. Informatie-uitwisseling 1 leverancier, combinatie met cluster Scheepvaartverkeer Vrijwel alle externe informatie-uitwisseling geschiedt via het cluster Scheepvaartverkeer. Interne communicatie geschiedt volgens het geschetste principe in de vorige paragraaf. Beheer IP-Netwerken 1 leverancier COM 1 leverancier Dit is een niet omvangrijk, maar wel specialistisch kavel. Housing & hosting geschiedt doorgaans door de verticale leverancier of een speciale webhoster. Haven & Industrieel Complex Scheepvaartverkeer Besturing en Ondersteuning Telefonie, Marifonie en Radar Regie en functioneel beheer Adviesdiensten 1 leverancier (met mogelijk onderaannemers) 1 leverancier (met mogelijk onderaannemers), combinatie met Informatieuitwisseling Dit cluster van nautische kavels is specialistisch van aard. Vermoedelijk zijn partijcombinaties nodig om dit kavel met specialistische kennis te kunnen leveren. Partijen uit dit spectrum zijn gewend om samen te werken. Dit cluster van nautische kavels is specialistisch van aard. Vermoedelijk zijn partijcombinaties nodig om dit kavel met specialistische kennis te kunnen leveren. Partijen uit dit spectrum zijn gewend om samen te werken. 1 leverancier Kavel dat veel in de markt wordt uitgevraagd. Groot aantal ge-renommeerde specialisten aanwezig in de markt. HbR zelf, eventueel is Telefonie te combineren met het cluster Eindgebruikersbeheer HbR zelf HbR zelf, aangevuld met mantelpartijen. Gezien de ontwikkeling van de telefoniemarkt richting IP-Tele-fonie en de steeds grotere vraag naar Unified Communications (integratie van Telefonie en Officeapplicaties) gebruikelijk te combineren met werkplekdiensten. In 99% van de gevallen doen outsourcende organisaties zelf de regie. In de markt is gebruikelijk om projecten inhuurmantels af te sluiten waarmee HbR tegen gunstiger voorwaarden snel en effectief specialisten kan inschakelen. TOTAAL 6 leveranciers Exclusief mantel Adviesdiensten 9

10 Samengevat in één figuur komt dat neer op het volgende leverancierslandschap.: 3 Implementatie nieuwe IT-dienstverlening 3.1 Scenariomodellen: continueren, big-bang of geleidelijk Er zijn drie scenariomodellen voor de implementatie van de gewenste situatie: Continueren, Big-bang en Geleidelijk. Het volgende verstaan we onder elk van deze scenario s: Scenariomodel Continueren Big-bang Geleidelijk Kenmerken Dit scenariomodel gaat uit van continuering van de huidige contracten met de huidige leveranciers. Dit betekent niet dat Havenbedrijf dan helemaal niets meer kan. Binnen de huidige contracten moet dan worden geoptimaliseerd ten goede van de business. Dit scenario wordt beperkt door de mogelijkheden van de aanbestedingswet die grote wijzigingen in de omvang van de scope van het contract verbiedt. Het big-bang scenariomodel betreft een overgang naar de nieuwe situatie in één keer. Het gaat hier dus om aanbesteding van alle nieuwe kavels in één keer. Binnen de opzegtermijn moet een transitie per kavel en alle bijbehorende organisatie en procesverandering gerealiseerd worden. De transitietermijnen kunnen enigszins worden opgerekt, mits KPN bereid is hieraan mee te werken. Het geleidelijke scenariomodel beoogt te optimaliseren tussen beheersbaarheid en veranderbaarheid. Door een doordacht stappenplan te doorlopen kan stap-voor-stap in de juiste richting worden bewogen, waarbij elk van die stappen omkeerbaar zijn en met diverse maatregelen omgeven om risico s tot het minimum te beperken. Nieuwe kavels worden geleidelijk aanbesteed, terwijl de bestaande cruciale kavels nog enige tijd bij de huidige leverancier blijft zodat te allen tijde continuïteit kan worden gegarandeerd. Gekozen is voor het scenariomodel Geleidelijk, dit biedt mogelijkheden om voor alle betrokkenen voordeel te behalen, terwijl de gewenste verandering richting verticale verkaveling stap-voor-stap, beheerst, kan worden uitgevoerd.. Het Havenbedrijf heeft de zekerheid van continuïteit, zelfs verbetering van de huidige dienstverlening de komende jaren en een gunstige prijs voor het bestaande contract. 10

11 3.2 Sourcing stappenplan Onderstaand stappenplan is getoetst aan de huidige looptijd van contracten. Daarnaast is toetsing nodig aan de lopende en opstartende veranderprogramma s binnen de IT-strategie van het Havenbedrijf. Deze programma s vervullen een deel van de randvoorwaarden om de nieuwe situatie mogelijk te maken. Sommige kavels kunnen pas worden aanbesteed na het wegwerken van de belangrijkste delen van het achterstallig onderhoud en reductie van complexiteit. Dit inzicht moet in samenwerking met business en IV in detail verkregen worden voordat met de aanbesteding van een aantal van de verticale kavels kan worden begonnen. Het gaat in het bijzonder om de kavels Haven en Industrieel Complex en Scheepvaart. Het voorlopige stappenplan ziet er als volgt uit: Stappen Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 1. Verkaveling definitief maken 2.Vernieuwingingprogramma s bepalen 3.Huidige contracten in lijn brengen 4.Vernieuwen en optimaliseren regie 5.Aanbesteding en transitie COM 6.Aanbesteding en transitie HIC 7.Aanbesteding kavel Adviesdiensten 8.Aanbesteding en transitie B&O 9.Aanbesteding en transitie Eindgebruikersbeheer 10.Aanbesteding en transitie Scheepvaart en IW Uitvoering / transitie Aanbesteding Het stappenplan moet: continuïteit van de dienstverlening zoveel mogelijk waarborgen; uitgaan van juridische (on)mogelijkheden; met de (looptijden van de) huidige contracten rekening houden; in lijn zijn met de programma s die zich bezighouden met het wegwerken van achterstallig onderhoud en het op orde brengen van architectuur en ook met de verschillende andere programma s; zodanig geleidelijk zijn dat een parallelle professionalisering van de regieorganisatie mogelijk wordt; geen ontoelaatbare aanbestedingsdruk veroorzaken op de regie-organisatie en procurement; bestaan uit kleine beheersbare stappen, die geëvalueerd worden en voorkomen dat fouten worden herhaald en de resultaten iteratief worden geoptimaliseerd; indien mogelijk uit omkeerbare stappen te bestaan. Doelstellingen van het stappenplan zijn: het creëren van meer vrijheid in het doorvoeren van verticale verkaveling; het mogelijk maken van een geleidelijke implementatie; tegelijkertijd wel de continuïteit van de dienstverlening te waarborgen en tevens een aantal verbeteringen door te voeren 11