Beheer

IT beheer
Service integration management

Uitbesteden... maar hoe?

Alle partijen in de keten moeten maar één doel voor ogen hebben: klantgerichtheid.

22 februari 2017

Alle partijen in de keten moeten maar één doel voor ogen hebben: klantgerichtheid.

Heeft u een eigen, goedkope en goed functionerende IT-afdeling? Goed zo. Vooral niet aankomen. Maar als u er al eens aan gedacht heeft 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 nogal eens een probleem.

Hans Bezemer & Mirijan Casterop

Om te bepalen welke taken u kunt uitbesteden en welke niet, moet eerst duidelijk zijn hoe de IT-afdeling in elkaar steekt. Daarvoor hanteren we de ‘platte kubus’ uit figuur 1, die eerder al in het blad IT-Infra van september 2014 is besproken [zie figuur 1].

Platte kubus

De primaire processen genoemd in figuur 1 blijft u natuurlijk zelf doen. Dit zijn echter wel de processen waarbij de behoefte aan IT-ondersteuning ontstaat en de gewenste functionaliteit geformuleerd wordt. Dat resulteert in een wensenlijst met daarin zaken als Requirements Management en PDC. Daarvoor worden de managementoplossingen ontwikkeld en zaken als planning, monitoring en analyse.

Volwassenheid
Nu kunt u natuurlijk alleen de IT-functies als management en monitoring buiten de deur zetten, maar dan blijft u wel met een gezellige bulk werk zitten. Wat dat werk nu concreet inhoudt, kan de kubus middels het volwassenheidsmodel in figuur 2 ook beantwoorden.

Kubus volwassenheidsmodel

Kubusvolwassenheidsmodel

Change- en configurationmanagement stelt een IT-afdeling in staat enigszins gestructureerd te werken. Het lijkt daarom vanuit de rest van de organisatie gezien nogal introspectief. Dat verandert met niveau 1, waar de IT-afdeling invulling geeft aan de operationele, taktische en strategische aspecten van 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 vervolgens een verdere uitwerking en professionalisering van niveau 1, waar specifieke IT-aspecten op de klant worden toegespitst.

Als u dus alleen de hard- en software buiten de deur wilt zetten, blijft u met al deze beheerfuncties 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 – wat meestal niet het geval is, 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. Het uitvoeren van de basale beheertaken lukt de meeste IT-afdelingen namelijk 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 takenpakket 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 laten de functies van niveau 1 uit figuur 2 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.  ( figuur 4 )

Zeven aspecten van SIaM

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 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 in de praktijk kan worden ingevuld, wordt geïllustreerd in figuur 3, waar we duidelijk de drie verschillende lagen uit figuur 1 in terugzien.

Service integration and management

Figuur 3

Maak echter niet de fout te denken dat u de enige bent aan wie de service integrator zijn diensten levert. Tevens is het 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 hóéft niet.
Uiteraard wordt het met een groot aantal partijen wel complexer om gezamenlijk tot een uniforme 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-uursservice 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, wat moet leiden tot de vorming, borging en verspreiding van een verzameling onderling gedeelde normen, standaarden en werkwijzen’.

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.

"Als partijen blijven hangen in hun werkwijzen, is het onmogelijk tot een samenhangend product te komen"

Stel dat u tegen een incident aanloopt, dan is het 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 e-mail. 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 servicelevelrapportages 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 of 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 móé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.

Lees meer over Beheer OP AG Intelligence
Reactie toevoegen