Her er Danmarks fem bedste CIO’er lige nu:Se de fem nominerede til prisen som Årets CIO 2024

Maersk Lines kuldsejlede it-projekt

En kædereaktion af uheld og fejlvurderinger udløste it-skandalen hos A. P. Møller – Mærsk. Historien handler om fejldispositioner, organisatorisk rod samt et pludseligt og voldsomt behov for computerkraft.

Tilbage til artikel-oversigten: It-arven hos A.P Møller.

Det var en overraskende åbenhed, der prægede ledelsen hos A. P. Møller – Mærsk, da koncernen offentliggjorde sit halvårsregnskab for lidt over en måned siden.

Tilsyneladende i hvert fald.

Selv om regnskabet stadig var skæmmet af de voldsomme it-problemer, som containerrederiet har bøvlet med i snart halvandet år, havde koncernen kørt flere topchefer i stilling i forsøget på verbalt at nedskyde enhver tvivl om it-systemet og mane rygtestrømme om fortsatte problemer effektivt i jorden.

Et eksempel på åbenheden illustreres blandt andet af reaktionsevnen.

For en koncern, hvor det er mere reglen end undtagelsen med venlige, kortfattede skriftlige afslag på interviewforespørgsler, var det yderst bemærkelsesværdigt, at regnskabsdirektør Per Møller ringede tilbage fem minutter efter en telefonisk forespørgsel.

It-systemet blev også nævnt af administrerende direktør Jess Søderberg og finansdirektør Søren Thorup Sørensen på en telekonference og i flere medier.

En ny åbenhedsstrategi? Og dog. For den havde sine grænser.

Grænser for åbenheden

Der blev ikke afsløret mange detaljer, som ellers ville kunne give aktionærerne et indblik i selskabets tilstand.

En ny ting kom dog frem: For første gang erkendte A. P. Møller – Mærsk, at store dele af it-systemet reelt først blev implementeret i juli i år – halvandet år efter integrationen af P&O Nedlloyd.

Der var især tale om faktureringsdelen og import-delen af de it-systemer, der har været de helt store smertensbørn for virksomheden.

Men hvordan kunne det gå så galt, at store dele af systemet måtte vente med at komme på plads til i år – med den konsekvens, at Maersk Line røg ud i en kæmpe finansiel krise, der senere kostede flere topledere jobbet i A. P. Møller – Mærsk Gruppen?

Computerworld har via kilder, der ønsker at være anonyme, forsøgt at komme lidt tættere på, hvad der egentlig skete bag de ellers nærmest hermetisk lukkede mure i koncernen.

Via kilder tæt på projektet er vi dykket ned i maskinrummet for at se nærmere på udviklingen af selve it-systemet.

For ganske vist gabte A. P. Møller over lidt for meget, da koncernen valgte at implementere systemet, samtidig med integrationen af P&O Nedlloyd.

Men meget tyder på, at systemet ikke var helt velfungerende, da det blev leveret til Maersk Line – blandt andet på grund af kapacitetsproblemer, organisatorisk bøvl og medarbejderflugt.

Begynder i 2002

Historien begynder i 2002. Da går Maersk Sealand, der senere omdøbes til Maersk Line, i gang med en stor og ambitiøs udskiftning af systemporteføljen.

De gamle applikationer er baseret på en IBM-mainframe. Med fremtidige briller vil systemerne være ufleksible og for dyre at vedligeholde på længere sigt.

Samtidig er systemerne baseret på såkaldt batch-håndtering. Shippingmedarbejderne skal ind i mange forskellige systemer for at håndtere en containerfragt fra A til B.

Ved at smelte det hele sammen i et system, er der mange åbenlyse fordele:

For det første ville systemet kunne optimere anvendelsen af hver enkelt container på verdenshavene.

For det andet ville det give kunderne mulighed for at følge fragten i real-tid.

Og for det tredje kunne store backoffice-funktioner placeres i store, globale servicecentre.

Planen bliver derfor at udvikle en ny generation af applikationer på en moderne platform.

Den nye tekniske platform består af Sun-servere med Oracle RDBMS og Hitachi SAN. Applikationerne skal afvikles i en såkaldt 3-tier arkitektur.

De nye applikationer bliver organiseret i en række projekter. De største er MLIS, GCSS og MARS (se boks), men der er også en række mindre projekter.

Trimmer organisationen

Tilsyneladende bliver der gjort en stor indsats for at få forløbet til at glide bedst muligt.

Maersk Sealand etablerer en organisation, som skal modtage og integrere de nye applikationer i organisationen.

Der bliver oprettet en såkaldt facility management-afdeling, som definerer infrastrukturen og forhandler kontrakter med leverandøren.

Det er primært Mærsk Data Transport, som skal levere de nye it-systemer.

Hos Maersk Sealand bliver der oprettet et team pr. projekt – for eksempel inden for MLIS.

De enkelte team er bemandet med en tung projektleder, og en masse unge leder-aspiranter fra Maersk, der typisk er under 30 år.

De kommer til Danmark fra hele verden og bidrager med en masse praktisk erfaring.

Idéen er, at de skal deltage i projektet i ét til to år og herefter tage hjem og være en slags evangelister, som skal tale systemets sag i deres hjemland.

Dårligt samarbejde

Hos Mærsk Data Transport opbygges en tilsvarende projektstruktur med drift- og udviklingsteam.

Men ifølge en kilde begynder flere ting at kikse:

Driftsafdelingen er i begyndelsen meget lille, da de grundlæggende ydelser købes hos DMdata. Samtidig outsources en del af udviklingsopgaverne til underleverandører og en del klares internt.

Efterhånden som udviklingen skrider frem, bliver den interne driftsafdeling udvidet internt, fordi DMdata ikke er i stand til at levere den forventede service.

En del af forklaringen er ifølge en kilde, at DMdata er organiseret afdelingsvis i siloer ud fra teknologier som for eksempel Unix, Windows, Oracle Databaser, SQL Server, SAN og netværk.

Det betyder – ifølge kilden – at når en banal opgave for Mærsk Data skal løses, kræver det nærmest en hel projektorganisation at koordinere DMdata.

Alle opgaver indebærer et komplekst samarbejde mellem mange juridiske enheder – og i praksis viste det sig næsten umuligt, fortæller kilden.

Konsekvensen bliver, at samarbejdet mellem Mærsk Data og DMdata reelt kun fungerede tekniker og tekniker imellem – ledelses-lagene var mere eller mindre brudt sammen, forlyder det.

Redningsaftale

I det sidste halve år før IBM køber DMdata og Mærsk Data forhandler Mærsk Data Transport og Maersk Sealand en ny facility management-aftale, en såkaldt ISA (integrated service agreement).

Det sker som en konsekvens af, at de nye forretningskritiske systemer for Maersk Sealand ikke kører optimalt.

Aftalen pålægger eksempelvis Mærsk Data en stor bod, hvis systemerne er utilgængelige i længere tid end specificeret.

Da IBM i 2004 køber Mærsk Data og DMdata, arver den amerikanske koncern både ISA-aftalen, det dårlige samarbejde og et kæmpe udviklingsprojekt for Maersk Sealand.

I sig selv indebærer opgaven store udfordringer, som ikke bliver mindre.

Kun et år senere køber Maersk Sealand verdens tredje-største rederi, P&O Nedlloyd, hvilket betyder en dramatisk vækst i containtervolumen.

Behovet for at få de nye it-systemer på plads vokser hastigt.

Planen for integrationen er ifølge en kilde ekstremt ambitiøs. Blandt andet stiller
Maersk Sealand meget store krav, som det senere skal vise sig at være umulige at gennemføre.

De nøgleressourcer hos IBM og Maersk Sealand, der kunne have gennemført integrationen af P&O Nedlloyd, var allerede 100 procent allokeret til de igangværende projekter.

En kilde fortæller, at stemningen i første omgang var positiv efter medarbejderne fik at vide, at IBM købte Mærsk Data.

Men virkeligheden bliver en anden.

Fortsat store problemer

I det første år var det ‘business as usual’. Dog havde de enkelte medarbejdere meget store frihedsgrader, fordi de formelle ledelsesslag ikke fungerede optimalt.

Sommetider havde en afdelingsleder for eksempel 100 direkte ansatte, fordi organisationsplanen hele tiden blev lagt om, fortæller en kilde.

Til gengæld er projektorganisationen robust i efteråret 2005 – umiddelbart før Maersk Sealand skal integrere P&O Ned­lloyd.

På daværende tidspunkt er der drejet på alle organisatoriske skruer for at få projektet på skinner – og der er ikke mere at give af på den konto.

På applikationssiden er historien en anden. Her bliver foretaget en voldsom mængde ændringer, som giver en kaskade af problemer for Maersk Sealands forretning. Der er blandt andet nedetid og funktionelle fejl.

Desuden vokser kapacitetskravene kraftigt fra år til år og ligger lige på grænsen af, hvad serverparken kan håndtere.

Kravet til CPU-forbruget vokser voldsomt. I forhold til 2004 stiger CPU-behovet i 2006 med 300 procent og i 2007 med 450 procent.

Årsagen er store ændringer i systemerne, der blandt andet medfører, at Maersk Sealands forretninger i perioder står helt stille, indtil der er ryddet op.

Frustrationerne vokser

IBM bruger derfor mange ressourcer på at genforhandle ISA-aftalen, oplyser en kilde til Computerworld. Ifølge en anden kilde vokser frustrationerne hos IBM, der har svært ved at følge kravene fra leverandøren.

Opfattelsen hos IBM er, at en del af problemerne er Maersk Sealands egne høje ambitioner.

