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…
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.