B&O ramt af skuffende outsourcing
more_vert
close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.

B&O ramt af skuffende outsourcing

B&O's forsøg med at outsource først og fremmest softwareudvikling til Indien og Estland, hvor ingeniørlønningerne er lave, mislykkedes.

Administrerende direktør Kalle Hvidt Nielsen erkender over for Ingeniøren, at »outsourcingen ikke fungerede«.

»Der har været outsourcet mange opgaver, og det er et område, hvor jeg ikke synes, at vi kan være tilfreds med udbyttet,« siger han.

»Der har været outsourcet mange opgaver, og det er et område, hvor jeg ikke synes, at vi kan være tilfreds med udbyttet,« siger Kalle Hvidt Nielsen, CEO Bang & Olufsen. Illustration: Mikkel Hagstroem/Kaliberfoto.dk

Den fejlslagne outsourcing er en af de grunde, som Kalle Hvidt Nielsen giver, når han skal forklare, hvorfor Struer-koncernen har lanceret skuffende få produkter på hovedmarkedet, audio og video til hjemmet. Han angiver desuden det forholdt, at B&O ikke formåede at »etablere effektive teknologiplatforme«.

»Vi har nu fået langt bedre struktur og fokus på den måde, vi bruger ekstern assistance. Vi har blandt andet skåret antallet af partnere gevaldigt ned. De, der er tilbage, har en berettigelse i form af kompetencer, som vi ikke har nok af, eller har kapacitet, som vi mangler,« forklarer Kalle Hvidt Nielsen.

»Vi ville foretrække at gøre tingene in-house, men der er mange steder, hvor man kan give et løft ved at bruge eksterne partnere,« tilføjer han som begrundelse for at fortsætte med outsourcing af udviklingsopgaver.

De manglende produktnyheder var en af årsagerne til, at B&O i det netop afsluttede regnskab præsenterede et underskud på en halv milliard kroner og et omsætningsfald på en milliard kroner i forhold til foregående regnskabsår.

En kilde med indgående kendskab til Bang & Olufsen, som ønsker at være anonym, mener at vide, at det særligt gik galt med de opgaver, som blev sendt til Indien.

»Der har været store lanceringsforsinkelser og mange fejl, som har skullet rettes op på af danske ingeniører - som dermed har haft de kedelige opgaver, mens deres indiske kollegaer har haft det spændende arbejde,« forklarer han til Ingeniøren.

Ifølge Kalle Hvidt Nielsen, forsikrer, at udviklingen nu er vendt, at der er styr på partnerne, og at B&O er på vej med flere produktnyheder til at puste liv i salget.

»Vi har vendt udviklingen og fået en række produkter ud. Vi har også en stærk pipeline for de næste 12 måneder,« siger han.

Nyhedsmagasinet Ingeniøren bringer fredag en analyse af B&O's.

sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Det er desværre set alt for tit. En alt for snæver fokus på timepris fører ikke til noget godt. Slet ikke når det drejer sig om videnstunge opgaver. Hvis man satsede på at få de bedste Indiske ingeniører til halv dansk timepris frem for til en 1/10 dansk timepris, så kunne man få nogle der også havde vestlig kulturforståelse og som ikke jobshoppede videre efter 3 måneder. Envidere vil det være en god ide, at selv ansætte inderne frem for at have et firma ind i mellem, der skal tjene penge på det. Det giver først og fremmest for mange uærlige svar i forbindelse med leverancer.

Dem der satser på rusland, Indien og Kina uden at fokusere på lave timepriser, dem spår jeg en god fremtid.

Omvendt dem der benhårdt satser på lave timepriser, de begynder sikkert snart at se mod syd til f.eks. Nigeria
(her har de længe været teknologisk førende indenfor email....).

  • 0
  • 0

Det kan ikke være ingeniører lønningerne, som sænker en virksomhed. Da de dygtige ingeniører ikke får en løn som står i mål med den værdi som de skaber. Da lønnen står i forhold til hvad den samme ingeniør kunne få på en anden arbejdsplads, hvor ingeniøren er uerfaren og ikke er inde i produktet.

  • 0
  • 0

Forskellige tidszoner gør det sværere at koordinere.

Der er ekstra omkostninger til hoteller, forplejning, flybilletter, når man skal mødes til status og vidensoverdragelse.

