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…
@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 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.
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;-)
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.