Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Rondrennende mannetjes en SLA

 

Computable Expert

Gijs in ‘t Veld
CTO bij Motion10, Motion10. Expert van Computable voor de topics Digital Transformation, Cloud Computing en Infrastructuur.

In een requirements workshop vandaag bij een organisatie in de financiële dienstverlening was één van de onderwerpen dat management het fijn vindt om bij incidenten rondrennende mannetjes te zien die druk bezig zijn om een it-probleem op te lossen. Het kantoor had ook opmerkelijk veel glazen wanden.

Het zien van deze mannetjes geeft het geruststellende idee dat er aan het probleem gewerkt wordt en dat er waarschijnlijk snel een oplossing zal komen. Net als dat er bij de betere koffiemachines altijd bonen te zien zijn (dat moet wel goede koffie zijn) en bi-dashboards vaak kleurrijke en bewegende meters bevatten, vertrouwen mensen veelal op visuele informatie. Op het zelfde kantoor hing op de afdeling it-operations ook een aantal grote flatscreens met daarop allerlei statusinformatie in groene, oranje en rode balken en taartpunten.

Ik vermoed dat het niet door de it’ers op de afdeling zelf gebruikt wordt (die krijgen hopelijk pro-actieve alerts), maar eerder daar is voor de managers ‘by walking around’ en voor de incidentele rondleiding van zakenpartners of klanten, om indruk te maken en om de indruk te wekken dat alles onder controle is. Maar het fijne voor management is wel dat ze te allen tijde inzicht kunnen hebben in de status van de it-operatie. Incidenten kunnen ook door hier en daar wat (mondelinge) instructies te geven van prioriteit veranderd worden indien nodig. Men heeft het gevoel volledig 'n control' te zijn. Want men is er bij.

Net als bovengenoemde organisatie, worstelen vele organisaties mede  hierdoor met het volledig uitbesteden van bepaalde delen van de it-infrastructuur en applicaties. Bij het uitbesteden naar een hosting provider waar je een directe relatie mee hebt, zijn de lijntjes nog steeds kort en direct. Vaak lopen de mannetjes van de derde partij zelfs gewoon op de eigen werkvloer rond en kun je ze dus nog steeds zien. En beïnvloeden.

Voor private cloud geldt het zelfde. Echter, bij het uitbesteden van infrastructuur en applicaties naar een publieke cloud neemt het abstractheidsniveau enorm toe. De mannetjes rennen ergens rond waar je ze niet kan zien. Rennen ze wel rond? Of lopen ze op hun sloffen? Is jouw probleem wel belangrijk genoeg of krijgt een andere tenant meer aandacht? Wordt het probleem wel zo snel mogelijk opgelost?

Door middel van een service level agreement (sla) kan een hoop onzekerheid en frustratie weggenomen worden. Het besef dat incidenten binnen een bepaalde tijd worden opgelost, afhankelijk van de categorie, geeft wat geruststelling. Rapportage van incidentstatus en voortgang door middel van een dashboard helpt ook. De dashboards zullen ongetwijfeld ook steeds informatiever en meer real-time worden. We zullen echter met z’n allen moeten wennen aan het idee van 'loslaten'.

Het niet meer in directe 'control' zijn zal niet voor iedereen even gemakkelijk los te laten zijn. Het devies is: Vertrouwen op sla en de cloudleverancier er mee om de oren slaan als het niet nagekomen wordt. En misschien helpt het als er in de 'control rooms' van de cloud datacenters videocamera's worden opgehangen en dat je via augmented reality kan zien of het betreffende rondrennende mannetje met jouw ticket bezig is...

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4801163). © Jaarbeurs IT Media.

?


Lees meer over


Partnerinformatie
 

Reacties

Bij mijn weten gaan alleen konijnen en schildpadden harder lopen als ze SLA zien ....


Een afspraak op papier tussen een manager die enkele lagen hoger in de organisatie zit en een klant doen de gemiddelde IT-er echt niet harder lopen.
Kwaliteitsbesef, kennis, motivatie en gedrevenheid van mensen (wat nodig is om problemen snel en adequaat opgelost te krijgen) kun je niet sturen door een contract op hoger niveau.

Op een dag komt Piet de systeembeheerder binnen op het werk met een tas. Hij loopt naar zijn kantoor en haalt daar uit zijn tas een lang dik touw. Vervolgens begint hij met een grote lus in het touw te knopen en terwijl hij er de laatste hand aan legt komt zijn manager binnen en vraagt hem wat hij aan het doen is. Hij antwoord daarop:
Dan kunnen jullie zien wanneer het fout gaat.

Gijs,

Herkenbare 'window dressing' omdat sommige managers inderdaad helemaal niets van AUTOMATISERING hebben begrepen. Misschien dat we vroeger nog met ponskaarten moesten rondrennen maar tegenwoordig lossen we 99,99% van de incidenten remote op.. Meeste datarooms zijn ook een 'dark room' waar genoemde camera alleen hangt om de zeldzame fysieke toegang te controleren. Maar goed loslaten en SLA's zijn dan ook een contradictio in terminis, de vierkante cirkel van een verbo(r)gen realiteit.

Zeg maar een tegenstelling in termen waardoor de eenduidigheid van SLA's al te betwisten valt en kijkend naar aantal 'hops' gaat het inderdaad vaak zoals Pa Va Ke zegt. Mijn ervaring is dat incidenten (of problemen) pas opgelost worden als iemand het eigenaarschap ervan NEEMT en niet omdat deze contractueel op zijn/haar bordje GESCHOVEN zijn. Maar goed over de 'paradox of interest in outsourcing' zijn al vele boeken geschreven en komen er steeds weer nieuwe modellen.

Of zoals wij 'vroeger' al in de krijgsmacht uitlegde aan aspirant officieren in opleiding; gezag krijg je niet door het aantal sterren op je schouder, maar door de manier waarop je acteert. Zo geldt dit ook voor SLA's. Een SLA is een prima manier om gemaakte afspraken en verwachtingen van klanten formeel vast te leggen, het vertrouwen komt pas echt indien diezelfde klant ervaart dat de verwachtingen daadwerkelijk zijn waargemaakt. Als je die verwachtingen ook echt wilt waarmaken als leverancier moet je investeren in kennis, kennisoverdracht en voortdurende sturing op houding en gedrag van je IT professionals. Ook de klant moet voldoende energie stoppen in de gemaakte afspraken en bijv. tijdig de juiste informatie aanleveren en bereid zijn eerder gestelde normen aan te passen. Ga als leverancier met een klant om als zou het je privépartner is......dan maakt het niet uit of je een contract heb of niet...

@Pa Va Ke

Natuurlijk wordt de gemiddelde ITer niet warm of koud van service levels. Echter, als het goed is wordt aan de voorkant iets verkocht, wat aan de achterkant afgedicht is (OLA).. Iets waar de achterkant op ingericht en geëquipeerd is. Dat dit bij teveel providers niet (afdoende) afgedicht is, is een ander verhaal. In dit geval bieden service levels slechts schijnveiligheid en een stok om het management mee te slaan bij onvrede, maar dat doet mijns inziens geen afbreuk aan het nut van service levels in een groter plaatje.

Goede toevoeging MaTi. Helemaal mee eens!

Een SLA is slechts een specificatie van de zaken die geleverd worden, maar zonder ingebouwde boeteclausules blijft het een abstract document. SAL's zijn bijzonder nietszeggend in situaties waar bijvoorbeeld :
- sprake is van een keten van outsourcingsbedrijven : bedrijf in Nederland besteedt uit naar IBM, IBM naar IBM India, IBM India naar een regionale partner.
- diensten worden gerealiseerd door meerdere outsourcingspartners, bijvoorbeeld netwerk dat door bedrijf 1 wordt gemanaged en ERP systeem gehost en gemanaged door bedrijven 2 en 3.

