Uitbesteden van ict is tegenwoordig de normaalste zaak van de wereld. De afgelopen jaren is er veel ervaring mee opgedaan, zowel door de uitbestedende klant als de inbestedende leverancier. Je zou haast verwachten dat beiden, klant én leverancier, zo langzamerhand op een professioneel niveau kunnen opereren. Helaas blijkt dat slechts weinig klanten écht tevreden zijn over de performance van hun leverancier.
Er is al veel onderzoek gedaan naar de succes- en faalfactoren van outsourcing. Eén aspect in dit kader ‘de wijze van aansturen van de leverancier(s) bij een resultaatverplichtend contract' wil ik ter discussie stellen. Dit wordt samengevat met de volgende stellingen:
1. De klant en leverancier zouden samen verantwoordelijk moeten zijn voor het formuleren van eisen aan en het zoeken van oplossingen.
2. De klant is verantwoordelijk voor het vaststellen van de eisen en het kiezen van de te implementeren oplossing.
3. De leverancier is verantwoordelijk voor de (technische) implementatie van de gekozen oplossing.
4. De klant is verantwoordelijk voor het stellen van eisen aan de beschikbaarstelling van de gekozen oplossing; de leverancier is verantwoordelijk voor de exploitatie conform de gestelde eisen.
Succes- en faalfactoren
Eigen ervaringen brachten de onderstaande factoren aan het licht waardoor outsourcing vaak niet de gewenste en/of de verwachte resultaten opleverde.
1. De diensten van de leverancier zijn niet helder geformuleerd.
2. Het ontbreekt aan adequate regie (vanuit de veronderstelling dat een contract en SLA's voldoende randvoorwaarden leveren voor adequate dienstverlening).
3. Er is een ‘verkeerde' leverancier gecontracteerd; de klant vraagt daarbij om diensten die de betreffende leverancier niet kan leveren.
4. Er is een wurgcontract afgesloten.
5. Er is geen samenwerking tussen klant en leverancier, vaak gebaseerd op wantrouwen naar de leverancier toe.
Het lijkt (of blijkt?) echter dat de wijze van aansturing van de leverancier, bij een resultaatverplichtend contract, vaak ook een belangrijke faalfactor is.
De klant stuurt de leverancier functioneel aan
Bij outsourcing geeft de klant de voorkeur aan een resultaatverplichtend contract met een leverancier. Daarbij wordt er vaak voor gekozen om de leverancier ‘in functionele termen' aan te sturen; hierbij formuleert de klant de eisen aan de oplossing en kiest de leverancier de daarbij passende technologie. De motieven hiervoor zijn talrijk. Een paar voorbeelden:
1. De klant kan zich concentreren op de businessbehoeften en de ‘wat-vraag', de leverancier is dé technische specialist en is het beste in staat om oplossingen (het ‘hoe') te bepalen.
2. De regieorganisatie bij de klant kan van minimale omvang blijven, omdat zij de behoeften alleen in functionele termen hoeft te formuleren.
3. De klantorganisatie heeft outsourcing juist gekozen omdat men moeilijk aan technische specialisten kan komen.
Dit zijn valide argumenten waardoor het al dan niet afsluiten van resultaatverplichtende contracten niet ter discussie gesteld wordt. De vraag die hierbij naar boven komt is of deze ‘functionele aansturing' wel voldoende is om het gewenste niveau van dienstverlening te bereiken?
Overwegingen
Over het algemeen geldt bij resultaatverplichtende contracten dat de klant zich – uit principe – ver van de technologie moet houden om de leverancier aan zijn ‘resultaatverplichting' te kunnen houden. Wanneer de klant de technische aspecten van de oplossing gaat voorschrijven, is er (tenminste) sprake van een gedeelde verantwoordelijkheid. Dit druist in tegen het principe van een resultaatverplichtend contract.
Om de scope van de overwegingen scherper af te bakenen moet er een verschil worden gemaakt tussen:
1. Het vaststellen van de behoeften.
2. Het vaststellen van de functionele eisen aan de oplossing.
3. Het vaststellen van de technische oplossing.
4. De implementatie van de oplossing.
5. De exploitatie.
Ad. 1. Het vaststellen van de behoeften
De behoefte aan oplossingen is vooral een ‘business vraagstuk'. Los van het door de leverancier gegeven advies is het vaststellen van de behoeften de exclusieve verantwoordelijkheid van de klant.
Ad. 2. Het vaststellen van de functionele eisen aan de oplossing
Over het algemeen wordt gesteld dat de klant verantwoordelijk is voor het opstellen van de functionele eisen aan de oplossing. De klant kan immers het beste vanuit de behoeften vaststellen welke functionele eisen aan de oplossing gesteld moeten worden. Bij een puur functionele aansturing van de leverancier worden deze eisen vervolgens aan de leverancier overgedragen.
Ervaring heeft geleerd dat bij deze situatie drie problemen ontstaan:
1. Het ontbreekt de klant aan expertise om eenduidig de eisen te formuleren.
2. Er is sprake van een communicatiekloof tussen klant en leverancier; klant en leverancier ‘praten' elkaars ‘taal' niet.
3. De leverancier blijkt de klant niet goed te begrijpen.
Om deze problemen op te lossen wordt gesteld dat:
1. De klant en leverancier gezamenlijk verantwoordelijk moeten worden gesteld voor het formuleren van de functionele eisen aan de oplossing; als zij hier beiden bij zijn betrokken, bestaat er minder kans dat de leverancier niet goed begrijpt wat de klant bedoeld.
2. De klant exclusief verantwoordelijk is voor het vaststellen en accorderen van de vastgestelde functionele eisen.
Ad. 3. Het vaststellen van de oplossing
Bij een functionele aansturing van de leverancier wordt er vaak voor gekozen dat de klant niet is betrokken bij de keuze van de technische oplossing, De vraag is dan of de functionele eisen voldoende zijn voor de leverancier om een adequate oplossing te selecteren. Dit geldt zeker als de communicatie tussen klant en leverancier niet goed verloopt (zie ad. 2).
Gelet op deze overwegingen wordt gesteld dat niet alleen de leverancier, maar ook de klant een verantwoordelijkheid heeft bij de keuze voor de technische oplossing. De leverancier heeft hierin een adviesplicht (bijvoorbeeld het type oplossing, de voor- en nadelen), de klant maakt de keuze.
Ad. 4. Het implementeren van de technische oplossing
Om de leverancier verantwoordelijk te kunnen stellen voor de exploitatie, moet de wijze van implementatie exclusief de verantwoordelijkheid van de leverancier zijn. Indien de klant hieraan eisen gaat stellen, kan de leverancier niet exclusief de verantwoordelijkheid voor de exploitatie nemen.
Ad. 5. De exploitatie
Om de leverancier verantwoordelijk te kunnen stellen voor de exploitatie, moet de wijze van exploitatie exclusief de verantwoordelijkheid van de leverancier zijn. De klant zou wel eisen moeten stellen aan de beschikbaarstelling van de oplossing, zoals de performance en de beveiliging.
Conclusie
De conclusie is dat de leverancier bij een resultaatverplichtend contract uitsluitend en exclusief verantwoordelijk kan worden gesteld voor de implementatie en de exploitatie van een oplossing.
Tevens wordt gesteld dat:
1. Het formuleren van functionele eisen aan de oplossing een gezamenlijke verantwoordelijkheid van klant en leverancier zou moeten zijn.
2. Het vaststellen van deze eisen de exclusieve verantwoordelijkheid van de klant is.
3. Het kiezen van de oplossing de verantwoordelijkheid van de klant zou moeten zijn; de leverancier heeft hierbij een adviesplicht.
Discussie
De lezer wordt gevraagd te reageren op het gestelde. Vanuit mijn eigen waarnemingen is de resultaatverplichting van leveranciers in contracten vaak onvoldoende scherp omschreven, terwijl de aansturing door de klant zich te vaak slechts richt op het omschrijven van de functionele eisen aan de oplossing.
Al deze factoren leiden tot ontevredenheid, bij zowel klant als leverancier. Een goede oplossing voor dit vraagstuk is mijn inziens van groot belang!
Hier is volgens mij geen speld tussen te krijgen. Als alle outsourcing relaties tussen klant en leverancier op deze wijze vormgegeven worden, ontstaat een echte samenwerking en zullen projecten die hieruit voortvloeien succesvol verlopen.
Bij het vaststellen van de functionele eisen denk ik wel dat de situatie van de klant belangrijk is. Indien de klant een eindgebruiker is die uitbesteedt aan een software leverancier, dan is het vaststellen van de functionele eisen door beiden een effectieve oplossing. De leverancier weet in beginsel immers beter hoe deze eisen vast te stellen en welke oplossingen mogelijk zijn.
Indien de klant echter een software leverancier is die op zijn beurt een deel (offshore) uitbesteedt, is de situatie anders. De software leverancier dient de eisen vast te stellen samen met zijn eindklant. Het vaststellen van functionele eisen door de offshore leverancier kan voor problemen zorgen, daar deze geen directe lijn naar de eindklant heeft. De software leverancier dient in dit geval dus de functionele eisen samen met de eindgebruiker vast te stellen, waarop de offshore leverancier het uitvoerende deel voor haar rekening neemt.
In de drie geponeerde stellingen heb ik wel 1 vraagteken: wie is verantwoordelijk indien de leverancier de technische oplossing (die door de leverancier is voorgesteld en door de klant is goedgekeurd) niet afdoende blijkt te werken?
Hugo Messer
Bridge
http://www.bridge-int.nl/blog
Het is natuurlijk fijn als idee�n worden onderschreven en zeker als dit een mogelijke oplossing biedt voor een heikel punt. Daarvoor dank aan Hugo Messer!
Ik realiseerde mij bij het opschrijven van mijn idee�n dat het gestelde ‘conceptueel’ wellicht eenvoudig is, maar in de praktijk nog wel wat haken en ogen zal opleveren.
E�n van die situaties is – zoals Hugo aangeeft – het beheer van standaard software. Inderdaad heeft de leverancier daar vooral de leidende rol, zowel wat betreft het vaststellen van gewenste functionaliteit als de technische realisatie daarvan. Hoewel je als klant daar je idee?n over kan ventileren, ligt het primair bij de leverancier of hij hier notie van neemt. De leverancier heeft hier dus wellicht de sterkste positie. Kosten, baten en commerci�le positie staan hier bij de leverancier voorop.
Ook wat betreft de vraag van Hugo “wie verantwoordelijk is voor de situatie dat de technische oplossing niet voldoet”, ligt e.e.a. ‘gevoelig’. Als je er van uitgaat dat er een resultaatverlichting voor de leverancier geldt (en deze kan je het beste respecteren c.q. borgen) dan kan je de leverancier verantwoordelijk stellen voor het aandragen van oplossingen die voldoen aan de functionele vraag. Hoewel de klant naar mijn voorstel de keuze maakt, blijft volledig duidelijk wie verantwoordelijk is.
Johan Op de Coul
Kirkman Company