I begyndelsen af 2006 går integrationen af it-systemerne for alvor i gang.

Det viser sig at være en alt for stor mundfuld, og store dele af systemet rulles tilbage, blandt andet fordi der ifølge en kilde er nogle uhensigtsmæssigheder i systemet, der gør, at import-delen og eksport-delen ikke taler ordentligt sammen.

Herefter begynder den lange seje proces med at få systemet på plads. Samtidig rammes kunderne af fejlagtige fakturaer med forkerte fragtrater, fordi medarbejderne reelt arbejder i to komplet uafhængige systemer.

Utilfredsheden hos Maersk Lines kunder breder sig.

Medarbejderne flygter

Samtidig foregår der et stort genopretningsarbejde bag kulisserne. Selv om A. P. Møller i august 2006 bedyrer, at systemet for så vidt er godt nok, men at problemet er oplæring af egne medarbejdere, arbejdes der intenst hos IBM for at løse detaljerne.

Men opgaven er ikke let, for samtidig begynder IBM nu for alvor at få kontrol over de tidligere medarbejdere hos DMdata og Mærsk Data Transport. Resultatet er en medarbejderflugt.

Fakta: It-arven hos A. P. Møller
5. november tiltræder Nils Smede­gaard Andersen som ny topchef i A. P. Møller – Mærsk Gruppen, og fra dag ét skal han navigere i slipstrømmen af en bekostelig it-skandale hos Maersk Line.

Fakta: De nye it-systemer
MLIS
Maersk Line Invoicing System er et faktureringssystem til containertransport. Det er bygget på standardsystemet Oracle Financials, men kraftigt tilpasset Maersk Sealands cirka 50 interfaces til andre systemer.

GCSS
Bookingsystem til containertransport. Maersks kunder kan booke direkte gennem dette system via web eller direkte integration a la webservices, men systemet er også centralt i forhold til at følge transporten. Systemet er specialudviklet til Maersk Sealand og har haft en lang og problemfyldt udvikling.

MARS
Prissætningssystem til containertransport.

Fakta: Aktørerne
Mærsk Data Transport.
Det gamle Mærsk Data havde flere selvstændige forretningsenheder, men Mærsk Data Transport som havde fokus på kunden Maersk Sealand var den vigtigste både i omsætning og indtjening.

DMdata.
DMdata var ejet af Mærsk Data, Danske Bank og WM-data. Selskabet blev grundlagt som et facility management-selskab med den opgave at kunne løse tunge driftsopgaver for landets største virksomheder. En del af kontrakten var naturligvis, at Maersk og Danske Bank afviklede deres applikationer gennem dette selskab.

Maersk Line (før opkøbet af P&O Nedlloyd ‘Maersk Sealand’).
Containerrederiet, der er datterselskab af A.P. Møller
– Mærsk Gruppen.

Læs A. P. Møllers svar

Tilbage til artikel-oversigten: It-arven hos A.P Møller.




Brancheguiden
Brancheguide logo
Opdateres dagligt:
Den største og
mest komplette
oversigt
over danske
it-virksomheder
Hvad kan de? Hvor store er de? Hvor bor de?
Targit A/S
Udvikling og salg af software til business intelligence.

Nøgletal og mere info om virksomheden
Skal din virksomhed med i Guiden? Klik her

Kommende events
OT og IT: Modernisér produktionen og byg sikker bro efter et årelangt teknologisk efterslæb

Moderne produkter skal have mere end strøm for at fungere – og deres navlestreng skal ikke klippes når de forlader fabrikshallen. På denne konference kan du derfor lære mere om hvordan du får etableret det sikre setup når der går IT i OT.

30. april 2024 | Læs mere


Roundtable for sikkerhedsansvarlige: Hvordan opnår man en robust sikkerhedsposition?

For mange virksomheder har Zero Trust og dets principper transformeret traditionelle tilgange til netværkssikkerhed, hvilket har gjort det muligt for organisationer at opnå hidtil usete niveauer af detaljeret kontrol over deres brugere, enheder og netværk - men hvordan implementerer man bedst Zero Trust-arkitekturer i et enterprise set up? Og hvordan muliggør Zero Trust-arkitekturen, at organisationer opnår produktivitetsfordele med AI-værktøjer samtidig med, at de forbliver sikre i lyset af fremvoksende trusler?

01. maj 2024 | Læs mere


ERP-trends 2024

Bliv derfor inspireret til, hvordan du kan optimere dine systemer og processer når af nogle af de fremmeste eksperter på ERP-markedet dele deres iagttagelser af det aktuelle marked og vurderinger af, hvad vi har i vente de kommende 3-5 år. Vi sætter også fokus på, hvordan udviklingen kommer til at påvirke din organisation, hvordan du bedst forbereder og planlægger ERP-indsatsen og om, hvilke faldgruber du skal være opmærksom på.

02. maj 2024 | Læs mere