Uiteindelijk hangt de kwaliteit niet af van een papiertje maar van de kennis, kunde en gedrevenheid van de mensen die deze services leveren.

@MaTi Als ... als de leverancier naar verwachting levert en presteert en over een goede kwaliteitsdrive beschikt, dan zou die hele SLA niet nodig moeten zijn

Wellicht dat ik de verkeerde ervaringen heb opgedaan, maar de SLA's waar ik mee gewerkt heb (aan voor- en achterkant) worden opgesteld door in- en verkopers.

Voorbeeld uit een grijs verleden: ik werkte in een mainframe omgeving, waar we 24-uurs service leverden. Deze omgeving konden we via ons gewone LAN benaderen. Ik kom om 7 uur op m'n werk, en het pc netwerk blijkt er uit te liggen. Helpdesk niet bereikbaar ... pas vanaf 9 uur; dat was zo afgesproken (en uiteraard vastgelegd in een SLA).

2 verschillende takken van de organisatie zaten hier dus in elkaars vaarwater. De mainframe organisatie belooft 24 uurs service, maar het pc-netwerk om het mainframe te bereiken had geen 24 uurs service (dat was blijkbaar te duur)....

@ Pa Va Ke,

Goed punt. Voor het opstellen van een SLA heb je techies en het management nodig.

En mijn ervaring is dat een adviseur om het 1 en ander in rechte lijnen te leiden geen overbodige luxe is.

Mijn ervaring is dat een SLA niet waardevol is. Want wat gebeurt er? De applicatie is traag. Je schiet een ticket in de inderdaad snel beantwoord word. "Hier is alles snel, wellicht dat het aan je verbinding ligt." Of "Ah, iemand heeft zelf records direct in de database veranderd. Tja, dat valt niet onder de SLA"

Vaak zijn er zoveel lagen, dat het niet duidelijk is waar nu precies de schuld of het probleem ligt. Om de oren slaan zal dus heel lastig worden.

Uiteindelijk gaat het om politieke spelletjes intern en allerlei machtsverhoudingen of je bij een leverancier blijft, of als hij gewoon een goed product levert.

Ik heb liever iemand die met mij meedenkt en kijkt en aandacht geeft als iemand die de regeltjes in een SLA nakijkt of hij wel support mag en kan geven. Ofwel mensenwerk.

@Henri maar als je geen direct invloed hebt, zal toch op 1 of andere manier urgentie moeten worden "afgedwongen": SLA. Of een negatieve bonus. Een trage verbinding kan meestal snel geisoleerd worden. Iets rechtstreeks in een database veranderen... tsja, daar dat zal inderdaad niet onder en SLA vallen. Dus dat is dan je eigen schuld.

Het opstellen van een goede SLA is niet gemakkelijk. En vaak ben je overgeleverd aan de standaard SLA (template) van de leverancier. Hier zal ook je eigen IT beheer/supportafdeling op afgestemd moeten worden. Samenwerking zal opgezocht moeten worden. Want inderdaad, vaak zijn het toch problemen waarvan van te voren niet bekend is of het aan "hun" of aan "onze" kant ligt. Maar bij het meer-en-meer verplaatsen naar de cloud, zal ook het meerendeel van de problemen zich daar gaan bevinden.

Gijs,

Goede toevoeging. Helemaal mee eens. SLA's opstellen is tijdrovend en wordt door velen als lastig en overbodig gezien. Maar je wilt toch geen contract meti iemand aangaan zonder een resultaatsverplichting? De tijd dat je iemand op zij reputatie en zijn of haar mooie blauwe ogen kon vertrouwen ligt al tijden achter ons.

@ Henri,

Natuurlijk willen we dat allemaal. Iemand die mee denkt en altijd helpt als het nodig is. Alleen is het wel erg naief om te roepen dat SLA's niet waardevol zijn. Zeker in de Cloud zijn SLA's essentieel. Een duidelijke roles and responsebilities matrix kan hier uitkomst bieden. Zeer essentieel als je met meerdere partijen samenwerkt. Want een contract tekenen zonder resultaatsverplichting is wel heel blond.

Een risico van alles dicht proberen te timmeren met SLA's is dat je vooral vingerwijzen krijgt; geen van de partijen durft eigenaarschap te nemen van een probleem, waardoor je als klant geen meter verder komt.

Ooit probleem gehad met een combinatie van software van IBM, Microsoft en McAfee. Ze wijzen alle drie naar elkaar in eerst instantie, maar als klant (met premium support, SLA contracten etc) kwamen we geen meter verder.

Dit met probleem in een applicatie (bleek uiteindelijk). Applicatie wees naar netwerk, netwerk wees naar applicatie. Klant bleef in eerste instantie met probleem zitten.

Laatste voorbeeld: we hadden contract met infrastructuur leverancier (binnen Europa). Probleem met netwerk in Oostenrijk. Plaatselijke leverancier had weer afspraken met onderaannemer in een dorpje aldaar, waar net een groot feest aan de gang was. SLA op SLA op SLA, maar die feestende onderaannemer nam simpelweg zijn telefoon niet op. Dan is een SLA heel leuk, maar als klant ben je niet geholpen.

Daarom geloof ik al lang niet meer in SLA's.

Precies wat PaVaKe schrijft. Doordat alles is vastgelegd gaan mensen leven naar de regeltjes van de SLA en niet naar de werkelijke behoefte van de klant. Zoals in een eerder artikel geschetsts werd: Response-time van 2 uur werd gerealiseerd met een automatische e-mail beantwoorder. Volgens de SLA correct, maar niet wat de klant verwachtte.

En wat heb je eraan als je de leverancier om de oren kan slaan met een 1000 euro boete? De sfeer verslechterd en die 1000 euro lost je probleem niet op.

Ik zeg niet dat je geen afspraken moet maken, maar dat kan ook op een A4-tje waarin de geest van de samenwerking / relatie staat.

Ultiem gezien garandeerd een goede SLA geen uptime, dat doet een redundante architectuur.

Henri,

Over welke type omgevingen praat je? MKB of Enterprise? Juist bij Enterprise omgevingen ontkom je niet aan SLA's. En wordt de Cloud ook niet heel erg mistig als je geen SLA's gaat gebruiken? Je neemt iets af van iemand maar zonder resultaatsverplichtingen. Je suggestie om even 2 a4's op te stellen gaat echt niet werken bij de grotere en complexere omgevingen. Dat is iets te kort door de bocht.

Je opmerking dat een goede SLA geen uptime biedt, is op zich wel correct. Je infrastructuur zorgt daar voor. Echter zie je steeds vaker dat een infrastructuur gebouwd en gevormd wordt op basis van de interne SLA's die er al binnen een organisatie gelden. Er zijn natuurlijk 2 type SLA's interne en externe met leveranciers/klanten. En ook daar zit een wezenlijk verschil in.

Ik deel ook je mening dat responsetime weinig verplichtingen biedt. Maar dat weet je toch van te voren? Anders had je wel voor de duurdere variant time to fix gekozen.

SLA's goed opstellen en analyseren is een vak apart. Hier heb je vaak expertise en meerdere disciplines voor nodig. En hier gaat het vaak fout . Er worden nog te vaak SLA's opgesteld die niet aansluiten bij de wensen en eisen. En daar kom je dan vaak pas te laat achter. En als je met meerdere partijen moet samen werken, stel dan samen een rules and responsability matrix op. Leg vast hoe de partijen samen moeten werken en wat de wederzijdse verwachtingen zijn. En neem dit op in een overkoepelende SLA met resultaatsverplichtingen ( lees boetes ) Doe je dat niet dan zijn de scenario's die door PaVaKe en jou geschetst worden het logische gevolg.

Maar nogmaals SLA's zijn essentieel en maken je omgeving meet- en toetsbaar. Maar het is niet de holy graile die alles hoog beschikbaar maakt.

@Gijs Dat is allemaal leuk en aardig de rondrennende mensen alleen daar gaat de computer niet van werken, het is toch zoeken naar die vrouw of man die zwetend achter de computer zit. Met daarachter allerhande zenuwachtige mensen: Werkt het al? Heb je het al gevonden? Hoe lang duurt het nog?

Ik denk ook dat je niet ontkomt aan SLA's, als dat afspraken zijn tussen bedrijven en afdelingen zijn over de geleverde services en wat je van elkaar kan verwachten. Lastig is inderdaad wel zoals @PaVaKe zegt die SLA's met elkaar in conflict zijn en gaan tegenwerken. Als je zo een situatie hebt waarbij acuut iets opgelost dan kom je er niet altijd met ongelukkige oplossings windows. Dan moet het nu en niet later. Ik weet niet hoe dat is met SLA's maar je zou net zoals in die kwiz een aantal escapes moeten hebben zodat je direct ondersteuning kan krijgen. Dat kost wel geld denk ik.

Wat vaak het beste werkt is het informele circuit. Heel handig als je zelf of iemand anders bekend is met de organisatie, mensen kent en weet wie je moet hebben. Dan kan je buiten de reguliere processen en regeltjes om uitstekend zaken doen met je collega's bij andere afdelingen. Dit hoort bij collegiaal ict gedrag en voor wat hoort wat. Leve het ritsel en rommel circuit, de Haarlemmer olie van de ICT.

Wat je tot slot ook nog wel ziet is het overbekende 'escaleren; . Een bellende en schuimbekkende baas die het hogerop zoekt wil ook nog wel eens wonderen doen en gaan de molens draaien. Niet goed voor de werksfeer overigens.

SLA's zijn noodzakelijk en afstemmen van SLA's ook. Daar hebben we met z'n alleen nog een hoop te leren, zowel aan de consumenten als producenten kant.

Daarnaast is het erg belangrijk om een relatie te hebben met de cloudprovider waarbij je echt persoonlijke interactie kunt hebben. Alleen relaties bouw je met mensen 1-op-1 en vaak is de persoon die je helpt een persoon (vaak in India) die niet jouw permanent toegewezen contact persoon (of team) is.

Helemaal mee eens Gijs!

Ook helemaal mee eens Gijs.

En Ruud, uiteraard heb je een SLA nodig en geen SLA hebben krijg je niet verkocht en is niet te verdedigen.

SLA's bij cloud providers stellen vaak niet zoveel voor omdat de compensatie zelden het te besteden bedrag overschrijd. De SLA's zijn ook erg generiek en leverancier gericht. De certificering, methodieken voor uptime, audits en security maatregelen zijn daarentegen wel weer belangrijk en vooral het ontbreken ervan is een waarschuwing. Ook vallen slechts bepaalde delen onder de SLA en op basis van bepaalde voorwaarden waaraan voldaan moet zijn aan klantzijde.

Wat ik tegen een SLA heb is dat als het bij het oplossen van problemen het SLA als handvat wordt gebruikt je de essentie van de relatie mist. Of als je om de oren slaat met een SLA er iets diepliggender mis gaat en in dat geval lost een SLA niet je daadwerkelijke probleem op.

Maar goed, het hoort er bij al ben ik niet van plan een specialist daarin te worden.

Gijs,

Kijkend naar de praktijk:

1. SLA's worden opgesteld tussen verkopers en inkopers met hulp van juridische afdeling

Hierbij gaat het in hosting/cloud contracten vaak om horizontale SLA's voor vertikale diensten. Als beslissers feitelijk niets weten van de (interne) ICT, je moet ze vaak zelfs nog de werking en het belang van een DNS uitleggen, dan is inderdaad afstemming nog een probleem.

2. SLA's worden te vaak gebruikt als een prijzingsmodel in veel aanbestedingen

Als (kritische) bedrijfprocessen geheel of deels worden uitbesteed dan gaat het vaak om besparingen. En bij eerder genoemde paradox of interest in outsourcing, de provider is inderdaad evengoed op zoek naar besparingen en besteed dus ook weer uit om zo de cirkel vierkant te maken.

Ik trek de discussie mischien een beetje uit verband maar als je het over consumenten kant hebt dan ben ik jun ist benieuwd wat SLA's mij eigenlijk voor garanties geven. Om een sector toe te voegen aan het rijtje van Ruud (MKB of Enterprise) zie ik bovenstaande nog weleens gebeuren bij (semi)overheid. Hier vallen wat mij betreft tegenwoordig ook het gros van de banken onder en de SLA's zijn hier vooral een juridische verplichting tussen A en B met echter zoveel 'escapes' dat het inderdaad niet meer is dan een stuk papier, verspilde moeite om tot betere consumenten services te komen.

Even terugspoelen naar genoemde paradox of interest in outsourcing waarbij de SLA een leidend begrip is geworden maar iedereen elkaar probeert het vel over de neus te halen, hoe verwonderlijk zijn 'incidenten' als DigiNotar, RBS en nog wat spraakmakend falen van (semi)overheden en banken?

Natuurlijk kunnen we niet zonder afspraken waarop we kunnen vertrouwen, maar een SLA is echt geen: "Een man een man, een woord een woord" meer, zeker niet naar de consument. Op papier ziet het er allemaal fantastisch uit maar in werkelijkheid is het een duct-tape oplossing en als dat niet werkt gewoon nog meer duct-tape. Dus geen geld terug met rente, verkoop van banken met winst en nog een heel rijtje van teleurstellingen omdat we ons telkens laten foppen door de ontransparantie van het systeem.

Om hiermee te breken zal vragende partij dus eerst zijn zaken op orde moeten hebben want problemen kun je wel uitbesteden maar worden daarmee dus nog niet opgelost. Betreffende je genoemde afstemming ben ik trouwens benieuwd hoe we dat bereiken als methodieken zoals SCRUM/AGILE populair worden. En de cloud voegt hier nog een leuke abstractie toe waarbij ik betreffende MKB benieuwd ben hoe je afwijkende voorwaarden met de grote providers kunt afdwingen.

@Ewout Agile (m.n. SCRUM) is al populair. En heel bruikbaar. En tegelijkertijd wil dat niet zeggen dat we architectuur maar moeten vergeten. Waar we normaal gesproken beheer als vroegtijdig moeten betrekken bij het ontwerp en de ontwikkeling van een nieuwe oplossing, zullen we nu dat moeten doen + de (standaard) SLA's erbij moeten betrekken zodat we weten wat het betekent om een "supportable" oplossing te bouwen.

Gijs,

Ik ben bekend met die populariteit maar het ging me om de tegenstelling tussen lenigheid versus betrouwbaarheid, meeste reacties doen trouwens vermoeden dat er al met een zekere lenigheid met SLA's om gegaan wordt;-)

Gijs,
Ik ga mijn ict-zaken uitbesteden (cloud of outsourcing) om ontzorgd te worden. Zo te lezen dit is geen ontzorging (SLA op SLA op SLA etc) maar ik verplaats de zorgen naar ergens anders buiten de deur, ik maak mijn ict-keten langer en ik moet ook werken aan de relatie met mijn (cloud)leverancier in de hoop dat ik snel geholpen word als er iets gebeurd is. Mooi is dat, Ontzorging 2.0? Ik krijg het gevoel dat mijn ict-zorgen weggenomen worden en in plaats daarvan ik krijg andere zorgen terug.

Ik hecht ook waarde aan het opstellen van een sla. Een sla kent verschillende aspecten die door mensen met ervaring op dit gebied opgesteld moet worden, onderschat het niet.

En........je hebt niet altijd de kans en het recht om samen met je leverancier een sla op te stellen. Dat heb ik altijd in de reactie en cloudartikelen tegen Henri gezegd, grote cloud-leveranciers geven je wat sla-smaakjes, ze gaan niet met je rond de tafel zitten om een sla op te stellen. Wat doe je in dit geval dan?

En denk je dat je met een sla gedekt bent? Nee hoor, maar het is beter dan niks.

Een SLA zijn de huwelijkse voorwaarden bij een samenwerkingsverband tussen een IT leverancier en afnemer. Niet omdat ze uit liefde elkaar gevonden hebben maar omdat het een verstandshuwelijk betreft.
De liefde komt later....of nooit.

Alle reacties lezende kan ik enkel concluderen dat de eerste opmerking van PaVaKe de meest accurate is.

Mooi geschreven artikel. Het weerspiegelt het actuele spanningsveld tussen business en IT.

Als IT'r zou ik een goede vriend willen zijn van de business vanwege de voordelen die vriendschap biedt boven haat-liefde verhouding.

Ik betwijfel of SLA's met een cloud leverancier echt gaan helpen.

Immers, SLA's gaan over proces parameters. Zoals bijvoorbeeld de oplostijd van een storing. Of de doorlooptijd van een change.
Terwijl het onderwerp waar de 'bewerking' op losgelaten wordt, zijnde infrastructuur en applicaties, heel andere eigenschappen heeft dan een proces.
Of zou een afnemer tevreden zijn met een cloud leverancier die elke maand - zeg - 100 storingen heeft maar wel allemaal binnen SLA weet op te lossen?

En ook: managers roepen altijd dat besturen vooruitkijken is. Toch wordt er bij een SLA alleen maar van de achteruitspiegel gebruik gemaakt. Immers, de resultaten worden altijd achteraf beoordeeld op wat er had moeten gebeuren.

Mijn inschatting is dat het beter zou zijn om een stuurmodel te gebruiken dat gebaseerd is op de feitelijke gebruikerservaring van een applicatie - dus zeg maar datgene wat zich op het scherm afspeelt bij het klikken en tikken.
Waarbij het resultaat van bijvoorbeeld incidenten en changes gemeten wordt op hun bijdrage aan diezelfde gebruikerservaring.

Will,

Bij veel cloudaanbieders wordt dit al gedaan.

Er lopen vaak customer experience managers bij dat soort partijen rond.

@Ruud:
Die begrijp ik niet - daar heb ik wat uitleg bij nodig.
Kan (en wil) je daar iets meer over zeggen?

Een goede SLA geeft nog geen goede serviceorganisatie. Maar een goede SLA stelt de serviceorganisatie wel in staat haar werkwijze te veranderen van reactief naar pro-actief. Daarbij is het van belang een logisch procesmodel te hanteren, dat geen andere doel heeft dan het efficiënt en effectief leveren van functionerende functionaliteit, binnen of overeenkomstig de in de SLA vastgelegde normen. Service Level management als proces maakt daarbij deel uit van dat procesmodel.

Wie alleen een SLA maakt om te kunnen meten waar het mis is gegaan gebruikt haar verkeerd. Dat motiveert niemand en leidt niet of nauwelijks tot verbetering van de service. Het zet partijen onnodig onder druk en dringt hen in de verdediging in plaats van dat ze creatief, betrokken en gestructureerd werken aan verbetering. Dit geldt voor elke leverende (service) organisatie.

Voor de klant (business) is het van belang dat er regie kan worden gevoerd op de service die uiteindelijk wordt geleverd. Daarvoor heb je nog steeds een IT serviceorganisatie nodig die als eerste (en enige!) een SLA heeft met de business.
Alles wat daarachter gebeurt, door welke leverancier dan ook is het pakkie-an van de serviceorganisatie. Die dient er voor te zorgen dat in overeenstemming met de SLA wordt geleverd, uitbesteed of niet, en is de door de business aan te spreken partij.

In veel gevallen gaat dat mis omdat leveranciers te vaak rechtstreeks zaken doen met het management aan de businesskant. Die managers diskwalificeren hun eigen serviceorganisatie, maar rekent het haar al te vaak wel aan als dingen mislopen. In die situaties zijn SLA’s olie op het vuur.

Goede feedback Hans!

Ondertussen kwam ik deze interessante blog post tegen van David Chappell, met daarin zijn wel hele ontnuchterende conclusie over SLA: "These SLAs are discounting mechanisms, not guaranteed service levels. They're about pricing, not promises.": http://davidchappellopinari.blogspot.nl/2013/08/cloud-slas-pricing-not-promises.html

@Hans
Goed verhaal - deels ben ik het ook met je eens!

Het deel waar ik het niet mee eens ben is "een logisch proces model".
Anders gezegd - er wordt een proces model met dito cijfers en SLA's losgelaten op een onderwerp (infra en apps) die juist NIET gaan over processen. En de broncijfers die WEL gaan over infra en apps - mochten die er al zijn - die zijn dan weer GEEN onderdeel van datzelfde proces.

Vrij vertaald (en even zwart-wit): infra en apps zijn het onderwerp van gesprek. Daar wordt over geoordeeld - maar op basis van cijfers (de SLA's van een proces) die daar eigenlijk niks mee te maken hebben.

Hoe kan in een dergelijke situatie de kwaliteit van "een dienst" verbeterd worden? Hoe zie je dat?
Even aannemende dat "een dienst" gedefinieerd is als het beschikbaar stellen van een applicatie met een bepaald prestatie en beschikbaarheidsniveau gedurende een bepaald service window.

@Will. Onder diensten versta ik het leveren van services. IT Services worden bepaald door functionaliteit (wat kan de applicatie) en de mate waarin zij kan functioneren (snelheid, capaciteit en beschikbaarheid). De mate waarin een service enerzijds beschikt over functionaliteit en anderzijds functioneert, bepaalt de tevredenheid van de gebruiker.

Een IT serviceorganisatie zal zodanig georganiseerd moeten zijn dat niet alleen de gewenste functionaliteit wordt geleverd, maar dat die functionaliteit ook nog eens doet wat zij moet doen. Er zijn genoeg voorbeelden van overgeorganiseerde IT organisaties die daardoor juist niet meer efficiënt werken. Zoals je weet ben ik ISM adept (veel van wat ik zeg kun je terugvinden in het boek De ISM-Methode). ISM hanteert een logisch procesmodel waarbij de kern van effectieve serviceverlening ligt in hele basale principes: Afspreken (SLA), Leveren (Operations), Herstellen (Incident management) en Wijzigen (Changemanagement). Efficiency wordt bereikt via Quality management (voorkomen) en Configuration management (vastleggen en raadplegen).

Het kunnen leveren van een service is niet alleen afhankelijk van een goed georganiseerde IT service organisatie, maar ook van de middelen waarover zij kan beschikken om de gevraagde functionaliteit te laten functioneren. Hebben we genoeg bandbreedte, genoeg processorcapaciteit, genoeg geheugen etc. allemaal zaken die niets zeggen over de processen, maar toch wezenlijk van invloed zijn op de ervaring van de gebruiker. Dat “de IT” vaak genoeg de schuld krijgt van slecht functionerende functionaliteit is daarbij een vervelende bijkomstigheid die je juist via een goede SLA kunt ondervangen. Je zult aan moeten kunnen tonen dat procesmatig alles up to date is, maar dat bijvoorbeeld infrastructureel of hardwarematig verbetering noodzakelijk is.

Het beschikbaar stellen van de dienst kan dus verbeterd worden door onderscheid te maken tussen het leveren van de dienst an sich (dus het zorgdragen voor de beschikbaarheid van functionaliteit) en anderzijds het leveren van de mate waarin de dienst (de functionaliteit) kan functioneren.

Het is hoe dan ook van belang dat de verantwoordelijkheid voor het leveren van IT services ligt bij een IT serviceafdeling, of IT servicemanager die op basis van duidelijke afspraken (verzorgd via het proces Service Level Management) met de business leveringsafspraken maakt met in- en externe leveranciers.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×