/elektronik

It-udvikling outsources i blinde

Mange virksomheder flytter softwareudvikling til udlandet, men ofte uden at gøre deres forarbejde ordentligt, lyder dommen fra eksperter.

Af Jens Ramskov, mandag 30. nov 2009 kl. 07:16

Der ligger ofte irrationelle begrundelser bag beslutningen om at outsource softwareopgaver – også selvom rationelle begrundelser som besparelser angives som forklaringen. Det fremgår af en analyse udført af ph.d-studerende Per Svejvig fra Handelshøjskolen i Århus og professor Jan Pries-Heje fra Roskilde Universitet.

De har studeret årsagerne til, at en større skandinavisk højteknologivirksomhed har besluttet sig for at outsource softwareudvikling – på trods af, at alle erkender, det er en meget kompleks opgave. I begyndelsen mødte forskerne kun på det rationelle svar, at det var på grund af økonomiske besparelser.

Da de gik mere detaljeret til værk, dukkede andre begrundelser frem. Managementkonsulenter fremførte "bedste praksis", nogle medarbejdere promoverede outsourcing som en måde til selv at blive promoveret, og andre troede på outsourcing som den gyldne løsning på alt. Derfor foregår meget bag gardinerne, lyder forskernes konklusion.

Forskningen er foregået inden for rammerne af innovationskonsortiet SourceIT, som udføres af Delta og Roskilde Universitet sammen med Danske Bank, CSC Scandihealt og PBS. Projektet er støttet af Videnskabsministeriet.

Det er forhold, som man sikkert også kan se i mange andre virksomheder, mener afdelingsleder Jørn Johansen fra Delta, der gennem 15 år har arbejdet med metoder til procesforbedringer inden for softwareudvikling. Det kan være nogle af årsagerne til, at outsourcing nogle gange fungerer dårligt.

Jørn Johansen ønsker ikke at pege på konkrete virksomheder, men Ingeniøren har tidligere beskrevet, hvordan eksempelvis Bang & Olufsen har haft uheldige erfaringer med outsourcing til Indien.

»Man kan ikke outsource et helt projekt,« siger Jørn Johansen. »Man skal også bemande egen del af projektet i egen organisation med kompetente medarbejdere.«

Det lyder umiddelbart så indlysende, at man skulle tro, at alle virksomheder har forstået dette.

»Men det har de ikke,« siger Jørn Johansen.

Lad dig ikke blænde af fine bedømmelser
De store problemer, der beviseligt er, betyder dog ikke, at man skal opgive outsourcing som en mulighed, mener Jørn Johansen. Når SourceIT projektet er færdigt om et år, skulle der meget gerne foreligge et sæt metoder og værktøjer, der kan gøre outsourcingprocessen mere effektiv.

»Selv om der mange steder i verden er gået inflation i bedømmelserne af softwareudviklingshuse, behøver en dansk virksomhed dog ikke at være helt på Herrens mark,« siger Jørn Johansen.

Det tager mange dage at lave en egentlig vurdering (assessment), men en dansk virksomhed kan nu meget let finde ud af, på hvilket niveau den skal indplacere en mulig samarbejdspartner.

Jørn Johansens gode råd er at begynde med at stille helt enkle spørgsmål som: Har I et tidsregisteringssystem? Beskriv jeres fælles processer. Hvordan måler I effektiviteten af jeres arbejde?

»Svarene eller manglen af svar på disse og lignende spørgsmål giver hurtigt en fornemmelse af, hvilken organisation man sidder over for,« siger Jørn Johansen, der har fungeret som certificeret assessor i mere end 14 år.



30. nov 2009 kl 09:13

Dennis Haney

Een af de ting der går galt

Det største problem jeg ser i mange outsourcinger der går galt er noget så simpelt som at den blok arbejde der sendes ud er for stor.
I stedet for at splitte arbejdet op i mindre arbejdsenheder, som hver kan verificeres individuelt, så ender mange med at kun sende det overordnet opgave ud, og så 6-12 mnd senere opdager de at de slet ikke får de leveret som de troede.
Det er en ganske klassisk fejl indenfor projekt management.


30. nov 2009 kl 09:35

avatar

Michael Møller

Re: Een af de ting der går galt

Enig, en anden typisk ting er at de arbejdsopgaver der sendes ud ikke er logiske iforhold til arkitekturen i softwaren. Det giver en masse bøvl om hvem der har ansvaret for hvad, og det gør det umuligt at arbejde både for dem der har taget opgaven og for dem der skal bruge den software der kommer ud af det. Det er typisk fordi der er usikkerhed om arkitekturen, og hvis der er det, så er der også usikkerhed om organisationen.


30. nov 2009 kl 11:00

Peter Lind

Projektbeskrivelse

I de efterhånden lidt for mange danske softwarevirksomheder jeg har arbejdet i de sidste 11 år, har det været kendetegnende at opgaverne aldrig er defineret entydigt fra starten. Som udvikler er jeg altid endt med at deltage i lange og komplicerede diskussioner med et væld af projekt- og account-managere og kunderepræsentanter, hvor ingen er 100% enige om hvad det er der skal laves.
Når det så alligevel lykkes, er det som regel fordi vi allesammen taler samme sprog, og har mulighed for at mødes og kommunikere ustandseligt.
Den "luksus" har man ikke ved outsourcing - der er man delvist nødt til at betragte leverandøren som en leverandør hvor man får en sort boks tilbage med en given funktionalitet - ikke som en samarbejdspartner hvor man kan nå frem til en løsning i fællesskab.

Når outsourcing går godt, så er det i min opfattelse fordi projekterne har været vældig godt beskrevet, og man har fra starten været enige om hvad slutproduktet skulle være.


30. nov 2009 kl 13:35

avatar

Morten Lind

Re: Projektbeskrivelse

Jeg er enig med Peter, og synes det tyder lidt på at man skal få udført analyse og evt. prototype-implementering selv. Først når man har næsten helt "hul gennem" er man klar til at specificere og lægge rammer for den egentlige systemimplentering. Det er nok den, og driften, der kan outsources ...


30. nov 2009 kl 13:43

Hans Henrik Groth

IT Offshore anno 2009

Jeg mener der er et mere grundlæggende problem omkring forståelsen for anvendelse af IT Offshore hos flere virksomheder. IT Offshore har udviklet sig lige som alle andre brancher og en optimal udnyttelse af IT Offshore anno 2009 kræver efter min mening, at man som virksomhed ikke ser Offshore som en kravspecificeret opgave der skal sendes ud og så komme tilbage. IT Offshore skal anvendes på lige fod med måden vi ville udvikle systemer hvis udviklingsteamet sad både i Århus og København. Her ville vi jo aldrig drømme om at specificere i det detaljerings niveau som nogle virksomheder fortsat gør. For at drage fuld udnyttelse, skal offshore ressourcer ses som en fuldt ud integreret del af den danske (Onshore) organisation og udviklingen skal ske i samarbejde. Derfor glæder det mig også at se at dette netop er en af Jørn Johansens kommentarer. Tiden for omfattende kravspecifikationer og et syn på Offshore lokationen som et ”sort hul” som man som virksomhed reelt ikke forholdte sig til er slut og tiden er inde til at anskue Offshore ressourcer som fuldt ud på højde med danske udviklere og arkitekter – ja, ofte faktisk endnu bedre. I bund og grund er det to så gamle dyder som ledelse og erfaring der skaber en stor del af forudsætningen for succes.
Hans Henrik Groth, inCaptiva Offshore Solutions


30. nov 2009 kl 13:58

Per Hygum Due

Tanker om outsourcing

1. Kontrol af projektdeltageres kvalifikationer

Er eksamener bestået ?
Er der lavet dokumentfalsk ?
Har personen været ansat de steder, som er opremset på CV'et ?
Er personen rent faktisk medlem af opremsede bestyrelser, foreninger, etc. ?

2. Udarbejde use cases for hvordan systemet under udvikling skal bruges. Aftaler på skrift er at foretrække fremfor mundtlige aftaler, der ofte ender med uenigheder om hvad der er aftalt. Use cases skaber klarhed over systemet for alle interesseparter: slutbrugere, testere, udviklere, supportere, product managers, konsulenter, etc.

3. Med agile metoder kan man arbejde sig frem mod målet igennem en række overskuelige inkrementer. Arbejder man efter agile metoder opnås viden om uforudsete praktiske problemer allerede tidligt i projektforløbet.

Ex1: Der bruges en del måneder på at designe et klassehieraki på papiret. I designet indgår multipel arv. Senere når softwaren skal bygges viser det sig at udviklingsværktøjerne ikke supporterer multipel arv. Agile processer sikrer at problemet opdages tidligt i forløbet.

4. Undgå at parter der skal samarbejde meget bor i forskellige tidszoner. Når det er dag det ene sted er der nat det andet sted og en e-mail dialog bliver meget langsommelig.

5. Organisationens faste medarbejdere skal bruge en del tid på at koordinere med parter der outsources til: specifikation, leverencer, test og fejlbeskrivelser, software integration, etc.

6. Selvom softwarefirmaer har fine bedømmelser ændrer det ikke på at softwareudvikling er en svær størrelse at lave tidsplaner for. Softwareudvikling er komplekst. Moderne systemer er ofte et "kludetæppe" af: egenudviklede dele, binære biblioteker fra andre parter, open source kode man har lavet sine egne tilpasninger på, flere forskellige programmingssprog, managed og unmanaged kode, osv. De mange afhængigheder gør det svært at styre.


30. nov 2009 kl 15:03

Jørn Johansen

Re: Tanker om outsourcing

Rigtig mange spændende tanker og indlæg, som jeg vil tage med ind i SourceIT projektet.

Min synsvinkel er, at det er meget vigtigt med velfungerende processer i den grænseflade der ligger mellem kunden og leverandøren. For mig er en proces først velfungerende, når den er moden (indarbejdet og anvendt), når de nødvendige kompetencer er til stede hos de involverede parter, og når processen er understøttet af metoder og værktøjer.
Og nu er der jo to parter – og dermed er chancen dobbelt op for at det mislykkes.

Endvidere er det nødvendigt med en outsourcingstrategi, hvorpå et outsourcingforløb kan bygges, og som et projekt løbende kan forholde sig til og leve op til. Det betyder bl.a. at overgangen fra et projekt til det næste i det hele taget bliver muligt.

Outsourcing er en langsigtet investering, der både kræver solide processer, kompetencer og omtanke i forhold til hvad der outsources.

For at få så mange erfaringer som muligt at bygge på i projektet, prøver vi at etablere en så bred kontaktflade som muligt (bl.a. gennem Tecpoints netvæksgruppe 29 om outsourcing). Jeg vil i øvrigt være taknemmelig for, hvis I vil gå ind og udfylde spørgeskemaet på:
http://surveys.polldaddy.com/s...4F5/


30. nov 2009 kl 17:52

avatar

Lars Behrendt

Outsourcing - undervurderede aspekter

Min erfaring er, at beslutninger om outsourcing af softwareudviklingsopgaver ofte tages på mangelfuldt grundlag. Den umiddelbare besparelse i næste budgetår udregnet ved en simpel sammenligning af lønudgifterne hjemme og ude er tit set som eneste begrundelse.

Derved ignoreres eller undervurderes følgende:
- tid nødvendig for den nødvendige videnopbygning ude
- kultur- og ledelsesforskelle
- modstand hjemme, og de resulterende konflikter mellem hjemme og ude
- overhead fra samarbejdet over flere sites
- nødvendigheden af i en rum tid at bevare ekspertise hjemme for at sikre succes ude

Jeg er dog ikke i tvivl om, at outsourcing kan være en fordel for alle parter, forudsat, at det erkendes, at der er tale om et langsigtet projekt. Og at det kræver nogle investeringer at få sådan noget op at stå.


01. dec 2009 kl 09:00

Jørn Johansen

Succes med outsourcing

Ud fra indlæggende frem til nu, har jeg forsøgt med en opsummering:
- Arbejdet skal deles op i mindre arbejdsopgaver.
- Gennemarbejdet arkitektur som delelementer er designet ind i.
- Godt beskrevne projekter, hvor der er enighed om slutproduktet fra starten – baseret på en grundig analyse og evt. prototyping.
- Fokuser på modenhedens af de processer, der ligger i grænsefladen mellem kunde og leverandør.
- Baser på outsourcing / offshore på en solid strategi.
- Produktudviklingen skal foregå i et tæt samarbejde i et distribueret projekt.
- Kompetencerne skal være dokumenterede.
- Brug af usecases og agil produktudvikling.
- Anvend skriftlige aftaler.
- Kalkuler med at det tager tid at koordinering outsourcing for organisationens faste medarbejdere.
- Det er primært systemimplementeringen og driften, der kan outsources.
- Undgå forskellige tidszoner i det omfang det er muligt.
Glem ikke:
- At det er meget komplekst at udvikle systemer – ikke mindst når det foregår distribueret.
- At tid er nødvendig for den nødvendige videnopbygning ude.
- At kultur- og ledelsesforskelle skal håndteres.
- At der kan være modstand hjemme, og de resulterende konflikter mellem hjemme og ude.
- Overhead fra samarbejdet over flere sites.
- Nødvendigheden af i en rum tid at bevare ekspertise hjemme for at sikre succes ude.


01. dec 2009 kl 09:46

Dennis Haney

Re: Succes med outsourcing

>- Arbejdet skal deles op i mindre arbejdsopgaver.

Det er en tautologi. Nej, pointen er at arbejdet skal deles op på en sådan måde at en mængde af den kan sendes ned, og en prototype eller færdigt udgave af samme kommer tilbage indenfor overkommelig tid. Evt. med adskillelige del leverencer ind imellem. Afhænger selvfølgelig af komplexitet, men der bør ikke være med end allerhøjest 3 uger fra start til slut af et arbejde.

>- Gennemarbejdet arkitektur som delelementer er designet ind i.

Det ser jeg ikke som et krav. At opbygge arkitekturen kan sagtens være een af overstående arbejdsopgaver

>- Godt beskrevne projekter, hvor der er enighed om slutproduktet fra starten – baseret på en grundig analyse og evt. prototyping.

Nej, det er heller ikke nødvendigvis et krav. Man kan sagtens få beskrivelsen outsourcet også. Men igen, der skal et verifikations trin på inden der fortsættes med den givne arbejdsopgave.

>- Fokuser på modenhedens af de processer, der ligger i grænsefladen mellem kunde og leverandør.

Den forstår jeg slet ikke

>- Baser på outsourcing / offshore på en solid strategi.

Det er også en tautologi

>- Produktudviklingen skal foregå i et tæt samarbejde i et distribueret projekt.

Ja, daglige møder, tilgængelige tidsplaner etc.

>- Kompetencerne skal være dokumenterede.

Hvis du ikke har styr på om dem du hyrer kan det de siger, så synes jeg du skal fyre dit hiring team.

>- Brug af usecases og agil produktudvikling.

Det er slet ikke et krav der er specielt til outsourcing, det er almindelig sund fornuft i forbindelse med software udvikling.

>- Anvend skriftlige aftaler.

Det kommer an på hvordan man laver sin outsourcing. Hvis du laver det som at sælge en helt specifik opgave, så selvfølgelig. Du ville gøre det samme med den virksomhed der er din nabo. Hvis du derimod benytter outsourcing som en integeret del af dit firma, så er dette ikke en nødvendighed udover at sørge for at den ansvarlige har en fornuftig kontrakt.

>- Kalkuler med at det tager tid at koordinering outsourcing for organisationens faste medarbejdere.

Ja, og hav minimum een der er fuldstændig ansvarlig og rent faktisk har styr på software udvikling.

>- Det er primært systemimplementeringen og driften, der kan outsources.

Det er svært at outsource rengøringshjælpen...

>- Undgå forskellige tidszoner i det omfang det er muligt.

Nej, der kan være mange fordele i et split tidszone. Pointen er at undgå de ligger ALT for langt væk, e.g. vil outsourcing til Tasmanien være en rigtig dårlig ide i DK. (eller til asien i USAs tilfælde)

>- At det er meget komplekst at udvikle systemer – ikke mindst når det foregår distribueret.

Man skal heller ikke gøre problemet større end det er. Hvis man splitter sit hold forkert, er det klart at det kan gå helt galt. Typiske eksempler er at have testerne siddende i eet land og udviklerne i et andet.
Hvis man derimod tænker sig en smule om, så er det at være distribueret ikke et større problem end hvad man ellers vil have med at have 2 bygninger et par hundrede meter fra hinanden.

>- At tid er nødvendig for den nødvendige videnopbygning ude.

Enhver ny afdeling i en virksomhed tager tid. Dette er igen ikke specielt for outsourcing.

>- At kultur- og ledelsesforskelle skal håndteres.

Bestemt, men hvor meget det faktisk gør af forskel? Det er svært at sige, og er sikkert meget situationsafhængigt.

>- At der kan være modstand hjemme, og de resulterende konflikter mellem hjemme og ude.

Standard change-management applies.

>- Overhead fra samarbejdet over flere sites.

Yup, en god ide er at man identificerer kommunikationsveje, og sørger for at man splitter organisationen der hvor der er færrest, hvormed man mindsker overhead.

>- Nødvendigheden af i en rum tid at bevare ekspertise hjemme for at sikre succes ude.

IMHO så er det bedre at sende ekspertisen ud permanent. Ekspertise kan sagtens tage 5-10 år at opbygge, så hvorfor skulle man være interesseret i at slippe af med den?


Ny i debatten? Opret en brugerkonto

  • Seneste nyt
  • Mest læste
  • Topdebat
Populært på Facebook
 

Nyhedsbrev

Tilmeld dig vores nyhedsbrev.