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!
