Voor een toenemend aantal organisaties is outsourcing van ict-taken een serieuze overweging. Door de vele horrorverhalen is er echter ook sprake van terughoudendheid. De succesverhalen blijven onderbelicht en dat is jammer. Helaas gaat het inderdaad regelmatig mis en in de meeste gevallen wordt de oorzaak gezocht aan de kant van dictdienstverlener. Echter, een uitbesteder die met een vinger naar de leverancier wijst, wijst met drie vingers naar zichzelf. Naar mijn mening gaat outsourcing vaak mis omdat de uitbesteder onvoldoende in staat is om zijn eisen en wensen goed te beschrijven.
Wanneer je de berichten over ict-projecten en outsourcing leest, zal het je opvallen dat ongeveer 75 procent van alle projecten mislukt. Onder mislukken wordt in dit geval verstaan: een te late oplevering, het overschrijden van het budget, of een resultaat dat niet voldoet aan de verwachtingen. Dit percentage is natuurlijk veel te hoog, maar kan worden verlaagd door een betere samenwerking tussen de uitbesteder en de ict-dienstverlener.
Belangrijke succesfactor
Grote organisaties die outsourcing overwegen, richten voor een uitbestedingstraject een apart projectteam in. Het uitbestedingstraject wordt op een gedegen manier van begin tot eind doorlopen; de leveranciers worden grondig geselecteerd en de eisen en wensen zijn goed gedefinieerd. Ook wordt er gedurende het uitbestedingstraject een volwassen 'demand organisatie' opgezet waarmee de leverancier na gunning wordt aangestuurd, gecontroleerd en bijgestuurd. Kortom, het demand management is goed geregeld en dat blijkt een belangrijke succesfactor.
Voor kleinere organisaties die zelden met outsourcing te maken hebben gehad, is het inrichten van een volwassen demand organisatie vaak geen optie. De tijd, kennis en kunde ontbreken om de vraag goed te definiëren. In zo'n geval is outsourcen gedoemd te mislukken. Als de uitbesteder niet weet of heeft verteld wat de eisen en wensen zijn, kan er niet van een ict-dienstverlener worden verwacht dat het resultaat hierop aansluit; garbage in is garbage out.
De vraag achter de vraag
Veel ict-dienstverleners nemen te vaak aan dat de vraag van de uitbesteder goed is gedefinieerd. Zonder hierop door te vragen wordt deze vraag door de dienstverlener verwerkt tot een eigen interpretatie van het gewenste resultaat. Het mag dan geen verrassing zijn dat de uitbesteder niet tevreden is met het resultaat. Uitlopen in de planning of overschrijding van het budget is dan vaak de enige manier om iets te maken waar de uitbesteder wel blij mee is. Dit kan ook anders.
Uit eigen ervaring weet ik dat de initiële vraag van de klant vaak anders is dan hetgeen de klant echt wil hebben. Je zult dus als ict-dienstleverancier op zoek moeten gaan naar de vraag achter de vraag. Samen met de klant kun je dan de echte vraag en de daarbij behorende eisen en wensen definiëren. En hier loop je eigenlijk meteen tegen het volgende probleem aan. Het gezamenlijk specificeren van de vraag is kostbaar en tijdrovend. Vooral bij kleinere organisaties is hiervoor onvoldoende geld en tijd beschikbaar. De oplossing is echter ook voorhanden. Om binnen de gestelde voorwaarden (tijd en geld) het risico op een mislukte outsourcing zoveel als mogelijk in te perken, is een meer iteratief proces noodzakelijk: de zogenaamde Agile ontwikkelmethode.
Samenwerking en vertrouwen
De ict-dienstverlener en uitbesteder definiëren samen de eisen en wensen op hoofdlijnen. Vervolgens gaat de dienstverlener aan de slag om binnen twee tot vier weken na aanvang van het project een eerste resultaat (prototype) op te leveren. De klant wordt op deze wijze als het ware geconfronteerd met de interpretatie van het resultaat door de ontwikkelaars. Door dit tussenresultaat te bestuderen en te ‘testen' kan de uitbesteder al vroeg in het ontwikkeltraject terugkoppeling geven en indien nodig bijsturen. Afhankelijk van de totale doorlooptijd herhaalt deze cyclus zich een aantal keer. De kans dat een dergelijke aanpak het gewenste eindresultaat oplevert is vele malen hoger.
Let wel dat wederzijds vertrouwen en frequente communicatie noodzakelijk zijn om met behulp van de Agile ontwikkelmethode outsourcing tot een succes te maken. De intensiviteit aan de kant van de uitbesteder mag dan vergeleken met een eigen demand organisatie een stuk lager zijn, betrokkenheid blijft een belangrijke voorwaarde voor succes. Uit eigen ervaring, door schade en schande wijs geworden, weet ik dat op deze manier outsourcen leuk en succesvol is.
Outsourcen hoeft helemaal geen nachtmerrie te worden. Veelal liggen de problemen in het feit dat de outsourcer met de ICT-manager om de tafel moet om het project in te gaan. Juist degene bij wie de functie op de tocht staat. Alsof je met de kalkoen over het kerstdiner aan het praten bent…..
Beter is het dit soort trajecten te laten begeleiden door externe specialisten, zodat de ICT-manager als opdrachtgever namens directie kan fungeren. Daar waar het gaat om contractafspraken komt deze dan weer om de hoek kijken en onderhoudt een nauwe band met de consultant gedurende het gehele proces.
Het feit dat organisaties alles vaak zelf willen doen in te weinig beschikbare tijd is vaak killing voor dit soort activiteiten.
Onze ervaringen (3e generatie outsourcing, >10jaar) is dat een klant/leverancier verhouding door veel uitbesteders wordt ingezet. Dat werkt niet door de gedwongen winkelnering. Een partnermodel is wel bruikbaar; zie de uitbestedingscontractor als verlengstuk van de eigen organisatie. Dat vraagt echt een cultuurverandering.
Als het goed werkt, komt het contract nooit op tafel. Als dat wel nodig is, mag je serieus vragen stellen of sales en delivery binnen de contractor gelijke tred houden.
De oplossing ligt – zoals beschreven in het artikel – inderdaad op twee fronten:
1. Definiëren requirements
Uitbesteders dienen zeer helder, compleet en consistent hun wensen m.b.t. de te realiseren applicatie te documenteren en intern laten valideren door de betrokken ‘domeineigenaren’. Veel bedrijven menen de productie van IT succesvol te kunnen uitbesteden, maar verzaken vervolgens hun eigen organisatie hierop aan te passen. Hoeveel ‘uitbesteders’ hebben een methode ingevoerd welke ervoor zorgt dat er binnen de organisatie een voorschrift bekend is dat ertoe leidt dat er complete, consistente en begrijpelijke requirements worden opgesteld of hebben hiervoor externe hulp ingehuurd?
2. Prototype
De techniek om prototypes te genereren op basis van een volledig in kaart gebracht en gestructureerd model bestaat reeds. Waarom worden er vele Euro’s weggegooid door de outsource-partner applicaties te laten bouwen die niet voldoen aan de wensen van de uitbesteder? Hoe eerder elke fout intern wordt opgespoord, hoe kleiner de financiële consequenties op de lange termijn zullen zijn. Maak dus gebruik van deze mogelijkheid.
Mijn bedrijf PNA Group heeft een methode ontwikkeld, genaamd CogNIAM, welke een voorschrift biedt om dergelijke complete requirements intern op te stellen en het genereren van een prototpye-applicaite mogelijk maakt.
Het volledig geïntegreerd bedrijfsmodel kan aan de outsource-partner overhandigd worden, maar belangrijker is dat alvorens dit te doen op basis van het model – zonder tussenkomst van programmeurs – een werkend prototype van de applicatie kan worden gegenereerd. Dit stelt de uitbesteder in staat om intern het gemodelleerde te valideren en waar nodig aan te passen, nog vóór dat er ook maar een euro aan ontwikkelkosten extern is besteed.
Peter, goed stuk. Het raakt denk ik aan de essentiele key succes factoren in IT (!) outsourcing.
In mijn ervaring, moeten de samenwerkingspartners een paar stappen verder gaan dan waar het in de discussie hierboven om draait. Er moet dieper en langer nagedacht en gepraat worden over ‘hoe gaan we werken’ in plaats van ‘het project’. Bijna alle problemen komen voort uit te snel naar executie overgaan. Zonder stevig proces-fundament kan een complexe samenwerking niet goed gaan. Probleem is dat nu juist bij outsourcing meestal gedacht wordt ‘dat doen we even’ en ‘we gooien het project naar de leverancier en die lost alles wel op’.
Hugo Messer
Ik schrijf regelmatig artikelen over ditzelfde onderwerp: http://www.bridge-outsourcing.com
Bedankt voor alle reacties, mooi dat zovelen mijn opinie delen. Inderdaad heeft Hugo ook gelijk dat je nog dieper kunt gaan. Afgelopen week hebben wij ook een tweedaagse workshop gehad met een klant om elkaar te leren kennen, de problemen van de klanten van onze klant te begrijpen en af te spreken hoe we gaan samenwerken. Wat mij betreft is dit ook een essentieel onderdeel als je gaat outsourcen.