Offshore software ontwikkeling: plan van aanpak IT / ICT outsourcing

Elk bedrijf kan offshore software uitbesteden, maar alleen een goed geleid bedrijf kan ICT uitbesteden snel en doelgericht doen. Bij slecht georganiseerde bedrijven kan offshore ICT uitbesteden de problemen bij conversie software alleen maar uitvergroten. Tegelijk bewijst de praktijk dat men niet mag verwachten dat interne managers van meet af aan beschikken over specifieke deskundigheid over bijvoorbeeld conversie software die past bij een complex traject als offshore software ontwikkeling. De juiste inzet van ervaren externe specialisten kan echter zorgen voor organisatorische balans en verankering van expertise binnen de eigen onderneming.

Offshore klant-leverancier relatie? Geeft voordelen op lange termijn

Offshore is meer dan een eenmalige klant-leverancier relatie, het is een relatie die zijn grootste voordelen oplevert op de lange termijn. De gouden regel is zoveel mogelijk offshore te doen, laat ze niet alleen programmeren, maar laat ze ook specificaties uitwerken, ontwerpen, tests uitvoeren en test data maken. Hierdoor groeit namelijk de kennis offshore, en hoe groter de kennis daar is, des te eenvoudiger zijn ze aan te sturen vanuit de eigen organisatie.

Houd er ook rekening mee dat een offshore bedrijf zich in zekere zin spiegelt aan onze organisatie. Wanneer onze organisatie onvoorspelbaar gedrag vertoont, zal ook ons offshore bedrijf onvoorspelbaar worden. Anders gezegd; als we de offshore mensen niet respecteren, zal men ook ons niet respecteren.

Inshore en offshore duidelijke doelstellingen neerzetten

Het is de primaire taak van het management inshore en offshore om gezamenlijk een vertrouwensrelatie met duidelijke doelstellingen op te bouwen. Alle inspanningen moeten we derhalve richten op het vergroten van wederzijds vertrouwen:

• Stimuleer als projectmanager persoonlijke contacten.
• Formuleer als opdrachtgever duidelijke doelstellingen.
• Blijf als eigen organisatie voorspelbaar.
• Stimuleer als contactpersoon respect van de betrokkenen met heldere communicatie.

ICT kosten en offshore projecten beheersen

Offshore is een leerproces, we moeten leren hoe we deze projecten en ICT kosten moeten beheersen. Offshore projecten moeten slagen.

Basis opzet offshoring

1. Begin klein.
   Hoe groter een project, des te groter de kans op mislukking. Het is daarom het meest praktische om klein te beginnen, waarbij we eerder moeten denken in de Euro 20.000 tot 200.000 range.
2. Veranker het leerproces in de organisatie.
   Dit houdt dus in dat eigen vaste staf betrokken moet zijn bij het project, en dat we hierna vanuit deze kern van ervaren mensen nieuwe projecten kunnen starten.
3. Actieve betrokkenheid van het management.
   Stel bovendien een stuurgroep in, en houd regelmatig overleg met alle betrokkenen.

Er wordt veel geschreven over de selectie van offshore projecten, maar in de praktijk kost het weinig moeite één of meerdere projecten te selecteren die we extern kunnen uitvoeren. Het eerste project is dan ook meestal een uitbreiding of vervanging van een bestaand systeem.

Belangrijke aandachtspunten bij het opzetten van een offshore project

• Selecteer een belangrijk systeem, het is namelijk de bedoeling een echte leerervaring op te doen.
• Het systeem moet echter niet teveel interfaces hebben met andere systemen die in beweging zijn.
• Als we het onderhoud van een bestaand systeem uitbesteden, moeten we zorgen voor een ‘clean break’. Vanaf een bepaald moment mogen we intern geen onderhoud aan het systeem doen, alle onderhoud moet namelijk extern gebeuren.
• Selecteer zorgvuldig het eigen personeel. Leergierigheid, avontuur en inzet zijn belangrijke succesfactoren.

Kies een systeemontwikkelbedrijf met track record

Als groot bedrijf is het zinvol met meerdere offshore bedrijven in zee te gaan. Hierdoor versnelt namelijk het leerproces. Best Practice, het houdt de offshore systeemontwikkeling bedrijven scherp en bovendien hun prijsstelling concurrerend.
Beginnende offshore bedrijven zijn charmant, maar het is beter dat ze hun ervaring bij een andere klant opdoen. Dus selecteer een systeemontwikkeling bedrijf met een track record. Ervaren offshore bedrijven hebben meestal een groter probleemoplossend vermogen dan beginnende bedrijven, men heeft ervaring met grote Westerse bedrijven. Bij deze selectie is het volgende van belang:

Kies duidelijk aanspreekpunt met bevoegdheden

Veel offshore bedrijven hebben een onduidelijke structuur. Men heeft bijvoorbeeld in Europa een intermediair of verkoop organisatie met onduidelijke taken en bevoegdheden. Bij bedrijven met een offshore tak zijn we vaak een vragende partij. Men is tevens afhankelijk van de medewerking van zusterbedrijven of het moederbedrijf. Hoe groter het software bedrijf, over hoe meer schakels dit kan lopen.

Kies duidelijke communicatie structuur bij offshore software ontwikkeling

Een heel belangrijk punt is hoe eenvoudig de communicatie bij software ontwikkeling verloopt met de mensen die het werk moeten uitvoeren. Gaat dit eenvoudig, snapt men meteen wat er moet gebeuren, stelt men relevante vragen?
En weten we zeker dat dit één van de mensen is die het werk gaan uitvoeren of leiden, of is het slechts een intermediair?

Systems in place

Een offshore bedrijf moet beschikken over systemen? voor:

• Versie en change management.
• Publiceren van software, inclusief oplever protocollen.
• Project Management en procedures.

Offshore problemen door bereikbaarheid en tijdverschillen

Tijdverschillen en bereikbaarheid zijn in het begin niet zo belangrijk. Maar op een gegeven moment kan dit een onoverkomelijke barrière worden met aanverwante problemen.

In Rusland is er twee uur tijdverschil, maar alle kantoren beginnen twee uur later dan normaal. Dus met het westelijk gedeelte van Rusland is er in de praktijk geen tijdverschil.

Er is met India en China vooral aan het begin van de dag directe communicatie mogelijk. Gezien vanuit het offshore land betekent dit echter dat alle vragen moeten wachten tot het eind van de dag.
Gezien vanuit Europa betekent dit eveneens dat alle problemen die na 9 respectievelijk 11 uur gebeuren, pas de volgende dag in behandeling kunnen worden genomen.

Niet relevante zaken bij selectie offshore softwareontwikkeling partner

• Het bedrijf heeft een mooi kantoor.
  Fantastisch, maar we willen geen mooie kantoren, maar software. Voor mooie kantoren betalen we dubbel: de kosten van het kantoor + de hogere salarissen van de medewerkers.
• Ervaring met een specifieke technologie.
  Als we medewerkers via detachering inhuren willen we direct inzetbare mensen hebben. Bij offshore is dat echter niet relevant. Alle modern ontwikkelde omgevingen lijken sterk op elkaar, men is veel sneller dan de gemiddelde Nederlandse programmeur in staat zich snel in te werken in een andere technologie. Bovendien heeft men genoeg tijd over tussen maken van functionele specificaties en start van programmeren om zich een ontwikkelomgeving voldoende eigen te maken
• Domein ervaring.
  We moeten juiste bedrijfsspecifieke domein ervaring inbrengen, onze offshore partner alleen technische kennis. Domein kennis bij onze partner is alleen relevant als we niet alleen de IT ontwikkeling, maar het hele Business Process overbrengen.

Nog meer irrelevantie

• Risico’s in het betrokken land.
  Alle offshore landen zijn risicovol, hoe risicovol is echter niet te voorspellen. De manier om risico’s te vermijden is meerdere bedrijven te selecteren verspreid over verschillende continenten.
• Verkoopkantoor betrokken land.
  In de praktijk doet een verkoopkantoor alleen verkoop, en kan bovendien weinig doen voor het bijsturen van het operationele proces. Men heeft niet de kennis en onvoldoende macht binnen de eigen organisatie.
• Het offshore bedrijf zit in een leuk land, waar het prettig toeven is.
• Wij werken als u slaapt argument.
  Offshore bedrijven in India en China zijn zich goed bewust van het nadeel van al de tijdverschillen. Dus verpakken zij dit nadeel in ’24 uurs ontwikkeling’ argumenten. Maar hoe we het ook verpakken, het nadeel van het tijdverschil blijft, en niemand kan langere tijd meer dan 8 uur per dag effectief werken.
• Actieve steun van de Nederlandse ambassade of consulaat.
  Echter, in alle landen worden Nederlanders actief gesteund door de ambassade of consulaat.

Offshore contract software systeemontwikkeling

Een offshore contract afsluiten met een offshore bedrijf over offshoring software systeemontwikkeling in een niet westers land is tijdverspilling. Alleen met westerse bedrijven is het zinvol een juridisch sluitend contract af te sluiten, deze contracten kunnen we wel afdwingen. Maar dan in de praktijk ook alleen maar als het Westerse bedrijf het offshore bedrijf controleert.

Als we niet in de luxe verkeren met een controlerend westers bedrijf een contract af te sluiten is de enige mogelijkheid om in begrijpelijke taal te communiceren wat we precies verlangen.
Maak makkelijk leesbare afspraken en spreek die rechtstreeks (!), punt voor punt door met de manager offshore. Deze krijgt dan tegelijk een goed idee over de cultuur van de klant, waar we de nadruk op leggen, en wat we minder belangrijk vinden.

Invulling van offshore contract en tips

Fixed price afspraken contract, een aanrader

Offshore leent zich uitstekend voor fixed price ontwikkeling. Dit heeft bijkomende voordelen van hogere kwaliteit, lagere prijs en minder meerwerk achteraf. Zowel opdrachtgever als offshore bedrijf worden gedwongen, voordat iets wordt ontwikkeld, eerst specificaties te maken.

Geen offshore contract op basis van nacalculatie bij offshoring

Ga nooit akkoord met een offshore bedrijf dat capaciteit beschikbaar wil stellen voor een aantrekkelijk uurtarief, en projecten primair op nacalculatie wil uitvoeren. Door de ruime vraag en geringe aanbod proberen de laatste tijd sommige offshore bedrijven de klant hiertoe te verleiden. Met behulp van prachtige termen als ‘dedicated offshore centre’. ‘manage their work as if it are your own employees’ verkoopt men dit op een commerciële manier. Houd er rekening mee dat men soms veel meer uren op kantoor aanwezig is dan in Europa, maar dat dit niet altijd productief is. Programmeurs kunnen nu eenmaal gedurende langere tijd niet meer dan 40 uur per week effectief werken.

Financiële reden

Maar er is ook een harde financiële reden dat we nooit akkoord moeten gaan. Nee, het grote lek zit er niet in dat er met een vork wordt geschreven. Dat is iets dat men offshore niet snel zal doen, en dat hoeven ze ook helemaal niet te doen.
Het grote lek is dat men bij nacalculatie de langzaamste programmeurs op onze projecten inzetten. En de betere programmeurs zetten ze in voor andere klanten, die wel zo slim waren om alleen fixed price te willen werken.

Service Level Agreement deels vergoeden

Voor ondersteuning na oplevering kunnen we een Service Level Agreement (SLA) afsluiten. In een dergelijke Agreement regelen we wat de reactietijd op ondersteuning en gewenste wijzigingen is, en hoeveel mensen in principe beschikbaar moeten zijn om deze ondersteuning uit te voeren. Deze kunnen, als er geen werk is andere taken uitvoeren, dus we moeten nooit de volledige kosten vergoeden van de beschikbare capaciteit. Een kostenvergoeding is echter noodzakelijk, want als er een probleem is, of we willen een wijziging uitvoeren, dan moeten we wel prioriteit krijgen.
En ook hier geldt: nooit wijzigingen op nacalculatie laten uitvoeren, maar altijd op basis van vooraf opgegeven vaste prijs.

Duidelijke opzegmogelijkheid van contract

De loonkosten van offshore bedrijven stijgen jaarlijks met een behoorlijk percentage. Het offshore bedrijf zal dan ook geregeld zijn prijzen moeten verhogen. Neem in het contract op dat we dan het contract kunnen opzeggen.

Intellectueel eigendom goed vastleggen

Regel natuurlijk het intellectueel eigendom. Dat hoort bij de opdrachtgever, en moet geregeld worden overgedragen. Sluit om deze reden contracten af volgens het Nederlands Recht, dan weet we waar we aan toe zijn.

Toestemming en Escrow regeling bij inzet van derden

Als in een project componenten van derden worden ingezet, wat extra licentie kosten tot gevolg heeft, moet het offshore bedrijf vooraf toestemming vragen. Als het essentieel is, regel dan via een Escrow regeling de toegang tot de sources van de componenten. De kosten van Escrow worden dan altijd door de opdrachtgever gedragen.

Leesbare werkafspraken voor offshore personeel

De medewerkers offshore – en vaak ook het? eigen personeel – kunnen juridische documenten niet lezen, en gaan ervan uit dat het niet op hen slaat. Zorg daarom altijd voor leesbare werkafspraken voor offshore personeel en eigen personeel. Deze moeten niet te lang zijn, want niemand kan alle regels van een 50 pagina’s lang document operationeel in zijn hoofd houden. Wees duidelijke en beknopt, en beschrijf alleen de hoofdlijnen.

In de werkafspraken moeten we een evenwicht vinden tussen vertrouwen en controle.

Functionele specificaties inshore en offshore eisen

Eerst is het nuttig twee misverstanden te noemen rondom functionele specificaties inshore en offshore:

• Specificaties voor offshore is NIET hetzelfde als een functioneel ontwerp. Specificaties bevatten veel minder. Ze zijn noodzakelijk om een contract te kunnen sluiten tussen een offshore partner. Een Functioneel Ontwerp maken we gezamenlijk, inshore en offshore.
• Specificaties zijn ook NIET hetzelfde als een outsource overeenkomst. In een dergelijke outsource overeenkomst zijn namelijk meestal alleen procedures, meetcriteria en globale eisen opgenomen.

Leg alle offshore communicatie vast

Een gouden regel bij het maken van specificaties is dat we alle specificaties moeten vastleggen. Op dit punt heeft offshore zijn grootste voordeel: Van het ver weg zitten en van het nadeel van indirecte offshore communicatie wordt een voordeel gemaakt.

Van essentieel belang – dit kan niet genoeg benadrukt worden – is alle mondelinge en telefonische afspraken ook te bevestigen per e-mail. Breng hier vanaf het prilste begin de nodige discipline in.?

Train medewerkers inhoudelijk op maken specificaties

Het kan nodig zijn de medewerkers te trainen in het maken van specificaties. Het gaat hierbij niet om het aanleren van techniekjes (als UML) of een methode (als Prince2), maar om inhoudelijk te herkennen wat goede specificaties zijn, en hoe deze te beschrijven.

kernpunten offshore specificaties

Offshore specificaties moeten minimaal bevatten:

• Een beschrijving van het doel en gebruik van het systeem.
• Een beschrijving van het gegevens model. Dit hoeft nog niet helemaal precies te zijn, ze moeten echter zodanig zijn beschreven dat ze zijn uit te werken. Bijvoorbeeld “NAW gegevens” is voldoende, we hoeven niet precies te vermelden wat type en grootte zijn van de verschillende velden.
• Een beschrijving van alle niet triviale functies.
• Een beschrijving van de belangrijkste algoritmen en processen.
• De beschrijving van de interfaces met andere systemen.
• Een beschrijving van de technische omgeving: welke platforms, welke database systemen? Performance criteria, welke functies zijn cruciaal?

Herkennen van onjuiste offshore ICT specificaties?

Onjuiste offshore ict specificaties bevatten de volgende proces elementen:

• Commerciële ruis.
  Veel functioneel ontwerpen bevatten ruis: een soort reclame verhaal waarom het nieuwe systeem zo mooi is.
• Technologie beslissingen.
  Laat deze zoveel mogelijk beslissingen over aan de offshore partner.?
• Stilzwijgen.
  Sommige belangrijke aspecten worden niet genoemd.
  We kunnen hier achter komen door een lijst te laten geven van dingen die niet genoemd zijn in de specificaties.
• Over specificatie.
  Vooral ex-programmeurs hebben hier last van. Ze beschrijven het systeem in termen van oplossingen, niet wat er moet gebeuren. Deze ex-programmeurs moeten we trainen in het maken van functionele specificaties. Functionele specificaties bevatten bijvoorbeeld normen voor user interfaces, maar niet een beschrijving van elke user interface.?
• Controle maar geen inhoud.
  De specificaties gaan voor het grootste deel over de gebruikte methode, over taken en bevoegdheden van de medewerkers, regels voor change management, performance, evaluatie criteria, meetmomenten, rapportages etc. Dit is heel nuttig en noodzakelijk, maar dit zijn geen specificaties.

Onjuiste offshore ict specificaties bevatten de volgende inhoudelijk elementen:

• Contradictie.
  Er zijn tegenstellingen tussen verschillende onderdelen. Hoe gedetailleerder de specificaties, des te groter de kans op contradictie. Daarom zijn goede specificaties volledig en beknopt.
• Alleen schema’s of alleen tekst.
  Functionele specificaties die voor het grootste deel uit schema’s bestaan zijn vaak onbegrijpelijk voor programmeurs, en zijn multi-interpretabel. Omgekeerd zijn specificaties die alleen uit tekst bestaan op sommige punten niet gedetailleerd genoeg. Goede specificaties bestaan voor het grootste deel uit tekst, aangevuld met illustraties op een aantal punten.
• Dromen.
  Er zijn dingen gespecificeerd die niet voor redelijke kosten zijn te realiseren. Bijvoorbeeld web interfaces met client server functionaliteit, platform onafhankelijkheid terwijl platform afhankelijkheden zijn ingebouwd, of onmogelijke performance eisen.
• Multi-interpretabel.
  Iets kunnen we op meerdere manieren uitleggen. Vooral medewerkers met een niet technische achtergrond zijn hier goed in.

Interactief samenspel en complete specificaties inhore en offshore

Complete specificaties komen tot stand bij een interactief samenspel tussen inshore en offshore.
Inshore specificaties moeten net voldoende zijn om offshore verder te werken. Te veel specificaties kosten uren van inshore medewerkers, te weinig specificaties leiden tot teveel communicatie over en weer.
Natuurlijk kunnen we in theorie alle specificaties inshore maken, het hele systeem kunnen we inshore maken. Maar dit heeft een aantal voor- en nadelen:

1. Het kost meer geld. Medewerkers offshore kosten minder.
2. Functionele kwaliteit. In een vroeg stadium kunnen we testen of men het allemaal wel begrepen heeft.
3. Technische kwaliteit. Men kan offshore vaak iets beters bedenken omdat men meer verstand heeft van de technologie.
4. Know how overdracht. Door ook offshore medewerkers te betrekken wordt een stuk van de know how overgedragen.

Voorbeeld?  specificatie met juiste balans inshore en offshore? 

Als onderdeel van het toekomstige systeem is een functie gemaakt voor het beheer van de gegevens van tabel A.
Elders in de specificaties is al beschreven hoe de database in elkaar zit, en hoe ongeveer een standaard invoer scherm eruit ziet.
Inshore is nu één regel genoeg: “Functie beheer gegevens tabel A”.
Voor het doen van een prijsopgave weet nu het offshore bedrijf voldoende.

Na opdracht kan men offshore een nadere beschrijving maken: een lijst met alle velden die moeten worden getoond, compleet met validatie en aanwijzingen voor zoeken. Een tekstuele beschrijving is echter voldoende, we hoeven geen plaatjes te maken.

In dit voorbeeld hoeven niet ook nog een technisch ontwerp te maken, de functionele beschrijving is voldoende om met de juiste tools aan het werk te gaan.

Testen user interface

Na goedkeuring van de opdrachtgever kan de functionele beschrijving dan ook direct worden omgezet in een programma. Men maakt een user interface, en deze test het Offshore bedrijf intern.
Na eerste aflevering checkt men inshore of alles werkt zoals de bedoeling was, en zo niet kan men het nog aanpassen.
Waarom mag men offshore nu niet meteen beginnen met programmeren? De reden is voortschrijdend inzicht. Tijdens het detailleren van het Functioneel ontwerp kunnen zowel inshore als offshore medewerkers erachter komen dat een veld is vergeten. Dit wordt dan alsnog toegevoegd aan de database en user interface. Het is natuurlijk nauwelijks extra werk als dit extra veld wordt toegevoegd tijdens de Functionele Fase. Als het echter pas ontdekt wordt na aflevering is het veel meer werk in de user interface, op zijn minst moeten velden worden herschikt, en soms moeten hele user interfaces gesplitst worden naar meerdere schermen.

Specificaties expliciet maken

Wees er zeker van dat specificaties de juiste specificaties zijn:

• Check specificaties, check technisch ontwerpen.
• Keur altijd specificaties expliciet goed of af.?
• Manage specificaties changes.? The never ending specification story.

Ontwerpmethode

Ontwerptechnieken als rapid prototyping, extreme programming en agile development kunnen worden gebruikt. Maar door de hoge interactie die hierbij nodig is, ligt het niet erg voor de hand.

Wel kunnen ideeën uit deze methoden met succes offshore worden ingezet:

• Het gebruik van test scripts draagt bij tot begrip offshore
• Gebruik geïntegreerde builds van systemen om feed-back te krijgen
• Hou geregeld korte online status meetings. Dit kan per email, telefoon of IM.?
• Gebruik korte interactie slagen tussen builds. Typische iteratie is wekelijks of twee wekelijks.
• Vaste aflevertijdstippen van builds.

Nadelen als inshore detachering te lang duurt

Het is op het eerste gezicht verleidelijk om offshore medewerkers inshore te detacheren, en hun te laten zorgen voor de communicatie. Natuurlijk kan dit in het begin voor een paar weken nuttig zijn. Op permanente basis heeft inshore detachering echter een aantal nadelen:

• We krijgen niet de beste mensen.
• De beste mensen zijn natuurlijk offshore nodig om de boel aan te sturen.
• We maskeren de problemen in de eigen organisatie.
  Er is geen reden waarom iemand van de eigen organisatie deze mensen niet kan aansturen.
• Het leereffect voor de eigen organisatie stellen we uit.

Natuurlijk willen de meeste offshore bedrijven dit graag, Het traint hun medewerkers, waar nog voor betaald wordt ook. Het geeft de mogelijkheid zich dieper te nestelen in de organisatie van de opdrachtgever, het geeft de mogelijkheid om onmisbaar te worden. En op een gegeven moment is het offshore bedrijf echter nog de enige organisatie die begrijpt hoe de systemen werken.

Verankering ICT met offshore outsourcing consultant

Het is belangrijk de ervaringen in één project te verspreiden in de organisatie. Anders gaat men overal het wiel opnieuw uitvinden.
Ook van belang is, dat de inshore en offshore medewerkers elkaar persoonlijk kennen, en leren elkaar te respecteren. Zorg ervoor dat beide partijen elkaar regelmatig bezoeken. Bij dit proces is een deskundige begeleiding noodzaak.

Resumerend zijn hier de belangrijkste zaken:

• De primaire taak van het management zowel inshore als offshore is het vergroten van het wederzijds vertrouwen en de succesfactor bij dit complexe proces is een deskundige begeleiding.
•  Laat zoveel mogelijk offshore doen. Laat specificaties offshore uitwerken.
• Zorg voor regelmaat, voorspelbaarheid en controle.
• Doe alles fixed price.

Klik hier voor het oorspronkelijke artikel op managementkennisbank.nl.

Discussieer mee op LinkedIn.