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