-

Hoe risicovol is near- en offshoring?

Aan nearshoring of offshoring kleeft nog altijd een riskant imago. Die angst is onterecht, vindt Eelke Boersma: met de juiste voorzorgen, krijg je betaalbare kwaliteit met minimale risico’s. Zo kan dat. 

We hadden ooit een Indiase freelance-ontwikkelaar. De kwaliteit van zijn code was prima, maar halverwege het project, toen wij hier keihard bezig waren, was hij opeens een week lang onbereikbaar. Dat heeft ons aardig wat leergeld gekost.

Als ik met klanten praat over near- en offshoring, beginnen ze het vaak over dit soort risico’s. Maar met de juiste voorzorgen kan het een echte oplossing zijn voor het acute gebrek aan goede en ervaren ontwikkelaars in Nederland.

Dit is de top-5 van zorgen die ik de laatste jaren hoorde
  1. Als het ver weg gebeurt, heb ik geen idee waar ze mee bezig zijn. Wie garandeert me dat alles volgens afspraak gebeurt en dat het op tijd klaar is?
  2. Als ik het ontwikkelwerk uitbesteed, gaat de know-how de deur uit en keldert de (toegevoegde) waarde van mijn bedrijf.
  3. We hebben vroeger slechte ervaringen opgedaan, dus het werkt gewoon niet.
  4. Het is voor mij echt duister wat voor effect uitbesteden van IT-ontwikkelwerk heeft op mijn bedrijf. Hoeveel tijd vraagt het, wat betekent het voor mijn mensen en voor de organisatie?
  5. Het is een enorm risico. Maar wat voor risico? Dat weet ik eigenlijk niet …

Deze zorgen zijn reëel: zonder goede maatregelen kan nearshoring/offshoring zeker leiden tot problemen. Maar lijken de gevaren niet verdacht veel op de risico’s die je loopt wanneer je werk outsourcet in je eigen land, of werkt met freelancers, of iemand in dienst neemt die binnen een jaar vertrekt? Het probleem zit niet zozeer in nearshoring/offshoring, maar in het overdragen van werk op zich. 

Signaleren zonder analyseren

Nearshoring/offshoring van je IT-ontwikkelwerk is niet zonder risico’s, net als andere vormen van outsourcing of delegeren in het algemeen. Vaak blijven mensen echter hangen in het signaleren van die risico’s, zonder ze kritisch te analyseren. Door de risico’s goed in kaart te brengen, zie je hoe je ze beheersbaar kunt maken. En dan komen nieuwe oplossingen voor je tekort aan ontwikkelaars binnen bereik.

Je kunt de eerder genoemde risico’s ook anders benaderen
  1. Ben je bang het zicht te verliezen, sluit dan vooraf overeenkomsten over transparantie en rapportage.
  2. Zorg dat de fundamentele kennis ook binnen je eigen organisatie aanwezig blijft en leg dit zwart op wit vast.
  3. Zoek uit wat de slechte ervaringen precies inhielden, en leg ze voor aan de de nieuwe samenwerkingspartner. Maak ze bespreekbaar en transparant.
  4. Een ervaren nearshoring/offshoring-partner kan je veel voorbeelden geven van vergelijkbare situaties bij andere bedrijven. Vraag ernaar.
  5. Een goed onderzoek van wat er mis kan gaan, kan je een boel ellende besparen en geeft je inzicht in de beste aanpak om problemen te voorkomen. Leer van de (slechte én goede) ervaringen van klanten en leveranciers.
Wanneer is nearshoring/offshoring een realistische optie?

Door de risico’s in kaart te brengen, een plan te ontwikkelen om ze te beheersen, en ze af te zetten tegen de oplossingen die deze aanpak kan bieden, kom je zelf tot het antwoord op deze vraag. Dit zal je niet in een paar uur lukken, maar nauwkeurige analyse van je situatie door een ervaren partner kan je goed op weg helpen.

Nearshoring/offshoring heeft risico’s, maar die kun je dus minimaliseren

Denk bijvoorbeeld aan de volgende middelen:

  1. Een betere analyse vooraf. Die is sowieso vaak noodzakelijk voor outsourcing.
  2. Kies een bedrijf dat ingericht is op het werken voor West-Europese klanten. We hebben bijvoorbeeld een bestand van zo’n honderd bedrijven in Oost-Europa en India, waarvan we precies weten wat ze kunnen. Dat soort informatie vind je niet met Google of op een website.
  3. Gebruik specialisten in jouw specifieke technologie-stack. Niet iedereen is overal goed in. Een uitstekend product vereist optimale samenwerking tussen de producteigenaar (de klant), de ontwerpers (UI/UX) en de ontwikkelaars. Door ontwikkelwerk gedeeltelijk uit te besteden aan specialisten op een bepaald terrein kun je de kwaliteit van je product vergroten. Hierbij kun je de bedrijfskritische processen intern houden.
  4. Pak de samenwerking met de externe partner gestructureerd aan. Quality Assurance (QA) kan hierbij een belangrijke stap zijn in de richting van meetbare en voorspelbare kwaliteit van je ontwikkelwerk.
  5. Maak duidelijke afspraken over wanneer er gewerkt wordt. Leg alle afspraken vast in contracten, net zoals in Nederland vaak gebeurt. Neem daarin NDA’s (non-disclosure agreements) en SLA’s (service level agreements) op.
  6. Verschuif de risico’s naar de leverancier: als hij bijvoorbeeld te laat levert, betaal jij minder.
  7. Projectmanagementtools zoals PRINCE2 werken heel goed: dan zie je bijvoorbeeld elke twee weken wat er geproduceerd is.
  8. Met afstandstools zoals Skype kun je elkaar geregeld in de ogen kijken. Ga bij langdurige samenwerking een paar keer per jaar op bezoek, of andersom. En denk ook bij bedrijfsuitjes aan je samenwerkingspartners, want uiteindelijk zijn het gewoon mensen.

Deel dit bericht

2 Reacties

Bert van Hijfte - CConsultancy

Niets over de soft skills en culturele competentie en interculturele communicatie in het bijzonder? Uit alle onderzoek blijkt dat daar de grootste problemen ontstaan. Zo simpel als het hier wordt voorgesteld is het in de praktijk bijna nooit.

Eelke Broersma

@Bert van Hijfte Uiteraard zijn dit ook zaken die belicht kunnen/moeten worden. En die wij meenemen in de keuze voor de juiste partner voor onze klant. In dit artikel heb ik echter gekozen meer te richten op de technische kant.

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond