Offshoring strategi

Hvorfor skal man overhovedet have en strategi? Kan man ikke bare starte på Offshoring og så regne med/håbe på at man opnår de ønskede resultater? Nej, det kan man ikke, fordi gennemførelse af offshore projekter er af natur forskellige fra interne udviklingsopgaver, og det kræver et kompetenceløft i organisationen for at kunne gennemføre offshore projekter med succes. For at få succes med offshoring bør en organisation derfor kunne svare på følgende spørgsmål: Hvad ønsker vi at opnå ved sourcing, hvem i organisationen påvirkes og hvordan, hvordan vil vi tilpasse vores organisation for at opnå det og hvordan måler vi effekten? Det skal understreges at udarbejdelse af en offshore strategi ikke behøver at være en tung og langstrakt proces, men at den ofte vil kunne udarbejdes på 2-3 måneder, men at den til gengæld giver et solidt grundlag for at indføre offshoring af IT udviklingsopgaver i organisationen.

Det første man skal gøre sig klart er hvorfor man påbegynder et offshore initiativ. Hvis prisen er det primære mål bør man overveje om der er andre måder at opnå besparelsen på. Det kan f.eks. være ved optimering af interne udviklingsprocesser, større anvendelse af standardkomponenter eller genbrug af SW elementer. Desuden skal man finde en måde at måle besparelsen på. Blot at tælle udviklingstimer og sammenligne vil være at sammenligne æbler og pærer, da der ofte er en faktor 4-5 i forskel på en rutineret dansk udvikler og en junior programmør i Indien eller Kina. Ligeledes skal indregnes den support organisation der skal etableres i den danske virksomhed for at håndterer specifikationer, kvalitetskontrol, koordinering og rejseomkostninger, test og svare på spørgsmål fra offshore partneren. En anden vægtig grund til at vælge offshoring er adgang til ressourcer med specifikke kompetencer. F.eks. er det uhyre svært at finde danske COBOL programmører, hvorfor mange danske finanshuse er tvunget til at offshore deres COBOL udvikling for at kunne holde vedligeholde deres IT-systemer. Her er det igen vigtigt at man gør sig klart hvad det er man er ude efter. Hvilken kompetence, forretningserfaring (f.eks. fra bankdrift) og evne til at løse opgaver selvstændigt har man behov for? Det er uhyre vigtigt at man har gjort sig behovet klart inden vælger sourcing land og leverandør, og man kan nemt befinde sig i en situation, hvor den bedst egnede leverandør ikke nødvendigvis har de billigste timepriser eller ligger i Asien!

Lige så vigtigt det er at formulere målene med offshoring, lige så vigtigt er det at identificere dem i organisation som påvirkes og skal bidrage til gennemførelse af sourcing strategien. Ved at gennemføre en stakeholder analysis i organisation får man afdækket hvem der henholdsvis bidrager til gennemførelse af strategien, hvem der påvirkes, og ikke mindst hvem der er meningsdannere (enten positive eller negative) i forhold til offshoring. For hver stakeholder skal udarbejdes en plan for henholdsvis inddragelse og information, for at kunne imødegå at der opstår for meget modstand mod strategien.

At offshoring kræver en anden måde at arbejde på er uomtvistelig, men man glemmer at det ikke kun er udviklingsafdelingen der påvirkes. En væsentlig parameter til succes er derfor en grundig analyse af hvilke afdelinger der selv skal deltage i offshore initiativet eller som bliver påvirket af det, for at sikre at alle implicerede arbejder mod et fælles mål. Derefter bør tilpasningen i de enkelte afdelinger planlægges og koordineres samlet i Offshore initiativet. Se i øvrigt mit blog indlæg: "Offshoring berører ikke kun udviklingsafdelingen": http://www.computerworld.dk/blog/outsourcing-bloggen/217300/offshoring-beroerer-ikke-kun-udviklingsafdelingen.

Hvordan måler man effekten af Offshore initiativet for at afgøre om det har været en succes eller fiasko? Det er ofte her at danske virksomheder løber ind i problemer af to grunde. For at kunne måle effekten er det nødvendigt at man har måltal for den eksisterende interne udvikling, for at have en baseline at sammenligne med, hvilket det er få danske virksomheder der har. Derudover vil det i praksis være svært at adskille omkostninger til gennemførelse af det første pilotprojekt med udgifter til generelle organisationsændringer relateret til Offshore initiativet. De mest modne udviklingsorganisationer benytter sig f.eks. af Function Points (FP) som giver et objektivt input til sammenligning af produktiviteten, men det vil ofte være at tilføre et ekstra risikoelement at starte på FP beregninger hvis man ikke har er erfaringen i forvejen. En mere enkel tilgang kan være at identificere et simpelt pilotprojekt, hvor man med rimelighed kan forudsige hvad det ville koste at få udviklet internt, og så se hvad det koster at få udviklet eksternt. Blot skal man huske at tillægge en ekstra buffer til at opsuge de ekstra omkostninger der hidrører fra indførelse af en ny teknologi = Offshoring. I de fleste tilfælde vil det beløbe sig til 30-50% ekstra.

Som ved enhver anden organisationensændring er der risici forbundet med Offshoring, som skal mitigeres. Særlige risici forbundet med Offshoring er: personale gennemstrømning hos leverandøren (hos indiske leverandøren er 20-25% ikke usædvanligt), manglende ressourcer både hos kunden og leverandøren, utilstrækkelige kompetencer hos enten kunden eller leverandøren, organisatorisk modstand hos kunden, geo-politiske forhold, vigende kvalitet i leverancer, uklare mål (kravet "leverancen skal være brugervenlig" er for vag) for blot at nævne nogle få. For at få succes med Offshoring der det derfor absolut nødvendigt løbende at følge op på risikobilledet, og eskalere faresignaler til styregruppen hvis de truer gennemførelsen af projektet. Dette gælder i øvrigt alle projekter, ikke kun Offshore projekter, her er det blot ekstra vigtigt.

At starte et Offshore initiativ uden at have udarbejdet en strategi, svarer til at starte på et husbyggeri uden at have en arkitekttegning! Desværre ser man ofte at Offshore initiativer startes over hals og hoved, uden at der er foretaget nogen form for forberedelse, ud fra en fejlagtig antagelse at Offshore udvikling kan sidestilles med inhouse udvikling, og at man derfor kan bruge de samme styringsmekanismer og det samme mindset. I stedet bør man bruge de første måneder på at forberede projektet, ved at udarbejde en strategi, kommunikationsplan, stakeholder analysis og specifikke målepunkter. Derved vil man kunne undgå mange af de skuffelser og overraskelser som ikke forberedte organisationer løber ind i. Et godt råd på falderebet: brug andres erfaringer ved at tilknytte en person som har prøvet det før, det vil ofte være den bedst forrentede investering man kan fortage!