For 6-7 år siden var offshoring et nyt fænomen; et buzzword, der hos nogle gav rynker i panden og hos andre julelys i øjnene. Men hvad er status i dag på offshoring, og hvilke erfaringer har man gjort sig siden? Det giver IT-koncerndirektør Jørgen Jakobsen her et bud på fra sin side af skrivebordet i TDC.
Hvad er status på offshoring i dag?
For nogle år siden var offshoring et modebegreb, tror jeg, i forbindelse med det øgede fokus på globalisering. Offshoring har vel gennemgået et forløb fra at være et nyt fænomen til et punkt, hvor det nu er en naturlig del af den måde, man tænker på, når man laver og outsourcer projekter. Vi var forholdsvis tidligt ude med vores offshore-projekter hos TDC og har nu opnået en modenhed på området, som gør, at det er en naturlig og integreret del af det, vi foretager os som IT-virksomhed. På vores gamle systemer var det betydelig mere besværligt at tænke i offshoring. Men på vores nyeste projekter, som fx Siebel CRM implementering, er offshoring medregnet fra starten af. Om det omhandler store systemer og prioriteringer eller blot produktudvikling, så er offshoring tænkt med ind i alt det, vi laver.
De offshore-projekter, vi laver, foregår i Indien. Vi fronter dog ikke de indiske udviklingscentre selv, selvom vi nok ville få den ultimative økonomiske effekt ved at gøre det direkte. Men som virksomhed har vi ikke den fornødne modenhed, der skal til. For os var det bedre at snakke med en mellemmand (et frontoffice), som allerede havde et veletableret indisk udviklingscenter (backoffice).
Hvad er i hovedtræk de primære ting, som skal overvejes, inden man kaster sig ud i sådanne projekter?
At man skal give sig tid til at etablere, implementere og lave vidensoverdragelse, og så skal man have en klar plan for, hvilke roller der skal spilles – set i forhold til de roller, der har været spillet i selve virksomheden. Også i forhold til en dansk underleverandør eller i forhold til konsulenter. Der vil ske en ombrydning i rollemønstret, og man kommer altså til at arbejde op imod et indisk apparat, med — for eksempel — en meget meget høj CMMI certificering. Så du får altså, hvad du beder om, hvilket er fint nok — især hvis du er god til at beskrive præcis, hvad du gerne vil have.
Kan du give et eksempel på det?
Ja, et godt eksempel havde at gøre med de folk, der sidder i Indien og laver vores kreditvurderingssystem. Når der står et “A/S” så er det jo meget enkelt for os i Danmark. Vi ved, at det drejer sig om et selskab – men det er ikke sikkert, man forstår det i Indien. Det er heller ikke sikkert, at de, der sidder og laver systemerne, forstår betydningen af “c/o adresse”, og at det ikke er ensbetydende med, at det er en folkeregisteradresse. Så der kan jo være sådanne ting, hvor man kan være forholdsvis implicit omkring de specifikationer og de designs, man laver. Hvis ikke du sørger for at gøre de ting meget eksplicitte og beskrivende, så får du lige nøjagtig den eksplicitte fortolkning af, hvad du selv havde med. Det er måske et banalt eksempel, men løftet lidt op i en overordnet betragtning, så betyder det, at man skal give sig tid. Hele den vidensoverflytning, der skal ske fra virksomheden til et frontoffice og backoffice, tager tid. Så at tro at man “over night” kan skære 50% af omkostningerne eller noget i den retning – det kan man altså ikke.
Hvad har været din største udfordring mht. offshoring?
Det ligger vel i at give sig tid. Vi har jo brugt offshoring i Indien i forbindelse med forskellige strategiske overvejelser for at få adgang til markant flere ressourcer, som kunne de ting, vi havde behov for. De systemer, vi der har i vores offshore-aftaler, er til vores mobilmarked, og mobilmarkedet er utroligt volatilt og hurtigtflyttende, så derfor er der brug for at skaffe flere ressourcer og gøre tingene mere dynamiske.
Det er vigtigt at forventningsafstemme hele vidensoverdragelsen med modtagerne. Det tager noget tid at implementere, inden man er kommet over i en stabil tilstand, hvor det nye setup bare kører. Så min erfaring har været, at man skal sørge for at lave en ordentlig forventningsafstemning, som gør, at man får tid til at implementere tingene ordentligt.
Der skal jo flyttes viden frem og tilbage mellem både Danmark og Indien. Og jeg tror, den største læring — uanset hvem man kommer til, og uanset hvor meget man planlægger — er at få flyttet viden fra det ene sted til det andet. Vi har gjort det, at vi i det første år har haft to medarbejdere i Indien, der fungerede som liason, og som tilførte noget forretningsforståelse og nogle direkte kontakter til os i Danmark. Det kan man også sagtens bruge freelancekonsulenter til.
Hvilke erfaringer og gode råd kan du give videre til andre mht. offshoring?
Man skal i hvert fald tænke sig godt om! I princippet kan man jo offshore alt. Og hvis man tager det fulde skridt — altså hvor 95% af opgaven, lige fra udvikling til og med tests osv., bliver foretaget offshore — så skal man huske på, at der ingen vej er tilbage. Når man først har lavet sin vidensoverdragelse, så ligger den altså et andet sted. Det giver selvfølgelig fordele på den ene side omkring ressourcer, priser mm., men det kan på den anden side også give nogle ulemper ved, at man opnår større afhængighed af den tredje part.
Jeg ved, at nogle har erfaringer med at blande tingene, sådan at man har egne medarbejdere og offshore-medarbejdere på samme projekt. Det tror jeg ikke er anbefalelsesværdigt – det er enten eller! For det er svært at sidde i Danmark og udvikle på noget, og så sidde i Indien og udvikle på noget andet, og så få det til at hænge sammen i sidste ende. Det handler jo om, at en udviklingsproces er en sekventiel proces, og der skal man ikke forsøge at blande tingene sammen. Så hvis ansvaret hos os er de to første trin i en proces, så er det virksomhedens ansvar, og hvis man så har offshoret og outsourcet den resterende del, jamen så er det som regel den proces, der tilhører en anden. Ellers bliver det for svært at styre. Så det er enten eller!
Og så skal man give sig tid til vidensoverdragelse både i processen, inden man går i gang, og efterfølgende. Det er vigtigt. I den proces skal man være helt sikker på, at man forventningsafstemmer med modtagerne. Ellers kommer man bare under pres, hvilket som regel er meget irriterende. Det er i vidensoverdragelsesfasen, at vi har opnået de største erfaringer om, hvor offshoring kan volde problemer. Og det drejer sig om vidensoverdragelse både til et frontoffice og et backoffice.
Giv et eksempel på, hvordan en vidensoverdragelse kan gå galt.
For eksempel har vi på den ene side virksomheden med behov for god vidensoverdragelse, og på den anden side sidder dem, der skal transformere den viden til noget, som man så kan programmere videre på. Hvis man ikke har denne viden placeret i midten, som et koblingspunkt mellem dit offshore-apparat og din virksomhed — hvis den viden af en eller anden årsag forsvinder eller ikke bliver overdraget – ja, så mangler du et vigtigt led i kæden. Alle led i kæden skal derfor være stærke. Hvis tingene bliver for implicitte, går det ikke godt, og man er derfor nødt til at gøre tingene meget eksplicitte.
Er der noget mht. offshoring, som danske IT-konsulenter skal være særlig opmærksomme på?
I og med at jeg tror på, at en ret stor del af den samlede udviklingsopgave bliver løst offshore, så gælder det jo om for freelancere at finde det rigtige sted, hvor de kan gøre en forskel – altså hvor man kan være med inde og danne det her koblingspunkt. Så det handler vel om, at hvis man skal have en rolle, skal man bygge sine kompetencer op – og man skal finde sin plads lige nøjagtig i den værdikæde.
Hvis man kan komme ud i en virksomhed og sige: “Jeg har ar på ryggen, jeg forstår, hvad offshoring handler om,” så tror jeg, at man bliver en god freelance-konsulent. Og så skal man jo nok også til at tænke lidt mere segmentspecifikt, fordi store virksomheder nu er ved at have gjort sig gode erfaringer med offshoring.
Hvordan mener du, at danske IT-konsulenter bedst udnytter hele offshoringtendensen?
Jeg tror faktisk, at man skal ind og finde det sted, hvor man lige nøjagtig kan skabe værdi for en virksomhed og tænke med det som konsulent. Dels kan det være en midlertidig opgave, som en virksomhed løser, hvor man som konsulent byder sig ind til at håndtere opgaven og facillitere, at den bliver udviklet billigst muligt i et offshore-apparat. Dels kan det være, at man kommer ind som konsulent og er med til at opbygge de kompetencer, som virksomheden skal besidde for at kunne benytte sig af offshoring. Så der er forskellige vinkler — man skal bare finde ud af, hvad man kan tilbyde, som er af værdi og så satse på det.
Hvilke udfordringer mener du, at danske IT-konsulenter står over for i fremtiden?
Freelance-konsulenter, som forstår en given industrigren — det kunne være inden for finans, forsikring eller andre ting — og som også har forstået, hvad offshoring kan gøre for en virksomhed, og som ved, hvad man kan byde ind med, vil altid blive lukket ind, når de banker på ude hos virksomhederne. For det vil altid være en knap ressource.
Hvordan forestiller du dig fremtidens IT-konsulent?
Det er en person, der er serviceorienteret og relationsskabende, og hele tiden fokuserer på, hvordan man skaber værdi for virksomheden. Man skal ikke gemme sig nede i et eller andet kæmpe stort projekt; man er nødt til at komme frem og vise, at man skaber den værdi — måske især som freelance-konsulent, fordi det er meget nemt at sige: “Nu skærer vi ned på freelance-konsulenter!” Så man er nødt til at integrere sig i den virksomhed, man arbejder for som freelancer og synliggøre sin værdi og så ellers være enormt serviceorienteret, fleksibel og alle de andre ting – ligesom de bedste medarbejdere også er.
Så succeskriteriet er vel næsten, at man betragtes som en del af virksomhedens bedste medarbejdere. Hvis man kan det, så er man en rigtig dygtig freelance-konsulent. Så er det i hvert fald ikke en, virksomheden har lyst til at skille sig af med!