Svindel med eksamenspapirer. Er ikke dataloger, ingeniører, etc.

Det er mere tidskrævende at koordinere aktiviteterne via emails, chat, online whiteboards istedetfor at mødes.

Høj personaleomsætning er gift for udviklingsprojekter, da det tager tid at opbygge viden igen.

Kræver klare specifikationer og interfaces. I moderne Agile udviklingsprocesser bliver der mere klarhed for hvert
inkrement der gennemføres hen imod en release. Outsourcing egner sig nok mest til opgaver der lader sig klart og tydeligt specificere i starten af forløbet.

Det er tungere at rette softwarefejl pga. langsommere kommunikation imellem parterne. Man kan ikke mødes om whiteboardet og lave en hurtig afklaring. Fejlen skal beskrives og dokumenteres i detaljer for at modparten kan finde ud af hvad der er sket og forstå sammenhængen.

Dårlig engelsk over ringe telefonforbindelse giver flere misforståelser.

Mere spildtid på buildproblemer.

  • 0
  • 0

Nå da. En interessant liste.

Forskellige tidszoner gør det sværere at koordinere.

Dette er en beskrivelse af en »mundtlig« virksomhed, dvs. man evner ikke at basere sig på asynkron interaktion (e-mail, voice-mail, video-mail og forfatning af artikler som i ing.dk).

Der er ekstra omkostninger til hoteller, forplejning, flybilletter, når man skal mødes til status og vidensoverdragelse.

Igen: Dette er en beskrivelse af en »mundtlig« virksomhed. I en sådan kan man typisk intet styre eller foretage sig uden at mødes ansigt til ansigt. Sådant, at mødes, har projekter ikke længere tid til i vor verden fuld af trængsel, fordi rejser tager alt for lang tid og belaster alt for hårdt. Som betyder, at de opgaver som man kan outsource, især kun er de opgaver som man på forhånd evner at definere overfladen på, på en ikke-mundtlig måde.

Svindel med eksamenspapirer. Er ikke dataloger, ingeniører, etc.

En beskrivelse af en inkompetent ansættelsesprocedure. Man skal sørge for at kontrollere en ansøgers påstande, før man ansætter. Ellers slipper løgnere ind, som altid fører til tab. At man outsourcer til et uafhængigt selskab, fjerner ikke dette krav til ansættelser. Som betyder, at man skal kræve, før man underskriver en outsourcing-kontrakt, at modtage CV fra alle projektdeltagere hos outsourcingpartneren, og disse skal man kontrollere, og man skal også kontrollere, i det daglige projektarbejde, at det rent faktisk er disse mennesker der udfører arbejdet. Hvis man undlader dette, vil partneren med stor sandsynlighed snyde, det vil sige underbemande projektet. Dette betyder i praksis, at man behøver at være i videokontakt med alle projektdeltagere direkte ved alles skriveborde. Hvis man ikke har en sådan evne, er projektet ilde stedt. Denne detalje stiller meget store krav til en dedikeret og krypteret båndbredde (som koster kassen!), så man altid er garanteret forbindelse og beskyttelse imod spionage og sabotage.

Det er mere tidskrævende at koordinere aktiviteterne via emails, chat, online whiteboards istedetfor at mødes.

Endnu engang: En beskrivelse af en mundtlig virksomhed, som er gammeldags. Videnstunge udviklingsprojekter kan stort set slet ikke løftes medmindre at de bliver baseret på skriftlig interaktion imellem samtlige deltagere, vel at mærke en interaktion der følger en fastlagt og effektiv protokol, og som bliver administreret af et effektivt fælles system. Årsagen til dette krav er, at moderne produkter er fyldte med viden, som er stablet i mange lag, og hvoraf nogle af disse lag er meget abstrakte, det vil sige alt skal indpasse i én stor indre fælles arkitektur, som forudsætter stringens i alt projektarbejde.

Høj personaleomsætning er gift for udviklingsprojekter, da det tager tid at opbygge viden igen.

