Inmiddels ben ik 22 jaar werkzaam in de ict-industrie en ondanks alle goede bedoelingen is Nederland nog steeds een detacheringsland. In mijn jonge jaren, zo’n vijftien jaar geleden, sprak ik als accountmanager al met klanten over het outsourcen van applicatiebeheer en het aangaan van een resultaatverplichting bij bouwtrajecten. Smalend werd in die tijd al gesproken over ‘uurtje/factuurtje’, of wat netter ‘time and material’. Het leek alsof de ict-industrie niets anders wilde en de klantorganisatie niet anders kon.
In de jaren negentig zijn de Anglo-Saksische landen ons voorgegaan bij het outsourcen van ict en het neerleggen van een resultaatverplichting bij de ict-leveranciers. Alleen in Nederland zijn we nog niet veel verder gekomen dan het grootschalig uitbesteden van het beheer van infrastructuren. Op het gebied van applicatieontwikkeling en -beheer wordt nog steeds aarzelend gekeken naar uitbesteding en wordt er regelmatig verslag gedaan van het feit dat uitbestedingen, zeker in samenhang met offshore, niet vanzelfsprekend een succes zijn.
Het appplicatiebeheer zal vaak samen gaan met het offshoren hiervan. Immers, als de klant wil dat de ict-leverancier het goedkoper kan met behoud van kwaliteit, dan is transformatie van onshore naar offshoren een must. Ook bij applicatieontwikkeling wordt gebruik gemaakt van offshore capability. Offshore capability die vaak op het allerhoogste niveau is gecertificeerd (CMMI Level 5). Offshore capability met goed opgeleide en sterk gemotiveerde mensen. En toch lukt het gewoon niet altijd. Er zijn situaties bekend dat een paar honderd Indiaase ict'ers maanden naar Nederland moesten komen omdat een cruciaal project bij één van Nederlands grootste banken dreigde vast te lopen.
En zo hebben we na al die jaren nog steeds de situatie dat in de ict-servicesindustrie circa 4 miljard euro wordt uitgegeven aan applicatieontwikkeling en – beheer, waarvan circa 70 procent op basis van detachering en dus vrijwel allemaal in Nederland worden uitgevoerd. Waarom lukt het ons nog steeds niet om die resultaatverplichting aan te gaan? Hiervoor is een aantal redenen aan te geven:
– Detachering is flexibel. De opdrachtgever zit niet vast aan commitments die vaak voor langere periode worden aangegaan bij contracten met een resultaatverplichting.
– De regiefunctie bij de opdrachtgever is nog niet goed ontwikkeld. Als je een resultaatverplichting wilt neerleggen bij een derde partij, dan dient heel duidelijk te zijn wat dat resultaat dan moet zijn en hoe het changemanagementproces naar de leverancier is ingericht.
– Angst voor het onbekende. De mislukkingen met uitbesteden boezemen angst in en leiden tot de vermeende veilige weg van het zelf doen met inhuurkrachten.
– De kalkoen moet het menu voor de kerst vaststellen. De cio moet zijn grote ict-afdeling van de hand doen en zich als regisseur en intermediair opstellen tussen de business en de ict-leverancier. Niet alle cio's willen of kunnen dit.
Bovengenoemde redenen zijn reëel en moeten niet gebagatelliseerd worden, maar ze lossen niet vanzelf op. Zelfs in tijden van zware bezuiniging op ict-budgetten zien we geen fundamentele verandering van het aanbestedingsmodel. Wel wordt er minder gedetacheerd en ingehuurd, maar niet als gevolg van een transformatie naar resultaatverantwoordelijk aanbesteden. Er wordt gewoon minder ingehuurd. Toch is er hoop en ligt er een evolutionaire verandering in het verschiet. Dat is ‘detacheren op afstand'. Dit is de lang gezochte ‘missing link' in de ontwikkeling van de ict-industrie in de volgende fase van het volwassen worden.
Voor bijvoorbeeld een bouwtraject houdt ‘detacheren op afstand' in dat de externe ict-leverancier een team met een aantal goede ontwikkelaars ter beschikking stelt van de opdrachtgever. Het peoplemanagement wordt gedaan door de externe leverancier en de inhoudelijke aansturing door de projectleider van de klant (desgewenst ondersteund door degene die het peoplemanagement doet). Op dagelijkse basis staat de projectleider met het team in contact via conference calls, Skype, Sharepoint, etc. Op periodieke basis gaat de projectleider naar zijn team toe voor de oh zo belangrijke persoonlijke contacten.
Zeker als deze vorm van detachering gedaan wordt met een nearshore-oplossing (bijvoorbeeld Oost-Europa) is dit goed werkbaar. Er zijn geen tijdsverschillen, de vliegafstand is goed te doen (Amsterdam-Belgrado is slechts twee uur vliegen, er gaan per dag drie rechtstreekse KLM-vluchten naar Kiev, etc.), de projectleider heeft geen last van een jetlag en hoeft geen dagen in een duur hotel te zitten. Daarnaast zijn de cultuurverschillen tussen Oost-/Centraal-Europa en Nederland goed hanteerbaar, waardoor communicatie effectiever is en een goede basis is voor het model van detachering op afstand.
Dit betrekkelijk eenvoudige model creëert met een geringe inspanning een enorme besparing van minimaal 40 tot 50 procent en veelal nog wel meer. Tevens zorgt dit model ervoor dat de klant zijn regiefunctie kan ontwikkelen en de ict-leverancier en de klant in hun relatie kunnen groeien die ook een resultaatverplichting aan kan. Alleen op een heel vanzelfsprekende, evolutionaire wijze, die direct kostenbesparend is.
Ik wil een pleidooi houden voor het Darwinistische principe van evolutionaire ontwikkeling via de ‘detachering op afstand'. Ik zie dit met name in Oost-Europa als zeer kansrijk en hoop dat ik over vijftien jaar kan zeggen dat Nederland detacheringsland-af is en via de evolutionaire stap van ‘detachering op afstand' een land is geworden waar we op zakelijke wijze een effectieve resultaatverplichting met elkaar aan kunnen en willen gaan!
Paul Schuyt
Chief Executive
Levi9 Global Sourcing
Dit betrekkelijk eenvoudige model creëert met een geringe inspanning een enorme besparing van minimaal 40 tot 50 procent en veelal nog wel meer.
Tot zover de sales pitch … nu alleen nog wat concrete feiten, gedocumenteerde cases of andere verifieerbare bewijsvoering ;-). Tot zover herinneren deze boude beweringen sterk aan de verhalen over India van 2000-2005 (voordat de tarieven daar een aantal malen verdubbelden en bleek dat de CMM-level 5 bedrijven hun oorspronkelijke tien briljante ingenieurs allemaal al lang hadden moeten inruilen voor honderden gemiddelde schoolverlaters).
Zeer verstandig artikel
Klinkt mooi allemaal. Maar dan de vraag “wat doen we met de mensen die nu gedetacheerd worden in Nederland?” Als die allemaal werkeloos worden rijzen de kosten voor uitkeringen de pan uit, wat indirect ook weer betaald moet worden.
Hoe harder er genearshored naar O Europa wordt, des te sneller zullen de tarieven daar stijgen…
Of het nu in India, Oost-Europa of in Nederland zelf gebeurd, ontwikkeltrajecten op afstand zijn altijd zeer moeilijk te managen en vaak op voorhand gedoemd te mislukken. Dit ligt niet aan onkunde of onwil van het Nederlandse bedrijfsleven maar eerder aan het feit dat communicatie over een grote afstand, groter dan face to face, erg onderhevig is aan verschil in interpretatie. Hiermee wil ik niet zeggen dat er bij face to face communicatie geen verschil in interpretatie is of kan zijn maar het is in ieder geval makkelijker te herkennen en bij te sturen. Wat face to face in vijf minuten uitgelegd kan zijn, kan zomaar een uur duren per telefoon, MSN, Email, etc. Daarnaast is er nog de taalbarrière, wij Nederlanders verstaan over het algemeen wel redelijk Engels maar een goede conversatie is er over het algemeen niet bij tel daar bij op het gebrekkige dialect-Engels in de out-source landen (ja, ook in India) en de fundering voor een ramp is zo goed als compleet.
Ook het verschil in cultuur, hoe klein ook, leidt negen van de tien keer tot misinterpretatie van de gevraagde functionaliteit wat weer leidt tot langere doorlooptijd wat uiteindelijk de opgeleverde besparing op uurtarief weer te niet doet. Deze misinterpretatie is, naast de taalbarrière, vaak ook te herleiden naar het gemis van domein/branchekennis. Off-shore outsourcingspartijen zijn over het algemeen niet meer dan grote coderingsfabrieken met wellicht een gedegen kennis van de ontwikkeltaal maar waar enige vorm van domein/branche specifieke kennis ver te zoeken is. Dit is waarom on-shore aanwezigheid zo belangrijk is, fouten kunnen zo vroegtijdig afgevangen en gecorrigeerd worden.
Een ander aspect is het niet goed of onvolledig opstellen van de functionele requirements. Meer dan eens wordt er tijdens het opstellen van de requirements niet of nauwelijks nagedacht over de bedrijfsprocessen maar wordt er gekeken naar wat er op het scherm moet komen te staan of nog erger er is geen budget om een goed functioneel ontwerp op te zetten, immers we willen allemaal zo snel mogelijk iets tastbaars hebben in de vorm van een werkende applicatie. Een goed functioneel ontwerp is uiteraard van groot belang om in een ontwikkeltraject tot een goed eindresultaat te komen en bepaald uiteindelijk de kwaliteit en bruikbaarheid van een applicatie. Maar bij outsourcingstrajecten is dit van levensbelang, dat wat je vraagt krijg je tot op de letter nauwkeurig opgeleverd niks meer en niks minder.
Onder andere de combinatie van onvoldoende functionele beschrijving, misinterpretatie van deze functionaliteit, de taalbarrière maar ook het gebrek aan dagelijkse aansturing van het team door een domeindeskundige is een goed recept voor het mislukken van outsourcingsprojecten.
Mede hierdoor zie ik eerder de huidige trend van het in-sourcen op detacheringbasis toenemen dan afnemen in de komende jaren.
Volgens de cijfers (en volg het nieuws) en de
wandelgangen binnen grotere bedrijven, welke hun ICT-beheer en development uit besteden blijkt toch dat wat dat wat er wordt aangekocht, afgesproken in de de zo mooie (resultaat verplichtingskontrakten) niet wordt geleverd wordt, de prijzen blijven de pan
uitrijzen en daarnaast wordt de klant niet bediend zoals hij/zij bediend zou moeten worden. Zelf de grote in-sourcingspartijen met hun connecties, dochter maatschappijen in het Oostblok danwel in India leveren veelal niet wat is afgesproken, om het over de communicatie over en weer nog maar niet hebben.
Ik denk namelijk dat het de Grootste fout is die deze bedrijven kunnen maken, namelijk dat zij hun ICT-gerelateerde zaken de deur uit doen! En hierdoor volkomen overgeleverd raken aan de uitvoerende partijen, zij hebben hierdoor veelal geen zeggenschap meer over hun eigen diensten en produkten.
En ik heb nog geen enkel bedrijf gehoord
die met zo’n beslissing geld gewonnen heeft
( zeg maar besparing) en al helemaal geen die een
die er uberhaupt baat bij heeft( de tevredenheidsfactor)! Kortom, het is al moeilijk genoeg
om met elkaar te communiceren als bij elkaar we elkaar live(face to face)aan tafel zitten, laat staan even skypen tussen twee partners welke beide
niet in hun eigen/moeders-taal communiceren.
Allemaal mooi voor in het boekje theoretisch klinkt het
prachtig, maar loop eens bij zo’n bedrijf
binnen, welke zogenaamd zo modern en veel
goedkoper heeft uitbesteedt.
Je zou er bijna medelijden mee krijgen! En nog maar te zwijgen over de uitbesteding naar de Nederlandse grote softwarehouses en system integrators, zelfs dat gaat in bijna van alle gevallen al niet van een leiendakje. Nee pas op de plaats , hand op de knip en uitgeven aan daadwerkelijke “kennis” die in huis haalt en
kan controleren en kunt aanspreken op hun
kwaliteit.
Ik pleit voor Nederlandse kennis en kwaliteit er is genoeg beschikbaar en ook tegen een competitieve tarieven.
Bedrijven zouden zich alleen niet moeten verlaten op een handje vol aanbieders, welke pretenderen de wijsheid in pacht te hebben. Groot in aantallen, zegt nog steeds niet over de kwaliteit.
Misschien kan iemand hier een cursus voor ontwikkelen om dat besef bij te brengen( de overheid zou best een leuke klant/afnemer kunnen zijn van deze aan te bieden kennis-trajecten( ha ha). Daar ligt baanbrekend werk!
Wat ik mis in het verhaal is een stukje onderhoudsverplichting.
Ik heb voorbeelden gezien van bedrijven die code lieten ontwikkelen in India om hier in hun omgeving te integreren.
Sowieso viel het al niet mee om langer dan een jaar dezelfde mensen als gesprekspartner te houden in India. Als de softwarefabriek die 1 verdieping hoger zit in het kantorengebouw 5 roepie per uur meer biedt (bij wijze van) dan was de ontwikkelaar al vertrokken.
Dit helpt absoluut niet bij het opbouwen van de benodigde domeinkennis om het te maken product in de goede context te maken.
Nadat het product opgeleverd was, zijn de ontwikkelaars in India allemaal naar andere projecten gegaan.
Vervolgens worden er problemen gevonden in de software.
Hier in Nederland durfde echter niemand zijn handen te branden aan de software. Deze zat zo slecht in elkaar, dat men bang was dat alles om zou vallen als ze iets zouden wijzigen.
Netto resultaat: in Nederland is de helft van het outsourcingwerk opnieuw gedaan om problemen netjes op te kunnen lossen en het product in de toekomst te kunnen onderhouden.
Ja, dit had voorkomen kunnen worden door eerder inspecties te doen op code etc.
Echter, dan haal je het de hele winst weer weg. Als je daar goedkoop laat programmeren, en vervolgens hier duur moet reviewen / herstellen, dan heeft het hele outsourcen maar voor 1 partij winst opgeleverd.
En die partij zit in India, niet in Nederland !
Paul en schavuiten wilden zo snel mogelijk het werk naar India verschepen in de tijd dat Paul bij Logica werkte. Nu zijn nieuwe bedrijf een dependance in het land van na zdrovi heeft is India passe. Lekker stabiel land Oekraiene, vandaag waait de wind oost en morgen west.
Mooie ontwikkeling is de concurrentie van Indiase bedrijven die in europa kantoren starten en vervolgens de anglosaksische automatiseerders beconcurreert.
Yorrick heeft eens sterk punt. Detachering en Outsourcing is gedoemd te mislukken alleen vanwege de communicatie. Een IT-er in India heeft een andere interpretatie van jouw probleem en lost het vaak op een andere manier op dan eigenlijk bedoeld wordt.
Ik ken een aantal IT-ers uit India die bij een grote nederlandse leverancier van energie zijn gedetacheerd maar na enkele maanden al weg zijn, reden: miscommunicatie en een andere interpretatie van kwaliteit.
In nederland is talent genoeg.
Ik kan een aantal redeneringen niet volgen.
Nacalculatie is m.i. niet per definitie niet resultaat gericht. Een time and material opzet, kan (hopelijk) nog steeds betekenen dat er een goed plan, met goede inschattingen t.a.v. doorlooptijd, inspanning, kosten, kwaliteit etc. aan te grondslag ligt. Nacalculatie is zeker geen blanco cheque, maar vereist van leverancier / project management goede rapportages, verantwoording etc.
Uurtje / factuurtje oftewel sec capaciteit leveren lijkt mij inderdaad niet voor iedere opdrachtgever geschikt. De afstand of tijdsverschillen vergroten de gevolgen wellicht, maar ik zie verder geen oorzakelijk verband tussen mislukte detachering en onvermogen of onwil om inspanningsverplichting aan te gaan.
De klant de optie bieden om zelf inhoudelijk aan te sturen en vanuit leverancierzijde uitsluitend ontwikkelaars en ‘people management’ te leveren, lijkt mij een vorm van inspanningsverplichting pur sang. Dit is op zich uitstekend, maar mag natuurlijk niet verpakt worden als resultaatverplichting. Of kan in deze vorm de leverancier aangesproken worden op resultaat?