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