Mijn topic ‘Outsourcing is niet altijd de oplossing’ heeft interessante reacties opgeleverd. Ook bleek consensus dat goede samenwerking met de leverancier en effectieve regie outsourcing wel of niet tot een succes kunnen maken. In dit artikel wil ik een aantal van mijn ideeën presenteren waarom outsourcing regelmatig niet tot de gewenste resultaten leidt.
Mijn onderzoek naar de faalfactoren bij outsourcing is een, overigens niet wetenschappelijk verantwoord maar vooral praktisch gericht, onderzoek. Hieruit kwamen de volgende faalfactoren naar voren:
1. Onvoldoende inzicht en consensus over de gewenste dienstverlening.
2. Niet adequate regie op de outsourcing bij de klant.
3. Onvoldoende samenwerking tussen klant en leverancier.
4. Een situatie van een ‘wurgcontract’.
5. De keuze voor een ‘verkeerde’ leverancier.
Vervolgens heb ik onderzocht welke factoren ‘achter’ deze faalfactoren een rol spelen.
Als belangrijkste faalfactor komt het onvoldoende inzicht in de gewenste dienstverlening naar voren. En, zoals in mijn vorige artikel aangegeven, zelfs onvoldoende inzicht in de gewenste dienstverlening door de klant (!). Dit ondanks het streven om bij contractafsluiting sla's op te stellen waarin de gewenste dienstverlening toch goed zou moeten zijn omschreven.
De achterliggende faalfactoren zijn dat het vaak moeilijk is om de gewenste dienstverlening volledig en eenduidig te onderkennen en de condities aan te geven om deze adequaat te kunnen leveren. Onderstaand een aantal voorbeelden ter illustratie.
1. Volledigheid, eenduidigheid en interpretatie
Stel dat in een sla de beschikbaarheid van een netwerk is gesteld op 99.x procent. Dit is eenvoudig en lijkt eenduidig. Maar wat als buiten kantooruren een storing optreedt? Hoewel misschien ‘binnen' de sla, is die storing dan ongewenst? Is er dan sprake van een verkeerde interpretatie van de sla of is deze niet volledig? Iedereen, ook de leverancier, snapt dat een storing tijdens kantooruren ongewenst is. Je zou ook kunnen stellen dat deze beschikbaarheid beter had moeten worden gedefinieerd om eenduidig de gewenste dienstverlening af te bakenen.
Mijn praktijk rond dit voorbeeld heeft mij overigens andere inzichten gegeven, bijvoorbeeld dat de klant het afvangen van storingen tijdens kantooruren als (te) duur heeft gekwalificeerd. Helaas heeft een klant vaak onvoldoende inzicht in de gevolgen daarvan.
2. Benodigde kennis en inzichten bij de servicedesk
Een tweede voorbeeld betreft het afhandelen van incidenten die bij een servicedesk worden gemeld. In een sla zijn vaak criteria opgesteld om een incident te kwalificeren op prioriteit van afhandelen. Het is vaak moeilijk om een hiervoor een eenduidige en volledige beschrijving op te stellen.
Dit kan ik illustreren door een sla over het beheer van en de support op kassa's in een supermarkt. De urgentie van het uitvallen van één of meerdere kassa's is gekoppeld aan het tijdstip van de dag en de dag zelf. Op een doordeweekse dag heeft het uitvallen van een kassa minder impact dan bijvoorbeeld op zaterdagochtend. Bovendien speelt de grootte van de vestiging/winkel ook een rol: de impact van het uitvallen van één kassa in een kleine vestiging heeft meer impact dan bij een grote vestiging. Hoe wil je de impact van een storing, gelet op het complex van drukte en grootte van een vestiging, nu eenduidig in een sla vastleggen? Een eenvoudige oplossing is om een storing met een kassa, op welk moment en voor welke vestiging dan ook, met de hoogste prioriteit te kwalificeren. Gelet op de kosten, is dit dan weer niet gewenst!?
3. Als klant kan je voor verrassingen komen te staan
Een derde voorbeeld betreft de openingstijden van een servicedesk. Na discussie kwamen we erop dat er normale openingstijden van de winkels waren, en avond- en zondagsopeningen die per stad verschilden. Al die openingstijden werden uiteindelijk expliciet gemaakt. Na overdracht van de servicedesk waren de klachten uit de vestigingen niet van de lucht: 'We krijgen te beperkt support onder het contract!' Wat bleek er aan de hand: er werd structureel overgewerkt en buiten de openingstijden van de vestiging was derhalve ook support nodig. Dit inzicht ontbrak bij deze klant.
Bevindingen
Als ik de achterliggende faalfactoren met betrekking tot de gewenste dienstverlening nu op een rijtje zet, kom ik tot het volgende:
– Het is soms moeilijk om de gewenste/noodzakelijke dienstverlening eenduidig en compleet te onderkennen en vervolgens in een sla vast te leggen.
– Om (te) hoge kosten te vermijden, is het soms nodig om risico's te accepteren. Het is naar mijn mening de verantwoordelijkheid van de klant om inzicht in de risico's en de impact daarvan, met name voor de business, te kennen en zijn conclusies daaruit te trekken.
– Kennis en inzicht in de bedrijfsprocessen van de klant zijn soms bij de leverancier nodig om de dienstverlening op adequaat niveau te kunnen leveren. Opleiding en training van de medewerkers van een leverancier behoort tot de mogelijkheden, maar deze medewerkers zijn meer ‘volatiel' dan de medewerkers van de klant en het blijven, met alle respect, medewerkers van de leverancier, met bijvoorbeeld minder affiniteit met de klantorganisatie.
Hoe kan (of moet?) het anders?
Zowel de klant als de leverancier zouden moeten onderkennen dat een eenduidige en volledige vastlegging van de gewenste dienstverlening in een sla moeilijk is, maar ook de interpretatie daarvan. Dit vraagt om een nauwe samenwerking omdat het inzicht in de gewenste dienstverlening vaak pas tijdens de delivery-fase voor zowel klant als leverancier (volledig) duidelijk wordt.
Voorts zou ik een lans willen breken dat zowel de klant als de leverancier deze lastige materie onderkennen en accepteren, in het bijzonder met betrekking tot de financiële consequenties indien wordt onderkend dat een sla moet worden uitgebreid of beperkt. Vasthouden aan het contract, door zowel de klant als de leverancier, leidt tot ongewenste discussies. Meer leveren, betekent door de klant meer betalen; minder leveren betekent dat de leverancier minder factureert. Dit is de basis voor een clausule in het contract, waar ik groot voorstander van ben.
Mag ik tot slot een parallel trekken met systeemontwikkeling? Jarenlang ben ik, onder andere als projectleider, actief geweest bij het ontwikkelen van nieuwe systemen en het onderhouden van bestaande. Het opstellen van een functioneel ontwerp wordt uitgevoerd door informatie-analisten en functioneel ontwerpers, naar aanleiding van ‘het gesprek' tussen deze ontwerpers en de gebruiker. Dit resulteert in een min of meer formeel stuk, het functioneel ontwerp, waarin de gewenste functionaliteit wordt gedefinieerd. Bij systeemontwikkeling hebben we geleerd dat een ‘cleane' analyse en het vastleggen van het ontwerp in een document niet werkt. Daarom zijn methoden en technieken als ‘prototyping', ‘RUP', ‘use cases' en ‘Agile' ontstaan. Allen hebben het kenmerk dat in een cyclisch proces en door een nauwe samenwerking tussen klant/gebruiker en leverancier/ontwerper specificaties ontstaan die enerzijds door de gebruiker worden herkend en als ‘juist' worden gekwalificeerd, en anderzijds die allen (zo goed als mogelijk) eenduidig begrijpen en interpreteren.
Het lijkt wel of wij in de wereld van outsourcing deze lessen bij systeemontwikkeling zijn vergeten: we willen direct sla's die compleet zijn, eenduidig en volledig interpreteerbaar. En we willen als klant de leverancier hier ook ‘hard' op afrekenen. Wat mij betreft dus een illusie!
@ Johan,
Goed en herkenbaar stuk.
Zeker punt 3 is zeer herkenbaar “3. Als klant kan je voor verrassingen komen te staan”
Het gebeurt nog te vaak dat een klant geen enkel idee heeft wat hij precies kan verwachten. Helaas komt de klant hier vaak te laat ( lees tijdens een escalatie ) achter.
Echter heeft de klant hier natuurlijk ook zelf een grote rol in. Nog te vaak worden er dingen vergeten of te onduidelijk toegelicht. En dan krijg je te maken met de interpretatie van de aanbieder. En die bieden vaak het minimale ( lees goedkoopste ) aan om zich te kunnen kwalificeren.
Een logisch stuk dat echter wel heel erg de nadruk legt op sla’s. Een sla alleen maakt niet gelukkig. Is de klant tevreden als je de kassastoring netjes binnen de tijd hebt opgelost? Vermoedelijk niet (want hij heeft minder (consument-)klanten kunnen helpen. De opdrachtgever van ict (demand manager) zal aan het eind van de maand een oplospercentage zien dat wellicht tot tevredenheid stemt, de storing wordt dan verborgen achter de 0,x procent onbeschikbaarheid. De klant/gebruiker heeft een beter geheugen en zal zich de individuele storing nog herinneren. Met andere woorden: het perspectief van gebruiker of opdrachtgever bepaalt vaak de tevredenheid.
Overweeg of je in die sla ook wilt vastleggen dat je elkaar wederzijds bijv. één keer per jaar de ‘stomste’ fout die je ooit kon maken zal vergeven (uiteraard binnen bepaalde grenzen). Als dat met iets ludieks (taart of iets dergelijks) wordt ondersteund, blijft de situatie vervelend maar blijf je samen werken aan een goede relatie.
Kennis van of gevoel voor de klantorganisatie is bij uitbestede dienstverlening vaak een issue: met site visits etc. zijn hier eenvoudig stappen in te zetten. Waarom zou je een nieuwe it-medewerker niet een dag laten meedraaien achter de kassa van die supermarkt? Ja, dat is iets dat je samen moet willen afspreken (in een sla?) en waar je wat uren aan moet besteden. Daarnaast is het goed vastleggen in je cmdb welke functie een CI heeft mede van belang. Een voorbeeld is een printer die een algemene KA-functie heeft (en dus bij storing makkelijker vervangbaar is) of juist een specifieke bedrijfsfunctie (bijvoorbeeld pakbonnen uitprinten, waarbij er wellicht maar één printer beschikbaar is op een lokatie).
Johan,
Discussies over SLA’s doen me altijd een beetje denken aan het grapje in kinderjaren waar je vriendje vroeg overal het woord ‘mij’ achter te zetten.
Dit is soms ook precies wat er gebeurt met allerlei gedrochten die een abstractie als dienstverlening proberen te beschrijven. Natuurlijk zitten er hele objectieve eisen in maar niet zelden ook subjectieve wensen. Die je prachtig verwoordt in 5 punten en waarmee dit soort afspraken gewoon ‘SLA MIJ’ worden.
In alle processen die we hebben voor de aansturing van de ICT ben ik nog nooit verwachtingsmanagement tegen gekomen. Wel vaak de verwachting dat voor niets de zon opgaat, dat dienstverlener dus voor eigen rekening de tekorkomingen oplost. Dat dit niet werkt zien we trouwens steeds vaker in aanbestedingen.
In tegenstelling tot voorgaande sprekers vind ik een sla onmisbaar en een uitstekend middel om een dienst te beschrijven. De dienstverlener stelt een dienst beschikbaar op een aantal, vaak technoligisch bepaalde, niveau’s, en de sla beschrijft de dienst zoals die geld voor het gekozen niveau. Om het inzichtelijk te houden wordt gebruik gemaakt van een beperkt aantal parameters in de beschrijving die het onderscheid tussen de verschillende niveau’s goed weergeven.
Vervolgens mag je dan als afnemer natuurlijk verwachten dat de dienst globaal gezien ook beantwoord aan de beschrijving. Om dat zeker te stellen meet je dienst en rapporteert daarover. In die rol is een sla een onmisbaar instrument. Het wordt gebruikt om de behoefte van het bedrijf zo kosten efficient mogelijk te vertalen naar een dienst niveau.
Het probleem ontstaat als we vervolgens de kpi’s die het dienstniveau beschrijven gaan inzetten om de dienstverlener zelf te gaan beoordelen. De onvrede over een dienstverlener is slechts in zeer beperkte mate afhankelijk van het al dan niet halen van de afgesproken diensten kpi’s.
Het probleem ligt in het onvermogen om gezamenlijk de levering van het dienstenpakket goed te besturen. Kpi’s die daarbij slechts één van de twee betrokken partijen meten zijn gebruikelijk, maar volstrekt ontoereikend. Er wordt te weinig gekeken naar de rol van de klant en de performance daar wordt al helemaal niet gemeten. Alsof het behalen van een rijbewijs afhankelijk is van het merk auto en niet gekeken wordt naar de bestuurder. Een praktijk voorbeeld: bij infrastructuur, zeg een omgeving waarop een klant zijn eigen applicatie kan draaien, wordt beoordeeld op beschikbaarheid van de dienst. Als vervolgens de klant om de 2 maanden een ongeteste release op het systeem zet dan wordt de kpi ‘beschikbaarheid’ meer beïnvloed door de klant dan door de leverancier. De kpi is ontoereikend om het dienstniveau te beschrijven. En dus zullen beide partijen altijd ontevreden zijn, de klant haalt zijn afgesproken niveau niet, en de leverancier moet veel meer tijd steken in het stabiel krijgen en houden van zijn platform.
Willen we hierin verder komen dan zullen we ook kpi’s moeten definiëren voor de samenwerking op zich, en deze ook meten voor beide partijen. En niet de sla misbruiken om de samenwerking te beoordelen.
Het voorbeeld wat Lars aanhaalt in zijn reactie is mijn grote bezwaar tegen de schijnzekerheid die gecreëerd wordt door SLA’s af te sluiten.
Voortbordurend op zijn voorbeeld, een praktijkvoorbeeld waar ik ooit mee te maken heb gehad:
– Klant betrekt netwerk bij partij A, en applicaties bij partij B. Met beide partijen zijn SLA’s afgesloten met betrekking tot performance.
– partij B introduceert een nieuwe applicatie. In de SLA staan dingen als performance genoemd, en een testrapport is bijgevoegd dat de performance gehaald wordt
– in praktijk blijkt de performance bij lange na niet gehaald te worden. Partij B zwaait met het testrapport, en wijst naar het netwerk als de schuldige; het netwerk is volgens hun te traag
– partij A monitort het netwerk nauwkeurig, en kan meteen laten zien dat de performance van het netwerk ruimschoots binnen alle afgesproken KPI’s valt.
Beiden voldoen aan hun SLA, en wijzen naar elkaar. De klant is de dupe; weet niet wie die moet geloven, en is heel veel tijd en geld kwijt aan bemiddelen en om het probleem opgelost te kijken.
En hij dacht nog wel gebeiteld te zitten met zijn geweldige SLA’s………
In dit geval werden de SLA’s gebruikt door de partijen om zich achter te verschuilen; immers, beiden voldeden aan de gemeten KPI’s. En die KPI’s waren echt goed en met zorg opgesteld.
(na veel zoeken bleek patij B getest te hebben op een LAN, waar client-server naast elkaar stonden, daar waar in praktijk gebruik werd gemaakt van een WAN over 500 km. Door de latency zakte de performance van de applicatie in)
@Pavake. En daarom moet je als klant met maar één partij, namelijk de ICT serviceorganisatie, een SLA afsluiten. Maar ik vermoed dat je hier met “klant” juist de ICT serviceorganisatie zelf bedoelt die een SLA met leveranciers heeft. Dat gaat zo niet werken.
De klant in ICT termen is de gebruikersorganisatie. Die heeft maar één SLA: met de ICT serviceorganisatie. Als die laatste bepaalde diensten levert door gebruikmaking van externe leveranciers dan heeft ze de verantwoordelijkheid om met die leveranciers contracten af te sluiten die garanderen dat ze voldoen aan de SLA zoals die met de eindklant is overeengekomen. Als die garantie niet kan worden gegeven moet de SLA met de klant worden heroverwogen. Bij de afstemming en afsluiting van een SLA voor een dienst aan de klant moet de serviceorganisatie dan ook goed weten wat externe leveranciers kunnen leveren, omdat dit bepalend kan zijn voor de te hanteren normen voor de afgesproken KPI’s.
Kortom: er is maar één loket voor de klant. Wat daar achter zit (Matroesjka- of Droste-effect) is voor de klant niet interessant.
@HK
Ik snap wat je bedoelt, maar daar is de klant bottom line niet mee geholpen.
Wanneer ik een kaartje koop bij de NS, sluit ik een soort contractje met hun af dat zij mij gaan vervoeren.
Lukt dit niet omdat bijvoorbeeld de wissels bevroren zijn, wijst NS naar prorail. Inderdaad, voor mij niet interessant, ik had een kaartje gekocht bij de NS.
Maar al met al ben ik nog steeds niet op de plaats van bestemming. Ook hier zie je dat de NS zich verschuilt achter het contract met prorail, die op haar beurt weer door kan verwijzen naar de 3e partijen waar zij zaken mee doen.
Eind van het verhaal hebben we een heleboel SLA’s en verwijzingen naar iedere partij in de keten, en sta ik nog op het station met mijn kaartje te wachten dat ik naar huis kan.
Dat is wat ik bedoel met de schijnzekerheid die gecreëerd wordt door de SLA’s. Met een SLA kom ik niet thuis, daar heb ik een rijdende trein voor nodig.
Uit mijn eigen ervaring ken ik situatie waarbij mijn ‘klant’ tevreden is terwijl de SLR op meerdere KPI’s ‘op rood staat’. En tegelijkertijd ken ik situaties waarbij de SLR ‘groen is’ en de klant toch diep ongelukkig.
Ik geef de voorkeur aan de eerste situatie. Namelijk die situatie waarin een SLA richtinggevend is maar niet zaligmakend. ‘Beheer’ is veel meer als het halen van servicelevels. Mijn klanten willen ‘partneren’ en zien dan hun problemen door ‘ownership’ ook de onze zijn.
Als de klant daarvan is overtuigd blijft de SLA richtinggevend en signalerend maar niet langer leidend. Zulke contracten bieden daarmee de juiste voedingsbodem voor een lange constructieve relatie waarbij outsourcing de juiste vorm is.
(Door het belang dit gevoel van ownership voel ik me dus ook niet bedreigd door ‘India’ of ‘Oost-Europa’.)
Uit de reacties komt duidelijk naar voren dat een SLA geen wondermiddel is. Een SLA is dan ook een meet-instrument, en geen stuur instrument. Zoals blijkt uit Johans artikel: Je moet je altijd afvragen of je op het juiste punt meet, en of je misschien te maken hebt met een meetfout. Als je alles goed doet heb je een redelijk goede weergave of de dienst voldoet; maar alleen op de parameters die je meet!
Als in de praktijk blijkt dat je de meet instrumenten nog moet aanpassen omdat de dienst niet voldoet, en dat dit niet goed naar voren komt uit de metingen, dan zul je om de tafel moeten met je leverancier. Je zult als klant de regie moeten voeren, ook als je maar één leverancier hebt.
Daarnaast is het belangrijk dat je de middelen hebt om te sturen, en de juiste knoppen ook daadwerkelijk hebt om te kunnen sturen. En ook hier geld een kosten afweging, hoe meer controle je hebt, hoe duurder de dienst (maatwerk kost nu eenmaal meer). Als individuele klant heb je weinig mogelijkheden om een leverancier als Microsoft aan te kunnen sturen, maar de dienst wordt dan ook tegen een hele andere prijs geleverd als maatwerk software.
Al met al blijf ik bij mijn stelling dat een SLA een bijzonder waardevol gereedschap is, maar voor een goede dienstverlening heb je meer gereedschap nodig. Een timmerman kan niet zonder hamer, maar hij heeft meer nodig voor het bouwen van een huis.
Mijn artikel heeft veel reacties uitgelokt. En interessant!
Eén van mijn punten was dat de dienstverlening soms (eigenlijk best vaak) niet goed verloopt doordat er geen consensus bestaat over de inhoud en condities van de dienstverlening. Velen geven aan dat er meer nodig is dan een SLA, en terecht! Maar dat was in dit geval mijn punt van mijn betoog niet.
Ik zou vervolgens niet weten hoe je de gewenste dienstverlening kan communiceren en vervolgens contractureel kan afsluiten, zonder SLA’s.
Consensus (en de juiste en volledige informatie en vervolgens interpretatie) over de door de klant c.q. gebruiker gewenste dienstverlening lijkt mij toch wel een basis-voorwaarde; wij wensen immers contractuele afspraken, en veel belangrijker: de door de gebruiker gewenste dienstverlening.
En nogmaals, een SLA is niet de enige voorwaarde om tot goede dienstverlening te komen!
Een SLA is – zoals sommigen aangeven – ook maar een instrument. Zoals ik het graag zie: een instrument om met mekaar tot inzicht en consensus te komen over de gewenste dienstverlening. En dat lukt niet als je bij contractafsluiting (en de illusie hebt om)gelijk SLA’s af te sluiten die dekkend voor de gewenste dienstverlening zouden moeten zijn. Dit vraagt om samenwerking met je leverancier, zowel bij het initieel afsluiten van de SLA als later bij aanpassingen. Wat dat betreft heb ik verwezen naar de methoden en technieken om tot functionele specificaties te komen bij systeemontwikkeling.
Een SLA is voorts voor mij dus een communicatie-, stuur- én een meetinstrument. We vergeten nogal eens dat ook de leverancier belang heeft bij ‘meten’, namelijk om te weten of hij het goed doet. Dat is het belang van zowel klant als leverancier!
Sturen doe je vervolgens vanuit consensus over de gewenste/gecontracteerde dienstverlening. En dat vraagt samenwerking, afstemming, begrip, partnership, etc.