Og igen: Dette er naturligvis et problem for en virksomhed som især kun lagrer viden i biologiske hjerner. Moderne virksomheder, derimod, har systemer der gør det muligt at anvende en evig strøm af kortvarige gæster (specialister, eksperter, professorer, studerende, kontraktansatte), fordi alles arbejdsbidrag resulterer i konkret skriftlighed i en form som alle kan arbejdere direkte videre med, det vil sige at der er en protokol som sikrer dette og der er et administrativt system der sikrer at protokollen er lynhurtig og nem at anvende. Det siger sig selv, at hvis et sådant system udgør nogen som helst gnidningsmodstand for ansattes arbejde, uanset hvor lille, da vælger ansatte i stedet at udveksle mundtligt, og da er der dømt fiasko for projekterne.

Kræver klare specifikationer og interfaces. I moderne Agile udviklingsprocesser bliver der mere klarhed for hvert inkrement der gennemføres hen imod en release. Outsourcing egner sig nok mest til opgaver der lader sig klart og tydeligt specificere i starten af forløbet.

Nej. Uanset om en god kontrakt ligger til grund for en outsourcing, er dette slet ikke nok. Outsourcing er dødsdømt, hvis den daglige proces er baseret især kun på mundtlighed. »Klart og tydeligt« er noget som man sikrer ved hjælp af arbejdsredskaber og systemer.

Det er tungere at rette softwarefejl pga. langsommere kommunikation imellem parterne. Man kan ikke mødes om whiteboardet og lave en hurtig afklaring. Fejlen skal beskrives og dokumenteres i detaljer for at modparten kan finde ud af hvad der er sket og forstå sammenhængen.

Ja og også nej. Erfaring viser, at det i praksis er umuligt at outsource opgaver til vildfremmede lande, hvis opgaverne kun kan løses af mennesker med stor social og kulturel forståelse for det marked som et produkt henvender sig til. Som betyder, at man skal sørge for selv at udvikle alle brugerflader, hardware såvel som software, for eksempel. Derimod kan man sagtens outsource fx softwaremoduler af den slags som forbliver usynlige for en bruger af en vare, naturligsvis forudsat at man klokkeklart definerer de indre funktionsoverflader (input og output af variabler) samt arkitektur for fejlhåndtering, krav til performance, maksimumgrænser for forbrug af computerressourcer m.m., det vil sige alt hvad der vil sikre at moduler vil samvirke problemfrit.

Dårlig engelsk over ringe telefonforbindelse giver flere misforståelser.

Igen: Dette afslører inkompetence, en beskrivelse af en ansættelse af outsourcede ansatte der ikke skulle have været ansat. »Ringe telefonforbindelse« er også en afsløring, at man har undladt at skabe en dedikeret forbindelse med en garanteret båndbredde.

Mere spildtid på buildproblemer.

Hvad menes der her, kompilering af færdige komplette brugbare produktversioner? I så fald: Ja, man har sig et problem, hvis man kun tildeler et versionsnummer til det overordnede produkt. Man skal sørge for at give versionsnumre også til alle moduler (herunder de outsourcede moduler) og holde styr på al historik for disse moduler. Kun således kan man styre modningen af et produkt, før man frigiver det til markedet.

Jeg kan huske, at en chef i en koncern engang sagde til mig, og dette var hans erfaring, hans visdom, at det kun var muligt at lave projekter hvis alle deltagere var danskere. Som var fatalt for mig at lytte til, for koncernen havde engelsk som koncernsprog og de fleste ansatte befandt sig i udlande. I den koncern var der også andre faresignaler, for eksempel virkede intranettet ikke, og der var ingen telefonlinier eller datalinier med garanterede båndbredder, som betød at kommunikation med udenlandske kollegaer ofte slet ikke var muligt pr. langdistance, og som betød at rejser var nødvendige, med evigheder af tidsspild. I softwareprojekter var der kun ingeniører ansat, aldrig dataloger, dette med argument bag at ville spare penge, som, man tager sig til hovedet.

  • 0
  • 0

Hvis man satsede på at få de bedste Indiske ingeniører til halv dansk timepris frem for til en 1/10 dansk timepris, så kunne man få nogle der også havde vestlig kulturforståelse og som ikke jobshoppede videre efter 3 måneder. Envidere vil det være en god ide, at selv ansætte inderne frem for at have et firma ind i mellem, der skal tjene penge på det. Det giver først og fremmest for mange uærlige svar i forbindelse med leverancer.

Dem der satser på rusland, Indien og Kina uden at fokusere på lave timepriser, dem spår jeg en god fremtid.

Omvendt dem der benhårdt satser på lave timepriser, de begynder sikkert snart at se mod syd til f.eks. Nigeria
(her har de længe været teknologisk førende indenfor email....).

Skal vi ikke bare nedlægge alle vores ingeniøruddannelser, når vi kan få så mange billige ingeniører fra udlandet ?.
Så kan vi leve som romerne i romerrigets sidste dage.

  • 0
  • 0

Kvalitet koster penge alle steder!

Nej, kvalitet koster tid, men mere tid koster ikke nødvendigvis flere penge, hvis man elsker sit arbejde.

  • 0
  • 0

Det er også et spørgsmål om hvilke kompetencer man vil opbygge internt og hvad man vil købe sig til.

  • 0
  • 0

Så kan vi leve som romerne i romerrigets sidste dage.

Det gør vi sådan set allerede: "Gamet" er at "Vesten" skal levere IP og Kapital til "Barbarerne" som så til gengæld skal producere varer som vi kan forbruge.

Det holder sådan cirka indtil een eller anden simpelthen (uden konsekvenser - for vores hære har for travlt med at tabe krige mod simple bønder til at beskæftige sig med en rigtig modstander) beholder kapitalen selv, stjæler IP'en eller at USD - som er kapitalen i det spil - mister sin troværdighed.

Romeriget røg ned primært på grund af outsourcing af kornproduktionen, sekundært på grund af udbredt korruption. Den outsourcede kornproduktion udkonkurrede de lokale bønder som holdt op med at producere korn; da barbarerne gjorde oprør opstod der mangel på mad i Rom - som naturligvis ledte til optøjer og revolution så da barbarerne så invaderede kunne man ikke længere rejse en hær og smide dem ud igen.

  • 0
  • 0

Kræver klare specifikationer og interfaces.

Og ikke mindst testvektorer. Når der skrives specifikationer, skal der også udvikles test programmer, eller test vektorer, der afprøver applikationen. Kun hvis applikationen opfylder samtlige tests er den godkendt. En del af disse tests, skal udviklerne naturligvis have, og deres arbejde er først godkendt, når testvektorerne er bestået. Dertil, har man ekstra sæt vektorer til eget brug, eller programmet til at lave ekstra testvektorer eller nye tests, som bruges til at tjekke med.

Når specifikationerne skrives, gør det dem desuden mere overskuelige, hvis der medfølger eksempler. Disse eksempler, indeholder resultater, som programmet gerne skulle give.

I langt de fleste tilfælde kommer på et tidspunkt tiden til en ny udgave. I så fald, er det relativ nemt at opskrive testvektorer og specifikationer, og få nogle til at lave en ny udgave, der måske fungerer - i modsætning til den første udgave, der oftest er fyldt af fejl.

Er der brug for en tredie udgave, kan de samme test vektorer, og specifikationer gives til et tredie hold, og programmernes resultater sammenlignes. I de fleste tilfælde, vil derved kunne opdages programmeringsfejl. Eneste krav det sætter, er at udviklingsværktøjer (programmeringssprog, og operativsystem) er deterministisk. Det er de fleste programmeringssprog designet til, da de ellers ikke kan bruges seriøst, på grund af problem med bevisføreslen.

Vil man bruge dobbelt tid, er således nemt at udvikle dobbelt (med uafhængige hold, og det er bedst at outsource mindst et af disse, eller begge hold), og dermed opnå at forskellige holds resultat kan sammenlignes med hinanden på deffinerede deterministiske grænseflader, og derved opdage om der er kodefejl. Dette kræver naturligvis lavere lønninger. Men resultatet er færre fejl, da programmørerne først får deres arbejde godkendt, når der ikke opstår fejl, og at der er udført tilstrækkeligt mange tests, til at enhver linie, og enhver branch, har været gennemgået overalt. Ofte er nemmere at opdage fejl, end hvis der haves manuelle tests.

Outsourceing vil derfor normalt kunne føre til færre fejl, da det muliggør uafhængig kode.

  • 0
  • 0

Nå da. En interessant liste.

Ja bestemt.

Forskellige tidszoner gør det sværere at koordinere.

I mange tilfælde kan det faktisk gøre tingene nemmere. Her har vi 5-6 timers tidsforskel, hvilket gør at alle de ting man normalt ikke ville gøre i "åbningstiden" har vi mulighed for at gøre før frokost.

Der er ekstra omkostninger til hoteller, forplejning, flybilletter, når man skal mødes til status og vidensoverdragelse.

I de 4 år jeg har arbejdet for en dansk virksomhed har jeg været hjemme een enkelt gang. Fra DK kommer de en gang om året, ofte lidt sjældnere.
Det er absolut ikke et krav at man skal se hinanden for at kunne overdrage viden. Men det kræver dog et ordenligt internet, så man kan holde møderne.

Svindel med eksamenspapirer. Er ikke dataloger, ingeniører, etc.

En beskrivelse af en inkompetent ansættelsesprocedure.

I aller højeste grad en beskrivelse af inkompetent ansættelsesprocedure.

Det er mere tidskrævende at koordinere aktiviteterne via emails, chat, online whiteboards istedetfor at mødes.

Videnstunge udviklingsprojekter kan stort set slet ikke løftes medmindre at de bliver baseret på skriftlig interaktion imellem samtlige deltagere

Jeg vil nu give ret i at det tager mere tid at koordinere aktiviteterne via elektronisk vis, fremfor bare at gå ind på den andens kontor og snakke. Derudover undgås dette ikke selv om der er en massiv stak skriftlig interaktion. Derimod skal der kun gøres med de ledende medarbejdere og om større ting, eftersom alle detaljerne som regel tages lokalt.

Høj personaleomsætning er gift for udviklingsprojekter, da det tager tid at opbygge viden igen.

Ja, i allerhøjeste grad. Men grunden til den store personale omsætning er 2 ting... At man ikke følger lønudviklingen i forhold til andre outsourcing projekter, og at mange outsourcing projekter typisk behandler deres medarbejdere som lort. Istedet burde de give dem ansvarsfølelse og ejerskabsfølelse overfor den vare de producerer.

Kræver klare specifikationer og interfaces. I moderne Agile udviklingsprocesser bliver der mere klarhed for hvert inkrement der gennemføres hen imod en release. Outsourcing egner sig nok mest til opgaver der lader sig klart og tydeligt specificere i starten af forløbet.

Nej, det er et meget snævert syn at have på tingene. Outsourcing af en enkelt lille specifik opgave er bedst hvis det er klart og tydeligt specificeret, men på den anden side, sådan er det også når du vil have en kollega til at klare dine opgaver...
Hvis du antager at folk skal kunne forstå din samlede vision i nogle få udvekslinger, så er dit outsourcing eventyr ovre før du ved det. Der må en kontinuerlig opfølgning på.
Men igen, hvordan er det anderledes end at skulle sende en opgave til en anden afdeling i virksomheden?
Det problem som man oftest ser at at virksomheder outsourcer en opgave, og antager at den på magisk vis vil leve op til de forventninger de havde til den. Istedet skulle de se det som at de åbner en afdeling i et andet land, og de er nød til faktisk at styre denne.

Det er tungere at rette softwarefejl pga. langsommere kommunikation imellem parterne. Man kan ikke mødes om whiteboardet og lave en hurtig afklaring. Fejlen skal beskrives og dokumenteres i detaljer for at modparten kan finde ud af hvad der er sket og forstå sammenhængen.

Tungere? Det kommer da vist an på hvad du mener. Hvis du bygger en kæmpe maskine op omkring din fejlhåndtering, så ja. Tager det virkelig så lang tid at skrive 2 sætninger om hvad der er galt? Og hvorfor gør du ikke det når din "mand" er i samme bygning istedet for at spilde hans tid med at skulle gå op til dig, se hvad du laver af problemer og så skulle gå ned og løse det.

Dårlig engelsk over ringe telefonforbindelse giver flere misforståelser.

Det kan absolut anbefales at der er minimum 2 permanent udsendte medarbejdere fra virksomheden, således at den primære udveksling af denne type misforståelser slet ikke opstår.

Mere spildtid på buildproblemer.

Hvis du outsourcer til en virksomhed som ikke engang kan finde ud af når deres builds fejler, hvordan vil du så kunne udveksle viden.

Din post tyder åbenlyst på at I tidligere har haft en virkelig ringe outsourcing erfaring, og at I i virkeligheden intet har lært af den.

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten