In veel artikelen over het offshoren van ict-activiteiten, of het nu projecten zijn of een businessproces, wordt vaak en passant vermeld ‘dat communicatie natuurlijk veel lastiger gaat in het geval van offshore’. Zonder daar verder op in te gaan. Het is blijkbaar een gegeven dat communicatie een nadeel is in het geval van offshore, een verlies dat je moet nemen als je deze stap zet. Toch is het goed om het verschijnsel van tijd tot tijd onder de loep te nemen.
Interpretatie en vastlegging
Wat men vaak bedoelt als het gaat over communicatieproblemen is gebrekkige communicatie die ertoe leidt dat projecten vertraging oplopen, dat er niet gebouwd wordt wat de bedoeling was of dat er door een opeenstapeling van kleine incidenten het vertrouwen geleidelijk verdwijnt. Ditzelfde rijtje geldt overigens voor ict-projecten die niet ge-offshored zijn, alleen is daar blijkbaar het risico dat deze zaken zich voordoen kleiner. Wat belangrijker is naar mijn mening is dat er meer mogelijkheden zijn om snel in te grijpen bij on-site development. En let wel, er zijn ook andere oorzaken dan communicatieproblemen die ict-projecten doen mislukken.
Als we inzoomen op de elementen van de problematiek zien we twee basisfactoren:
– interpretatieproblemen van communicatie (‘Ik had gedacht dat je het zó zou doen')
– vastleggingsproblemen van communicatie (‘Hier hadden we toch afspraken over gemaakt?')
Als deze problemen zich voordoen zijn de directe gevolgen niet altijd groot. Vaak ontstaan de belangrijkste negatieve effecten door een opeenstapeling van kleine incidenten. Dat leidt tot een situatie van ‘de druppel die de emmer doet overlopen' waarbij de andere partij soms stomverbaasd is aangezien er over de opstapeling van communicatieproblemen óók niet gecommuniceerd was.
Culturele oorzaken
Er zijn een aantal elementen die een rol spelen bij communicatieproblemen in de offshorecontext: verschillen in cultuur, verschillende tijdzones en fysieke afstand zijn. Cultuurverschil betekent in deze context vaak dat partijen een verschillend antwoord geven op de vraag 'wat kan je van elkaar verwachten?'. Bekend voorbeeld is dat Aziaten nooit ‘nee' zeggen, of ‘dat kan niet', maar dat het resultaat vervolgens niet is wat er werd gevraagd. Of neem het klassieke misverstand tussen ict'er en opdrachtgever, dat ongeveer zo gaat: ‘Je hebt niet gebouwd wat ik vroeg'. ‘Maar de specs waren onduidelijk'. Cultuurverschillen die er toch al bestaan tussen ict'ers en niet-ict'ers worden uitvergroot op het moment dat de offshorefactor erbij komt. Daarom wordt in veel artikelen ook een sterke sturing van de zijde van de klant bepleit, zowel voor projecten als voor het outsourcen van businessprocessen.
Afstand in tijd en fysieke afstand spelen ook een grote rol. Daarom geeft een belangrijk aantal bedrijven de voorkeur aan een offshorepartner in Oost-Europa (nearshore), waar het tijdsverschil een uur is en de kantoortijden makkelijk gelijkgeschakeld kunnen worden. In het geval van een offshorebestemming in Azië is daar veel meer moeite voor nodig. Ook hier spelen weer verwachtingen een rol. Er zijn bepaalde ongeschreven etiquetteregels ontstaan over hoe lang je moet wachten op antwoord op een e-mail, een instant messaging-bericht of een bevestiging op een uitnodiging voor een conference call. Er zijn Aziatische dienstverleners die hun kantoortijden verschuiven of in ploegendienst werken, maar dat is niet ideaal. 's Nachts ligt de arbeidsproductiviteit en accuratesse nu eenmaal lager.
Liaison-manager
Om problemen van interpretatie en vastlegging van communicatie te voorkomen of op te lossen wordt in de literatuur veel gepleit voor een sterke regierol van de opdrachtgever. Als je je ict-afdeling hebt ge-offshored dan betekent dat niet dat niemand in het eigen bedrijf zich nog met ict bezig hoeft te houden. De offshorepartij moet aangestuurd worden, met het idee dat als de klant niet weet wat hij wil, de leverancier niet het juiste product zal leveren.
Ik wil daaraan toevoegen dat ook aan de kant van de leverancier hier expliciet aandacht voor moet zijn. Bij langere samenwerkingsverbanden ligt dit voor de hand, dan gaat het meestal om een variant van accountmanagement. Maar ook bij korte projecten is het belangrijk om hierin te investeren, anders verandert een kort project maar al te vaak in een langlopend project. Bij zowel de opdrachtgever als bij de offshorepartner moet de taak belegd zijn om te anticiperen op bekende interpretatieproblemen en om deze te voorkomen. Als dit niet expliciet iemands taak is, gebeurt het niet of niet gestructureerd. Dit is een punt dat, objectief beschouwd, enorm voor de hand ligt.
Toch komt het vaak voor dat het actief opsporen en adresseren van interpretatierisico's door de opdrachtnemer in het buitenland een onderschoven kindje is. Er zou een liaison-manager moeten zijn die vertrouwd is met beide culturen, processen zoals functioneel ontwerpen kan begeleiden en kan ingrijpen op het moment dat zich een communicatieprobleem voordoet. Voor kleinere projecten kan de liaison-manager meerdere ballen tegelijk in de lucht houden. Als er maar iemand is aangewezen die dit als taak heeft.
Om vastleggingsproblemen te voorkomen grijpen partijen vaak naar vuistdikke SLA's, waarin iedere mogelijke omstandigheid moet worden afgedekt. Een veelgehoord commentaar op uitgebreide SLA's is dat het niets meer is dan ‘gestold wantrouwen'. Een andere bekende klacht is dat deze documenten vaak zo uitgebreid zijn dat niemand weet wat erin staat. Zeker niet op het niveau waar de beslissingen worden genomen. Toch ligt het voor de hand om heldere afspraken te maken over projecten en processen, die vast te leggen en te beheersen in de discipline service level management. Alleen voorwaardelijk voor het slagen van dit soort afspraken is een zekere beknoptheid en tegelijkertijd een grote mate van helderheid die ervoor zorgt dat ze breed gedragen kunnen worden door beide partijen. Als de liaison-manager tegelijkertijd service level manager is, is dat een uitgelezen kans om én communicatieproblemen én een teveel aan papierwerk te voorkomen.
