Uitbesteden . . . . maar hoe?

Als u gaat uitbesteden, weet u dan exact wat er op u af gaat komen? Met andere woorden, welke taken kunt u buiten de deur zetten en met welke blijft u zitten? Dat blijkt toch nog wel eens een probleem.
Hans Bezemer en Mirijan Casterop

Heeft u een eigen goedkope en goed functionerende IT afdeling? Goed zo. Vooral niet aankomen. Maar als u er al eens aan gedacht hebt om het een en ander uit te besteden, weet u dan exact wat er op u af gaat komen? Met andere woorden, welke taken kunt u buiten de deur zetten en met welke blijft u zitten? Dat blijkt toch nog wel eens een probleem.
Om dat vraagstuk op te lossen moeten we eerst goed begrijpen hoe het allemaal in elkaar steekt. Daarvoor hanteer ik de ‘platte kubus’ uit figuur 1 die eerder al in het blad IT-Infra van september 2014 is besproken.

Platte kuub

Figuur 1: Platte kubus

Het bovenste (grijze) gedeelte vande kubus wordt gevormd door uw eigen primaire bedrijfsprocessen. Dat blijft u natuurlijk altijd zelf doen. Dit is echter wel de plek waar de behoefte aan IT ondersteuning ontstaat en de gewenste functionaliteit geformuleerd wordt. Die wordt in het middelste (gele) gedeelte omgezet naar de concrete artefacten, die zich in het onderste (groene) gedeelte bevinden. Links bevindt zich de reeds gerealiseerde en beheerde IT ondersteuning, terwijl rechts in het kader van innovatie nieuwe IT ondersteuning wordt ontwikkeld.
De zwarte pijlen geven de verschillende vormen van wijzigingsbeheer aan. Van gewenst naar geraliseerd (de halfronde pijlen links en rechts), van nieuw en nnovatief naar gerealiseerd (de grote zwarte pijl) en van voortdurens verbeterend, (de U-vormige pijlen onderaan).
Volwassenheid
Nu kunt u natuurlijk alleen de IT uit het onderste (groene) gedeelte buiten de deur zetten, maar dan blijft u wel met een gezellige bulk werk zitten. Wat dat werk nu concreet inhoudt is een vraag, waarop de kubus middels het volwassenheidsmodel ook een antwoord kan geven.

 Volw model

Figuur 2: Kubus volwassenheidsmodel

Het basisniveau 0 is datgene wat nodig is om een IT afdeling enigszins gestructureerd te laten werken. Het is daarom vanuit de rest van de organisatie gezien nogal introspectief. Dat verandert met niveau 1, waar de IT afdeling zijn vleugels uitslaat door invulling te geven aan de operationele, taktische en strategische aspecten van een daadwerkelijk op de organisatie gericht service management. Het omvat niet alleen de helpdesk, maar ook ketenbeheer, service catalogue management, service level management en service design. Niveau 2 is overigens alleen maar een verdere uitwerking en professionalisering van niveau 1. Daar gaan we specifieke IT aspecten nog nader op de klant toespitsen.
Als u dus alleen de hardware en software (het groene gedeelte) buiten de deur wilt zetten, blijft u hiermee zitten. Dat plaatst ons enigszins voor een dilemma. Immers, vaak wordt uitbesteding overwogen als men zelf de zaakjes niet voor elkaar heeft en hoopt dat een commerciële aanbieder het beter kan. Echter, het model toont aan dat men dan wel op een vrij hoog volwassenheidsniveau moet zitten - en meestal is dat niet het geval, in tegendeel zelfs. Met andere woorden, men stoot juist die taken af die men nog enigszins beheerst en blijft zitten met de taken waar men eigenlijk geen raad mee weet.
Want laten we wel wezen, het uitvoeren van de basale beheertaken lukt de meeste IT afdelingen nog wel, maar het steeds maar weer laten aansluiten van de IT dienstverlening op de continu veranderende eisen van het bedrijf blijkt vaak een uitdaging van een wezenlijk andere grootte. En met alleen dozen schuiven kom je er dan niet.

Ondeelbaar
Het opmerkelijke van het overgebleven takenpaket is, dat het ondeelbaar is. Tenzij men er een pervers genoegen in schept om de argeloze gebruiker voor de vraag te plaatsen welke helpdesk hij vandaag nu weer moet bellen natuurlijk. En elke afdeling zijn eigen applicatiepakket bij elkaar laten sprokkelen door losse afspraken te maken met allerlei leveranciers is ook weer zo wat.
Toch laat de middelste laag zich uitstekend uitbesteden. U hoeft zich dan alleen nog maar bezig te houden met de taken die dicht tegen de primaire processen van de klantorganisatie aan zitten. Uw partner houdt zich dan bezig met alle andere aspecten. Dat noemen we ”Service Integration and Management”, kortweg SIaM.
Maar wat is SIaM? Volgens de boekjes is het ‘een set van principes en ervaringen voor het leveren van diensten aan klanten, waarbij voorspelbaarheid en beschikbaarheid van deze diensten worden geborgd, door het aansturen van een IT keten met meerdere leverende partijen die vanuit klantperspectief als één organisatie functioneert’. Met andere woorden, de klant heeft het gevoel met één enkele partij van doen te hebben, ongeacht hoeveel onderdeeltjes en aanbieders er daadwerkelijk onder de motorkap huizen. Die ene partij is de ‘Service integrator.

Service integrator
De Service integrator vertegenwoordigt dus feitelijk de klantorganisatie en stuurt operationeel de keten van de leverende partijen aan. De levering van de dienst aan de klant staat daarbij altijd centraal. Dat klinkt allemaal nog erg vaag. Hoe een dergelijke constructie er in de praktijk kan worden ingevuld, wordt geïllustreerd in figuur 3, waar we duidelijk de drie verschillende lagen uit figuur 1 in teruzien

 Plaatje

Figuur 3: Service integration and management

U moet echter niet de fout maken door te denken, dat u de enige bent aan wie de Service integrator zijn diensten levert. Tevens is het helemaal niet gezegd, dat de Service integrator zelf altijd alle benodigde infrastructuur moet beheren. Dat kan natuurlijk wel en eigenlijk is het ook best wel zo gemakkelijk, maar het hoéft niet.
Uiteraard wordt het met een groot aantal partijen wel een stuk complexer om gezamenlijk tot een uniform stuk dienstverlening naar de klant te komen. Immers, niet elke aanbieder is hetzelfde of werkt hetzelfde. Derhalve is het ook niet slim om zelf allerlei contracten met verschillende aanbieders aan te gaan en dit bonte gezelschap dan over te dragen aan de Service integrator. U loopt dan een gerede kans, dat u een aantal aspecten over het hoofd heeft gezien en daardoor contractueel een aantal zaken heeft weggegeven, die het leven van de Service integrator onnodig veel lastiger gaan maken.
Bijvoorbeeld als u van uw Service integrator een 24-uurs service verlangt, maar voor de netwerkprovider alleen een supportcontract voor kantooruren heeft afgesproken. Of als u de overdracht van Configuration Management gegevens niet bedongen heeft. Of dat u het op dat moment wel logisch vond, dat een leverancier op willekeurige momenten wijzigingen mag doorvoeren zonder voorafgaande goedkeuring of kennisgeving. Tja, daar staat u dan.

Grip op governance
Uiteraard is het om te beginnen een goed idee om uw Service integrator te betrekken bij onderhandelingen met een mogelijke leverancier, maar besef wel dat u er daarmee niet bent. Om een goed product te kunnen leveren is het noodzakelijk, dat de Service integrator grip heeft op de totale ‘governance’, oftewel ‘een conglomeraat van interactie- en besluitvormingsprocessen tussen diverse partijen met een gezamelijke en eenduidige opdracht, dat moet leiden tot de vorming, borging en verspreiding van een verzameling onderling gedeelde normen, standaarden en werkwijzen’.

Moer

Figuur 4: Zeven aspecten van SIaM

Dat lijkt een hele mond vol, maar het is wel cruciaal voor het welslagen van de hele operatie. Want als partijen blijven hangen in hun eigen organisatie en werkwijzen is het vrijwel onmogelijk om tot een samenhangend product te komen. We hebben namelijk niet alleen te maken met de normale lijnverantwoordelijkheden, maar ook nog eens met de ITIL processen, die daar dwars doorheen lopen.
Stel, dat u tegen een incident aanloopt, dan is het wel zaak dat de diverse leveranciers op een soortgelijke wijze op hun tweedelijns verantwoordelijkheden kunnen worden aangesproken. Aan de andere kant is het niet reëel om van uw leveranciers te vragen om hun hele interne organisatie om te gooien, alleen omdat ze één van uw ketenpartners zijn. Dat vereist de nodige afstemming.
U ontkomt er dus niet aan om de algemene verantwoordelijkheden en taken van een ketenpartner goed te beschrijven en vast te leggen. En wel voor elk ITIL proces. Dat vereist natuurlijk ook, dat uw ketenpartner intern zijn zaakjes goed op orde moet hebben, want anders zal hij niet in staat blijken te zijn om binnen een dergelijke organisatie goed te kunnen functioneren. Daarnaast dienen ook de communicatie- en escalatielijnen te worden bepaald. U zult maar eens tegen een incident aanlopen, waar het niet op voorhand mogelijk is om de schuldige aan te wijzen. In dat geval is het wel handig dat u een middel heeft om iedereen rond de tafel te krijgen.

Tooling
Een ander probleem is veel lastiger op te lossen: de tooling. U zult maar zelden een leverancier tegen het lijf lopen, die precies dezelfde tooling als uw Service integrator gebruikt en die ook nog eens exact zo heeft ingericht. Toch zult u in staat dienen te zijn om een incident of een verzoek tot wijziging over te dragen. Soms is het mogelijk om een interface tussen beide systemen te leggen, maar als dat te kostbaar of om andere redenen niet mogelijk is, zult u afspraken moeten maken over de overdracht - al is het maar per email. Let wel, u zult ook afspraken dienen te maken over welke gegevens daarbij noodzakelijk zijn en op welke wijze die vastgelegd dienen te worden, alhoewel waarschijnlijk niet altijd alle ‘vertaalslagen’ kunnen worden voorkomen.
Het wordt echt nog veel leuker als er service level rapportages dienen te worden gemaakt. Waarschijnlijk kunnen de geaggreerde rapportages nog wel uit het systeem van de Service integrator worden gehaald, maar als er detailinformatie benodigd is ontkomt u er mogelijk niet aan om uw ketenpartners te vragen die gegevens te verstrekken. Daarbij is het wel belangrijk om met elkaar af te spreken, dat er altijd maar één administratie leidend is voor een specifiek gegeven, de zogenaamde bronadministratie. Als er afwijkingen zijn, worden ze dáár gecorrigeerd - de rest van de administraties wordt daarvan afgeleid.

Ketenpartners
De ketens zélf vragen om speciale aandacht. Vaak weet de organisatie zelf wel welke diensten zij afneemt. Aan de andere kant weet de leverancier ook wel welke infrastructuur zij ter beschikking stelt. Echter, de vraag met elke infrastructuur een specifieke dienst wordt gerealiseerd wordt door beide partijen meestal in het midden gelaten. Toch is deze informatie van doorslaggevend belang bij probleem- of impactanalyses, om nog maar te zwijgen over een mogelijke interne financiële doorbelasting. Daarom is het goed om ook over dit vraagstuk na te denken en daar heldere afspraken over te maken.
Wat we hier eigenlijk proberen is om van de diverse ketenpartners ‘black boxes’ te maken met gestandaardiseerde communicatiekanalen op het gebied van procedures, standaarden en tooling. Met andere woorden, we proberen eigenlijk alleen maar op de diverse raakvlakken te sturen. Dat heeft een aantal voordelen, zowel voor de Service integrator als de ketenpartner.
De ketenpartner behoeft alleen maar de vertaling te maken van het door de Service integrator gedefinieerde raakvlak naar zijn eigen, interne organisatie. Aan de andere kant geeft het de Service integrator - en daarmee ook de klant - de mogelijkheid om op transparante wijze nieuwe ketenpartners ‘aan te sluiten’ of van zelfs van ketenpartner te wisselen zonder dat de dienstverlening daar merkbaar onder lijdt.
Het concept van ‘gedefinieerde raakvlakken’ wordt overigens ook al gebruikt bij ITIL implementaties, omdat het de mogelijkheid biedt om een proces met een relatief hoog volwassenheidsniveau in een organisatie te plaatsen zonder het risico daarmee de aansluiting naar aanpalende processen te missen. Het lijkt daarmee een generiek toepasbaar concept te zijn.

Houding en gedrag
Tenslotte nog een factor, die helaas maar al te vaak over het hoofd wordt gezien: houding en gedrag. Het is absoluut noodzakelijk, dat alle partijen in de keten maar één doel voor ogen hebben: klantgerichtheid. Het is een illusie om te denken, dat je een contract zo kunt dichttimmeren dat de andere partij wel goede dienstverlening moét gaan leveren. Het trieste feit is echter, dat je eigenlijk al verloren hebt op het moment dat er met contracten gezwaaid moet gaan worden - en daar is niemand mee gebaat.
Waar iedereen - klant en leverancier - zich bewust van moeten zijn is dat het uiteindelijk alleen maar gaat om dat ene, gezamenlijke resultaat. Dat kun je alleen maar bereiken door optimaal gebruik te maken van elkaars kwaliteiten en het zorgvuldig afwegen van je eigen en andermans belangen. En dan komt het heus allemaal wel goed.

Hans Bezemer en Mirijan Casterop zijn beiden Service Manager van de Service Integratie unit bij Ordina.

 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag