Welke project keuzes maken bij offshore software development?

Offshore software development is vandaag de dag vrij normaal voor veel bedrijven. Desondanks kent het uitbesteden van softwareontwikkeling naar lagelonenlanden, zoals India en Rusland, nog steeds vele valkuilen. In het een eerder artikel heeft u kunnen lezen wanneer u wel of niet moet overgaan op offshore outsourcing.

Belangrijke offshore uitgangspunten zijn:

• De organisatie moet inzien dat het perspectief van lagere kosten slechts een eerste drijfveer is en het grootste voordeel zit in specialisatie, zodat de eigen mensen weer de handen vrij hebben voor hun product.
• Als u inziet dat er een stevige eigen afdeling moet zijn die snapt wat functionele specificaties zijn en deze kan vertalen naar de wens van de organisatie. Men hoeft zich niet meer bezig te houden met vragen als ‘hoe programmeer je nu precies iets in .Net en welke libraries moet je kopen’?

De eigen werknemers kunnen dan uitzoeken welke functies hun klanten precies willen en hoe die functies eruit moeten zien. Door technologie de deur uit te doen, maakt de organisatie een natuurlijke keuze richting markt en gebruikers.

Dit artikel probeert vooral antwoord te geven op de vraag: op welke wijze men een offhore software development beheersbaar kan houden door het maken van de juiste offshore keuzes. Allereerst is het van belang om vast te stellen welke typen van software development projecten voor offshoring in aanmerking komen om dan over te gaan op het selecteren van een geschikte offshore leverancier.

Typen projecten voor offshore software development

Rangorde bij uitbesteden?	Type project
1	Klein onderhoud
2	Systeembeheer
3	Herschrijven kernsystemen
4	Kleine systemen
5	Migratie grote systemen
6	Uitbreiden bestaande applicaties
7	Nieuwbouw applicaties
8	Technische systemen

Rangorde bij uitbesteden van ICT projecten

Het merendeel van software projecten bestaat uit het vervangen of uitbreiden van bestaande systemen, zoals Client Server systemen en een groeiende vraag van back office systemen. Het uitbreiden van deze systemen is vaak geen goede optie omdat de gebruikte technologie daarbij inmiddels te ouderwets en te achterhaald is. Als u ICT investeringen overweegt om redenen van effectiviteit en efficiëntie is dat het moment om over offshore uitbesteding na te denken. Belangrijke overwegingen zijn daarbij:

• Bedrijven hebben vaak te weinig capaciteit om zich met applicatiebeheer bezig te houden: het uitvoeren van kleine wijzigingen (klein onderhoud). Kernvraag is dan of u nieuwe ontwikkelaars wilt aannemen of deze taak offshore uitbesteden?
• Welke taken kunnen nu wel of niet offshore worden uitbesteed?

Klein onderhoud van ICT systemen en outsourcen

Klein onderhoud bij ICT systemen is het herstellen van kleine fouten in een applicatie of het doen van kleine uitbreidingen. Bijvoorbeeld het toevoegen van een veld op een scherm of het aanpassen van een overzicht. Een programmeur is hier enkele uren of zelfs soms een paar dagen mee bezig. Deze vorm van onderhoud laat zich het makkelijkst uitbesteden, omdat er hier sprake is van een strak gedefinieerd bestaand systeem. Verrassend genoeg staat klein onderhoud van ICT systemen bij projectleiders en opdrachtgevers juist onderaan als het gaat om uitbesteding. Vanwaar deze weerstand?

Weerstand bij projectleiders bij uitbesteden klein onderhoud

Deze voornamelijk psychologische weerstand heeft de volgende achtergrond:

• Klein onderhoud is prettig om te doen voor een programmeur, omdat je snel resultaten ziet.
• Klein onderhoud doet de projectleiders goed, omdat ze bedankjes krijgen van de gebruikers.
• Projectleiders kunnen zich niet voorstellen dat een andere partij zonder al te veel inwerktijd toch een systeem door en door kan leren kennen en effectief onderhoud kan doen.
• De projectleider wil snel ingrijpen als er iets misgaat. Dit laatste argument lijkt als enige valide, maar is het niet omdat dit snelle ingrijpen in de praktijk tot chaotische projecten leidt. De snelle oplossing wordt niet goed en integraal getest en leidt weer tot nieuwe fouten. Daarbij keldert de kwaliteit van het systeem dramatisch, terwijl wijzigingen alsmaar langer duren en resteert tenslotte een totaal inflexibel en peperduur systeem.

Klein onderhoud moet projectmatig worden uitgevoerd. Een duidelijk versiebeleid is nodig, net zoals uitgebreide tests en goede installatieprocedures. Dit vermindert de hoeveelheid problemen aanzienlijk. De tevredenheid van gebruikers neemt toe en de kwaliteit en efficiency zijn veel hoger.

Veel gebruikers schamen zich over de kwaliteit van de door hun gebruikte software en dat is niet zonder reden. Bij grote organisaties is de kwaliteit van de legacy data vaak beneden alle peil. Soms treft men cruciale systemen aan waarbij 20% van de historische records feitelijk onjuist is. Records verwijzen of naar de verkeerde personen of er worden onjuiste gegevens bijgehouden. Slechts van ongeveer 5% van de personen in de database klopten alle gegevens.Bij een andere database met tientallen miljoenen records was het nog erger. 50% van de records verwezen naar records die niet bestonden. Een simpele technische test wees dat uit. Van de in het schema opgenomen velden (10.000 stuks) bleek 98% niet te worden gebruikt.

Systeembeheer uitbesteden naar lagelonenland

Systeembeheer is een 2e activiteit die men eenvoudig kan uitbesteden naar een lagelonenland, omdat het een strakke goed gedefinieerde taak is, althans behoort te zijn.
Eigenlijk zitten systeembeheerders altijd in een verliessituatie. Als hun taak wel strak gedefinieerd is, kan die worden uitbesteed. Wanneer die echter niet strak is omschreven, hebben ze hun werk niet goed gedaan. En hun werk staat al onder druk door de toenemende automatisering.

Maar als je systeembeheer uitbesteedt, geldt de gouden regel van outsourcing: de aansturing moet wel in handen van de opdrachtgever blijven. Er kunnen best 20 systeembeheerders in India voor je werken, maar in Nederland moeten er managers zijn die de systeembeheerders aansturen en contact hebben met gebruikers. Zij moeten de kwaliteit in de gaten houden.

Herschrijven van kernsystemen en uitbesteden

Het derde type project dat eenvoudig is uit te besteden, is het herschrijven van kernsystemen. Dit zijn zaken die diep in het operating systeem zitten zoals compilers, optimizers en netwerkprotocollen. De interfaces naar de rest van het systeem zijn louter technisch en vaak redelijk gedefinieerd.

Pas echter op als nieuwe standaards moeten worden geïmplementeerd. Nieuwe standaards van standaardisatieorganen als W3C zijn matig van kwaliteit en geven teveel interpretatievrijheid. Deze organen laten in feite de echte standaardisatie over aan de industrie.

Men kan zich afvragen waarom deze standaards zo matig van kwaliteit zijn. Kunnen deze standaardisatieorganen niet helder denken? Missen ze leiderschap en richting? Bestaan deze organen uit weggepromoveerde managers die vooral gewichtig willen doen en verder niets? Spelen er commerciële en politieke belangen? Zijn ze bewust zo vaag in de specificaties omdat ze verantwoordelijkheid bij implementatie willen ontlopen?

Uitbesteding van kleine software systemen

Uitbesteding van kleine systemen is vaak een aantrekkelijke optie. De laatste jaren is het mode alle software te vervangen door standaard software. Helaas begint veel software steeds meer te lijken op een kerstboom. Om de verkoop te bevorderen worden er steeds meer functies aangehangen. Elk jaar hebben gebruikers langere tijd nodig om de weg te vinden in software pakketten. Uit onderzoek blijkt dan 85% van de gekochte functionaliteit helemaal niet wordt gebruikt.

Besparen op kosten van personeel en licentie ERP systeem

Steeds meer bedrijven uit het MKB laten ICT zelf ontwikkelen. De rekensom is meestal snel gemaakt. Als je voor 50.000 euro investering twee personeelsleden uitspaart, geen licentiekosten meer hoeft te betalen en ook nog sneller je informatie krijgt, hoeft geen enkele ondernemer daar lang over na te denken.

Ook bij grote organisaties gebeurt dit steeds vaker. Door snel een systeem te maken, kan men veel besparen op personeelskosten en licentiekosten van ERP systemen. Bovendien kan men veel effectiever werken, omdat het eigen systeem veel meer een verlengstuk is van de organisatie.

Offshore software development vervangen / migreren van bestaande applicaties (legacy)

Het vervangen van bestaande applicaties is een activiteit die goed offshore kan worden uitgevoerd.
Applicaties moeten om de vijf tot tien jaar worden gemigreerd naar nieuwe technologie. Grote stappen waren bijvoorbeeld de overgang van mainframes naar minicomputers, van minicomputers naar MS DOS en van MS DOS naar Windows. Op dit moment worden de meeste Visual Basic systemen en webapplicaties vervangen door .Net-technologie.

Om commerciële redenen wordt bij het vervangen van applicaties meestal de eis gesteld dat de gebruikersinterface gelijk moet blijven. Hierdoor bemerken gebruikers nauwelijks of niet dat de software is vervangen en zijn zij eerder geneigd de nieuwe versie in gebruik te nemen.
Het effect is dat het nieuwe systeem wordt opgespannen tussen technisch nauwkeurig beschreven interfaces en hierdoor strak gedefinieerd is. Dit proces wordt migreren genoemd en kan met de juiste hulpmiddelen grotendeels automatisch gebeuren.

Eén van de eerste taken na migratie is het technisch opschonen van het systeem. Dat kan de offshore software development leverancier heel goed doen omdat hij het systeem inmiddels door en door kent.

Uitbreiden bestaande applicaties en offshoring software development

Kleine uitbreidingen zijn eenvoudig offshore uit te besteden. Grotere uitbreidingen, die meer op nieuwbouw lijken, zijn wat minder geschikt voor offshoring.

Offshore uitbesteden van nieuwbouw applicaties

Moeilijker om offshore software development uit te besteden is nieuwbouw. Dit wordt veroorzaakt door de onzekerheid over specificaties. Toch zijn sommige offshore organisaties wel degelijk in staat om een geslaagd nieuwbouw project op te leveren.

Nieuwbouw op basis van moderne technologie is voor een offshore leverancier het leukste om te doen. Samen met de opdrachtgever wordt het systeem vorm gegeven en worden elegante oplossingen bedacht. Offshore medewerkers zijn trots als zij erin slagen binnen het budget en de levertijd te blijven. Onzekere specificaties kunnen zo ook als een positieve uitdaging worden opgevat.

Offshore outsourcen van technische systemen

Het moeilijkste bij offshore outsourcen is de nieuwbouw van technische systemen. Bijvoorbeeld PC software die instrumenten aanstuurt of de embedded software in technische apparaten.

Het probleem is de product integratie, de verificatie en de validatie. Hiervoor is het technische apparaat nodig op de offshore locatie. Maar vaak bestaat het technische apparaat nog niet omdat het een prototype in wording is. Of het technische apparaat bestaat wel, maar kan niet verplaatst worden omdat het te groot is of omdat het te veel andere infrastructuur nodig heeft.
Soms is dit probleem te omzeilen door het testen remote (op afstand besturen) uit te voeren.

Validatie binnenshuis houden

Het testen van systemen bestaat uit twee componenten: verificatie (werkt het systeem volgens specificaties) en validatie (zijn de specificaties in orde). Allen verificatie kan offshore worden uitbesteed. Het is echter veel moeilijker om validatie uit te besteden, omdat validatie onderzoekt of de specificaties wel juist zijn en of het systeem wel werkt in de gebruikersomgeving.

Hoofdzaken bij selectie van de offshore software development leverancier

Een opdrachtgever moet bij het selecteren van een offshore leverancier alleen naar hoofdzaken kijken ook al valst dit in de praktijk niet mee bij het ontwikkelen van een nieuwe zienswijze. Opdrachtgevers met ervaring in offshore software development komen tot volgende hoofdzaken:

• Technologische expertise.
• Kosten.
• Flexibiliteit. Hieronder wordt verstaan de bereidheid samen te werken met andere leveranciers en te participeren in het risico van de klant.
• Bestaande relatie met de offshore leverancier.
• Referenties en reputatie.

Een aantal jaren geleden hanteerden bedrijven andere criteria voor de selectie van offshore leveranciers. Toen dachten managers dat domeinexpertise en de grootte van de leverancier van belang waren. Daar zijn bedrijven van teruggekomen. Het is niet meer van belang of een leverancier groot is of dat hij van alle markten thuis is. Het gaat erom dat de leverancier precies die expertise in huis heeft die nodig is om een klus te klaren.

De verkoper beweert…?	Maar bedenk…
93.5% van de projecten is binnen de tijd opgeleverd.	Opleveren is heel iets anders dan testen, accepteren en implementeren.
92% van de projecten binnen het budget.	Hoe kan dat. Fixed price projecten zijn per definitie toch altijd 100% binnen budget.
Uit onderzoek blijkt dat van onze klanten 80% zeer tevreden is en 15% tevreden?	En wie betaalt de onafhankelijke onderzoekers? Wie selecteerde de klanten? Wie selecteert de mensen waarmee de onderzoekers mogen praten??
Wij zaten binnen 3 jaar op de afgesproken Total Cost of Ownership (TCO)?	Dat is niet zo moeilijk omdat het in het contract stond. Meer geld kreeg de leverancier niet.?

Methoden voor selectie offshore leverancier

Er zijn grofweg drie methoden om een offshore leverancier te selecteren:

• Door een raamcontract.
• Door een Request For Proposal (RFP).
• Door een pilot

Offshore software development raamcontract

Grote organisaties sluiten een raamcontract af voordat de eerste projecten van start gaan. Door het raamcontract weet een offshore leverancier waar hij ongeveer aan toe is. Hij kan dan met bepaalde zaken, zoals personeelsbezetting rekening houden. Meestal staat daar geen enkele verplichting voor de opdrachtgever tegenover.

Dergelijke contracten zijn groot en de selectie moet dan ook heel zorgvuldig gebeuren. Een afnemer moet vaak nog een leerproces doorlopen. De eerste keer dat een bedrijf offshore gaat, worden meestal de verkeerde vragen gesteld. Op zich komt het bedrijf wel achter alle feiten, maar het management is niet in staat te beoordelen wat belangrijk is, terwijl het raamcontract met de offhore leverancier al is gesloten.

Request For Proposal (RPF)

Ondernemingen maken vaak gebruik van een Request For Proposal (RPF). Bedrijven nodigen dan andere ondernemingen uit een offerte te doen. Dat kan met en zonder voorselectie van leveranciers.
Maar verwacht niet teveel van het uitsturen van een RFP. Leveranciers weten maar al te goed dat de opdrachtgever eigenlijk al een leverancier heeft geselecteerd en dat een RFP alleen voor de vorm wordt gedaan, waarbij de opdrachtgever ook nog gratis allerlei nuttige tips krijgt.

Offshore pilot project

Veel kleinere bedrijven beperken zich tot een paar leveranciers en kiezen in eerste instantie voor een soort offshore pilot project. Ze kiezen de leverancier die hen het meest aanspreekt. Zo gaat het ook bij kleinere projecten voor grotere organisaties. De energie die anders in een RFP zou worden gestoken, bewaren ze voor het traject met de uitgekozen leverancier.
De eerste stap is het opstellen van de offerte. Deze komt meestal in gezamenlijk overleg tot stand, waarbij meerdere concept offertes de revue passeren. Na de opdracht gaan beide partijen het systeem realiseren.

Tijdens het gezamenlijk offerte stadium blijkt al vaak wat voor vlees je in de kuip hebt. Snapt de leverancier niet wat je bedoelt of luistert hij eenvoudigweg niet, dan kun je er op dat moment altijd mee stoppen.

Verdeel het project in fasen en beding het recht om na elke fase de overeenkomst te beëindigen.

Succesvol managen van offshore software development projecten

Over het managen van offshore software projecten valt nog zoveel meer te vertellen. Dit artikel is de tweede in een reeks over offshoring die de komende maanden gepubliceerd wordt.

Ben u nieuwsgierig geworden en wilt u meer weten over offshore uitbesteden? In het bijzonder het protocol en de voorgang binnen offshore projecten? Kent u nog Hans van Nek, de oprichter van Grote Beer, die zo’n beetje de uitvinder is van structuur achter ICT? Inmiddels is hij directeur van offshore bedrijf Lizatec met een softwareontwikkeling vestiging in het Russische Sint Petersburg. Met inbreng van zijn enorme ervaring heeft hij een glashelder boek over offshoring geschreven met kleurrijke anekdotes. Een boek dat iedere projectleider gelezen moet hebben voor hij aan het hachelijke avontuur offshore outsourcen begint.

Klik hier voor het artikel op managementkennisbank.nl

Discussieer mee op LinkedIn.