DE
Bij nearshoring hoor ik vaker spreken over risico’s dan over een realistische oplossing voor het nijpende tekort aan goede en ervaren ontwikkelaars en testers.
De top 5 van de risico’s die ik in de afgelopen jaren heb gehoord;
- Wanneer het ver weg is heb ik geen zicht meer wat er gebeurt. Wie garandeert mij dat alles volgens afspraak wordt uitgevoerd en dat alles op tijd klaar is?
- Wanneer ik mijn ontwikkeling buiten de deur breng verlies ik alle kennis en gaat de (toegevoegde)waarde van mijn bedrijf omlaag.
- We hebben slechte ervaringen uit het verleden, dus het werkt sowieso niet.
- Ik weet niet wat het nearshoren van softwareontwikkeling voor effect heeft op mijn organisatie. Hoeveel tijd gaat het kosten, wat betekent het voor mijn mensen en de organisatie?
- Het is een enorm risico, maar ik weet eigenlijk niet goed (uit eigen ervaring) wat dat risico is…
Bovenstaande risico’s zijn reëel en zullen vast en zeker problemen worden wanneer hier niet goed op geanticipeerd wordt. Maar lijken deze niet heel erg op risico’s die u mogelijk binnen uw bedrijf haalt als u werk uitbesteed binnen Nederland, werkt met freelancers of een nieuwe medewerker aanneemt die binnen een jaar weer vertrekt? Het probleem ligt hem niet zo zeer aan het nearshoren, maar aan het uit handen geven van een deel van uw business (en als het goed is niet de controle hierover…). Een goede beheersing van de risico’s is dus in alle gevallen aan te bevelen.
Bezint eer ge begint…
Nearshoring van uw softwareontwikkeling is dus niet iets dat zonder risico’s is, net als andere vormen van uitbesteden (of delegeren) van werk. Vaak is het echter zo dat het ophoudt bij het signaleren van deze risico’s, zonder deze ook daadwerkelijk verder te onderzoeken. Het goed in kaart brengen van de risico’s kan u een goed beeld verschaffen hoe om te gaan met deze risico’s en het pad effenen naar nieuwe oplossingen voor uw tekort aan software ontwikkelaars en/of testers. U kunt bovenstaande risico top 5 ook op een andere manier benaderen:
- Wanneer u bang bent het zicht te verliezen, kunt u (vooraf) afspraken maken over transparantie en rapportage.
- Zorg ervoor dat de basis kennis OOK binnen uw organisatie geborgd blijft en maak daar (contractuele) afspraken over.
- Zoek uit wat de slechte ervaringen waren en leg deze voor aan de nieuwe samenwerkingspartner. Maak het bespreekbaar en inzichtelijk.
- Een ervaren Nearshoring partner kan u vele voorbeelden geven van vergelijkbare situatie bij andere bedrijven. Vraag ernaar.
Een goed onderzoek van wat er mis kan gaan kan veel ellende besparen en inzicht geven hoe het best om te gaan met deze risico’s. Leer van de (slechte en goede) ervaringen van klanten en leveranciers.
Wanneer is nearshoring een reële optie?
Door het in kaart brengen van de risico’s, het opstellen van een plan om deze te managen en dit af te zetten tegen de oplossingen die nearshoring kan bieden, geeft u een antwoord. Dit antwoord heeft u misschien niet in een middag gevonden, maar een ervaren partij, die bereid is een eerlijke analyse van de situatie met u te maken, kan u goed op weg helpen.
Door het nearshoren van softwareontwikkeling kunnen risico’s worden gecreëerd, maar even vaak kunnen er ook risico’s mee worden beperkt. Hierbij kunt u denken aan;
- Betere kwaliteitsborging in uw proces, door een gestructureerde aanpak met een externe partner. Hier kan het toevoegen van Quality Assurance (QA) een belangrijke stap zijn naar meetbare en voorspelbare kwaliteit van uw ontwikkeling.
- Gebruik maken van specialisten op het gebied van softwareontwikkeling. Niet iedereen is goed in alles. Voor een goede ontwikkeling moet er een optimale samenwerking zijn tussen de product owner (opdrachtgever), design (UI/UX) en developers. Het (gedeeltelijk) uitbesteden van de ontwikkeling aan specialisten op dit gebied zou uw ontwikkeling kunnen verbeteren.
- Een betere analyse vooraf (die vaak noodzakelijk is voor uitbesteden).
- Door de leverancier contractueel laten afdekken van risico’s (in termen van tijd en geld bijvoorbeeld).
Meer over hoe nearshoring wel of niet werkt in het MKB en een handige checklist waar u op moet letten? Download hier het whitepaper dat ik hier over geschreven heb.
