1. ICT wordt onbeheersbaar
2. Demand organisatie is nodig
3. Afstemming standaardservice aan de gebruikers
4. Inrichting toeleveringsketen
5. Vereiste volwassenheid partijen in de keten
6. Functioneel beheer is het inkopen van ICT-diensten 

1. ICT wordt onbeheersbaar

De ICT is in de loop der jaren een steeds sneller en krachtiger bedrijfsmiddel geworden met steeds meer mogelijkheden. Hierdoor is echter ook de complexiteit van de ICT-oplossingen en dus van het beheer sterk toegenomen. Er zijn allerlei specialisaties ontstaan. Alleen voor de ICT-infrastructuur en de bedrijfsapplicaties van een middelgrote organisatie zijn er al gauw enkele tientallen leveranciers, die in de vorm van producten en diensten elk één of enkele stukjes van de puzzel leveren. (Zie ook ‘ICT en functioneel beheer steeds meer logistieke processen’.) En uiteraard is elk stukje van die puzzel voorzien van een eigen gebruiksaanwijzing en bovendien, in het eigen jargon, van een eigen garantieregeling (die hebben we service level agreement oftewel SLA genoemd), opdat een leveranciers ervan verzekerd is, dat geen klant hem ooit zal vastpinnen op wat hij heeft beloofd. 

Figuur 1: Inrichten beheer is als het leggen van een puzzel

Aan de vraagkant ontbreekt echter doorgaans het overall-plaatje. U zult als organisatie veelal zelf moeten proberen de stukjes van deze complexe puzzel zodanig in elkaar te passen, dat de gebruikers over bruikbare ICT-oplossingen kunnen beschikken op hun werkplek. Dit klinkt niet zo heel ingewikkeld. We zien dan ook dat veel organisaties het beheer inrichten op het leggen van die puzzel.  

2. Demand organisatie is nodig

Voor de meeste organisaties is het echter niet lonend zelf de puzzel van het beheer weer ‘ín control’ te brengen. Weliswaar zijn hiervoor allerlei methoden beschikbaar, maar deze zijn vaak alleen geschikt voor organisaties die voldoende capaciteit en expertise hebben om het beheer netjes in te richten. (Zie ook ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1′). De meeste organisaties missen hiervoor de capaciteit. Maar ze hebben deze ook helemaal niet nodig. Vrijwel alle componenten van de ICT-infrastructuur zijn standaard of er zijn standaards voor verkrijgbaar. Als ICT niet uw’core business’ is, is het daarom onverstandig te investeren in het onderscheidend vermogen van de ICT. Want dat maakt het onderhoud en het beheer onnodig complex en daardoor kostbaar. Leveranciers van standaardcomponenten zijn uitwisselbaar. Zij moeten dus zien te overleven in een zeer competitieve markt. Zij moeten continu presteren om hun marktpositie te behouden. Ze zullen een goede dienstverlening moeten bieden tegen lage kosten. Doen ze dat niet , dan staan degenen die dat wel doen in de rij om het van hen over te nemen. In organisaties waar ICT niet core business is, zal het beheer zich daarom moeten richten op standaardisatie. Dan kan er slim ingekocht worden. En dan gaat het niet om het inkopen van puzzelstukjes in de vorm van hard- en software, maar om het inkopen van een compleet gelegde ICT-puzzel, zoveel mogelijk beheerd door een partij voor wie ICT core business is. (Zie ook ‘Veel dienstverleners kunnen geen koopbare diensten in hun businessmodel definiëren’.)
Het inkoopbeleid zal dus gericht moeten zijn op inkoopkracht, op het inkopen van schaalvoordelen, en op het inkopen van competenties met betrekking tot operationele producten en diensten zoals ICT-beheer, functioneel beheer, software, security en technische infrastructuur. (Zie ook ‘Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen’.) Er ontstaat dan de volgende situatie, met demand management aan externe leveringsketens. 

Figuur 2: De demandorganisatie

De demand organisatie heeft een tweetal taken: 

• het afstemmen van een gestandaardiseerde ICT-service met de gebruikersorganisatie;
• het aansturen van de ICT-leveringsketens.
   

3. Afstemming standaardservice aan de gebruikers

Van belang is, dat niet gestart wordt met een uitgebreide inventarisatie van wensen en eisen van de gebruikers. Het risico is dan veel te groot, dat er een waslijst met eisen ontstaat, die het onmogelijk maakt om nog een standaarddienst in te kopen. Vaak is het beter om op grond van een aantal knock-out criteria eerst een inventarisatie te maken bij die leveranciers, die in staat zijn de complete puzzel als een standaardpakket leveren (Zie ook ‘Selectie leverancier voor outsourcing werkplekbeheer’.) Daarbij zullen vooral ook de bestaande applicaties tegen het licht gehouden moeten worden, om te bepalen of ze eigenlijk nog wel nodig zijn. Van veel software die men vijf jaar geleden nog moest aanschaffen, bestaan nu volledige webbased versies, waarvoor slechts een browser nodig is om ze te draaien. Vaak wordt die software ook nog als freeware aangeboden. Hierdoor ontstaan mogelijkheden om ‘fat clients’ te vervangen door ‘thin clients’ en dus om te standaardiseren.
Vaak stuit vervangen wel op enige weerstand bij gebruikers. Maar het argument, dat er ooit een goede reden was om de software aan te schaffen, snijdt geen hout. Het tegenargument is, dat op basis van zulke argumenten ooit uw eigen rommelzolder is ontstaan. En dat argument is vaak wel overtuigend. Zeker als er ook nog een kostenplaatje kan worden getoond, waarbij geen investeringen meer nodig zijn en er alleen nog betaald wordt voor het gebruik. (Zie ook ‘SaaS is voor de gebruiker meer dan alleen stroom uit het stopcontact’.)  

4. Inrichting toeleveringsketen

Behalve dat de demand organisatie twee genoemde taken dient uit te voeren, vormt zij ook het hart van de leveringsketen. Bij de demand organisatie ligt het klantorderontkoppelpunt. Hier worden de eisen en wensen van de gebruikersorganisatie vertaald in een standaarddienstverlening. (Zie ook ‘Plaats klantorderontkoppelpunt (KOOP) is basis voor optimale klantgerichtheid en kosten’.) De leveringsketens die nodig zijn om de complete puzzel gestandaardiseerd in te vullen, worden hier samengesteld.
Eenvoudig te standaardiseren zijn het technisch beheer, het werkplekbeheer en zaken als telecom, beveiliging en continuïteit. De menukaart voor de klant voor dit soort zaken hoeft niet zo uitgebreid te zijn. Ingewikkelder zijn veelal het functioneel en technisch applicatiebeheer. De hiervoor benodigde kennis is vaak nogal specifiek en voer voor specialisten. Bovendien zijn juist de door de klanten gebruikte bedrijfsapplicaties nogal divers en het is vaak niet wenselijk om deze te vervangen. Zo zijn er bijvoorbeeld alleen al meer dan duizend verschillende ERP-pakketten met voor een groot deel dezelfde functionaliteit. Daarom zal de demand organisatie voor deze diensten procedures op moeten stellen met betrekking tot de inkoop, het applicatiebeheer en de rapportage en hier leveranciers bij moeten zoeken, die in dit plaatje passen.
Het plaatje komt er dan als volgt uit te zien: 

Figuur 3: Facility management

Uiteindelijk leidt dit meestal tot outsourcing van het totale functioneel en technisch beheer en van het applicatiebeheer. Aan de klantkant wordt daarbij het hele ICT-beheer vaak uitgekleed tot een facilitair beheer organisatie met dikwijls een aantal ’super-users’ die afstemmen met de demand-organisatie als ’single point of contact’, dat zelfs ondergebracht worden in een bestaande afdeling voor facilitaire zaken.
Het inrichten van de nieuwe situatie kan het best projectmatig aangepakt worden. Valkuil is dat er een belangrijk tegengesteld belang gemanaged moet worden: 

• het scherp inkopen van de gewenste ICT-diensten, met onderhandelingen op het scherp van de snede;
• het opbouwen van een goede samenwerkingsrelatie met de toekomstige outsourcingspartner.

Door het inzetten van een onafhankelijke partij die namens de gebruikersorganisatie inkoopt, kan deze valkuil vermeden worden. Deze derde partij heeft doorgaans meer ervaring met het inkopen van ICT-diensten en is een passant, voor wie de relatie met de toekomstige partner van minder belang is. De relatie tussen de gebruikersorganisatie en de beoogde leverancier hoeft zo niet te worden verstoord. Tevens kan deze partij als breekijzer optreden naar partijen, die in de toekomst mogelijk onderdeel van de leveringsketen worden.
Nadat het project is afgerond, verdwijnt de derde partij en wordt facility management aanspreekpunt voor de demand organisatie. De vraag is dan natuurlijk waar het facility management wordt belegd. Veel organisaties laten de ICT-afdeling het facilty management invullen. In veel gevallen pakt deze keuze slecht uit. Inkopen is immers een proces waarmee de meeste ICT’ers weinig affiniteit hebben. Zij kicken te veel op technische hoogstandjes en te weinig op bedrijfseconomisch nut. De afdeling inkoop of facility management zal niet in deze valkuil trappen. Maar de inkoop van diensten waarvan de specificaties vooraf nog niet vaststaan, is voor dergelijke afdelingen vaak een brug te ver. Daarom adviseren wij om de aansturing van de demand organisatie in het begin te beleggen bij het tactisch functioneel beheer. Hier zit de affiniteit met de ICT, samen met voldoende inzicht in de business om evenwichtig diensten in te kunnen kopen, ook zonder vastgestelde specificaties. 

5. Vereiste volwassenheid partijen in de keten

Voor een toeleveringsketen met lerend vermogen is het van belang, dat de demand organisatie, die de regie voert over de keten, in staat is de totale leveringsketen naar een hoger niveau te brengen. In het artikel ‘Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen’ worden de stappen naar volwassenheid beschreven aan de hand van het volgende plaatje: 

Figuur 4: Stappen naar volwassenheid in ICT

Als alle partijen op het eerste niveau acteren, dan heerst in de keten min of meer het principe van ‘de lamme leidt de blinde’. Dat leidt uiteraard tot niets anders dan extra overhead. Maar niet iedere partij in de keten hoeft door te groeien naar het vierde niveau. In principe is het voldoende dat de demand organisatie op het vierde niveau acteert. Daar wordt dan ook de kennisborging geïnitieerd en vanaf dit punt wordt de keten georganiseerd.
De keten kan er dan als volgt uitzien: 

Figuur 5: Organisseren van de keten

Facility management kan vervolgens de kennis en ervaring insourcen vanuit de demand organisatie, natuurlijk aangevuld met standaards en procedures, zodat facility management naar de gebruikers toe kan optreden als een professionele dienstverlener, waardoor ook de gebruikersorganisatie op een hoger niveau getild wordt. Het niveau van de onderaannemers is vanuit de gebruikersorganisatie gezien minder belangrijk. Dat is het probleem van de demand organisatie. Als ICT-leveranciers niet aan kunnen haken bij de eisen die de demand organisatie stelt, dan worden ze eenvoudig vervangen als ketenpartner. Als er voldoende gestandaardiseerd is, dan is dit doorgaans geen enkel probleem. (Zie ook ‘Net als mannen worden ICT-bedrijven bijna nooit volwassen’.)  

6. Functioneel beheer is het inkopen van ICT-diensten

Kortom, de professionaliteit van ICT-leveringsketens (met dus het functioneel en technisch beheer van de ICT) hangt niet zozeer af van de professionaliteit van de gebruikersorganisatie of de beheerders. Veel belangrijker voor de totale kwaliteit van de dienstverlening is de professionaliteit van de demand organisatie en de wijze waarop facility management in samenwerking met deze demand organisatie in staat is om de ICT-dienstverlening af te stemmen op de gebruikersbehoeften.
Natuurlijk bepalen de gebruikers de bestemming. Functioneel beheer plant vervolgens de route en koopt diensten in, waarmee deze bestemming bereikt wordt. Ook bepaalt functioneel beheer de randvoorwaarden. Niet op basis van wat de gebruikers willen, maar op basis van wat de organisatie nodig heeft. Vervolgens is het de demand organisatie die bepaalt hoe deze route afgelegd wordt. Zij heeft immers op dit gebied de meeste deskundigheid. Zij beschikt vooral ook over ervaring en best practices om de klippen te omzeilen en problemen op te lossen. Een beschrijving van zo’n demand organisatie wordt gegeven in het artikel ‘Service Delivery: niet het proces maar de prestatie telt’.
Aan de achterkant moeten ICT-bedrijven de keuze maken of zij zelf als professionele demand organisatie naar de klant willen optreden. Missen ze de volwassenheid om hieraan invulling te geven, dan hebben ze ook nog de mogelijkheid om succesvol te zijn als onderaannemer die ‘lean and mean’ diensten aanbiedt en die door te snijden in overhead voor een ‘demand organisatie’ interessant wordt om op te nemen in de leveringsketen.
Juist doordat het accent bij klanten steeds meer komt te liggen op het inkopen van ICT-diensten, zullen ICT-bedrijven zonder een duidelijk eigen gezicht steeds minder gevraagd worden door de eindklant. Zeker gezien de huidige recessie, zouden bij deze bedrijven wel eens de klappen kunnen vallen. (Zie ook ‘De recessie is een kans voor ICT-leveranciers met recurring business’.) Maar dat is natuurlijk niet het probleem van de inkopers van de afnemers. Die zullen hooguit profiteren van de shake-out onder de minder professionele ICT bedrijven.

Download:         

Gerelateerde artikelen:

1. ICT en functioneel beheer steeds meer logistieke processen
2. BiSL maakt functioneel beheer wel erg ingewikkeld
3. Service Level Management en Service Management functioneel beheer

Vroeger was ICT lekker overzichtelijk. Er werd gewerkt op basis van ‘Het onmogelijke doen we direct, wonderen duren iets langer, maar we garanderen niets’. Daar echter organisaties in toenemende mate afhankelijkheid zijn geworden van hun ICT, is deze werkwijze niet meer houdbaar. Standaardmethoden als ITIL hebben hun intrede gedaan, er zijn SLA’s opgesteld, stuurgroepen zijn ingericht en er is uitgebreid gegoocheld met verantwoordelijkheden en bevoegdheden. Het gevolg is wel, dat iedere flexibiliteit uit de ICT-dienstverlening is verdwenen. Irritatie en onbegrip zijn hierdoor toegenomen. De outsourcingspogingen van diverse bedrijven hebben deze nog eens versterkt. Ook de kwaliteit van de ICT-dienstverlening is er veelal niet door verbeterd, ondanks vuistdikke procedure handboeken.

Het ergste is, dat zowel de ICT’ers als de gebruikers, gesteund door hun management, vaak meer kissebissen over procedures dan over de inhoud. Waar het naar toe moet is daarbij meestal helemaal onduidelijk. Het lijkt dikwijls dweilen met de kraan open.

Diverse malen hebben we organisaties mogen helpen met het dichtdraaien van die kraan. Graag willen we u hierover vertellen in het webseminar ‘Organisatie ICT, functioneel beheer en projecten’. En we zijn natuurlijk ook benieuwd naar uw ervaringen.

Onze webseminars houden we steeds van 16.15 uur tot 17.00 uur. Om deel te kunnen nemen heeft u alleen een internetverbinding en een telefoonlijn nodig. Voor meer informatie kunt u de handleiding voor deelnemers raadplegen. U kunt zich voor het webseminar ‘Organisatie ICT, functioneel beheer en projecten’, eventueel samen met collega’s, aanmelden via het aanmeldingsformulier. Na aanmelding krijgt u per mail een bevestiging van uw deelname. Data voor andere webseminars  kunt u vinden in de agenda. Ook via onze nieuwsbrief houden we u op de hoogte.

Webseminars die mogelijk ook interessant voor u zijn:

• Webseminar Pragmatische aanpak informatiebeveiliging volgens ISO 27002 (=ISO 17799) en NEN 7510′
• Webseminar Business continuity, een aanpak uit de praktijk

Om gebruik te kunnen maken van de formulieren op deze site moet u eerst inloggen. Als u nog geen inlogcode heeft, sturen wij u deze per mail, zodra u zich heeft geregistreerd. U kunt zich via het registratieformulier snel en eenvoudig registreren.

Download:         

Gerelateerde artikelen:

1. Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens
2. Casestudy Training functioneel beheer website
3. Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer

1. Wijze lessen over het SLA en outsourcing
2. Het begint met liefde en vertrouwen
3. Een SLA als samenlevingscontract
4. Boetes werken niet
5. Onvolwassen en naïef?

1. Wijze lessen over het SLA en outsourcing

Het klinkt zo logisch: voordat u kunt beginnen aan outsourcing moet u zelf uw zaakjes op orde hebben, anders is uw outsourcingscontract gedoemd te mislukken en zult u nooit krijgen, wat uw bedoeling was dat u zou krijgen. Alleen als u uw zaken op orde heeft, kunt u zich wapenen tegen die ‘valse’ ICT-leverancier, die gemeten langs zijn lineaaltje, u precies geeft wat u heeft gevraagd, maar doorgaans niet wat u nodig heeft. Die als u meer wilt hebben dan afgesproken is, daar nog net geen boete op zet, maar wel spreekt van meerwerk. Meerwerk dat, als u de Europese aanbestedingsregels volgt, ook nog gelimiteerd wordt. Alleen als u uw zaken op orde heeft, kunt u voorkomen dat als u op langere termijn ontevreden bent, u niet kunt bijsturen, kunt u voorkomen dat u dan te horen krijgt dat dat natuurlijk uw eigen schuld is, want:

• u had beter moeten nadenken over uw behoeften;
• u had uw risk-management beter op orde moeten hebben, om verrassingen te voorkomen;
• u heeft verzuimd een lange termijn innovatiestrategie in uw contract op te nemen;
• u dacht toch niet echt dat uw vermaarde outsourcingspartner zich ging aanpassen aan wat u wilt?

En dat is natuurlijk onzin, verzonnen door saaie consultants of accountants, die de zon niet meer in het water kunnen zien schijnen. Dan zou er immers nooit een spel tussen jongverliefden kunnen uitmonden in een relatie die de verwachtingen van beide partners overtreft. De beschreven situatie en het overtreffen van de verwachtingen zijn de twee uitersten in het liefdesspel dat ICT-outsourcing heet.
In de laatste fase op weg naar volwassenheid heeft zowel de outsourcende partij als haar partner alles al een keer meegemaakt, zijn beide parijen maximaal in control en worden ze geregeerd door controlfreaks, voor wie 1+1 altijd als uitkomst 2 heeft. Het is te vergelijken met een verstandshuwelijk op huwelijkse voorwaarden tussen zeer seniore mensen die er zeker van willen zijn dat onzekerheden, verrassingen en passie buitengesloten worden. De noodzaak om zich aan elkaar aan te passen wordt ordelijk buitengesloten en de perfecte LAT-relatie is een feit.
Gelukkig geldt voor de meeste bedrijven dat ze nog kansen zien en bereid zijn om te leren, risico’s te nemen om hun doelen te bereiken en te investeren in relaties. Natuurlijk kun je dat als bedaarde en wijze goeroe onbezonnen vinden. De meeste organisaties hebben echter nu eenmaal niet overal ervaring mee. Maar zolang er enthousiaste dienstverleners zijn, die nog verliefd kunnen worden op hun klanten en in hen willen investeren, ontstaan er samenwerkingsverbanden met wederzijds hoge toegevoegde waarde, ondanks het feit dat die rationeel bekeken door gebrek aan ervaring misschien niet zouden moeten ontstaan. Waar een wederzijdse wil is, is ook een weg, ook al moet die misschien nog worden gevonden. En niet door controlfreaks, maar door ondernemers met een jeugdig elan. Best practices uit het verleden kunnen hier uiteraard wel bij helpen, maar die hoef je niet beslist eerst zelf te ervaren om er je voordeel mee te kunnen doen. 

2. Het begint met liefde en vertrouwen

Bent u op weg naar dat ICT-sprookje, dat eindigt met de standaardfrase ‘…. en ze leefden nog lang en gelukkig’? Dan heeft u vast een partner gevonden waarmee het klikt. Een partner die u vertrouwt. Een partner waarmee u kunt lachen, huilen en ruzie maken. Een partner die uw onbewuste behoeften aanvoelt en daarop anticipeert. En een partner die erop vertrouwt dat dat laatste wederzijds is. Sedert het begin van de mensheid worden zulke relaties gebouwd. Maar ogenschijnlijk is aan het eind van de vorige eeuw hierin een kentering gekomen. (Zie ook ‘Controle is goed, maar vertrouwen is beter’.) De babyboomers zijn in die periode grijs geworden. Ze hebben hun wilde haren verloren. In control werd hun motto. En het antwoord op deze ontwikkeling liet niet lang op zich wachten.
Samenleven en samen werken, het was ooit het devies van Balkenende 4. Helaas zijn liefde en zorg voor elkaar daarbij ondergeschikt geraakt aan de kleine lettertjes, de lettertjes die alles dichttimmeren en waarmee men zich indekt, maar die in een goede relatie volstrekt irrelevant zijn. De norm is nu: alles wat niet is afgesproken en vastgelegd, bestaat juridisch niet. (Zie ook ‘Waardecreatie belangrijker dan geld en macht’.) Het gevolg is een sterke juridisering van onze samenleving. Zo is het SLA geboren. Het SLA zelf werd gesteld boven zijn eigen bedoeling, namelijk vruchtbaar samenwerken. En het doet er niet toe of het nu gaat om outsourcing, samenwerking of een regeerakkoord, de kleine lettertjes zij de dienst gaan uitmaken. Geld verdienen of verliezen doe je tegenwoordig in de rechtszaal. Maar is deze hype wel duurzaam?

3. Een SLA als samenlevingscontract

Laten we een SLA eens beschouwen als een samenlevingscontract en kijken wat hierin geregeld wordt. Een samenlevingscontract is volgens postbus 51 een overeenkomst waarin afspraken worden gemaakt over zaken die met samenwonen te maken hebben. Onderwerpen waarover afspraken worden gemaakt, zijn:

• de financiële bijdrage in de kosten van elkaars levensonderhoud;
• de verdeling van de kosten van de huishouding;
• het gebruik van bankrekeningen;
• de verdeling van de bezittingen bij beëindiging van de relatie;
• alles wat met de woning te maken heeft.

Het gaat in het samenlevingscontract dus over zaken die niets te maken hebben met de intentie van het samenleven. Het gaat om financiële procedures en een exit-scenario. De condities waaronder dit exit-scenario van kracht wordt, zijn evenmin vastgelegd.
Een SLA zou in feite niet veel meer moeten zijn. Bij outsourcing stapt u in een avontuur, waar in principe twee partijen beter van moeten worden. Wat er precies geleverd wordt, is niet te omschrijven. Klanttevredenheid is immers meer gestoeld op de perceptie van de dienstverlening dan op het kille resultaat van de service. Als in een liefdesrelatie een kosten-baten analyse gemaakt wordt over de waarde van de relatie voor één der partijen, betekent dat, dat de vonk is gedoofd. De relatie kan dan beter gestopt worden. Het gaat in een liefdesrelatie tenslotte niet om ‘jij en ik’ maar om ‘wij’. Wat je samen zult tegenkomen op je pad, ligt verborgen in de toekomst. Zeker alle beproevingen voor de relatie zijn doorgaans niet te voorzien. Je gaat samen verder of je besluit uit elkaar te gaan. In het eerste geval zijn er twee winnaars en in het tweede geval twee verliezers, die proberen de schade te beperken omdat winstkansen geminimaliseerd zijn.

4. Boetes werken niet

Afspraken maken over boetes als één van beide partijen in gebreke blijft, is natuurlijk onzin. De basis van samenwerken is communicatie. Als één van beide partijen zich niet gelukkig voelt in de relatie, moet er gewerkt worden aan een oplossing waarbij beide partijen zich goed voelen. Als deze niet gevonden kan worden, dan rest slechts het exit-scenario. Maar dat is natuurlijk niet waarom de samenwerking is begonnen en waarom er is geïnvesteerd in de relatie. Blijkbaar kan de eisende partij dan onvoldoende duidelijk maken wat voor haar echt belangrijk is in de relatie. De wederpartij kan daardoor niet in de behoeften voorzien. Geld is geen vervanging voor de warmte van samenwerking, voor de intentie om samen dingen op te lossen. De waardevernietiging doordat het vertrouwen is ondermijnd is te groot om te compenseren. De vicieuze cirkel, de spiraal van schuld en boete komt dan heel dichtbij. In elk geval wenst men in zo’n situatie de partnet geen succes meer toe. Ook al bestaat het contract op dat moment nog, de relatie is dood of in elk geval verliesgevend voor beide partijen.
Geldzucht leidt alleen maar tot haat. Geldzucht staat een soepele afwikkeling van de exit-procedure in de weg. Er zal een situatie ontstaan, waarin de ex-partners elkaar bij een afscheid maximaal trachten te treffen. In dat geval zijn er geen winnaars. En juist dat moet worden voorkomen door het exit-scenario, alle goede bedoelingen van boeteregelingen ten spijt. Een bloemetje, een welgemeend ’sorry’ en inspanningen om verbeteringen te realiseren leveren vaak veel meer op. De basis voor een goed huwelijk is immers meestal geen uitgebreid contract, maar slechts een simpel ‘ja-woord’ voor de ambtenaar van de burgerlijke stand. En samen ben je er dan voor verantwoordelijk, dat het huwelijk een succes wordt.

5. Onvolwassen en naïef?

Mits u dus geen verzuurde, bejaarde controlfreak bent, die alles al een keer gezien heeft, ligt outsourcing binnen uw bereik. Niet met minimale risico’s en met optimale efficiency, maar als een avontuur dat u veel meer kan brengen dan simpele kostenvoordelen. U krijgt een partner met een complementaire expertise en samen kunt u elkaar naar een hoger niveau stuwen.
Dat u beide nog onvolwassen bent, is geen bezwaar, maar zelfs een voordeel. U kunt dan beide nog verder gevormd worden en zult beide bereid zijn om te leren. Het zou echter dom zijn om niet te willen leren van de expertise van anderen. U hoeft tenslotte niet elke fout opnieuw te maken en iedere best practice opnieuw uit te vinden. Dat zou het proces met uw partner maar stroperig maken en uw intenties onder druk zetten. Sta open in de wereld. Afspraken zijn goed en geldig tot u samen betere afspraken maakt.
Het is daarom dan ook niet verkeerd uw leverancier te volgen in zijn procedures, mits hij u wel de ruimte geeft om tussentijds aanpassingen te maken. (Zie ook ‘Alleen leveranciers die groot en sterk genoeg zijn, kunnen bij outsourcing denken aan Customer Intimacy, mits ..’.) Als u echter denkt dat bij outsourcing ICT uw aandacht niet meer vraagt en u veel goedkoper uit bent, dan is dat een misvatting. U sluit toch geen huwelijk uit winstbejag? U haalt extra expertise en operationele ondersteuning in huis, waarbij u moet leren deze optimaal te benutten. Als uzelf niet wilt leren, dan is outsourcing inderdaad een kansloze onderneming. Dan voelt namelijk niemand zich meer verantwoordelijk voor uw ICT.
Zoekt u echter niet een partij waarvoor outsourcing een commodity is, een operationeel proces met weinig toegevoegde waarde. Het verschil in volwassenheid of levensopvatting is dan te groot. Durf verliefd te worden op een partner die bij u past en ga samen het avontuur van outsourcing aan. Niet het onderliggende samenlevingscontract vormt daarbij de basis. Communicatie en respect zullen de basis moeten vormen. ( Zie ook ‘ICT-service management: contact is belangrijker dan contract’.) En dan zal het zijn als in het sprookje:’ ….. en ze leefden nog lang en gelukkig.’

Download:         

Gerelateerde artikelen:

1. Voor veel overheden geen verschil tussen Outsourcing BPO en Shared Service Center SSC
2. ERP-software voor klantordergestuurde of projectmatig werkende organisaties
3. Selectie leverancier voor outsourcing werkplekbeheer

1. Met blijdschap geven wij kennis …..: ITIL 3
2. Aanleiding ontstaan ITIL 3
3. Alternatieven voor ITIL
4. Conclusies ITIL 3

1. Met blijdschap geven wij kennis …..: ITIL3

Eerder dit jaar is ITIL3 gelanceerd. In het verleden ben ik nogal kritisch ben geweest over ITIL (zie ‘Begrafenis ITIL is begin van herstel ICT-imago’) en een reactie van mijn kant kan nu dan ook niet uitblijven.
Laat ik echter eerst duidelijk maken, dat ik absoluut geen ITIL-hater ben. Ik ben de eerste die zal toegeven, dat de introductie van ITIL in hoge mate heeft bijgedragen aan de volwassenheid van ICT-beheer binnen bedrijven.
Mijn kritiek richt zich meer op de eigen positionering van ITIL (de presentatie van een omgevallen boekenkast met best practices) als de strategische oplossing voor bedrijven, op de wijze waarop ITIL geïmplementeerd is door consultants en op de continue stiptheidsactie die vaak het resultaat waren van deze implementatie.
We gunnen u echter eerst kort een blik op de nieuweling binnen de ITIL-familie, die uiteraard weer opgebouwd is uit boeken met best practices. In voetnoten vindt u steeds ons specifieke commentaar en in hoofdstuk 4 trekken we onze conclusies.
De nieuwe generatie ITIL-boeken wijkt in filosofie af van de vorige generatie. Daar waar ITIL2 gebaseerd is op procesmatig werken – incidentbeheer, wijzigingsbeheer, et cetera -, is het kernidee achter ITIL3 het service lifecycle management*. In de service lifecycle wordt de levensloop van producten en diensten beschreven. De huidig in gebruik zijnde ITIL-literatuur wordt in zijn geheel vervangen door 5 nieuwe ITIL-boeken, die tezamen invulling geven aan deze cyclus:

• Service Strategies;
• Service Design;
• Service Introduction;
• Service Operations;
• Continual Service Improvement.

Service Strategies omvat vooral die onderwerpen die betrekking hebben op de positionering en het beheer van service processen bij service aansturende clusters.
Service Design houdt zich bezig met de architectuur van een dienst: hoe de dienst ontworpen en opgebouwd is en uitgevoerd kan worden.
Service Introduction en Service Operation bieden een raamwerk dat toegespitst is op de operationele processen.
Continual Service Improvement bespreekt hoe de processen volwassen worden en hoe veranderingen aangepakt kunnen worden.
Doel van deze service lifecycle is, ICT-diensten optimaal aan te bieden en daarmee continuïteit te waarborgen. De IT-organisatie krijgt hiermee een meer strategische rol, waarbij het gaat om het continu verkennen van veranderende omstandigheden en het aanpassen van de dienstverlening. Hierbij staat integratie van processen, middelen en mensen centraal**.

* De service lifecycle bestaat net als ieder kwaliteitssysteem uit ‘Plan-Do-Check-Act’. Deze cyclus en het kwaliteitsdenken waren al bekend toen ITIL2 werd gemaakt. Is dat het OCG destijds ontgaan? Nu worden bedrijven verplicht de structuur van hun handboeken aan te passen om ITIL3 compliant te worden, terwijl dit mechanisme reeds is ingebakken bij veel bedrijven die ITIL hanteren als een kwaliteitssysteem voor de dienstverlening.  
** Dat IT een steeds belangrijkere rol binnen organisaties krijgt, is terecht,
omdat organisaties steeds meer afhankelijk worden van deze IT en deze vaak de enabler is voor innovatie.
Dat impliceert echter geenszins, dat de IT-organisatie een steeds strategischer rol moet vervullen.

2. Aanleiding ontstaan ITIL3

ITIL is het eigendom van UK Office of Government Commerce (OGC). Dit wil na het uitbrengen van de nieuwe set boeken voor het eerst ook studiehulp voor ITIL-examens ontwikkelen, plus een nieuw, strategisch introductieboek voor managers en een brochure voor de board*.
De kernboeken moeten dunner worden dan nu, en alleen de echte kernconcepten en algemene best practices omvatten. Omdat die niet snel aan verandering onderhevig zijn, zal de volgende updateronde van ITIL minder gecompliceerd zijn, verwacht OGC**. Er wordt maar weinig van de bestaande inhoud volledig vervangen. Deze wordt vooral logischer gehergroepeerd naar een nieuw, meer op de business georiënteerd raamwerk***.
ITIL werd voor het laatste geüpdatet in 2000. De eerste reden voor deze update is, dat technologieën inmiddels verder zijn ontwikkeld en dat de behoefte van ICT-gebruikers en de business is veranderd. Bestaande ITIL-processen zijn in ITIL3 daarom opgepoetst en nieuwe processen zijn toegevoegd****.
De tweede reden is de kritiek op ITIL2. ITIL2 zou een wat abstracte procesbeschrijving hebben. Daarnaast lopen deze abstracte processen dwars door de hiërarchie van de organisatie en daarmee dwars door afdelingen en autorisatieniveaus. Deze factoren maken de implementatie moeilijk en tijdrovend. Bekend zijn de verhalen van organisaties die al voor de tweede of derde maal ITIL implementeren*****.
Een derde reden is dat ITIL gemakkelijker ingezet moet kunnen worden door kleinere organisaties. ITIL2 werd door veel organisaties als complex, veelomvattend en weinig schaalbaar gezien. Niet alleen door het aantal ITIL-processen, maar ook door de complexiteit van de processen zelf. Er zijn bijvoorbeeld weinig organisaties die hun service level management op orde hebben******.

* Als ITIL3 bestaat uit ingeblikte best practices, hoe zullen bedrijven dan strategisch voordeel kunnen behalen uit het gebruik van ITIL? Waarom moeten dan de managers en de board hiermee lastig gevallen worden?  

** Heeft het OGC ITIL als melkkoe ontdekt? Steeds met minimale inspanningen een nieuwe ITIL-versie uitbrengen en dan maximaal vangen omdat ITIL-gebruikers en ITIL-dienstverleners weer compliant willen zijn met de laatste versie.  

*** Zou het zo langzamerhand niet beter zijn om de term ‘best practices’ eens weg te laten uit de omschrijving van ITIL, wetend dat ITIL3 vrijwel geheel geschreven is door consultants?  

**** Dat de technologie en de behoefte veranderd zijn in de afgelopen jaren, dat is correct, maar waarom betekent dit dat ook de processen aangepast moeten worden? Deze zijn meestal zeer stabiel in de tijd. Waarschijnlijk is de enige reden, dat in ITIL3 voor een ander begrippenkader is gekozen, waardoor allerlei termen vertaald moeten worden om consistent te blijven.  

***** Juist hier wreekt zich, dat ITIL zich altijd geprofileerd heeft als een verzameling van best practices en procedures en met name dat het implementatiemodel ontbrak om te weten in welk ontwikkelingsstadium welke versie van ITIL thuishoort. Dit werd aan consultants overgelaten en vaak ontaardde dit in het rücksichtslos implementeren van alle procedures, waardoor de bekende permanente stiptheidsactie ontstond. Door onvoldoende te luisteren naar ‘het veld’ en ITIL te beschouwen als het middelpunt van het heelal heeft het OGC dit probleem eenvoudigweg gemist.  

****** Dat ITIL3 beter schaalbaar is, is misschien wel juist. ITIL verzuimt echter aan te geven hoe dan wel. Juist de operationele invalshoek maakte ITIL1 voor kleinere bedrijven hanteerbaar: je kon er direct mee aan de slag, mits je wist wat je wilde. Er is nog vrijwel geen kleinere ICT-organisatie, die de graad van volwassenheid ambieert, die ITIL3 voorstaat. Sterker nog; zo’n organisatie heeft liever ITIL1 met hierover een sausje van ITIL2 en ITIL3 in het implementatie model.  

3. Alternatieven voor ITIL

Gezien het succes van ITIL was het te verwachten, dat er alternatieven voor ITIL zouden komen. Ook die willen we kort in onze beschouwing meenemen.
IT-organisaties die een best practice willen invoeren, kunnen tegenwoordig kiezen uit een keur aan normen en procesinrichtingen. Twee opvallende spelers zijn ISO/IEC 20000 en BiSL.
ISO/IEC 20000 is niet zozeer een procesinrichtingsmodel, maar eerder een formele standaard voor het IT-servicemanagement. ISO/IEC 20000 doet meer aan het meten van benodigdheden voor die processen. Het beschrijft vrij concreet waar een organisatie aan moet voldoen. Daar waar ITIL momenteel bezig is aan een opmars in de Verenigde Staten, Zuid-Afrika, Australië en Oost-Europa, neemt ISO/IEC 20000 ondertussen in Azië en Duitsland een hoge vlucht.
Sinds enige jaren is er ook het Nederlandse BiSL (Business Information Services Library). Het doel van BiSL is, een brug te slaan tussen de bedrijfsprocessen en de informatiesystemen. Bij BiSL wordt uitgegaan van de gebruikers van de IT-middelen. BiSL biedt een procesmodel om informatiesystemen beter en efficiënter in te zetten voor ondersteuning van de bedrijfsprocessen. Waar andere best practices gericht zijn op alleen de IT-organisatie, is BiSL dus meer gericht op het management en de professionals.
Eén van de redenen voor de populariteit van ITIL is, dat ITIL altijd publiek eigendom is geweest. Op het gebied van consultancy en implementatie kan er breed worden gezocht naar aanbieders. Ook is er voldoende documentatie voorhanden. ITIL behoort niet toe aan een specifieke leverancier of producent. Tot voor kort tenminste.
Het beheer van ITIL is namelijk recent door OGC uitbesteed aan de commerciële instelling TSO, de voormalige staatsuitgever in het Verenigd Koninkrijk. De ITIL-certificeringen zijn uitbesteed aan APMG, bekend van het beheer van Prince2. Leveranciers van servicemanagement-applicaties of IT-consultants die ITIL willen gaan gebruiken, moeten hier waarschijnlijk voor gaan betalen. ISO/IEC 20000 en BiSL zijn wél publiek eigendom, of in ieder geval zit men niet vast aan een commerciële dienstverlener voor licenties, implementatie en advies.
Een ander voordeel van ISO/IEC 20000 en BiSL is, dat op basis van deze normen een audit kan plaatsvinden. Dat is waar, maar tegelijkertijd nietszeggend. Als het business management in zijn beleid vaststelt, dat het ICT-dienstverlening wil hebben met als uitgangspunt: ‘Het onmogelijke doen we direct, wonderen duren iets langer maar we garanderen niet’, dan is op grond van dit uitgangspunt iedere norm als overbodig te classificeren en is ook de auditor verplicht om hier zijn fiat aan te geven en het certificaat toe te kennen.

4. Conclusies ITIL3

In de voetnoten hebben we ons specifieke commentaar gegeven. Duidelijk mag zijn, dat dit commentaar in feite weinig kritiek bevat op ITIL 3, maar veel meer op de organisaties die ervan profiteren en op de valse verwachtingen die gewekt worden.
ITIL is een dijk van een merknaam geworden. Daar ITIL echter van niemand is, kan geen bedrijf hiervan exclusief profiteren. Dit weeffoutje wordt nu blijkbaar rechtgezet door het OGC. De merknaam gaat vanaf nu omgezet worden in klinkende munt, opgebracht door de ITIL-gebruikers, die ITIL met elkaar gerealiseerd hebben.
Voorts geldt voor zowel ITIL als voor  ISO/IEC 20000 en BiSL, dat je je moet afvragen wat je concreet hebt, als je het geïmplementeerd hebt. Het resultaat hiervan voor organisaties is onduidelijk en het is maar de vraag of het ambitieniveau van de ITIL-gebruiker gelijk is aan het impliciete ambitieniveau van het OGC. Door echter hierover geen uitspraken te doen, voorkom je de discussie en de vraag voor gebruikers of meegaan in een volgende versie überhaupt relevant is. In een volgend artikel gaan we dieper in op de positionering van de verschillende versies van ITIL in relatie tot de doelen die gebruikers van ITIL willen realiseren. (Zie ‘Van ITIL 1 naar ITIL 3: wat bereik je daar als organisatie mee?’.)
Door het ontbreken van een implementatiemodel maakte een beetje consultant bij de implementatie van ITIL1 al zijn eigen blauwdruk. (Zie ‘Blauwdruk processen IT-organisatie’.) Dit om de klant uit te leggen wat de waarde van ITIL voor hem kan zijn en wat hij precies krijgt. Op basis daarvan kon dan een eigen inrichtingsmodel gedefinieerd worden, waarmee de omgevallen boekenkast die ITIL in feite is, wordt teruggebracht tot de essentie. (Zie bijvoorbeeld ‘Inrichtingsmodel IT-beheer’.) Zowel de blauwdruk als een inrichtingsmodel, gebaseerd op ITIL1, gebruiken wij al jaren als uitgangspunt voor onze klanten, vaak naar grote tevredenheid van deze klanten. Gebruik van dergelijke modellen maakt migratie naar ITIL2 en ITIL3 in feite overbodig en de inkleuring kan plaatsvinden met behulp van de best practices die ITIL biedt.
Het belangrijkste dat per versie wijzigt, is het begrippenkader en de definities en dat is bottomline alleen de verpakking. De oorspronkelijke kracht van ITIL was, dat bepaalde begrippen van ICT-beheer gedefinieerd waren en dat de communicatiestoornissen over die begrippen daarmee werden weggenomen. Als ITIL echter zelf deze sterkte bij het oud vuil zet, dan moet je je afvragen of je nieuwe versies van ITIL nog een kans moet geven en of je je niet beter kunt beperken tot het toetsen van de eigen geïmplementeerde methode op het voortschrijdend inzicht dat in volgende versies van ITIL wordt toegevoegd.
Laat consultants hun verantwoordelijkheid nemen en dit issue ter discussie stellen, om hun klanten veel onnodig leed te besparen. (Zie ook ‘Wat mogen bedrijven tegenwoordig van hun adviseurs verwachten?’.) En laat klanten goed  nadenken voor ze besluiten te migreren naar ITIL 3. Nog geen organisatie heeft ooit strategisch voordeel gehaald uit de implementatie van een methodiek en dat zal ITIL3 niet veranderen. Het nieuwe gedachtegoed van

