Home Nearshoring risico of onvermijdbaar realisme?

Nearshoring risico of onvermijdbaar realisme?

"Een goede analyse van de risico's met een dito actieplan maakt nearshoring realistisch"

  • Breng de risico's in kaart
  • Analyseer wat het betekent voor uw organisatie
  • Neem maatregelen vooraf, zodat risico's geen fouten worden

Nearshoring risico of onvermijdbaar realisme?
Delen

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;

  1. 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?
  2. Wanneer ik mijn ontwikkeling buiten de deur breng verlies ik alle kennis en gaat de (toegevoegde)waarde van mijn bedrijf omlaag.
  3. We hebben slechte ervaringen uit het verleden, dus het werkt sowieso niet.
  4. 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?
  5. 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 bezorgen 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 hieronder het Whitepaper dat ik hier over geschreven heb.

Literatuurlijst


Freek van Helderen - 07/07/2018

Heel goed geschreven artikel, kan me goed in terug vinden. Nog even het whitepaper doornemen, want zonder een goed stappenplan tast je in het donker.

Hartelijk dank voor je reactie. Wanneer je, na het bestuderen van het stappenplan, nog vragen hebt kun je ons uiteraard ook bellen.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

Wilt u het gehele stappenplan lezen?

Wanneer u ons Whitepaper over hoe nearshoring in het MKB (niet) werkt wilt lezen, kunt u het hier downloaden. Een makkelijke handleiding om te beoordelen of nearshoring iets voor u kan zijn en een stappenplan om goed voorbereid te beginnen.

Bekijk de ontwikkeling van Technosoft

1977 Vandaag
2001
Start verkoop AxisVM
1983
Registratie merk Technosoft
1984
Start ontwikkeling CAD software
2000
Overname activiteiten door Brunel en vestiging in Deventer
2007
Technosoft Duitsland
2009
Technosoft Moldavië
2015
Technosoft Roemenië
1993
Van DOS naar Windows platform
2014
Introductie 3Muri aardbevingssoftware + eerste KOMO certificering
2013
Start Business unit Quality Assurance & testing
2011
Overstap naar Eurocode software
2012
Start van nearshoring onder de naam In-shore
2006
Technosoft door Brunel verkocht door middel van een Management Buy Out
1998
Projectmanagement software