Download:         

Gerelateerde artikelen:

1. Van ITIL 1 naar ITIL 3: wat bereik je daar als organisatie mee
2. ITIL: professionalisering of indekken
3. Checklist ITIL Computer Operations

1. Samenvatting veranderingen in ITIL 3
2. ITIL 1, 2 en 3 hangen samen met volwassenheid
3. Hoe zijn nu ITIL 1, 2 en 3 in het plaatje in te passen?
4. Hoe kunt u het beste omgaan met ITIL 3?

1. Samenvatting veranderingen in ITIL 3

ITIL 2 is jarenlang de absolute wereldstandaard geweest voor het vakgebied IT-servicemanagement. Elf processen (Incident Management, Problem Management, Change Management, Configuration Management, Release Management, Service Level Management, Financial Management, Continuity Management, Avalability Management, Capacity Management en Security Management) verdeeld over twee sets (Service Support en Service Delivery) bieden een raamwerk van processen dat, mits in goede samenhang op elkaar afgestemd, een kwalitatieve dienstverlening mogelijk maakt.
De kern van ITIL 3 is de service lifecycle. (Zie ook ‘ITIL3: oude wijn in nieuwe zakken’.) Deze lifecycle bestaat uit vijf onderdelen:

• Service Strategy (over het ontwerpen, ontwikkelen en implementeren van service management);
• Service Design (over het ontwerpen en ontwikkelen van services en service-managementprocessen);
• Service Transition (over het ontwikkelen en verbeteren van het vermogen van de organisatie om nieuwe en veranderde diensten te operationaliseren);
• Service Operation (over het managen van service; efficiency en support in delivery en support);
• Continual Service Improvement (over het creëren en beheren van toegevoegde waarde voor klanten door het beter ontwerpen, introduceren en aanbieden van services).

Als bij ITIL 2 de voornaamste klachten de abstractie en de complexiteit zijn, wat is er in ITIL 3 dan verbeterd op deze gebieden? Kort en krachtig: ITIL 3 is een stuk abstracter geworden en de elf processen zijn uitgegroeid (afhankelijk van hoe je telt) tot wel 32 stuks. Daarom durf ik zonder terughoudendheid te stellen, dat de meeste organisaties in Nederland de komende jaren niets aan ITIL 3 zullen hebben of doen.
Toch is hier een nuance nodig: een klein deel van de organisaties is juist wél gebaat bij ITIL 3. Dat zijn vooral de zeer grote organisaties, die een hoge volwassenheid nastreven en die de ITIL 2-processen al lang soepel hebben draaien en nu een stap verder willen. Want daarin zit namelijk het waardevolle element van ITIL 3: de processen vormen niet meer het uitgangspunt, maar de service aan de klant. In alle eerlijkheid: dat is waar het in het IT-servicemanagement vakgebied om zou moeten draaien.
De vijf genoemde domeinen vormen het uitgangspunt om kwalitatief hoogwaardige ICT-dienstverlening te realiseren. Maar zoals gezegd: er zijn maar weinig organisaties die deze uitdaging aankunnen, of belangrijker, voor wie dit nodig is.

2. ITIL 1, 2 en 3 hangen samen met volwassenheid

Wat opvalt, is dat het werkelijke onderscheid tussen ITIL 1, 2 en 3 onderbelicht is gebleven. Dit onderscheid hangt namelijk niet samen met de ontwikkeling van ITIL, maar met de ontwikkeling van de ITIL-gebruiker en met het stadium van volwassenheid waarin deze ITIL-gebruiker zich bevindt.
Om deze volwassenheid aan te geven, wordt vaak het CMM-model gebruikt. (Zie ‘Capability Maturity Model’.) Nadelen van dit model zijn de complexiteit en de nogal interngerichte benadering. Zelf gebruiken wij al vijftien jaar een ander model, met veel meer herkenbare elementen. We zullen dat model eerst kort uiteenzetten.

2.1 Model om de volwassenheid te bepalen

Uitgangspunt is, dat de ICT-functie zich ontwikkelt en tijdens deze ontwikkeling stabiele en instabiele fases kent. Verder is de belangrijkste variabele de beheersingsgraad, of anders gezegd de flexibiliteit. Schematisch ziet de ontwikkeling van de ICT-functie er als volgt uit:

Figuur 1: Groeipad ICT-functie

 In de eerste fase is de dienstverlening van de ICT te karakteriseren als: ‘het onmogelijke doen we direct, wonderen duren iets langer, maar we garanderen niets’. Zolang de ICT nog weinig complex is, werkt dienstverlening op deze wijze uitstekend. Het evenwicht tussen flexibiliteit en beheersing ligt geheel links. Pas als het geheel complexer wordt, zullen er meer fouten worden gemaakt, waardoor de betrouwbaarheid van de dienstverlening afneemt. Dan ontstaat de behoefte aan beheersing.
De tweede stabiele fase is te karakteriseren als: de ‘gezonde klant-leveranciersrelatie’. De ICT-dienstverlening is ‘in control’ en er wordt gewerkt in opdracht van de klant op basis van projectcontracten en Service Level Agreements.
De derde fase is die van Business-ICT alignment. De ICT participeert in business solutions en kan hiertoe zelfs initiatiefnemer zijn. Niet de klant maar de klant van de klant en de ketenpartners staan centraal.
Het verloop van deze ontwikkeling is weergegeven in de volgende afbeelding:

Figuur 2: Verloop ontwikkeling ICT

 De instabiele fase tussen de stadia A en B verloopt via een situatie van absolute beheersing en volledige afwezigheid van flexibiliteit. De onrust met betrekking tot de leverbetrouwbaarheid van de service weegt dan echter niet op tegen de stroperigheid en het gebrek aan klantgerichtheid in de dienstverlening. Toch is het bereiken van uiterste beheersing noodzakelijk om deze als de norm neer te kunnen zetten en om de tijd van ‘vrijheid, blijheid’ definitief te beëindigen. Vervolgens moet echter weer een stuk flexibiliteit terugkomen onder het motto ‘een afspraak is goed en geldig tot we (tijdelijk) een betere afspraak maken’.
Organisaties die proberen in een rechte lijn van A naar B te komen, zullen merken, dat ze enerzijds steeds weer gedwongen worden om flexibel te zijn en anderzijds voortdurend verwijten krijgen, dat ze onbetrouwbaar zijn in hun dienstverlening. Natuurlijk is het wel zaak de instabiele periode zo kort mogelijk te houden.
Meer dan de helft van de Nederlandse organisaties echter verkeert ergens in deze instabiele fase. Helaas zijn er vele die dat zelfs al tien tot twintig jaar doen, doordat zij het doel van het veranderingsproces niet onderkennen.
Het veranderingsproces van B naar C is minder heftig. Overigens denken doorgaans alleen consultants dat ze zich hierin bevinden. In dit artikel gaan wij hier nu niet dieper op in.

3. Hoe zijn nu ITIL 1, 2 en 3 in het plaatje in te passen?

ITIL is ooit ontstaan vanuit een behoefte, een behoefte aan houvast die bij ICT-organisaties ontstond, doordat er klachten waren over hun dienstverlening. Hieronder zijn de verschillende versies van ITIL in bovengenoemd model geplaatst:

Figuur 3: Versies ITIL in groeimodel

Opvallend is wel, dat zowel ITIL 1, als 2 als 3 in de instabiele fases is gepositioneerd. Dat is echter gemakkelijk te verklaren:

• ITIL 1 kwam voort uit de behoefte meer beheersing te krijgen.
• ITIL 2 kwam voort uit de behoefte om naar een gezonde klant-leveranciersrelatie te komen.
• ITIL 3 had als doel tot een betere integratie te komen van de business en de ICT.

Welke versie van ITIL nuttig is, hangt af van het veranderingsproces waaraan de organisatie behoefte heeft. ITIL is dus geen doel maar een middel. De presentatie van ITIL 1 gaf daarom destijds ook blijk van visie. ITIL 1 was niets meer en niets minder dan een gereedschapset waarmee invulling gegeven kon worden aan het veranderingsproces. (Zie ook ‘Inrichtingsmodel IT-beheer’.)

4. Hoe kunt u het beste omgaan met ITIL 3?

ITIL is vercommercialiseerd.Het zijn de consultants die de macht gegrepen hebben en ITIL tot doel hebben verheven, wat onder andere blijkt uit het volgende:

• De schrijvers van ITIL 3 waren op één na allemaal consultants.
• De terminologie wordt in elke volgende versie van ITIL weer veranderd, waardoor geïmplementeerde beheerstandaards snel niet meer up-to-date lijken, en dat terwijl het sterkste punt van ITIL ooit was, dat er met ITIL eindelijk eenduidigheid kwam in het begrippenkader van het werkveld van Beheer.
• De scope van ITIL is gericht op annexatie van grensgebieden waarvoor de business accountable is. De ICT heeft hooguit responsibilities met betrekking tot deze grensgebieden, maar zeker geen zeggenschap.
• Het strategisch niveau is bij ITIL 3 veel zwaarder ingevuld. De strategische termen die in het verleden jammerlijk schipbreuk hebben geleden zijn opnieuw gelanceerd. Bij implementaties van ITIL 1 en 2 was het tactisch niveau in feite het top-level en was het strategisch niveau meer iets voor de vergadertafel van het ICT-management.

Hoe u uw beheer inricht en of u een volgende stap wilt maken in de ontwikkeling naar volwassenheid bepaalt u zelf. Dat bepaalt niet ITIL. En u kiest daarvoor die variant van ITIL als hulpmiddel, die u de beste handvatten geeft voor uw voorgenomen veranderingsproces.
En als u zich in een stabiele fase bevindt en u bent daar gelukkig mee, vergeet u dan deze hele discussie over ITIL 1, 2 of 3. (Zie bijvoorbeeld ‘Voorbeeld opzet handboek voor ICT kwaliteit deel 3′.) Een goed werkende situatie moet u in stand zien  te houden. Onze ervaring heeft ons geleerd, dat met een goed implementatiemodel ook op basis van ITIL 1 de doelstellingen van ITIL 2 en 3 zijn te realiseren. Een voorbeeld hiervan vind u in ‘Blauwdruk processen IT-organisatie’.

Download:         

Gerelateerde artikelen:

1. ITIL: professionalisering of indekken
2. Checklist ITIL Computer Operations
3. Checklist ITIL Change Management

1. Soft skills ook in ICT-beheer
2. Frontoffice en backoffice
3. Inrichting helpdesk of incidentbeheer
4. De rol van de service manager
5. Het profiel van de service manager

1. Soft skills ook bij ICT-beheer

ITIL is bedoeld voor het technisch beheer van de ICT binnen de ICT-afdeling zelf. De gebruiker echter vraagt service. Gecertificeerde ITIL service managers hebben wel het belang van service meegekregen, maar de soft skills ervoor ontbreken veelal. Daardoor ontstaat vaak een kloof tussen gebruikers en SM’ers. (Zie ‘Begrafenis ITIL is begin van herstel ICT-imago’). De ICT-afdeling zelf beschikt over voldoende technische vaardigheden. Voor een service manager zijn sociale en communicatieve vaardigheden daarom van groter belang. Daarmee kan onderling begrip worden gekweekt.Het zijn tenslotte de koppelvlakken tussen ICT en gebruikersafdelingen, waar de basis gelegd wordt voor miscommunicatie. (Zie ook ‘Blauwdruk processen IT-organisatie’.) Waar die koppelvlakken precies liggen, is niet het issue. Het issue is dat beide partijen weten waar die koppelvlakken liggen, daar naar handelen wat betreft hun takenpakket en beide zorgdragen voor een goede overdracht op het koppelvlak.

Figuur 1: Relatie gebruikers - IT-organisatie

Juist op het koppelvlak ontstaat vaak het onbegrip: ICT’ers denken in ICT en gebruikers denken in toepassing en beide partijen denken het recht te hebben om de inhoud vanuit hun professie te belichten, zonder daarbij rekening te houden met de ander. Vaak wordt zelfs niet eens een poging gedaan om zo dicht mogelijk langs elkaar heen te praten.

2. Frontoffice en backoffice

Het is niet voor niets, dat aan zowel de kant van de gebruikers als van de ICT’ers een frontoffice wordt ingericht. Die frontoffices zijn op de hoogte van elkaars problemen en communiceren op grond daarvan beter met elkaar.
Veel organisaties bevinden zich voor wat betreft hun ICT echter nog in het ontwikkelingsproces van stadium A: ‘Het onmogelijke doen we direct; wonderen duren iets langer, maar we garanderen niets’ naar stadium B: ‘De professionele klant-leverancierrelatie’. We zien dan ook dat in veel gevallen de ingerichte frontoffices netjes omzeild worden en er direct contact plaatsvindt tussen businessexperts en ICT-experts.

Figuur 2: Ontwikkelingsstadia

Juist doordat de servicegerichtheid in stadium A veel groter lijkt dan in stadium B, ervaren veel gebruikers de invoering van bijvoorbeeld ITIL als een grote stap terug in de dienstverlening. Zeker de gebruikersexperts die met de ICT-experts een goede relatie hadden opgebouwd en precies wisten welke ICT-expert ze moesten hebben voor welk probleem, raken gefrustreerd door de gewijzigde klant-leverancierrelatie. Die goede relatie die ze hadden stond tenslotte borg voor een snelle en adequate dienstverlening. Dat er tevens een onbeheersbare situatie bestond met betrekking tot de betrouwbaarheid van de informatievoorziening zien ze vaak niet. En dat beheersing eerst de geaccepteerde norm moet worden, voordat flexibiliteit weer toegepast kan worden evenmin.(Zie ook ‘Support samenwerking gebruikers en ICT-afdeling’.)
Juist de key-user zijn vaak degenen die de weg naar beheersing het meest verstoren. Zij kennen de sluiproutes, waardoor de file als geheel alleen maar langer wordt. Het volgende plaatje is vaak kenmerkend voor de communicatie in dergelijke situaties.

Figuur 3: Huidige praktijk

Door de inrichting van een frontoffice in de vorm van een helpdesk kan één en ander gestroomlijnd worden. Helaas is de kwaliteit van de helpdeskmedewerkers vaak zodanig, dat deze links en rechts gepasseerd worden.

3. Inrichting helpdesk of incidentbeheer

Enkele jaren geleden is de naam van het frontoffice proces gewijzigd van helpdesk naar incidentbeheer. Dit is veelzeggend. De focus van dit proces ligt duidelijk op ellende, terwijl in het meest gunstige geval ook nog service geleverd wordt. Voor de ICT-afdeling als service organisatie levert dit een onhoudbare situatie op. Het probleem is echter niet opgelost met te zeggen dat er te weinig awareness is bij de gebruikers, het stokpaardje van informatiebeveiligers. (Zie ook ‘Informatiebeveiligers verpesten iedere awareness’) Roepen dat opdrachtgevers zich niet goed kwijten van hun taak, wat reclamebureaus tegenwoordig doen (zie ook ‘Marketing- en reclamebureaus zetten de wereld op z’n kop!’), lost evenmin iets op.
Het probleem ligt primair bij de ICT-afdeling en die zal het moeten oplossen. Het gaat hierbij enerzijds om architectuur die niet afgebroken mag worden en anderzijds om relatiebeheer met de interne en externe klant. De verantwoordelijkheid hiervoor moet echter wel belegd worden. Volgens de ITIL-methodiek behoort dit te gebeuren op strategisch niveau, ofwel op het niveau van de ICT-manager. Maar ICT-managers hebben wel wat beters te doen. Sommige sturen daarom de helpdeskmedewerkers naar een cursus ‘klantgericht communiceren’ en denken daarmee het probleem te hebben opgelost.
In andere bedrijven wordt druk gepolderd in de vorm van het benoemen van stuurgroepen of overlegorganen. Die nemen dan vaak besluiten waarvan realisatie grote inspanningen verg. Bovendien wordt daarbij vaak geen rekening gehouden met architecturen en koppelvlakken, waardoor op langere termijn weer instabiliteit ontstaat. (Zie ook ‘Waarom stuurgroepen vaak het roer niet kunnen vasthouden’.)
Waar het in feite op neerkomt, is dat willen serviceafspraken gaan werken, ze niet gemaakt moeten worden op strategisch of operationeel niveau, maar op tactisch niveau.

Figuur 4: Serviceafspraken op tactisch niveau

 4. De rol van de service manager

Natuurlijk zijn er contacten en afspraken nodig op strategisch en operationeel niveau. Als er echter geen concrete afspraken gemaakt worden op tactisch niveau, dan is de rest gebakken lucht. (Zie ook ‘Besparingen door gebruik van professionele Service Level Agreements – SLA’ s’.) Het opstellen van een SLA is in feite niets meer dan het slaan van paaltjes, die het gebied afbakenen waarbinnen de resultaten van de onderhandelingen op tactisch niveau moeten uitkomen. Zonder tactische afspraken leiden operationele afspraken tot een terugkeer tot het niveau van ‘het onmogelijke doen we direct … etc’. Juist dat tactische niveau is het terrein van de service manager.
Helaas onderkent ITIL de rol van service manager niet. ITIL laat sowieso in het midden, wie welke rol moet vervullen, doordat een implementatiemodel ontbreekt. (Zie ook ‘Inrichtingsmodel IT-beheer’.)
In het kort kunnen we zeggen dat de service manager drie rollen dient te vervullen:

• bieden van zekerheid over de informatievoorziening aan de klant;
• beheersen van het ICT-beheer, opdat die dienst ook inderdaad geleverd wordt;
• geven van vertrouwen, opdat eisen en wensen van de gebruikers zodanig vertaald worden, dat de dienst op economisch verantwoorde wijze geleverd kan worden, zonder dat dit afbreuk doet aan de architecturen.

In feite is dit een ‘mission impossible’. ITIL legt de eerste rol op tactisch, de tweede op operationeel en de derde op strategisch niveau. Organisaties die conform ITIL werken, dwingen hun service managers in een spagaat, die in de praktijk onuitvoerbaar is.
Veelal wordt dit probleem opgelost door met name het derde aspect uit de functieomschrijving te halen. De derde rol wordt dan echter vaak niet elders belegd. Daardoor blijft de chemie tussen de gebruikers en de ICT ontbreken. Dat maakt het voor de service manager weer vrijwel onmogelijk om de eerste rol te vervullen. Meestal vlucht men vervolgens in een SLA, waarvan in de praktijk niemand gelukkig wordt, doordat men hiervoor standaards gebruikt. (Zie ook ‘ITIL: professionalisering of indekken?’.) Wat rest is de operationele interne taak binnen de ICT, om de levering van ICT-diensten veilig te stellen.

5. Het profiel van de service manager

Service managers blijken in de praktijk vaak ambitieuze ICT’ers te zijn, die hogerop willen. Als we kijken naar het profiel van de service manager zoals het Exin dat omschrijft, dan moeten we vaststellen dat weinig ICT’ers daaraan voldoen. Dit geldt zeker voor de laatste twee punten.

Het Exin geeft aan: Met het behalen van het certificaat ITIL Service Manager heeft u vaardigheid in:

• het analyseren van een bestaande organisatie voor het beheer van de ICT infrastructuur;
• het ontwerpen van een organisatiestructuur ten behoeve van het beheer van de ICT-infrastructuur;
• het beschrijven van de ICT-service management processen en het beoordelen van de ICT-service management processen in een gegeven organisatie;
  het adviseren inzake veranderingstrajecten;
• schriftelijk rapporteren en interactief communiceren.

Het Exin-examen toetst echter met name de eerste drie punten en is zeker niet gericht op de vaardigheidseisen.

In de praktijk bestaat de schaap-met-vijf-poten- functie van service manager niet, omdat de functie vrijwel niet is in te vullen:

• operationeel manager van een ICT-dienstverleningsorganisatie;
• accountmanager voor de klant;
• architect van oplossingen om de dienstverlening conform de klantwens op een effectieve en efficiënte manier in te vullen.

Het aanstellen van een service manager lijkt dus niet de oplossing te zijn voor het probleem van miscommunicatie en wantrouwen. ICT-afdelingen en -organisaties moeten echter wel bovenstaande competenties per klant kunnen invullen.
Denkt u dat de inzet van een soft SM’er weggegooid geld is? Of dat werkelijk zo is, daar komen de meeste bedrijven pas achter als de SM’er weg is. Gebrek aan vertrouwen en communicatie kosten een veelvoud van zo’n soft SM’er. En daar helpt geen SLA tegen.

Download:         

Gerelateerde artikelen:

1. Wat is een Service Level Agreement
2. Assessment ICT Service Level Management
3. Service Level Management en Service Management functioneel beheer

1. Inleiding
2. Wat is een Service Level Agreement?
3. SLA opstellen
4. Controle: de rapportage over het service level
5. Conclusie

1. Inleiding

Alle leveranciers die zorgdragen voor aspecten van beheer, zowel op het gebied van hardware, databases, besturingssystemen en netwerken als van applicaties zouden de overeenkomst moeten vastleggen in de vorm van een Service Level Agreement. Het gaat daarbij niet alleen om het oplossen van plotseling optredende problemen, maar zeker ook om  het pro-actief beheren (controleren en signaleren) van de situatie bij de klant. Deze vorm van service verlening kan op locatie of op afstand via een inbelverbinding worden verleend. De klant bepaalt zelf welke vorm voor de onderneming de meest geschikte is. In overleg tussen klant en leverancier wordt bepaald welk niveau van dienstverlening voor de diverse aspecten van de ICT-omgeving gewenst is.
Op basis daarvan wordt een Service Level Agreement opgesteld, waarin helder, overzichtelijk en meetbaar ICT wordt gedefinieerd en welke afspraken ten aanzien van de dienstverlening zijn gemaakt Periodiek ontvangt de afnemer van de leverancier een rapportage over de uitvoering van de Service Level Agreement, zodat hij inzicht krijgt in de verrichte werkzaamheden.

2. Wat is een Service Level Agreement?

Een Service Level Agreement is een contract tussen klant en leverancier over het te leveren niveau en type service. Vervolgens wordt bijgehouden of de klant ook daadwerkelijk krijgt waar hij voor betaalt. Een SLA wordt onder andere opgesteld voor een organisatie die een deel van de automatisering wil uitbesteden aan een leverancier. Ook kunnen SLA’s worden opgezet voor de verschillende afdelingen binnen een organisatie. De kosten worden dan per afdeling afgestemd en het gebruik wordt per afdeling verrekend. Zo worden de kosten van de automatisering beheersbaar en controleerbaar gehouden.

2.1 Ontwikkelingen

De ontwikkelingen binnen de computerwereld volgen elkaar snel op. Na het mainframe, deed de LAN zijn intrede en nu zijn het Web georiënteerde applicaties die de markt veroveren. Omdat deze ontwikkelingen niet betekenen dat alle “oude” technologie bij het straatvuil wordt gezet, is de automatisering er niet gemakkelijker op geworden. Mainframes, WAN systemen en Webtechnologie worden met elkaar geïntegreerd, wat inhoudt dat laag op laag wordt gebouwd.
Simpele centrale capaciteitsplanning, zoals we die kennen uit het oude mainframe tijdperk is er daarom niet meer bij. Een mainframe is één centraal systeem waarvan de capaciteit en het aantal gebruikers bekend zijn. Een Service Level Agreement is hiervoor goed te maken, omdat capaciteit en gebruik eenvoudig zijn vast te leggen. Als een klant bijvoorbeeld 30% van de processortijd van een mainframe gebruikt, dan is daar gemakkelijk een prijsje aan te verbinden, omdat alles centraal wordt geregistreerd.
Tegenwoordig hebben we te maken met een veelheid aan systemen, die vaak op ondoorzichtige wijze aan elkaar gekoppeld zijn. Van het aantal gebruikers kan vaak slechts een schatting worden gemaakt. Hoewel het gedistribueerde systeem een groot aantal voordelen kent, is het opstellen van een goede Service Level Agreement een lastig karwei. Hierbij moeten lange ketens van subsystemen, waaruit het totale systeem bestaat, onder de loep genomen worden.

2.2 Meetbaarheid

Een leverancier moet toch een prijskaartje hangen aan het gebruik van zijn voorzieningen. Om een SLA op te stellen, moet hij weten welke capaciteit nodig is om het gewenste serviceniveau te kunnen leveren.

Om iets te kunnen zeggen over de capaciteit zijn de oude methoden ontoereikend, omdat er te veel schakeringen zijn die beperkingen kunnen opleggen aan het systeem. Nieuwe methoden en tools zijn ontwikkeld om toch iets te kunnen zeggen over de capaciteitsplanning. Tools worden ingezet om de aanwezige systemen op de voet te volgen. De meeste tools geven informatie over 3 kwaliteitsattributen: beschikbaarheid, betrouwbaarheid en responstijd.

2.2.1 Beschikbaarheid

Geeft aan hoeveel procent van de tijd het systeem beschikbaar is.

2.2.2 Betrouwbaarheid

Geeft aan in hoeveel procent van de gevallen de informatiebronnen juist en up-to-date zijn.

2.2.3 Responsetijd

Geeft aan in hoeveel tijd een percentage van het aantal gevraagde services is afgehandeld. Bijvoorbeeld: 95% van de serviceaanvragen is in maximaal 120 seconden afgehandeld.
Hoewel beschikbaarheid belangrijk is, prevaleert de betrouwbaarheid als sleuteleenheid, omdat betrouwbaarheid nauw verbonden is met beschikbaarheid. Is een systeem 90% beschikbaar, dan lijkt dat een mooi cijfer. Maar als dit betekent dat 10% van de gegevens niet aanwezig is, dan duidt dat op een lage betrouwbaarheid.
De gebruiker merkt het meest van de responsetijd. Hoge responsetijd maakt het werken met het systeem tot een langdurige bezigheid en vormt daarom een bedreiging voor de productiviteit van de gebruikers.

2.3 Behoefteplanning

Hoeveel gebruikers kan deze server aan? Kan ik de database SQL applicatie en een Exchange applicatie op één machine draaien? Hoeveel gebruikers kan ik gelijktijdig afhandelen met deze Exchange server? Capaciteitsplanning binnen de Windows wereld is vaak puur gokwerk. Het is niet altijd even duidelijk welke hardware benodigd is om de gestelde eisen te halen. Om daar toch wat meer over te kunnen zeggen zijn er speciale tools ontwikkeld. Deze tools belasten de gehele infrastructuur met echte serviceaanvragen. Zo kan worden nagegaan welke belasting de gevraagde services op de aanwezige voorzieningen legt. Deze gegevens kunnen vervolgens worden gebruikt om na te gaan welke capaciteit nodig is. Ook kan de leverancier nu de kosten bepalen die het gewenste serviceniveau met zich meebrengt.

3. SLA opstellen

Een SLA opstellen betekent in feite het koppelen van het businessmodel aan het technische model. De onderhandelingen tussen leverancier en de klant moeten niet gaan over cpu tijd en hoeveelheden gebruikt geheugen, maar over eenheden die begrijpelijk en meetbaar zijn voor de klant, zoals het aantal transacties per uur of het aantal mailtjes per dag. Het beste is een tabel op te stellen waarin aan de linkerkant de zakelijke doelen staan vermeld en aan de rechterkant de technische doelen. In het artikel ‘Checklist Service Level Agreement SLA’ vindt u een checklist die u van dienst kan zijn bij het opstellen van een SLA.
Voorbeeld van een zakelijk doel: verminder de “downtime” en het technische doel zou dan installatie van een pro-actief netwerk managementsysteem kunnen zijn. Een ander zakelijk doel: het verbeteren van de concurrentiepositie. Het technische doel is dan bijvoorbeeld een versimpelde toegang tot het extranet voor de klant.
In de SLA wordt de link gelegd tussen de zakelijke verwachtingen van de klant en de benodigde technologie. Hoewel het moeite en energie kost om een SLA op te stellen en zich hier aan te houden, levert het wel degelijk wat op: de leverancier kan laten zien dat hij de gewenste service levert, op een manier die begrijpelijk is voor de klant, conform vooraf gedefinieerde meetpunten en gerealiseerde resultaten. Bovendien weet de leverancier precies wat er van hem verwacht wordt. En de klant ziet zijn zakelijke verwachtingen gerealiseerd worden, zonder dat hij met onverwachte tegenvallers te kampen heeft.

3.1 Een SLA-model

Om een SLA op te stellen zijn verschillende modellen beschikbaar. In de volgende paragraaf wordt een veel gebruikt model besproken.
De leverancier verplicht zichzelf in een SLA een prestatiegarantie te geven. Hij is hierin wel afhankelijk van zijn toeleveranciers en van de systeemontwikkelaars. Zo ontstaat er een driehoeksverhouding tussen de partijen die in de onderstaande opstelling staan weergegeven.
De contractuele relaties vormen gezamenlijk de SLA. Zo valt de SLA dus uiteen in vier onderdelen:

• SLA/1: prestatie-eisen;
• SLA/2: afspraken over maximale belasting door de gebruikers;
• SLA/3: eisen die de leverancier stelt aan de systeemontwikkel- en onderhoudsorganisatie;
• SLA/4: eisen die de leverancier stelt aan derden (hardwareleveranciers etc.).

De opzet van deze SLA’s worden in de volgende paragrafen besproken.

3.1.1 SLA/1 prestatie-eisen

In dit gedeelte van de SLA worden de prestaties vastgelegd, die de klant verwacht van de leverancier. De volgende kwaliteitsattributen worden vastgelegd:

3.1.1.1. Betrouwbaarheid

• juistheid en volledigheid:
  De leverancier garandeert dat de juiste versie van de programmatuur en de bestanden wordt verwerkt en dat de verwerking aantoonbaar volledig wordt afgerond.
• veiligheid:
  De leverancier garandeert dat slechts toegang tot de verwerking en de gegevens wordt verleend aan diegenen, die daarvoor door de functioneel beheerders geautoriseerd zijn.

3.1.1.2. Continuïteit

• bedrijfszekerheid:
  De leverancier garandeert een bepaalde MTBF (Mean Time Between Failure).
• veerkracht en herstelbaarheid:
  De leverancier garandeert een bepaalde MTTR (Mean Time To Repair/Recover).
• uitwijkmogelijkheid:
  De leverancier kan afspraken maken over de tijd waarbinnen een noodvoorziening operationeel wordt na calamiteiten. Deze twee kwaliteitsaspecten worden vaak vastgelegd met behulp van een calamiteitenplan, waarin stap voor stap staat beschreven wat er staat te gebeuren als er dan toch problemen ontstaan.

3.1.1.3. Snelheid

De leverancier garandeert bepaalde gemiddelde en maximale responsetijden voor een aantal interactieve toepassingen en een bepaalde batch-turnaround-tijd voor de achtergrondtoepassingen.

3.1.1.4. Beschikbaarheid

De leverancier garandeert een bepaald percentage beschikbaarheid (bijvoorbeeld 95%) gedurende de tijden dat de geautomatiseerde informatievoorziening gebruikt wordt (bijvoorbeeld op werkdagen van 9-17 uur). Daarnaast garandeert de leverancier voor dat gedeelte van het netwerk dat hij zelf beheert, dat de informatievoorziening op alle afgesproken plaatsen toegankelijk is. (Garanties voor de beschikbaarheid van publieke netwerken zijn afhankelijk van de afspraken die de leverancier met de desbetreffende beheerders kan maken, zie SLA/4.)
In een goede SLA komen al deze kwaliteitsattributen voor.

3.1.2 SLA/2 maximale gebruikersbelasting

Wanneer de klant garanties wenst voor het prestatieniveau, dan hoort daar ook bij dat hij de maximale gebruiksbelasting aangeeft, waarbij dat kwaliteitsniveau nog gehaald moet worden. De maximale gebruiksbelasting wordt aangegeven in termen als:

• het maximum aantal werkstations dat tegelijk aanvragen doet op een server;
• de afstand van de werkstations tot de leverancier (zijn er alleen lokale werkstations, zijn ze verspreid over het land, of zelfs internationaal verspreid);
• het maximum aantal transacties per tijdseenheid (uitgesplitst naar soorten transactie, met indicatie van bijzondere piekbelastingen);
• de hoeveelheid gegevens die op de voorgrond aanwezig moet zijn;
• de hoeveelheid gegevens die dagelijks op de achtergrond in de batch verwerkt moet worden.

3.1.3 SLA/3 Eisen die de leverancier aan de systeemontwikkel- en onderhoudsorganisatie stelt

Het gaat hierbij om twee zaken:

3.1.3.1 Eisen aan het onderhoudsproces

De leverancier maakt afspraken over een snelle procedure voor correctief onderhoud door de onderhoudsorganisatie. Wanneer bijvoorbeeld de continuïteit van de informatievoorziening door fouten in de applicatieprogrammatuur in gevaar komt, moet zeer snel onderhoud gepleegd kunnen worden. De leverancier kan zelf de coördinatie van dit onderhoud in handen houden via de helpdesk.

3.1.3.2 Acceptatiecriteria voor de producten van de systeemontwikkel- en onderhoudsorganisatie

De leverancier stelt criteria op voor de acceptatie van de applicaties die de systeemontwikkel- en onderhoudsorganisatie in productie wil geven. Het hanteren van acceptatiecriteria betekent in ieder geval dat de leverancier die applicaties aan een eigen acceptatietest onderwerpt. Soms echter zal de leverancier ook inspraak eisen in de ontwikkeling van die applicaties. In het algemeen is een vroegtijdige betrokkenheid van de leverancier bij het ontwikkelproces sterk aan te bevelen. De te stellen eisen hebben met name betrekking op de volgende kwaliteitsattributen:

• Onderhoudbaarheid:
  Bij fouten in de applicaties die tot storingen in de geautomatiseerde gegevensverwerking leiden, moet snel correctief onderhoud mogelijk zijn, ook zonder dat men in de programmatuur is ingewijd.
• Geschiktheid van de infrastructuur:
  De applicatie moet geschikt zijn voor de technische infrastructuur waarover de leverancier beschikt.
• Betrouwbaarheid:
  De applicatie mag nagenoeg geen ‘technische fouten’ meer bevatten. Hieronder verstaan wij fouten die leiden tot afbreking van de verwerking, fouten die de bestanden beschadigen etc.
• Zuinigheid:
  De applicatie moet economisch omspringen met de resources (machinecyclus, opslagcapaciteit) waarover de leverancier beschikt. Men kan dit uitwerken tot normen voor het aantal I/O-accessen van kritische transacties. De applicatie moet ook zuinig omspringen met het personeel van de leverancier. Men kan bijvoorbeeld als norm stellen dat gegevensverwerkingen in principe zonder tussenkomst van operateurs worden afgehandeld.

3.1.4 SLA/4 Eisen van de leverancier aan derden

De hardwareleveranciers en de beheerders van publieke netwerken kunnen een zodanige invloed uitoefenen op de totale kwaliteit, dat zij in de afspraken betrokken moeten worden, zoals hierna is aangegeven.

3.1.4.1 Eisen aan leveranciers

De leverancier maakt met de leveranciers van hardware, basisprogrammatuur enzovoort afspraken over snelle reparatie van programmatuurfouten en vervanging van defecte onderdelen.

3.1.4.2. Afspraken met netwerkbeheerders

De leverancier maakt afspraken met de beheerders van publieke netwerken, zoals bijvoorbeeld de KPN, over de beschikbaarheid van (voldoende capaciteit van) dat netwerk.

4. Controle: de rapportage over het service level

Het sluitstuk van het Service Level Management wordt gevormd door rapportages over de uitvoering van de diverse onderdelen van de Service Level Agreement. Deze rapportages dienen ervoor om op de korte termijn te verifiëren of de gemaakte afspraken worden nagekomen, en om ze waar nodig bij te sturen. Daarnaast vormen zij op de lange termijn een belangrijk instrument voor verdere kwaliteitsverbetering, doordat zij aangeven op welke punten de service levels hoger gesteld kunnen worden.

4.1 Rapportage over het prestatieniveau

Alhoewel het merkwaardig aandoet, zal alleen de leverancier in staat zijn om een statistiek te maken over de kwaliteit van zijn eigen functioneren, om op basis daarvan te rapporteren over de bereikte prestatieniveaus. Aan de betrouwbaarheid van deze rapportage kan bijvoorbeeld in een third-partymededeling aandacht worden geschonken. Er dient vastgelegd te worden over welke periode telkens gerapporteerd wordt. Het is van groot belang om vergelijkbare periodes te kiezen, zodat de ontwikkeling in het dienstverleningsniveau blijkt. Dagen, weken of kwartalen voldoen als eenheid beter dan maanden. Bij kritische applicaties dient over een kortere periode gerapporteerd te worden. Afhankelijk van het type applicatie mogelijk ook nog naar tijdsperiode per dag: kantooruren, piek- en daltijden, enzovoort. Verder is het nuttig om vast te leggen dat ad hoc meer gedetailleerde informatie over het prestatieniveau kan worden gevraagd, om het gedrag van bepaalde onderdelen van de informatievoorziening onder de loep te kunnen nemen.

4.2 Rapportage over het gebruik

Ook de statistieken over het feitelijk gebruik van de geautomatiseerde informatievoorziening worden geproduceerd door de leverancier, als context voor en in samenhang met de rapportage over het prestatieniveau.

4.3 Rapportage over de kwaliteit van het onderhoud

Wanneer het spoedonderhoud wordt gecoördineerd door een helpdesk, kan deze helpdesk ook de rapportage over de uitvoering verzorgen. Deze rapportage zal statistisch van aard zijn, en bijvoorbeeld vermelden hoeveel urgente problemen binnen een uur werden opgelost, hoeveel binnen twee uur, enzovoort.

4.4 Acceptatierapport van de leverancier over de applicatie

Wanneer de leverancier de applicaties van de systeemontwikkel- en onderhoudsorganisatie telkens test voordat ze (opnieuw) in productie worden genomen, ligt het voor de hand om ook acceptatietestrapporten op te stellen, waarin de testresultaten worden vergeleken met de acceptatiecriteria.

4.5 Rapportage over de bijdragen van derden

Afhankelijk van welke bijdragen van derden betrokken worden in het Service Level Agreement, kan men hiervoor diverse rapportagevormen afspreken.

5. Conclusie

Resumerend kunnen we dus stellen dat een goede SLA een juiste vastlegging van alle technische en organisatorische afspraken bevat, die direct gekoppeld zijn aan het afgenomen dienstenpakket.
Hierbij dient nog vermeld te worden dat de financiële vergoeding veelal gekoppeld is aan het realiseren van het afgesproken dienstenniveau. Hierbij kan de hoogte van de financiële vergoeding gekoppeld worden aan de beschikbaarheid van een software applicatie. Anderzijds is het mogelijk om te werken met boetes indien het overeengekomen dienstenniveau niet gerealiseerd wordt.
Indien u nog weinig ervaring hebt met het opstellen van Service Level Agreements, kunt u zich uiteraard laten begeleiden door een externe partij. Deze partij dient te beschikken over  checklists en ervaring om dit proces snel uit te voeren, waardoor u per saldo geld bespaart.

Download:         

Gerelateerde artikelen:

1. Checklist Service Level Agreement SLA
2. ICT-service management: contact is belangrijker dan contract
3. Besparingen door gebruik van professionele Service Level Agreements

1. Inleiding
2. Waarom externe SLA ’s niet werken
3. Gewenste besparingen
4. Groei gebruikersorganisatie
5. Conclusie

1. Inleiding

Het Financieele Dagblad meldde het onlangs: “De helft van alle outsourcingprojecten mislukt”. Marktonderzoeker Gartner concludeerde dit op basis van een onderzoek over ICT-outsourcing. Binnen de automatiseringswereld is dit natuurlijk geen verrassing.
Vele grote ICT-aanbieders en gebruikersorganisaties hebben inmiddels al verscheidene jaren ervaring met outsourcing. In veel gevallen echter werkt men in Nederland en Oost-Europa of Azië zo dicht mogelijk langs elkaar heen. Maar ook in de Nederlandse klant-leverancier relaties gaat er veel mis. De crux is het managen van de SLA-contracten. Langzamerhand dringt het besef door dat Service Level Management een specialisme is.
Het probleem en de kosten van het SLA zitten namelijk niet in het opstellen van het SLA, maar in de naleving ervan. Vaak zijn in een SLA overbodige bepalingen opgenomen en worden juist de bepalingen die er toe doen, vergeten. Door een SLA op maat te maken en overbodige delen weg te laten, kunnen vaak tientallen procenten op de kosten worden bespaard.

2. Waarom externe SLA ’s niet werken

Er zij legio redenen waarom SLA ’s niet werken. De voornaamste valkuilen voor zowel de dienstaanbieder als de gebruikersorganisatie laten we in de volgende paragrafen de revue passeren:

2.1 Hoofdredenen

Als voornaamste redenen voor het mislukken worden aangevoerd:

Een SLA bevat vaak talrijke voorwaarden die alleen maar geld kosten en in de betreffende situatie niets opleveren.
De dienstenleveranciers leveren niet wat afgesproken is.
Er vindt geen regelmatig overleg plaats tussen leverancier en afnemer.
Er is onvoldoende flexibiliteit binnen de vigerende contracten om tussentijdse veranderingen door te voeren.
De feitelijke toedracht van mislukken ligt echter veelal dieper. Communicatie is cruciaal en dat is nu juist vaak de missing link. (Zie ook ‘ICT-service management: contact is belangrijker dan contract’.) Wat gaat er in de praktijk nu echt mis?

2.2 Niet nakomen van afspraken

Het niet nakomen van afspraken kan meerdere oorzaken hebben. Het kan natuurlijk een kwestie zijn van dat de leverancier simpelweg in gebreke blijft. Meestal echter is het niet leveren van een dienst van tijdelijke aard en wordt de dienst later alsnog geleverd. In de praktijk blijkt dat diensten die niet geleverd worden, simpelweg niet geleverd kunnen worden. De opgestelde overeenkomst is dan dermate krom en dubbelzinnig opgesteld, dat nakoming door de dienstaanbieder onmogelijk is. De onderstaande casus is hiervan een voorbeeld.

Casus
Een ICT-aanbieder wilde zijn diensten aanbieden conform de trends op het gebied van Service Level Agreements. Het betrof systeembeheerdiensten die remote (andere geografische locatie) uitgevoerd moesten worden. Door de aanbieder werd een beschikbaarheidgarantie afgegeven van 98% van de systeembeheerdiensten. In de praktijk kon dit echter niet worden nagekomen. De reden was dat de ICT-aanbieder wel meerdere medewerkers ter beschikking had, maar dat de medewerker die over alle kennis van het netwerk van de opdrachtgever beschikte, veelal niet bereikbaar bleek bij cruciale systeembeheervraagstukken. Uiteindelijk werd er voor gekozen om de SLA om te zetten naar een gewone helpdeskovereenkomst, zodat er geen sprake meer was van een SLA.
Het concreet meten van de beschikbaarheid was hier een belangrijk probleem.

2.3 Te weinig overleg

Regelmatig overleg tussen leverancier en afnemer lijkt eenvoudig te realiseren. In de praktijk blijkt dit echter vaak een grote bottleneck te zijn. Dit komt meestal doordat er bij de dienstaanbieder te weinig aandacht is voor een adequate bewaking van het overeengekomen dienstniveau. Wanneer deze bewaking wel doorgevoerd zou worden, kan de dienstaanbieder eerder constateren dat er zaken misgaan. Een adequate bewaking leidt automatisch tot regelmatig overleg. En waarom trouwens niet regelmatig gewoon eens geduldig luisteren naar de gebruiker? (Zie ‘Support samenwerking gebruikers en ICT-afdeling’.) Voor veel ICT’ers is dit vloeken in de kerk, maar de klant is uiteindelijk de klant en daar eet de ICT’er wel van. (Zie ook ‘Begrafenis ITIL is begin van herstel ICT-imago’.)

2.4 Onvoldoende flexibiliteit

De meeste SLA-overeenkomsten laten geen tot weinig ruimte om tussentijds veranderingen door te voeren. Veel contracten zijn erg rigide opgesteld, zodat niet geanticipeerd kan worden op wijzigende omstandigheden. In veel gevallen echter is dit wel gewenst. ICT-diensten zijn vaak afhankelijk van wisselende ICT-configuraties, waardoor het dienstniveau en de af te nemen soort dienst sterk fluctueren.

2.5 Slechte communicatie

De communicatie tussen ICT-aanbieder en afnemer moet goed worden gereguleerd. Dat geeft outsourcingprojecten een betere kans van slagen. Om goed te kunnen communiceren zullen ICT-aanbieder en -afnemer over hetzelfde kennisniveau moeten beschikken. De eerste communicatieproblemen zullen zich anders snel aandienen. Aangezien het kennisniveau op ICT-gebied bij ICT-aanbieder en -afnemer veelal niet gelijk is, is het wenselijk een professional in te schakelen, die verantwoordelijk is voor de communicatie met de ICT-aanbieder. Dan pas zal er sprake zijn van evenwichtige contractvorming.(Zie ook ‘Blauwdruk processen IT-organisatie’.)

2.6 Slechte afstemming op de bedrijfsprocessen

In veel gevallen is de ICT-aanbieder nog altijd in zekere mate ‘leidend’ bij de totstandkoming van SLA’s. “Wij weten wat goed is voor de klant. Wij zetten dat allemaal op papier en de klant heeft dat maar te accepteren”. De ICT-aanbieder heeft in veel gevallen echter onvoldoende inzicht in de bedrijfsprocessen van de gebruikersorganisatie. Aangezien ICT-middelen dienen als ondersteuning van deze bedrijfsprocessen, is het essentieel dat de ICT-diensten worden afgestemd op de bedrijfsprocessen. (Zie ook ‘Organisatie en inrichting functioneel applicatiebeheer’.)

2.7 Onvoldoende juridisch kennis

Juridisch gezien beweegt outsourcing zich op het snijvlak van ondernemings- en ICT-recht, twee werelden die hun eigen specialisten kennen en hun eigen invalshoeken hebben. Uitbesteden is meer dan een transactie waarbij de ICT-activiteiten worden overgedragen aan de dienstaanbieder. Het is een combinatie van de overdracht van ICT-activiteiten en een dienstverleningsovereenkomst. Om deze redenen is ICT-kennis naast juridische kennis noodzakelijk voor het opstellen van goede overeenkomsten.

3. Gewenste besparingen

De gebruikersorganisatie is in feite maar in twee dingen geïnteresseerd:

De overeengekomen diensten moeten worden geleverd, en wel tegen de afgesproken tarieven.
De geleverde diensten dienen een minimum aan verstoring van de bedrijfsprocessen op te leveren.
Door dit via outsourcing te realiseren, hoopt men bepaalde voordelen te behalen. Maar lukt dit in de praktijk ook?

3.1 Kostenbesparingen

Een gebruikersorganisatie denkt via outsourcing vaak kostenbesparingen te realiseren. Meestal is men echter onvoldoende voorbereid op de valkuilen die zich bij outsourcing voordoen. De misfit van de dienstverlening met de bedrijfsprocessen levert dikwijls teleurstellingen op en leidt juist vaak tot forse kostenverhogingen.

3.2 Focussen op core-business

De gebruikersorganisatie wil zich uitsluitend bezig hoeven houden met haar core-business taken, omdat op die wijze het beste rendement behaald kan worden. Ook hier speelt weer een rol dat de fit tussen de diensten en de bedrijfsprocessen vaak ver te zoeken is. Wanneer de fit wel goed is, zal de beschikbaarheid ook afdoende kunnen worden gewaarborgd, zodat de core-business taken steeds uitgevoerd kunnen worden.

3.3 Flexibele inzet van personeel

In veel van de outsourcingprojecten wordt daadwerkelijk flexibiliteit ten aanzien van de inzet van personeel gerealiseerd. Zo dragen grote gebruikersorganisaties vaak hun complete ICT-afdeling over aan een gespecialiseerde onderneming. Vervolgens wordt er door de gebruikersorganisatie op basis van behoefte diensten afgenomen tegen een vaste prijs en een bepaald kwaliteitsniveau, met een bepaald beschikbaarheidniveau.

3.4 Verhogen van de kwaliteit

Het verhogen van de kwaliteit ten opzichte van de klassieke situatie is ook vaak een reden om voor outsourcing te kiezen. De praktijk leert echter dat kwaliteit een moeilijk te definiëren en te meten begrip is. Verschil in interpretatie leidt veelal tot strubbelingen tussen dienstaanbieder en gebruikersorganisatie.

4. Groei gebruikersorganisatie

Belangrijk bij het opstellen van een SLA is ook dat rekening wordt gehouden met groei van de gebruikersorganisatie. De algemene tendens is dat organisaties groeien. De dienstaanbieder zal met de gebruikersorganisatie mee moeten groeien. Is de dienstaanbieder hiertoe niet in staat, dan heeft dit gevolgen voor de dienstverlening. De gebruikersorganisatie zal meer kosten moeten maken om de dienstaanbieder te controleren en bij te sturen. Als de dienstleverancier voor een langere periode onvoldoende capaciteit heeft, zal het preventieve karakter van de SLA omslaan naar een troubleshooter karakter.

5. Conclusie

Het realiseren van besparingen via outsourcing blijkt veelal slechts mogelijk te zijn door inschakeling van professionals die zich dagelijks bezighouden met het opzetten en beheren van SLA’s. Zodra niet terzake deskundigen zich met het opzetten van SLA’s gaan bezighouden, is de kans groot dat gewenste besparingen omslaan naar ongewenste extra uitgaven. (Zie ook ‘Service Level Management en Service Management functioneel beheer’.)
Het opstellen van SLA’s op maat vergt enerzijds inzicht in de eisen van de business en de gebruikers en anderzijds inzicht in de voorwaarden die in SLA’s dienen te worden opgenomen. Alleen de naleving van een met dit inzicht opgesteld SLA is kostenefficiënt, zonder dat dit ten koste gaat van de garanties en de diensten voor afnemers. Het simpelweg overnemen van een checklist (zie ‘Checklist Service Level Agreement SLA’) genereert zeker extra kosten en ontevreden klanten. Het is altijd een kwestie van een mix tussen reeds uitgevonden wielen en maatwerk voor de klant.

Download:         

Gerelateerde artikelen:

1. Wat is een Service Level Agreement
2. Checklist Service Level Agreement SLA
3. Assessment ICT Service Level Management

1. Aandachtspunten Service Level Agreement
2. Inhoud SLA
3. Slotopmerking

1. Aandachtspunten Service Level Agreement

Waarschuwing:
Deze checklist Service Level Agreement is een globale lijst van aandachtspunten die relevant zijn voor het opstellen van een SLA. Er wordt weinig in detail getreden, omdat het toesnijden op iedere individuele praktijksituatie ondoenlijk is. Er kan niet ingegaan worden op de afbreukrisico’s die gelopen worden in uw specifieke situatie. Door SLA’s moeten juist deze risico’s geminimaliseerd worden en vervolgens dienen de allocatie en maatregelen vast gelegd te worden. Deze problematiek is in het geheel niet af te vangen met deze standaardchecklist. Afhankelijk van de situatie waarvoor een SLA opgesteld dient te worden is er meer of minder maatwerk nodig.

2. Inhoud SLA

In dit hoofdstuk zijn de artikelen opgenomen die van belang zijn bij het opstellen van een Service Level Agreement. Aangezien het opstellen van contracten altijd een stukje maatwerk is, kan deze checklist uitsluitend als basis dienen.

2.1 Identificatie van partijen

Beschrijving van de partijen die betrokken zijn bij de overeenkomst.
namen (eventueel aangevuld met afkortingen, die in de SLA gebruikt worden);
locaties (adressen, in geval van een groot aantal, deze opnemen in de bijlage);
overeenkomstnummer (met versienummer).

2.2 Uitgangspunten

2.2.1 Definities en afkortingen

Lijst met sluitende en duidelijk gedefinieerde begrippen, afkortingen, formules en meetvoorschriften, die misverstanden helpen voorkomen.

• overzicht van in de SLA gebruikte definities;
• overzicht van in de SLA gebruikte afkortingen (geen afkortingen van de namen van de deelnemende partijen);
• overzicht van in de SLA gebruikte (algemene) formules en meetvoorschriften;
• overzicht van in de SLA gebruikte (algemene) tijdstippen van aanvang en beëindiging aan de hand van meetbare parameters.

2.2.2 Inleiding en uitgangspunten

Plaatsing van inleidende opmerkingen (bijvoorbeeld dat een SLA is opgesteld ter verbetering van de kwaliteit van de dienst) en uitgangspunten (bijvoorbeeld het feit dat personen gerechtigd moeten zijn om de dienst te gebruiken of het niet beschikbaar stellen van diensten aan derden).

• inleidende opmerkingen met betrekking tot de doelstellingen en de inhoud;
• uitgangspunten met betrekking tot het beschikbaar stellen van de dienst.

2.2.3 Onderwerp van overeenkomst

Aangeven op welke dienst (of diensten) de SLA betrekking heeft.

• korte beschrijving van de diensten waar de SLA betrekking op heeft (in relatief grote SLA’s) middels een zinsnede als “Het verzorgen van ……”;
• afsluiting van deze clausule met “Het beheren, onderhouden en in standhouden van de hierboven genoemde voorzieningen tegen de in de bijbehorende detailovereenkomsten genoemde prestatiecriteria”.

2.3 Randvoorwaarden

2.3.1 Aard en omvang van de overeenkomst

Beschrijving van de onderdelen waar de dienst betrekking op heeft, zoals de organisaties (en/of bepaalde afdelingen) die de dienst afnemen, de juridische status van de overeenkomst en een verwijzing naar algemeen geldende voorwaarden.

• omvang (geldigheid van de SLA voor delen van de cliëntorganisatie);
• juridische status en versie van de SLA;
• algemene voorwaarden;
• overige opmerkingen met betrekking tot de aard en de omvang van de overeenkomst.

2.3.2 Beschrijving van de dienst

Verwijzing per geleverde dienst naar de betreffende service level specificaties, die opgenomen zijn in de verschillende detailovereenkomsten of bijlagen.

• concrete beschrijving van diensten (verwijzing naar service level specificaties uitgewerkt per dienst);
• servicetijden (normale servicetijden, weekends, feestdagen en vakantiedagen);
• service beschikbaarheid (minimumpercentages, gemiddelde, maximaal aantal verstoringen per periode, meetperiode);
• serviceprestaties.

2.3.3 Afbakening

Expliciete beschrijving van de grenzen van de dienstverlening, zowel met betrekking tot de te leveren diensten zelf, als ook tot de hiervoor benodigde middelen.

• afbakenen van de dienst;
• afbakenen van de automatiseringsmiddelen.

2.4 Duur en beëindiging van de overeenkomst

Bepaling waarin wordt aangegeven voor welke periode de SLA geldt en hoe de standaardprocedure voor verlenging of beëindiging van de SLA luidt.

• duur van de overeenkomst (begin- en einddatum);
• procedure voor verlenging en beëindiging;
• bijzondere omstandigheden (eventueel met directe beëindiging als gevolg).

2.5 Overlegstructuren, contactpersonen en correspondentie

Vastleggen wanneer gestructureerd overleg plaatsvindt, wie er aan dit overleg zullen deelnemen en wie bij beide partijen verantwoordelijk is voor de onderlinge relatie. Tevens zal een overzicht opgenomen worden van alle contactpersonen en verantwoordelijken bij escalatie of calamiteiten.

• tijdstippen of aanleidingen voor overleg;
• betrokken personen bij overleg;
• verantwoordelijke personen voor de onderlinge relatie;
• overzicht van contactpersonen en verantwoordelijken (inclusief telefoonnummers) bij escalatie en/of calamiteiten (meestal een verwijzing naar de betreffende bijlage);
• overzicht van post- en bezoekadressen van betrokken organisaties en locaties (meestal een verwijzing naar de betreffende bijlage);
• standaardformulieren voor onderlinge correspondentie (meestal een verwijzing naar de betreffende bijlage).

2.6 Eigendom en risico

Bepaling van de eigenaar van de apparatuur en programmatuur die nodig is voor het leveren van de dienst, eventueel uitgebreid met een beschrijving van de verantwoordelijk persoon voor achteruitgang of tenietgaan van deze middelen.

• eigenaar van benodigde apparatuur en programmatuur;
• noemen van organisatie bij wie het risico van tenietgaan of achteruitgang van apparatuur en/of programmatuur ligt;
• opmerkingen over achteruitgang als gevolg van opzet of bewuste onzorgvuldigheid.

2.7 Beveiliging

Beveiliging van systemen, services en data zijn belangrijke aspecten. Deze onderdelen dienen dan ook beschermd te worden tegen interne en externe aanvallen.

• procedure van beveiliging van systemen, services, data;
• maatregelen bij het schenden van beveiligingsprocedures;
• aanspreekpunt bij beveiligingsincidenten.

2.8 Rapportage

Als opdrachtgever dient u zicht te hebben, te krijgen en te houden op alles wat te maken heeft met het informatiesysteem. Omtrent de rapportage moeten afspraken gemaakt worden betreffende:

• inhoud van de rapportage;
• verschijningsfrequentie;
• distributie (functionarissen, afdelingen, etc.).

2.9 Aanpassingen van de SLA

2.9.1 Wijziging van de dienst

Schetsen van mogelijkheden voor het wijzigen van de dienst (zowel door de leverancier als door de afnemer) indien dit noodzakelijk of wenselijk wordt geacht. Tevens wordt beschreven hoe en wanneer wijzigingsverzoeken ingediend kunnen worden en in welke mate het wijzigen van de dienst een herziening van de SLA noodzakelijk maakt. Vast te leggen items zijn:

• wijzigingsprocedure inclusief het noemen van het meldpunt (meestal de helpdesk) en aanmeldingsperiode voor wijzigingen;
• wijze van overleg over wijzigingsverzoeken;
• impact van wijziging op de SLA (eventueel een opmerking in de trant van “wijziging van de dienst, zoals installatie van nieuwe hard- en/of software, maakt herziening van de SLA in beginsel noodzakelijk”).

2.9.2 Herziening van de SLA

Beschrijving van de procedure voor het wijzigen van de SLA en de regeling met betrekking tot de looptijd van de SLA. Bij omvangrijke SLA’s loont het tevens de moeite om te beschrijven, wanneer vorige wijzigingen aan de SLA uitgevoerd zijn en wat er destijds gewijzigd is aan de SLA, zodat op eenvoudige wijze terug te zoeken is welke versies de SLA heeft gekend. Vast te leggen items zijn:

• opsomming van zaken die leiden tot een wijziging van de SLA;
• wijzigingsprocedure (wijze, tijdstip, overleg);
• verlenging van de looptijd van de SLA, bijvoorbeeld stilzwijgend, door middel van berichtgeving of na onderling overleg;
• vorige wijzigingen en versies van de SLA, inclusief de data waarop de verschillende versies in gebruik waren.

2.10 Financiële vergoeding

2.10.1 Prijzen

De hoogte van de vergoeding die betaald moet worden dient te worden vastgelegd, inclusief grenzen aan stijgingen. Hierdoor krijgt de opdrachtgever zekerheid met betrekking tot de jaarlijkse kosten. Vast te leggen items zijn:

• opdrachtgever zal een vergoeding van €  ……. per …….. voldoen in ……….. termijnen van € ….;
• prijzen in valuta .. , inclusief of exclusief BTW;
• prijsstijgingen gemaximaliseerd tot ..% per ….. of maximale prijsstijgingen conform consumenten prijsindex cijfer van CBS.

2.10.2 Betaling

Afspraken aangaande betaling van overeengekomen vergoedingen dienen te worden vastgelegd om onduidelijkheden en/of problemen hieromtrent te voorkomen. Vast te leggen items:

• betalingstermijn .. dagen na facturering;
• op welk bank-/girorekeningnummer betaald dient te worden;
• welke regels gelden er bij te late betaling;
• wat te doen indien opdrachtgever niet akkoord gaat met de factuur.

2.11 Verantwoordelijkheid, escalatie en reclame

2.11.1 Verantwoordelijkheid, aansprakelijkheid en strafbepalingen

Vermelding van zowel de aansprakelijkheid voor de bij de cliëntorganisatie opgestelde apparatuur en/of programmatuur als van de aansprakelijkheid van de leveranciersorganisatie voor het functioneren van de cliëntorganisatie.

• aansprakelijkheid van leveranciersorganisatie voor functioneren van cliëntorganisatie, bijvoorbeeld in geval van storingen of calamiteiten;
• gevolgen van het niet (volledig) nakomen van afspraken;
• verhalen van schade als gevolg van een onvoldoende functionerende dienst;
• beschrijving van overleg in geval van problemen (eventueel het verwijzen naar de clausule over geschillen);
• boeteclausules of andere financiële strafbepalingen.

2.11.2 Beperkingen, afhankelijkheden en overmacht

Vastlegging van beperkingen met betrekking tot het gebruik van de te leveren diensten, de afhankelijkheid van derde organisaties (bijvoorbeeld KPN t.b.v. communicatie) en het schetsen van situaties waarin de organisaties zich kunnen beroepen op overmacht.

• maximaal aantal gelijktijdige gebruikers van de verschillende diensten;
• maximaal aantal toegelaten gebruikers (maximaal aantal “accounts”) van de verschillende diensten;
• afhankelijkheid van andere organisaties of diensten;
• regeling met betrekking tot het beroepen op overmacht, inclusief de mogelijkheid tot het buiten werking stellen van de SLA en de te ondernemen acties om zo spoedig mogelijk terug te kunnen keren naar de normale situatie;
• algemene calamiteitenprocedure, inclusief een verwijzing naar de verschillende calamiteitenplannen;
• overige beperkingen (bijvoorbeeld het maximaal aantal transacties per periode).

2.11.3 Geheimhouding, verantwoordelijkheid en concurrentiebeding

Afspraken met betrekking tot het niet openbaar maken of aan derden beschikbaar stellen van vernomen informatie tijdens het opstellen van de SLA (inhoudelijke SLA-bepalingen) of het functioneren van de dienst (informatie verkregen door database-opvragingen dient als vertrouwelijk te worden aangemerkt). Tevens kunnen bepalingen worden opgenomen voor bescherming tegen het overnemen van personeel (concurrentiebeding) of het rechtstreeks onderhandelen van de cliëntorganisatie (buiten de leverancier om) met derden over de levering van (delen van) diensten.

• afspraken met betrekking tot geheime of vertrouwelijke informatie;
• concurrentiebeding, bijvoorbeeld aangaande het overnemen van personeel.

2.11.4 Geschillen

Beschrijving van het feit wanneer onderling overleg plaatsvindt en wat de procedure is bij het optreden van onderlinge conflicten of geschillen qua afhandeling en het betrekken van derde partijen.

• procedure;
• onafhankelijke derde instantie of persoon;
• feit of een uitspraak van een onafhankelijke arbiter bindend is of niet.

2.12 Slotbepaling en handtekeningen

Formele afsluiting van de SLA, waarin gesteld wordt dat de betrokken partijen “het bovenstaande” overeengekomen zijn ondertekend door verantwoordelijke personen uit beide organisaties.

• formele afsluiting;
• namen en handtekeningen van tekengerechtigde personen.

3. Slotopmerking

In de inleiding van dit artikel is reeds aangegeven dat een Service Level Agreement (net zoals de meeste andere contracten) een maatwerk contract is. Het kan zijn dat in uw situatie sommige artikelen niet van belang zijn, maar dat andere artikelen juist toegevoegd dienen te worden. U dient dus deze checklist niet zonder meer over te nemen. In het artikel ‘Wat is een Service Level Agreement?’ kunt u meer lezen over begrippen als beschikbaarheid, betrouwbaarheid, responsetijd en continuïteit. Hoe u door het opstellen van een goede SLA en het managen van de naleving ervan besparingen kunt realiseren, leest u in het artikel ‘Besparingen door gebruik van professionele Service Level Agreements’.

Download:         

Gerelateerde artikelen:

1. Wat is een Service Level Agreement
2. Besparingen door gebruik van professionele Service Level Agreements
3. Assessment ICT Service Level Management

1. Samenwerking gebruikers en ICT
2. Beter samenwerken
3. Support om samenwerking te realiseren

1. Samenwerking gebruikers en ICT

Samenwerking tussen gebruikers en de ICT-afdeling verloopt vaak moeizaam. Oorzaken hiervoor zijn:

• slechte of ontbrekende SLA’s;
• slechte of onvolledige afspraken;
• eenzijdige afspraken waardoor gelijkwaardigheid wordt verstoord;
• ontbreken van duidelijkheid in de verdeling van verantwoordelijkheden en taken;
• onvoldoende kennis van elkaars behoeften.

Meestal is een conflict de aanleiding om deze zaken weer aan de orde te stellen. Vaak zien we dan een  machtsspel ontstaan in plaats van een constructieve poging om het conflict op te lossen. Dit wordt veroorzaakt doordat veel ICT-afdelingen nogal eenzijdige ITIL gebruiken om hun processen te stroomlijnen (zie ‘ITIL: professionalisering of indekken?’) en er nauwelijks beschrijvingen zijn voor het functioneel beheer: doordat de ICT-afdeling haar processen wel op orde heeft is het enerzijds gemakkelijk voor haar om een muur op te werpen voor gebruikers, en dat  is natuurlijk voor de gebruikers zeer frustrerend,  maar anderzijds wordt de ICT-afdeling ook gestoord van gebruikers die zich niet georganiseerd hebben en vanuit hun persoonlijk perspectief steeds eisen stellen aan de ICT-afdeling. (Zie ‘Organisatie en inrichting functioneel applicatiebeheer’.)

Uitgangspunt voor een effectieve samenwerking moet zij dat  beide partijen beter worden van de samenwerking. Daarvoor zijn evenwichtige afspraken nodig met heldere verantwoordelijkheden en een zodanig slimme taakverdeling, dat het geheel kosteneffectief kan plaatsvinden, (zie ‘Blauwdruk processen IT-organisatie’) waarbij de contacten en overdrachtsmomenten tussen gebruikers en de ICT-afdeling centraal staan.

2. Beter samenwerken

Het is een bekend verschijnsel dat veel ICT-afdelingen initiatieven nemen om hun dienstverlening te verbeteren, met ITIL als uitgangspunt. Helaas beschrijft ITIL alleen de processen van de ICT-afdeling en samenwerken doe je niet alleen. (Zie ‘Begrafenis ITIL is begin van herstel ICT-imago’.) Dit betekent niet dat ITIL onbruikbaar is, maar wel dat de eerste stap is, het maken van afspraken over de verdeling van verantwoordelijkheden en over de verdeling van taken. Essentieel is dat dit in twee  stappen gebeurt, want ondanks het feit dat gebruikers mogelijk verantwoordelijk zijn voor een proces, is het gebruikelijk dat de uitvoering van dit proces wordt gedaan door de ICT-afdeling. Vaak is dit met het oog op de benodigde expertise ook inderdaad een handige constructie, maar dat laat natuurlijk onverlet dat de verantwoordelijkheid bij de gebruikers ligt en dat de ICT-afdeling budget moet krijgen voor deze uitvoerende taken. Dit geldt met name voor Service Level management en Wijzigingsbeheer.
Helaas positioneert ITIL ieder proces maar op één niveau (strategisch, tactisch of operationeel) en beschrijft ITIL in feite alleen procedures op basis van de uitvoering van het proces. Omdat ITIL ook geen implementatiemodel bevat, werkt dit een eenzijdige implementatie in de hand, waardoor de samenwerking met gebruikers eerder wordt verstoord dan wordt verbeterd. (Zie ook ‘Inrichtingsmodel IT-beheer’.)

3. Support om samenwerking te realiseren

Natuurlijk zit u niet te wachten op een adviseur, die voor u opnieuw het wiel gaat uitvinden. Het gaat u om het oplossen van de knelpunten en het leveren van input, zodat uw interne proces wordt versneld. (Zie ‘Wat mogen bedrijven tegenwoordig van hun adviseurs verwachten?’.)

ZBC is een adviesbureau, dat primair business consultancy levert en dus ook dit soort trajecten benadert vanuit de business. Daarnaast heeft zij een brede ervaring met het implementeren van ITIL, functioneel beheer, informatiebeveiliging en methoden en technieken voor projectmanagement, projectmatig werken en systeemontwikkeling.
ZBC is dan ook in staat om enerzijds het proces van samenwerking te begeleiden en anderzijds om de benodigde input te leveren op dit gebied, zoals u zelf kunt constateren door te klikken op genoemde onderwerpen, waarin u een aantal voorbeelden vindt van input, die wij u kunnen leveren om deze aan te passen aan uw bedrijfssituatie.
Uiteraard kunnen wij dit proces zelfs deels voor u uitvoeren, reviews doen op uw producten, ondersteunende workshops geven of optreden als coach voor u en voor een aantal van uw medewerkers.
Vanzelfsprekend is dan de basis een nul-urencontract, zodat wij niet meer doen dan dat waar u daadwerkelijk behoefte aan heeft. Binnen dat contract kunnen deelopdrachten opgenomen worden, die op fixed-price basis worden uitgevoerd.

Wilt u nader met ons en onze ideeën kennismaken, dan nodigen we u graag uit voor het volgende webseminar over dit onderwerp. U kunt zich hiervoor opgeven via het reactieformulier. Ook kunt u via het reactieformulier uw vragen stellen. Bellen naar 0318 641 898 kan natuurlijk ook.

Download:         

Gerelateerde artikelen:

1. Samenwerking tussen gebruikers en de ICT-afdeling door functioneel beheer
2. ITIL: professionalisering of indekken
3. Inrichtingsmodel IT-beheer