Erhvervsøkonomisk Institut Forfattere: Kandidatafhandling Morten Gunnersen Cand.merc.(dat.) Las Øhlenschlæger Olsen Vejleder: Pernille Kræmmergaard Jensen

Væsentlige kritiske succesfaktorer i globale Enterprise Resource Planning

implementeringer

Handelshøjskolen i Århus

2006

Forord Gennem vores cand.merc.(dat.) studie, har der været meget fokus på emneområdet ERP. Dette gav

os inspiration til at skrive indenfor ERP området og specielt omkring implementeringen af ERP

systemer, på grund af at vi til stadighed hørte om projekter der sprang både budget- og tidsrammer.

Nærværende afhandling tager udgangspunkt et litteraturstudie omkring kritiske succesfaktorer i

globale ERP implementeringer.

Gennem udarbejdelsen af afhandlingen har der været en række personer involveret. Vi vil i denne

forbindelse gerne takke Henrik Weis Aalbæk fra LEGO og John B. Nielsen fra Grundfos for deres

deltagelse og engagement samt Brian Jensen for værdifuld information. Derudover vil vi gerne

takke Heino Lejel Jensen, Jan Stie, Dennis Cassøe samt Kirstine Trøst Jørgensen for deres

konstruktive kritik. Sidst men ikke mindst vil vi gerne takke Pernille Kræmmergaard Jensen for

positiv og konstruktiv vejledning gennem hele forløbet.

Morten Gunnersen

Århus d. 15. juni 2006

Las Øhlenschlæger Olsen

Århus d. 15. juni 2006

Abstract During the last decade, ERP systems have become a major topic within the research field of

information technology. One of the reasons for this is the problems which enterprises have with

implementing these systems. According to a survey conducted by the Standish Group [URL 1] in

1994, only 16 % of all IS projects were successful based on time and budget. A decade later, the

number had risen to 29 % [URL 2]. It is therefore interesting to identify areas on which

firms/enterprises must focus in order to make the number of successful implementations increase

even further. In 2001, Nah et al. did a literature review, whose goal was to identify critical success

factors for ERP implementations. They identified 11 factors which were deemed critical. Their

studies do, however, not explicitly state under which condition they are valid, e.g. under stand alone

or global implementations.

As enterprises increasingly choose to implement ERP systems globally; i.e. several companies are

integrated into one big global system, it is interesting to examine which critical success factors are

relevant when dealing with global implementation. This thesis examines which critical success

factors are essential in a global ERP implementation context. In addition, this thesis examines what

companies today mean by the relative term success in this context, and whether or not the success

criteria has any influence on which critical success factors enterprises focus on.

This thesis first outlines the 11 critical success factors identified by Nah et al. (2003), which are

considered to be universal for ERP implementation in general. Secondly, a literature study is

performed. The goal of this literature study is to identify critical success factors for global ERP

implementations and confirm or disprove the universal nature of Nah et al.’s (2003) critical success

factors. The articles in this literature study need to contain the term “Enterprise resource planning “

or “ERP” and one of the following words “global”, “international” or “multinational” in the title.

Nine articles were found in electronic article databases at the Aarhus School of Business by means

of search on these terms, and the 11 critical success factors identified by Nah et al (2003) were

found to prove to be correct for global ERP implementations. Besides a confirmation of these

factors, two other main factors are identified. These are Politics and Culture. The 13 critical success

factors are classified in two groups: essential and less essential critical success factors in a global

ERP implementation. The classification does not mean that the less essential should be disregarded,

but it implies that they are not necessarily as crucial for a successful global ERP implementation as

the essential ones. The classification is based on the number of references by both the global

literature study, the study performed by Nah et al. (2003) and IT executives rating of Nah et al.’s

(2003) critical success factors. Eight critical success factors are identified as being essential to

global ERP implementation. These are Business plan and vision, Business Process Reengineering,

Change management and culture, Culture, ERP teamwork and composition, Politics, Project

management and Top management support. The five critical success factors which have been

identified as being less essential are: Appropriate business and information technology legacy

systems, Communication, Monitoring and evaluation of performance, Project champion and

Software development, testing and troubleshooting.

Two case studies have been performed with the purpose of empirically identifying critical success

factors for global ERP implementations. The two contributing companies LEGO and Grundfos both

qualified for the study by being Danish and having a successful global ERP implementation history.

Through the case studies, six critical success factors are identified as being essential in a global

ERP implementation context. These are Alignment of business and ERP strategy, Central ERP

organization, ERP teamwork and composition, Project management, Minimum customization and

Top management support. The case study classified three critical success factors as being less

essential. These are Master data and processes, Organization mature for change and Regain trust

and credibility. The case studies also revealed that enterprises today are still concerned with being

within budget and time frame. Enterprises today focus on stable operations through the

implementing phase and not losing customers or business as a result of the implementation.

The final part of the thesis classifies the 13 critical success factors by taking into consideration both

the theoretical and empirical data. This thesis concludes that there are seven critical success factors

in a global ERP implementation context. These are Business plan and vision, Process

Reengineering, Change management and culture, ERP teamwork and composition, Project

management, Software development, testing and troubleshooting, Top management support. The

less essential critical success factors are Appropriate business and information technology legacy

systems, Communication, Culture, Monitoring and evaluation of performance, Politics and Project

champion. Whether or not the success criteria that enterprises put forward have any influence on

which critical success factors they focus on is difficult to say. The empirical data suggest that there

might be a slight correlation between the focus on budget and time and Project management.

Indholdsfortegnelse 1 Indledning.........................................................................................................................1 1.1 Problemstilling...................................................................................................................2 1.2 Problemformulering...........................................................................................................3 2 Metode og opbygning.......................................................................................................5 2.1 Valg af undersøgelsesdesign..............................................................................................5 2.1.1 Hvorfor anvende eksplorativ integration?..........................................................................5 2.1.2 Den eksplorative integrative tilgang ..................................................................................6 2.2 Afhandlingens opbygning ..................................................................................................7 2.2.1 Den teoretiske del...............................................................................................................7 2.2.1.1 Global ERP implementering ..............................................................................................8 2.2.1.2 Succesbegrebet...................................................................................................................8 2.2.1.3 Kritiske succesfaktorer.......................................................................................................8 2.2.1.4 Forventninger .....................................................................................................................9 2.2.2 Den empiriske del ..............................................................................................................9 2.2.3 Analytisk generalisering ....................................................................................................9 2.3 Dataindsamling ..................................................................................................................9 2.3.1 Kildekritik ..........................................................................................................................9 2.3.2 Udvælgelse af cases .........................................................................................................11 2.3.2.1 De udvalgte virksomheder ...............................................................................................12 2.4 Casestudier .......................................................................................................................13 2.4.1 Præsentation af casestudiet ..............................................................................................13 2.4.2 Casedesign .......................................................................................................................15 2.4.3 Forventninger ...................................................................................................................15 2.4.4 Spørgeramme ...................................................................................................................16 2.4.5 Interviews.........................................................................................................................16 2.5 Validitet............................................................................................................................17 2.5.1 Troværdighed...................................................................................................................17 2.5.2 Overførbarhed ..................................................................................................................18 2.5.3 Afhængighed....................................................................................................................18 2.5.4 Bekræftbarhed..................................................................................................................19 3 Den teoretiske del ...........................................................................................................20 3.1 ERP systemer ...................................................................................................................20 3.1.1 Historie.............................................................................................................................20 3.1.1.1 MRP .................................................................................................................................20 3.1.1.2 Udviklingen fra MRP til MRP II .....................................................................................21 3.1.2 ERP ..................................................................................................................................22 3.1.2.1 Definition af ERP systemer..............................................................................................23 3.1.2.2 Definition af implementering...........................................................................................24 3.1.2.3 Definition af global ERP implementering .......................................................................27 3.2 Succesbegrebet.................................................................................................................27 3.2.1 Correspondence failure ....................................................................................................29 3.2.2 Process failure ..................................................................................................................29 3.2.3 Interaction failure.............................................................................................................29 3.2.4 Expectation failure ...........................................................................................................29

3.2.5 De fire syn........................................................................................................................30 3.3 Kritiske succesfaktorer.....................................................................................................30 3.3.1 11 kritiske succesfaktorer.................................................................................................31 3.3.1.1 Appropriate business and information technology legacy systems .................................31 3.3.1.2 Business plan and vision..................................................................................................32 3.3.1.3 Business process reengineering .......................................................................................32 3.3.1.4 Change management culture and program.......................................................................33 3.3.1.5 Communication................................................................................................................34 3.3.1.6 ERP teamwork and composition......................................................................................34 3.3.1.7 Monitoring and evaluation of performance .....................................................................35 3.3.1.8 Project champion..............................................................................................................35 3.3.1.9 Project management.........................................................................................................36 3.3.1.10 Software development, testing, and troubleshooting .......................................................37 3.3.1.11 Top management support.................................................................................................37 3.3.2 De globale udfordringer ...................................................................................................38 3.3.2.1 Appropriate business and information technology legacy systems .................................40 3.3.2.2 Business plan and vision..................................................................................................41 3.3.2.3 Business process reengineering .......................................................................................42 3.3.2.4 Change management culture and program.......................................................................44 3.3.2.5 Communication................................................................................................................45 3.3.2.6 ERP teamwork and composition......................................................................................46 3.3.2.7 Monitoring and evaluation of performance .....................................................................47 3.3.2.8 Project champion..............................................................................................................48 3.3.2.9 Project management.........................................................................................................48 3.3.2.10 Software development, testing, and troubleshooting .......................................................50 3.3.2.11 Top management support.................................................................................................51 3.3.2.12 Politics..............................................................................................................................51 3.3.2.13 Culture..............................................................................................................................53 3.3.3 Opsummering på de kritiske succesfaktorer ....................................................................55 3.3.4 Klassifikation af de kritiske succesfaktorer i den globale kontekst .................................55 3.4 Delkonklusion ..................................................................................................................57 4 Den empiriske del...........................................................................................................59 4.1 Forventninger til feltet .....................................................................................................59 4.2 Case – LEGO ...................................................................................................................60 4.2.1 Baggrund..........................................................................................................................61 4.2.2 LEGOs erfaringer.............................................................................................................62 4.2.2.1 It’s a long Journey............................................................................................................63 4.2.2.1.1 Management commitment................................................................................................63 4.2.2.1.2 Organization mature for change.......................................................................................63 4.2.2.1.3 Masterdata and processes.................................................................................................64 4.2.2.1.4 Regain trust and credibility ..............................................................................................65 4.2.2.1.5 Protect and develop..........................................................................................................65 4.2.2.2 The path to victory is not the sexy route..........................................................................66 4.2.2.2.1 Overall structures and requirements to flexibility............................................................66 4.2.2.2.2 Scenarios for overall structures and processes.................................................................67 4.2.2.2.3 Finance, reporting, master data, flow of good etc. models ..............................................67 4.2.2.2.4 Dedicated team, big enough to solve the task, small enough to be efficient ...................68

4.2.2.2.5 Sustainable platform ........................................................................................................69 4.2.2.3 Project management.........................................................................................................69 4.2.2.4 Efterrationaliseringer .......................................................................................................70 4.2.2.4.1 Dokumentation.................................................................................................................70 4.2.2.4.2 Uddannelse.......................................................................................................................71 4.2.2.4.3 Kommunikation ...............................................................................................................71 4.2.3 Succes...............................................................................................................................72 4.3 Case – Grundfos...............................................................................................................72 4.3.1 År 2000 problemer ...........................................................................................................74 4.3.2 Implementeringsstrategien...............................................................................................75 4.3.2.1 Forretningsmodellen ........................................................................................................77 4.3.3 Den succesfulde udrulning...............................................................................................78 4.3.3.1 De store udfordringer .......................................................................................................79 4.3.4 Fremtiden .........................................................................................................................79 4.4 Sammenfatning af cases...................................................................................................80 4.4.1 De væsentlige kritiske succesfaktorer..............................................................................80 4.4.1.1 Alignment of business and ERP strategy.........................................................................80 4.4.1.2 Central ERP organization.................................................................................................81 4.4.1.3 ERP teamwork and composition......................................................................................81 4.4.1.4 Project management.........................................................................................................82 4.4.1.5 Minimum customization ..................................................................................................82 4.4.1.6 Top management support.................................................................................................83 4.4.2 De mindre væsentlige kritiske succesfaktorer .................................................................84 4.4.2.1 Masterdata and processes.................................................................................................84 4.4.2.2 Organisation mature for change.......................................................................................84 4.4.2.3 Regain trust and credibility ..............................................................................................84 4.4.3 Succeskriterier..................................................................................................................84 4.5 Delkonklusion ..................................................................................................................85 5 Analytisk generalisering................................................................................................86 5.1 Appropriate business and information technology legacy systems .................................87 5.2 Business plan and vision..................................................................................................87 5.3 Business process reengineering .......................................................................................88 5.4 Change management culture and program.......................................................................88 5.5 Communication................................................................................................................89 5.6 Culture..............................................................................................................................90 5.7 ERP teamwork and composition......................................................................................90 5.8 Monitoring and evaluation of performance .....................................................................91 5.9 Politics..............................................................................................................................91 5.10 Project champion..............................................................................................................92 5.11 Project management.........................................................................................................92 5.12 Software development, testing, and troubleshooting .......................................................93 5.13 Top management support.................................................................................................93 5.14 Succes...............................................................................................................................94 6 Konklusion......................................................................................................................95

7 Perspektivering ..............................................................................................................99 7.1 Succes i forbindelse med ERP implementering...............................................................99 7.2 Kultur ...............................................................................................................................99 8 Appendiks: Dimensioner til vurdering af failurebegreber ......................................100 9 Litteraturliste ...............................................................................................................102 9.1 Bøger..............................................................................................................................102 9.2 Artikler ...........................................................................................................................103 9.3 Rapporter........................................................................................................................106 9.4 Hjemmesider ..................................................................................................................107 9.5 Andet..............................................................................................................................107

1 Indledning Igennem de seneste år har antallet af virksomheder, der implementerer et ERP system, været stødt

stigende. Ifølge rapporten ”IT i praksis 2003” [PLS Rambøll Management, 2003] har 51 % af de

medvirkende virksomheder foretaget investeringer i ERP systemer. Af disse har over halvdelen

foretaget ”betydelige investeringer”. Virksomhederne har i større grad fokuseret på systemer, der

samler og optimerer funktionerne i organisationen i ét og samme system. Elementer som den stadigt

stigende konkurrence og globalisering tvinger virksomhederne til altid at følge med udviklingen og

optimere deres forretning for at bevare og udvide deres markedsandele.

Der investeres i disse år rigtig mange penge i ERP systemer. Det er estimeret, at der i år 2002 blev

investeret 150 mia. kr. i ERP systemer, et beløb, der ventes at vokse til 235 mia. kr. i 2006

[Rikardsson et al., 2004]. Dette afspejler sig også indenfor forskningen, der igennem de seneste ti

år1 har udvist en stadigt stigende interesse for ERP systemer. Når virksomheder investerer stadig

større beløb i ERP systemer, indikerer det samtidig en stigende interesse indenfor området.

En anden grund til forskernes stigende interesse indenfor ERP, ud over ovenstående, kan henføres

til de vanskeligheder, virksomheder har haft med at implementere disse systemer. Det er ikke

trivielt at implementere et ERP system, hvilket kan læses ud af undersøgelser foretaget af den

amerikanske Standish Group2. Undersøgelserne bygger på IT-projekter fra hele verden med

hovedvægt på USA og Europa. Selv om undersøgelserne går på IT-projekter generelt, vurderes det,

at de kan overføres til ERP implementeringer, da ERP implementeringerne er en del af den samlede

betegnelse af IT-projekter. Undersøgelsen fra 1994 viser, at 16 % af alle projekter var succesfulde,

53 % havde problemer, mens hele 31 % blev opgivet [URL 1]. Siden hen er der sket en positiv

udvikling på området, så der i 2004 var 29 %, som var succesfulde, 53 % af projekterne havde

problemer, og 18 % blev opgivet [URL 2]. Trods den positive udvikling i tallene, hvor der groft

sagt er flyttet ti procent fra de opgivne til de succesfulde projekter3, er der stadig massive problemer

med at få projekterne færdige til tiden og med de ønskede funktionaliteter. Dette understøttes i en

1 Ved en søgning på termet ERP i den videnskabelige artikeldatabase Business Source Premier fra 1996 til 2005 på full text og peer reviewed artikler steg antallet af søgeresultater eksponentielt 96=27, 97=37, 98=54, 99=72, 00=111, 01=132, 02=163, 03=230, 04=283, 05=337. 2 Amerikansk baseret virksomhed, der har specialiseret sig i evaluering af IT projekter. 3 Defineret som overholdelse af tid og budget og med den oprindeligt planlagte funktionalitet.

1

anden undersøgelse om ERP implementeringer fra 2001 foretaget af The Conference board [URL

3], en uafhængig amerikansk non-profit organisation, hvor 34 % af virksomhederne var tilfredse

med implementeringen af ERP systemet, 58 % nogenlunde tilfredse, mens 8 % var utilfredse.

Undersøgelsen inkluderede interviews med ledere fra 117 virksomheder. De store problemer, der

stadig opstår i forbindelse med implementering af IT-systemer viser, at der stadig er meget, der kan

gøres med hensyn til at finde frem til de problemer, der opstår. Det vil derfor være interessant at

beskæftige sig med implementeringer af ERP systemer og undersøge, hvad der skal til, for at en

ERP implementering bliver en succes.

Kendetegnende for ERP systemer er, at de er komplekse, hvilket de ovennævnte tal om

succesopfattelse indikerer. Ofte er virksomheder nødt til at ændre i organisationsstrukturen og

arbejdsgangene i forbindelse med indførelsen af systemet. Grundet deres kompleksitet er de meget

ressource- og tidskrævende at implementere i virksomhederne. En anden undersøgelse af The

Standish Group [URL 4] viser, at en gennemsnitlig ERP applikation koster 1,3 millioner $US, samt

at hele implementeringen typisk koster 5 gange så meget, nemlig 6,4 mio. $US. Det skal her

bemærkes, at beløbsstørrelsen vil være noget mindre i Danmark, hvor ERP implementeringer typisk

vil foregå i virksomheder i gruppen af mellemstore og store virksomheder. Dog er størrelsen af

investeringen betydelig set i danske forhold.

1.1 Problemstilling De problemer virksomheder har haft i forbindelse med ERP implementeringer, er efterhånden

veldokumenterede. Forskere indenfor ERP området er kommet frem til flere grunde til, hvorfor de

enkelte ERP implementeringer har slået fejl. Dette har udmøntet sig i nogle forskellige områder,

som virksomheder skal fokusere på, for at opnå succes i forbindelse med en ERP implementering.

Disse områder kaldes også for kritiske succesfaktorer.

De kritiske succesfaktorer skal være med til at hjælpe virksomheder med at holde fokus på de

væsentlige områder under en ERP implementering, men gælder disse kritiske succesfaktorer i alle

tilfælde? Er der forskel på, hvilke kritiske succesfaktorer der skal fokuseres på, og i hvor høj grad,

alt efter om der foretages en lokal eller global ERP implementering? Virksomheder bliver i stigende

grad mere og mere globale i takt med, at handelsmarkedet er blevet globaliseret. Dette afspejles

2

blandt andet i, at vestlige arbejdspladser flytter til lande, hvor arbejdskraften er markant billigere

[URL 13]. Derfor findes det interessant at beskæftige sig med ERP i en global kontekst.

1.2 Problemformulering Med udgangspunkt i ovenstående problemstilling ønsker vi i teori og praksis at søge svaret på

spørgsmålet:

Hvad er de væsentlige kritiske succesfaktorer i en global ERP implementering?

For at kunne svare på dette hovedspørgsmål, er det nødvendigt at se på følgende:

Definering af en global ERP implementering

Succes begrebet i forbindelse med ERP implementeringer

Kritiske succesfaktorer i ERP implementeringer

Casestudie af succesfulde globale ERP implementeringer

Først og fremmest skal der defineres to begreber - ERP og implementering. Det er vigtigt at få disse

begreber slået fast, så der gives et indblik i, hvad der i afhandlingen ligges i disse.

Udover at fastlægge ovenstående begreber skal begrebet global implementering defineres. Hvad

ligger der i, at en implementering er global? Dette afsnit er vigtigt, da begrebet er centralt i

afhandlingen.

Succes i forbindelse med implementering af ERP systemer er som udgangspunkt et relativt begreb.

Begrebet afdækkes teoretisk og danner udgangspunktet for at se på succesopfattelsen i

casevirksomhederne. Succes er relevant at afdække empirisk, da virksomheders syn på succes kan

have indflydelse på, hvilke kritiske succesfaktorer der skal fokuseres på i forbindelse med

implementeringen.

Efter disse begrebsafklaringer vil vi kigge på kritiske succesfaktorer i forbindelse med ERP

implementeringer. Her vil vi afdække, hvilke kritiske succesfaktorer, der ifølge litteraturen er

vigtige for at skabe en succesfuld ERP implementering. Som en naturlig forlængelse heraf vil vi

3

foretage et litteraturstudie af artikler omhandlende globale ERP implementeringer, og analysere

disse med hensyn til de kritiske succesfaktorer. Endvidere vil de kritiske succesfaktorer blive

klassificeret i grupperne væsentlige og mindre væsentlige.

Med udgangspunkt i de teoretiske overvejelser vil vi derefter udføre empiriske studier i

virksomheder, der har foretaget succesfulde globale ERP implementeringer. Disse studier har til

formål at undersøge, hvordan virksomhederne griber deres implementeringer an, og hermed hvilke

kritiske succesfaktorer, de mener, er vigtige i en global ERP implementering. Den empiriske del vil

tillige med den teoretiske klassificere de kritiske succesfaktorer i væsentlige og mindre væsentlige

for som afslutning at komme med en samlet vurdering af, hvad der er de væsentlige kritiske

succesfaktorer i en global ERP implementering.

4

2 Metode og opbygning Nærværende afsnit har til formål at beskrive afhandlingens metodiske tilgang og opbygning. Dette

gøres for at give læseren et indblik i de valg, der er truffet samt hvilke konsekvenser, det har for

indhold og opbygning. Afsnittet er derudover med til at underbygge, hvorledes

problemformuleringen vil blive behandlet ved at skabe en overskuelig og naturlig struktur.

2.1 Valg af undersøgelsesdesign Dette underafsnit beskriver den tilgang, vi har valgt i denne afhandling. Afsnittet klarlægger

forskellige undersøgelsesdesign og argumenterer for, hvilket vi har valgt. Dette er med til at give

læser et overblik over den metode, der anvendes og dermed at give indsigt i opbygningen af

afhandlingen.

Med udgangspunkt i Maaløe (2002) findes der fire forskellige undersøgelsesdesign: etnografi,

teoritest, grundfæstet teori og eksplorativ integration. Det undersøgelsesdesign, der anvendes i

denne afhandling, er eksplorativ integration. Efterfølgende uddybes, hvorfor dette

undersøgelsesdesign anvendes i afhandlingen.

2.1.1 Hvorfor anvende eksplorativ integration? Etnografi er studier af bestemte grupper af mennesker; det være sig en stamme i en ukendt del af

verden, en bestemt gruppe i samfundet eller i en virksomhed. Denne tilgang kræver, at undersøger

placerer sig i feltet igennem længere tid4. Teoritest går ud på at opstille hypoteser, som kan testes.

Teoritest er meget positivistisk og kan låse undersøgeren, så vedkommende ikke kommer frem til

de reelle grunde til, hvordan tingene forholder sig, da vedkommende ikke kan gå ud over sine

hypoteser. Ved grundfæstet teori søges det gennem observation at komme frem med en teori uden

nogen forudfattet teoriforståelse. Denne tilgang kræver meget tid af undersøgeren5, da undersøger

skal opholde sig meget i det miljø, der ønskes undersøgt, før vedkommende kan præsentere nogle

resultater. Med eksplorativ integration tager undersøger udgangspunkt i den eksisterende teori. På

baggrund af teorien præsenteres forventningerne til undersøgelsen, hvilket kan gøres ved at opstille

nogle løse eller sammenknyttede teser, grafisk illustrere sammenhænge eller skrive et scenario.

4 Dette være sig fra uger til, i ekstreme tilfælde, flere år. 5 Dog mindre end under etnografi.

5

Denne præsentation skal ikke ses som noget, der skal testes som under teoritest, men mere bruges til

at åbne undersøgers øjne. Derved er det muligt løbende at tilpasse undersøgelsen. Med eksplorativ

integration ønskes det ikke at be- eller afkræfte forskellige teorier, men at udvide den eksisterende

viden på det undersøgte område.

Da vi ikke ønsker at undersøge en bestemt gruppe af mennesker, men undersøger nogle kritiske

succesfaktorer i forbindelse med ERP implementering, befinder vi os udenfor rammen for et

etnografisk studie. Denne tilgang finder dermed ikke anvendelse i denne afhandling. Afhandlingen

går udover definitionen af, hvad grundfæstet teori er, da vi i den første del af afhandlingen opstiller

teori i form af kritiske succesfaktorer, der er væsentlige i en global ERP implementering. Teoritest

virker mere oplagt til afhandlingens formål; dog med den ulempe, at det binder undersøgelsen til

kun at koncentrere sig om at be- eller afkræfte hypoteser. Da vi ikke ønsker at binde os til bestemte

opstillede kritiske succesfaktorer, hvilket ville forhindre os i at være åben overfor feltet, udelukkes

teoritest som undersøgelsesdesign. Derfor, med udgangspunkt i ovenstående gennemgang af de

forskellige undersøgelsesdesigns, mener vi, at den eksplorative integrative tilgang passer bedst til

det, vi ønsker at undersøge.

2.1.2 Den eksplorative integrative tilgang Den eksplorative integrative tilgang er sammensat af to af de tidligere nævnte

undersøgelsesdesigns, grundfæstet teori og teoritest [Maaløe, 2002]. De to undersøgelsesdesigns er

hinandens modsætninger, men i den eksplorative integrative tilgang er de blevet integreret for at

skabe en mere realistisk ramme omkring casestudierne, samt for at få det bedste fra de to

undersøgelsesdesigns samlet i ét design.

I den eksplorative integrative tilgang findes elementer fra henholdsvis teoritest og grundfæstet teori,

som enten anvendes eller forkastes. Fra teoritest er der holdt fast i kravet om at have et teoretisk

udgangspunkt. Dette medfører derfor også, at udgangspunktet for grundfæstet teori om ikke at have

kendskab til feltet forkastes. Med hensyn til cases søger tilgangen at holde fast i grundfæstet teoris

åbenhed overfor det undersøgte, og derfor forkastes teoritestens ambition om udelukkende at be-

eller afkræfte opstillede hypoteser. Denne integrering af de to tidligere undersøgelsesdesigns

medfører, at undersøger skal være særlig opmærksom på nogle punkter, blandt andet undersøgers

personlige bias [Maaløe, 2002]. Med personlig bias menes ”Forskeres ofte ubevidste ukendskab,

6

henholdsvis forudindtagethed af bestemte teorier og/eller optagethed i eget personligt spind af

projektioner, og stereotyper” [Maaløe, 2002]. Det vil sige, at undersøger til stadighed skal prøve at

ane sin egen personlige bias og arbejde med at åbne sig for andre end sine egne umiddelbare

slutninger. For det andet skal undersøger ved brug af denne tilgang have gjort sig tanker om, hvilke

resultater undersøgelsen kan tilvejebringe, og eksplicit have beskrevet disse [Maaløe, 2002]. Dette

gøres for som undersøger at danne sig et billede af, hvad det er, man står over for at skulle

undersøge.

Vi arbejder i denne afhandling med vores personlige bias ved at bruge hinanden som

sparringspartnere. Derved søger vi hver især ikke at stirre os blinde på en bestemt fortolkning.

Derudover søger vi i vores undersøgelse at være åbne overfor andre slutninger, end de for os

umiddelbare. For at sikre os mod fejltolkninger tilbyder vi i forbindelse med vores interviews at

sende de skrevne cases til gennemlæsning hos vores informanter. Med hensyn til på forhånd at gøre

sig tanker om det undersøgte opstiller vi, inden vi foretager interviewene, forventninger til det

undersøgte område. Disse forventninger skal være med til at åbne vores øjne for det undersøgte og

til ikke at låse os i nogle faste rammer.

2.2 Afhandlingens opbygning Afhandlingen er opbygget i tre dele. Den første del er den teoretiske del, hvor vi fastlægger de

forskellige begreber og foretager et litteraturstudie af globale kritiske succesfaktorer. Den anden del

er den empiriske del. Her foretages på baggrund af litteraturstudiet to casestudier i virksomheder,

der har gennemført globale ERP implementeringer. I den tredje del sammenholdes de teoretiske og

empiriske studier, og der foretages en analyse, der munder ud i at svare på afhandlingens

hovedspørgsmål. Sidste del af afhandlingen består af/rummer en samlet konklusion samt en

perspektivering over emnet.

2.2.1 Den teoretiske del Den teoretiske er del er opdelt i tre dele. Global ERP implementering, succesbegrebet og kritiske

succesfaktorer.

7

2.2.1.1 Global ERP implementering Introduktionen til globale ERP implementeringer startes ud med en kort gennemgang af den

historiske baggrund for ERP systemet, og en beskrivelse af, hvad et ERP system er. Derefter

defineres det i afsnit 3.1.2.1, hvad der i denne afhandling forstås ved et ERP system.

Med begrebet ERP på plads bliver begrebet implementering beskrevet i afsnit 3.1.2.2, samt hvad

dette betyder i en ERP sammenhæng. Der gennemgås her tre fasemodeller for at præcisere, hvad

der i denne afhandling forstås ved en implementering, herunder hvad de forskellige faser i en

implementering indeholder.

Det sidste begreb, global ERP implementering, beskrives i afsnit 3.1.2.3. Dette gøres ud fra en

definition af, hvad der ligger i ordet global.

2.2.1.2 Succesbegrebet Teoretisk ønsker vi at vise, hvor relativt begrebet succes er i forbindelse med globale ERP

implementeringer. Dette gøres ved en gennemgang af fire syn præsenteret af Hirschheim et al. i

artiklen Information system failures – a survey and classification of the empirical literature fra

bogen Oxford surveys in information technology fra 1987.

2.2.1.3 Kritiske succesfaktorer De kritiske succesfaktorer er det teoretiske omdrejningspunkt i denne afhandling. Der tages

udgangspunkt i reviewartiklen ERP implementation: Chief information officers’ perceptions of

critical success factors fra 2003 af Nah et al. Denne artikel er en udvidelse af deres tidligere artikel

critical factors for successful implementation of enterprise systems fra 2001 af Nah et al. Artiklen

introducerer 11 kritiske succesfaktorer, der er vigtige i forbindelse med en ERP implementering.

Ovenstående artikel har ikke eksplicit fokus på globale ERP implementeringer. Derfor foretages der

efterfølgende et litteraturstudie med specifik fokus på globale ERP implementeringer. Dette studie

foretages på baggrund af videnskabelige artikler6.

6 Se nærmere kriterier for litteratursøgningen i afsnit 2.3.1

8

2.2.1.4 Forventninger På baggrund af teorien opstilles der forventninger til casestudierne. Formålet med dette er at danne

et billede af, hvad vi forventer at finde frem til i forbindelse med casestudierne.

2.2.2 Den empiriske del Den empiriske del består af to casestudier. Casene præsenterer virksomhederne og deres globale

ERP implementeringer, herunder hvad de fokuserer på i denne sammenhæng. Efter gennemgangen

af de to cases sammenfattes de, og de væsentligste kritiske succesfaktorer udledes. Herunder

sammenholdes casevirksomhedernes succeskriterier for at anskueliggøre, hvordan virksomheder i

dag vurderer deres succes.

2.2.3 Analytisk generalisering Den analytiske generalisering foretages i henhold til vores valg af metode. Her sammenholdes de

kritiske succesfaktorer fra det teoretiske litteraturstudie med de erfaringer, som casevirksomhederne

har gjort sig. Her diskuteres forskelle og ligheder teori og empiri imellem. Dette munder ud i en

fremhævning af, hvilke kritiske succesfaktorer, der er de væsentligste i en global ERP

implementering og dermed besvarelsen af afhandlingens hovedspørgsmål. Derudover diskuteres det

kort, i hvilken grad succeskriterierne har indflydelse på, hvilke kritiske succesfaktorer

virksomhederne fokuserer på.

2.3 Dataindsamling I forbindelse med den teoretiske og empiriske del af afhandlingen er det væsentligt at komme

omkring kildekritik og caseudvælgelse. Kildekritikken vil behandle, de i afhandlingen brugte kilder

samt de kriterier der er opstillet for udvælgelsen af artiklerne til det globale litteraturstudie. Under

caseudvælgelse vil de kriterier, som virksomhederne skal leve op til for at komme i betragtning,

blive opstillet. Herunder præsenteres de to udvalgte virksomheder.

2.3.1 Kildekritik De kilder der er blevet brugt i de indledende, historiske og definitions afsnittene har ikke været

udsat for en større kritisk gennemgang end at den skulle forekomme troværdig. Derfor er der i disse

afsnit blevet brugt flere kilder til underbyggelse og evt. diskussion af forskellige holdninger. Det

9

kan være et problem, at der ikke har været en skarpere udvælgelsesproces, da det kunne have gjort

afsnittene mere nuancerede, hvis det bevidst havde været søgt at inddrage kilder med forskellig

opfattelse.

For at illustrere succesbegrebets relative størrelse har vi valgt at tage udgangspunkt i artiklen

Information system failures – a survey and classification of the empirical literature af Hirschheim

et al. (1987). At artiklen er af ældre dato menes ikke at være noget problem for afhandlingen, da

den anses for at være grundlæggende indenfor sit felt,7 og der præsenteres flere interessante bud på,

hvordan succes kan bedømmes i forbindelse med IS projekter. At artiklen omhandler IS projekter

generelt menes ikke at være det store problem, da ERP projekter er en afart af IS projekter.

Udgangspunktet for studiet af kritiske succesfaktorer er blevet taget i Nah et al.’s (2003) artikel

ERP implementation: Chief information officers’ perceptions of critical success factors. Artiklen er

så vidt vides den eneste af sin art på dette område og accepteres på den baggrund.

De artikler der benyttes i forbindelse med litteraturstudiet af globale kritiske succesfaktorer, er

fundet via søgning i de artikeldatabaser der er tilgængelige via Handelshøjskolen i Århus, samt i

Working Paper: A comprehensive ERP bibliography – 2000-2004 af Møller et al (2004). Dette

paper har samlet artikler omkring ERP fra forskellige artikeldatabaser på baggrund af følgende

kriterier:

Alle artikler skulle være peer-reviewed og i fuld tekst udgave på mere end to sider

Søgningen er foretaget på ordet ERP8 i keyword, titel og i andre felter end brødtekst

Vi vil ud fra de tilgængelige databaser og ovenstående working paper søge at finde frem til de

artikler, som omhandler globale implementeringer ud fra følgende søgekriterier:

Artiklerne skal indeholde betegnelsen ERP eller Enterprise resource planning i titlen

Artiklerne skal indeholde ordet global, international eller multinational i titlen

Artiklerne skal omhandle implementering af ERP systemer (screenes ved gennemlæsning)

7 Artiklen citeres ofte i andre artikler om emnet. Se bl.a. Brody (2005). En søgning på google vil tillige give mange referencer til artiklen. 8 Herunder søgning på lignende termer som Enterprise resource planning, Enterprise og Enterprise systems

10

De ovenstående søgekriterier har ikke kun til formål at finde frem til relevante artikler men også at

sikre, at kvaliteten af disse er i orden. Der foretages derfor ikke nogen yderligere screening.

2.3.2 Udvælgelse af cases Udvælgelse af cases kan ske på flere forskellige måder. Et tilfælde, hvor udvælgelsen giver sig selv,

er ved en unik case. En anden mulighed er ved at have speciel adgang til det område, der

undersøges [Yin, 2003]. I begge tilfælde er det givet på forhånd, hvilken informationskilde, der

ønskes brugt. En tredje mulighed er at opstille nogle kriterier, som de medvirkende virksomheder

skal opfylde [Yin, 2003]. Dette sikrer, at der ikke foretages en tilfældig udvælgelse, og at de valgte

virksomheder kan bidrage med relevant viden indenfor det, der ønskes undersøgt.

Det ikke ønskes at skrive en unik case, og da der ikke haves speciel adgang til nogle bestemte

virksomheder, der kunne være interessante i denne sammenhæng, opstilles de tre nedenstående

krav:

1) De skal være danske virksomheder

2) De skal have foretaget en global ERP implementering, hvor hovedkvarteret som minimum

skal være i shakedown fasen jf. Markus et al.’s (2000) 4-fase model9

3) Den foretagede implementering skal have været succesfuld

Ad. 1)

Valget af danske virksomheder er foretaget af tre forskellige grunde. For det første; hvis vi skulle

snakke med centrale personer i en global ERP implementering i en virksomhed, som ikke var

dansk, ville det højst sandsynligt medføre, at vi skulle rejse til og møde disse personer i et andet

land. Dette ville ikke have været muligt med de for os til rådighed værende ressourcer, hverken

økonomisk eller tidsmæssigt. For det andet forventer vi at have lettere adgang til de relevante

personer i Danmark, da vi er danske studerende. For det tredje, og ikke mindst, vil der være et

minimum af forståelsesmæssige og kulturelle problemer. Det være sig sprogmæssigt, men også med

hensyn til skik og brug.

9 Se afsnit 3.1.2.2.

11

Ad. 2)

For at en virksomhed vil komme i betragtning til denne afhandling, skal de have foretaget en global

ERP implementering qua afhandlingens units of analysis10.

Ad. 3)

De virksomheder, vi finder interessante i denne sammenhæng er dem, som har haft en succesfuld

erfaring med at implementere deres ERP system. Vi har en formodning om, at disse virksomheder

ligger inde med viden omkring, hvad der er vigtigt i en sådan implementering. Derfor vil vi gerne se

på, hvilke kritiske succesfaktorer de har fokuseret på, og hvad de efterfølgende har gjort sig af

erfaringer.

Udover de tre ovenstående krav er virksomhederne også blevet udvalgt på baggrund af en liste med

virksomheder, der har foretaget SAP ERP implementeringer. Derfor har begge de udvalgte

virksomheder foretaget SAP implementeringer. Vi mener dog ikke, dette er en svaghed, da vi

vurderer, at vi ville komme frem til det samme resultat, hvad enten systemet hedder SAP, BAAN,

Oracle eller noget helt fjerde. Dette mener vi, da kritiske succesfaktorer typisk er meget

overordnede størrelser, som vi ikke mener, er systemafhængige.

2.3.2.1 De udvalgte virksomheder På baggrund af de ovennævnte kriterier kontaktede vi syv virksomheder via et adviseringsbrev11.

Brevet blev sendt til fem IT-direktører, en ERP projektleder samt en administrerende direktør. I

brevet præsenterede vi os selv og vores afhandling, samt hvorfor vi mente, at de var en interessant

virksomhed i denne sammenhæng. Derudover skrev vi, hvornår vi ønskede at interviewet skulle

finde sted, hvem vi ønskede at snakke med og sidst, at vi efterfølgende ville kontakte dem for at

høre om deres interesse i deltagelse. Ud fra dette fandt vi frem til de to tidligere nævnte

virksomheder LEGO og Grundfos.

LEGO opfatter deres SAP implementering som succesfuld, hvilket er tilkendegivet af vores

informant i virksomheden. Derudover ligger der en kundehistorie på SAP Danmarks hjemmeside

[URL 5]. I denne case tilkendegives det ligeledes, at implementeringen har været succesfuld.

10 Se afsnit 2.3.2. 11 Vedlagt i bilag 3.

12

Vores informant hos LEGO er Henrik Weis Aalbæk. Henrik kontaktede os som følge af

henvendelsen til IT direktør Jan Amtoft12. Henriks forudsætninger for at medvirke som informant

er, at han har været ansat i LEGO siden 1987 og har arbejdet i flere forskellige afdelinger. Han har

været med i alle tre implementeringer hos LEGO. Henrik er direktør for afdelingen Enterprise

Architecture (EA), som har det forretningsmæssige ansvar for globale strukturerer, processer og

masterdata. Han var teamleder for den gruppe, som havde ansvaret for arkitektur, finansmodel og

masterdata i forbindelse med sidste ERP implementering.

Vores informant hos Grundfos, John B. Nielsen tilkendegiver, at de i Grundfos opfatter deres SAP

implementering som værende succesfuld. John har arbejdet med SAP siden 1988, hvor han startede

i Mobil Oil. Med et kortere ophold hos Danfoss kom han til Grundfos i 1997, hvor han startede som

SAP konsulent primært indenfor PP/MM området. Efter et år i Grundfos i USA, hvor han var med

til at implementere SAP i deres fabrik, kom han tilbage til Bjerringbro, hvor han fik ansvaret for én

afdeling af deres SAP kompetencecenter. I 2004 fik han det overordnede ansvar for SAP i Grundfos

koncernen, med direkte reference til IT direktør Karsten Steen Sørensen.

2.4 Casestudier De følgende afsnit omhandler en præsentation af casestudiedisciplinen med udgangspunkt i Yin

(2003), samt områder, der er relevante i forbindelse med gennemførelsen af denne type studier.

Disse områder er, ud over præsentationen af casestudier i afsnit 2.4.1, casestudiedesign (afsnit

2.4.2), forventninger (afsnit 2.4.3), spørgeramme (afsnit 2.4.4) samt interviews (afsnit 2.4.5).

2.4.1 Præsentation af casestudiet Casestudierne foretages i overensstemmelse med den eksplorative integrative metode som led i at

udbygge den eksisterende viden på et givent område. Casestudier er en god metode, når der skal

foretages undersøgelser af udforskningsmæssig (exploratory) eller forklaringsmæssig (explanatory)

natur [Yin, 2003].

En af casestudiernes unikke styrker er deres evne til at håndtere mange forskellige kildetyper, det

være sig dokumenter, interviews, observationer osv. [Yin, 2003]. Casestudier er derfor med dets

12 Se mail i bilag 4.

13

søgende eller forklarende natur ideelt i forbindelse med undersøgelser, hvor der ønskes en dybere

indsigt, og hvor der ikke er fuld klarhed omkring det, der undersøges. Derfor er casestudier meget

anvendelige i forbindelse med undersøgelse af nutidige temaer [Yin, 2003].

Der findes minimum fem situationer, hvor casestudier kan anvendes. Det er i situationer, hvor det

forsøges at forklare umiddelbare kausale forbindelser mellem hændelser, der er for komplekse for

andre strategier. En anden anvendelsesmulighed er at beskrive en hændelse, og konteksten i hvilken

den skete. Derudover kan casestudier illustrere bestemte emner i forbindelse med en evaluering på

en beskrivende måde. Casestudier kan også anvendes i situationer, hvor de udforskede hændelser

ikke har nogen klare udfald. Sidst kan casestudier bruges i situationer, hvor det ønskes at foretage

en metastudie [Yin, 2003]. I denne afhandling anvendes casestudiet til at undersøge, hvorledes

LEGO og Grundfos har udført deres globale ERP implementeringer og herunder hvilke erfaringer,

de har gjort sig.

Casestudier er ofte genstand for kritik angående stringens i arbejdsprocedurerne,

generaliseringsstyrke og tid [Yin, 2003]. Der findes ingen opskrift på, hvordan man skal forholde

sig til samt foretage casestudier. Arbejdsprocedurer i forbindelse med andre undersøgelsesformer er

langt mere detaljerede [Yin, 2003]. Vi søger i afhandlingen at være stringente i udførelsen af

casestudierne ved at opretholde en ensartet fremgangsmåde i dem begge. Derudover dokumenteres

de forskellige processer i form af vedlæggelse af korrespondance med virksomhederne,

spørgeramme, transskribering af interviews samt lydfiler fra interviewene.

Casestudier bliver også kritiseret for deres manglende evne til at kunne foretage generalisering. Det

er i denne sammenhæng vigtigt at skelne mellem statistisk og analytisk generalisering. I forbindelse

med casestudier er det kun muligt at foretage analytisk generalisering, hvor målet er at udvide eller

understøtte eksisterende teorier [Yin, 2003]. Formålet med det empiriske studie i denne afhandling

er ikke at generalisere statistisk, men snarere at finde frem til mulige tendenser indenfor globale

ERP implementeringer, hvorfor casestudie disciplinen findes egnet.

Den sidste kritik går på den tid, det tager at foretage casestudier. Dette skyldes, at casestudier til

tider forveksles med etnografiske studier og deltagerobservationsstudier. Begge studier kræver en

14

stor investering af tid i ”marken”. Casestudier er en undersøgelsesform, der ikke kun beskæftiger

sig med disse data, men også baserer sig på en del andre materialer som tidligere nævnt [Yin, 2003].

2.4.2 Casedesign Inden et casestudie foretages, er det vigtigt at fastlægge, hvilket design, der ønskes anvendt. Dette

gøres for at anskueliggøre, hvorledes casestudiet bidrager med viden til det felt, der ønskes

undersøgt [Maaløe, 2002]. Casestudier kan inddeles i 4 kategorier i en 2x2 matrix. Ud af den ene

akse kan man dele op i single eller multiple casestudier, og den anden akse beskæftiger sig med, om

der er én eller flere ”units of analysis”.

I denne afhandling foretages to casestudier og dermed et studie med et multipelt design. Multiple

casestudier har visse fordele og ulemper i forhold til single casestudier. En af fordelene er, at

multiple casestudier anses for at være mere robuste. En af ulemperne ved et multipelt casedesign er

fraskrivelsen af muligheden for at finde den sjældne og ekstraordinære case [Yin, 2003]. Da der i

dette tilfælde ikke søges at finde sjældne eller ekstraordinære cases, vil et multipelt casedesign være

en styrke. Der foretages en ”literal replication”, hvilket medfører, at begge cases skal leve op til på

forhånd fastsatte krav13. Antallet af cases er begrænset til to grundet de tidsmæssige ressourcer til

udfærdigelse af afhandlingen. Med hensyn til ”units of analysis” har vi i denne afhandling kun én,

værende feltet for globale ERP implementeringer, hvilket betyder et holistic design. Det valgte

design i afhandlingen er derfor et ”multi holistic” design [Yin, 2003].

2.4.3 Forventninger Opstillingen af forventningerne danner udgangspunktet for udarbejdelsen af spørgerammen. Maaløe

[2002] deler i sin gennemgang af tilgangen til eksplorativ integration disse forventninger op i fem

kategorier. Som den mindst detaljerede grad vælges som minimum et tema for undersøgelsen, hvor

den mest omfattende præsentation er i form af et scenario. De tre mellemliggende stadier er

opstilling af løse teser, præsentation af mere eller mindre sammenknyttede teser, samt grafisk

anskueliggørelse i form af billeder eller modeller. Hvorvidt den ene eller den anden beskrivelse

foretages, afhænger af det teoretiske grundlag for undersøgelsen. Opstillingen af et tema er mindst

krævende, hvor scenariet kræver et meget omfattende teoriapparat. Vores teoriapparat er

13 Se Udvælgelse af cases, afsnit 2.3.1.

15

velfunderet i eksisterende litteratur, men vores eget kendskab til den praktiske verden er begrænset.

Derfor er vores udgangspunkt set i forhold til Maaløes terminologi at opstille nogle

sammenknyttede teser om, hvad vi forventer at finde frem til i casevirksomhederne14.

2.4.4 Spørgeramme I forbindelse med et forskningsinterview skal der udarbejdes en spørgeramme. Denne skal

indeholde de emner, det ønskes at komme omkring [Maaløe, 2002; Fog, 2004]. Spørgerammen skal

ikke indeholde konkrete spørgsmål, da dette kan låse intervieweren. Derudover kan kontakten til

informanten ryge, hvis intervieweren sidder og kigger ned igennem listen af spørgsmål [Maaløe,

2002; Fog, 2004]. Spørgerammen skal derfor udføres i stikordsform med de relevante emner, så det

er op til intervieweren selv at formulere spørgsmålene, gerne med udgangspunkt i noget af det, som

informanten har sagt [Maaløe, 2002; Fog, 2004]. Vores spørgerammer er udformet på baggrund af

disse anbefalinger og kan ses i bilag 5 og 9. Spørgerammerne er marginalt forskellige. Hos LEGO

spurgte vi ikke ind til informanten Henrik Weis Aalbæks baggrund, da vi forinden havde fået disse

oplysninger pr. mail15. Derudover tilføjede vi i spørgerammen til Grundfos punktet om

implementeringsforløb. Et punkt, vi også var inde på i det første interview hos LEGO, og som vi

ønskede at komme ind på hos Grundfos også. I begge spørgerammer har vi listet de 13 fundne

kritiske succesfaktorer. De er ikke blevet anvendt til specifikt at spørge ind til hver faktor, men

mere som en referenceramme. Vi mener dermed, at vi har holdt os åbne overfor nye vinkler i

forbindelse med kritiske succesfaktorer16 i en global implementering.

2.4.5 Interviews Casestudierne i denne afhandling vil først og fremmest bygge på de to interviews. Disse interviews

vil have karakter af semistrukturerede interviews. Et sådant interview minder mest af alt om en

samtale [Maaløe, 2002]. Samtalen har til formål at hjælpe intervieweren på vej til en bedre

forståelse af det område, der undersøges [Maaløe, 2002]. Derfor er tilgangen positiv i forhold til den

interviewede og ikke kritisk som i mange journalistiske interviews. Dette betyder, at interviewet

skal foregå på informantens præmisser. Det er informanten, der sætter dagsordenen, og det er

interviewers opgave at prøve at forstå, hvorfor det, informanten snakker om, er interessant i denne

14 Der refereres her til Maaløes [2002] fem punkter side 128-29. 15 Se bilag 4. 16 Hvilket netop er en af kvaliteterne ved den eksplorative integrative tilgang.

16

sammenhæng. Det er dermed også interviewers opgave at bede informanten oplyse, uddybe, tage

stilling til og vurdere de emner, som berøres. Herved søges det at lede informanten hen imod

områder, hvis væsentlighed hermed begynder at dæmre for vedkommende [Maaløe, 2002]. Ved at

have en åben spørgeramme søger vi netop at lade vores informanter sætte dagsordenen i forhold til,

hvilke kritiske succesfaktorer, de har fokuseret på. Derved søger vi at undgå, at vi dikterer, hvilke

kritiske succesfaktorer, der snakkes om. Det skal dog bemærkes, at vi til stadighed søger at holde

samtalen indenfor afhandlingens kontekst.

Rent praktisk er interviewene foretaget hos LEGO og Grundfos. Begge opgaveskrivere er til stede,

med den ene som hovedinterviewer og den anden som notar og medinterviewer. Begge interviews

er optaget med informantens forudgående samtykke. Dette gøres for at lette skrivningen af casene

samt for, at interviewerne kan koncentrere sig om selve interviewet. Der kan stilles spørgsmålstegn

ved, om en informant vil være lige så åben, når mikrofonen er tændt. Vi mener dog, at fordelene

ved at optage interviewene, og dermed undgå at miste eller glemme detaljer i et interview, overgår

ulempen ved, at informanten i visse tilfælde kunne formodes ikke at komme med alle detaljer

omkring en episode, grundet at det bliver dokumenteret på optagelsen. Vi må i interviewsituationen

stole på, at vores informanter er ærlige.

2.5 Validitet Validitetskriterier i forbindelse med casestudier er vigtige, da casestudier ikke bygger på

repræsentativitet. Derimod bliver casestudier målt på deres troværdighed, hvilket betyder, at

caseskriver skal forholde sig til disse kriterier [Neergaard, 2001]. Hvilke validitetskriterier, der

gælder for kvalitative undersøgelser, er der ikke bred enighed om [Neergaard, 2001]. Vi vil i denne

afhandling bruge følgende fire begreber: troværdighed, overførbarhed, afhængighed og

bekræftbarhed til at beskrive validiteten af opgaven.

2.5.1 Troværdighed Troværdigheden er vigtig i forbindelse med casestudier. Hvis et casestudie ikke har nogen form for

troværdighed, mister den sin berettigelse [Neergaard, 2001]. Det materiale, der anvendes i

forbindelse med casestudiet, skal derfor have en vis troværdighed for at blive medtaget. Derfor er

der kun anvendt materiale fra anerkendte medier. De mest centrale kilder i forbindelse med

17

casestudierne er som tidlige nævnt de interviews, der gennemføres i LEGO og Grundfos. Det er dog

i denne forbindelse ikke op til os at vurdere, hvorvidt den interviewede taler sandt eller ej, men vi

må tage hans ord for pålydende.

Den interviewede bidrager til troværdigheden af casen ved at gennemlæse denne. De udarbejdede

cases er derfor sendt til informanterne, hvorved de har mulighed for at komme med kommentarer og

rettelser og derved sikre en så troværdig case som muligt. Begge informanter har givet

tilbagemeldinger. Hos LEGO var der få rettelser, der gik på faktuelle oplysninger og hos Grundfos

havde John B. Nielsen ingen yderligere kommentarer eller rettelser. Ud over interviewene bygger

casene på sekundære kilder såsom virksomhedernes hjemmesider samt udleveret materiale17. De

sekundære kilder bibringer udelukkende med faktuelle data omkring virksomhederne og deres ERP

implementeringer, hvorved vi ikke mener, at der er nogle problemer i forhold til troværdigheden af

disse.

2.5.2 Overførbarhed Overførbarheden har at gøre med, hvorvidt resultaterne kan generaliseres og derved overføres til

andre situationer. Generaliseringsværdien af casestudier kan diskuteres, hvilket umiddelbart er

problematisk i forhold til denne afhandling. I denne situation mener vi, at det er op til læser at

vurdere, om denne viden kan overføres til andre situationer.

Hvorvidt den viden, vi har erhvervet os i casestudierne, kan overføres til andre situationer eller ej,

kan der tillige stilles spørgsmålstegn ved i og med, at kvalitative studier netop er svære at

generalisere på. Vi kan ikke vurdere, om der vil opnås det samme resultat, hvis undersøgelsen blev

foretaget med en anden metode som f.eks. spørgeskemaundersøgelse eller et survey.

2.5.3 Afhængighed Afhængighed handler om, hvorvidt data er genereret og fortolket på en pålidelig måde. Det mener

vi, er tilfældet i denne afhandling. Vi beskriver, hvordan vi finder frem til de respektive

virksomheder og dermed vores informanter. Derudover vil læser have mulighed for at tjekke

pålideligheden af de fortolkninger, vi kommer med i vores cases, da både en transskribering samt de

17 Vedlagt i bilag 7 og 13.

18

originale lydfiler af interviewene er vedlagt i bilag18. Derudover vil vi i forbindelse med vores cases

gøre opmærksom på, under hvilke omstændigheder de forskellige virksomheder har foretaget deres

implementering. Dette har vi med, da det kan have konsekvenser for caseanalysens resultater, i

hvilken kontekst virksomhederne har implementeret deres ERP system [Neergaard, 2001].

Derudover har vi i afsnit 2.3.2.1 præsenteret informanterne og deres baggrunde, da dette kan spille

ind på, hvordan de ser på en ERP implementering.

2.5.4 Bekræftbarhed I forbindelse med casestudier bør forskere være opmærksom på egen bias. Derfor bør forskeren

konstant være på vagt overfor de antagelser, som vedkommende har foretaget og søge at være åben

overfor andre og modsatte slutninger, hvis det er muligt [Neergaard, 2001]. Udover dette er

triangulering en mulighed for at øge troværdigheden af analysens resultater, idet der bruges flere

forskellige data som dokumentation. I forhold til bias opstiller vi på forhånd nogle forventninger til

resultatet af undersøgelserne i de casevirksomheder, hvilket illustrerer den bias vi måtte besidde.

Derudover er vi tro imod vores metode og vil være åbne for eventuelle nye emner, som kunne

dukke op i forbindelse med casestudiet. Det er tillige med de ovenstående kriterier op til læser at

vurdere, hvor god bekræftbarheden af casestudierne er [Heldbjerg, 2003].

18 Se bilag 6, 10 og 14.

19

3 Den teoretiske del Den teoretiske del har til formål at behandle og besvare problemformuleringens første tre punkter.

De første afsnit vil kort gennemgå ERP systemets historie og definitioner af ERP systemer,

implementering samt hvad der menes med en global ERP implementering i denne afhandling. Med

dette på plads vil succesbegrebets relativitet blive illustreret. Det sidste afsnit vil beskæftige sig med

afhandlingens hovedtema kritiske succesfaktorer.

3.1 ERP systemer Enterprise Resource Planning (ERP) er et relativt nyt begreb, som dukkede op i starten af 90’erne.

Der er ikke den store konsensus omkring begrebet, da forskere har forskellige opfattelse af, hvad

ERP er; og en del forskere foretrækker at kalde ERP systemer for business systems eller enterprise

systems [Klaus et al., 2000]. Dette afsnit redegør for den historiske udvikling fra de første systemer,

til det system, der i dag kendes som ERP. Herunder gives en definition af begrebet ERP system.

3.1.1 Historie ERP systemet har sine rødder i de tidlige systemer material requirements planning (MRP) og

manufacturing resource planning (MRP II)19. Et indblik i, hvad der ligger til grund for ERP, vil

samtidig give et indblik i ERP systemets kerneydelser.

3.1.1.1 MRP ERP systemet som det kendes i dag, er resultatet af en udvikling, der kan dateres tilbage til

1960’erne. Teknikken MRP blev introduceret i USA som et ”… computerized inventory control

system…” og kom sidst i 1960’erne også frem i Europa. Joseph Orlicky, George Plossl, Oliver

Wight samt APICS20 krediteres for introduktionen af MRP systemet [Russell et al., 1998].

Grundlæggende set er MRP et system, der styrer efterspørgslen på materialer i en produktion. Det

udregner efterspørgslen efter komponenter, holder styr på hvornår de skal bruges, og udregner

19 Vi er her opmærksomme på, at dette blot er ét syn, med udgangspunkt i det produktionsmæssige, hvor andre syn kan argumentere for en anden historisk udvikling. Vi mener dog ikke, at dette har nogen konsekvenser for opgaven, da det, vi ønsker at undersøge, ikke er betinget af et bestemt syn som f.eks. det produktionsmæssige. 20 American Production and Inventory Control Society. APICS er en amerikansk non-profit organisation, der bl.a. beskæftiger sig med ressourcestyring.

20

produktions- og indkøbsplaner, der passer sammen med, hvornår komponenterne skal bruges i

produktionen.[Russell et al., 1998].

Formålet med MRP er at have så lav en lagerbeholdning som muligt. Dette muliggøres ved at

systemet simulerer bestillinger, modtagelser og brug af råmaterialer, komponenter og færdigvarer

ind i fremtidige tidsskemaer. Derved er der altid de komponenter og materialer, der skal bruges i

produktionen. Samtidig advarer systemet om, når der i en plan vil opstå mangler af visse

komponenter til bestemte tider i forhold til den fremtidige produktionsplan. Fordelen med systemet

er, at effekten af en ændring i én del af produktionsprocessen afspejles i resten af systemet [Russell

et al., 1998].

3.1.1.2 Udviklingen fra MRP til MRP II Den første tilføjelse til MRP systemet i udviklingen imod dagens ERP system, var

kapacitetsberegninger af maskin- og mandetimer. Med dette tiltag i udviklingen kunne

ubalancerne21 i produktionen forudses, og dermed kunne mængde og/eller kapacitet justeres for

igen at opnå balance i produktionen [Russell et al., 1998; Goodfellow, 1994].

Den videre udvikling gik imod en samlet plan for virksomhedens overordnede produktion, hvilket

var en fastsat plan for hele færdigvareproduktionen. Denne var hele nerven i virksomheden og dens

produktion [Goodfellow, 1994].

I takt med at udviklingen af MRP gik fra ren materialeberegning til også at indbefatte kapacitet og

mandetimer over tid22, blev udtrykket MRP II mere og mere brugt. Forståelsen af teknikken

udvikledes, og den computertekniske del blev mere avanceret. Samtidig begyndte man at gå fra

batch fremstilling over imod ”on-line transaction processing” [Luscombe, 1993].

Med indførelsen af de samlede planer for virksomhedens overordnede produktion, fik topledelsen

til stadighed større indflydelse. Ved aktivt at deltage i udviklingen af planen kunne de sikre fuld

integration med virksomhedens forretningsplan og strategiske mål.

21 Under- og overbelastninger i mandskab og maskiner. 22 I slutningen af 1970’erne og starten af 1980’erne.

21

Denne udvikling førte også til, at der i start 80’erne dukkede flere og flere leverandører af MRP II

software op. Gradvist blev der tilføjet nye funktionaliteter til kerneprocesserne i systemet, og en

bred vifte af perifere moduler som markedsføring og finansielle elementer blev tilføjet softwaren.

Disse elementer var enkeltstående moduler, der kunne implementeres separat efter behov, men som

stadig hænger sammen i et større system.

3.1.2 ERP I starten af 1990’erne blev de første client server baserede ERP systemer introduceret, hvor bl.a.

tyske SAP i 1992 introducerede deres første løsning, R/3, baseret på denne teknologi [O’Leary

2000]. Netop client server teknologien er ét af de største tiltag i ERP. Hvor de tidligere systemer har

kørt på en mainframe, er introduktionen af client server teknologien med til at sikre en bedre

integration og rigtighed af data, da dataene ligger lagret på centrale servere, hvorfra de tilgås af de

forskellige klienter. Med overgangen til client server teknologien blev det muligt at opdatere

dataene i et ERP system i real-time, dvs. at når dataene er tastet ind i systemet kan det øjeblikket

efter ses andre steder i virksomheden.

Med introduktionen af client server teknologien, blev ERP systemerne desuden mere

interorganisatoriske. Det blev nu muligt at tilgå dataene via netværk som Intranet og Internettet,

hvilket gav større muligheder for, at store virksomheder, med afdelinger flere forskellige steder i

verden, kunne have et samlet system, hvor alle data er samlet.

Selve ERP systemet er bygget op omkring en central database [O’Leary, 2000], hvor alle data i

virksomheden samles. Herved undgås ”redundant information eller asymmetrisk information været

et problem [Jacobs et al., 2000]. Alle informationer i databasen optræder derfor kun et sted. Ovenpå

denne database ligger forskellige applikationer, der er tilpasset den enkelte afdelings behov. Disse

applikationer trækker alle på den centrale database, og derved har alle i virksomheden adgang til

den samme information.

Da et ERP system ofte omfatter store dele af virksomheden, er det en kompliceret affære at få det

implementeret, ikke mindst pga. systemets komplekse natur. ERP systemerne kommer med

prækonfigurerede procedurer, som er bygget op omkring ”best practices” [Markus et al., 2000].

Best practices er ERP leverandørens syn på, hvordan en virksomhed bedst hænger sammen. Disse

22

best practices er udviklet gennem studier af organisationer og organisationsteori [Markus et al.,

2000]. Disse procedurer kan konfigureres, hvis virksomheden ønsker det [Markus et al., 2000]. Et

ERP system har et væld af konfigurationsmuligheder, og der skal derfor tages stilling til mange

forskellige procedurer. Da det kan være en meget kompliceret og tidskrævende affære at

konfigurere et ERP system til virksomhedens nuværende arbejdsgange, vælger nogle virksomheder

at ændre deres arbejdsgange, så de passer til systemets best practices i stedet [O’Leary, 2000;

Markus et al., 2000]. Konfigurationsprocessen er meget vigtig, da et ERP system er svært at ændre,

når det først er implementeret. Derfor er det vigtigt at systemets procedurer understøtter

virksomhedens arbejdsgange [Rikhardsson et al., 2004].

3.1.2.1 Definition af ERP systemer Det er svært at finde en generel definition af, hvad et ERP system er. Vi vil i dette afsnit definere,

hvad vi mener med ERP systemer, så læseren ved, hvad vi forstår ved dette begreb.

Trods det, at mange definitioner af ERP systemer minder meget om hinanden, er der stadig ingen

egentlig konsensus om, hvad et ERP system er. Det kan hænge sammen med, at nogle forskere ikke

ønsker at bruge ordet ERP, da de mener, det er misvisende. I stedet bruger de termerne business

systems eller enterprise systems [Klaus et al., 2000]. Disse forskere fremhæver, at begrebet

enterprise resource planning er misvisende, da systemerne ikke hovedsageligt beskæftiger sig med

ressourceallokering. I denne opgave vil vi dog holde fast i begrebet ERP.

Vi vil i opgaven desuden bruge en definition af Rikhardsson et al., som i deres bog ERP fra 2004

definerer ERP systemer således:

”ERP systemer er informationssystemer, der understøtter online, integreret, realtime

transaktionsregistrering, databearbejdning og rapportering i forbindelse med afvikling af

virksomhedens forretningsprocesser ved hjælp af en central database, ofte i en client/server IT-

arkitektur.”

Grunden til, at vi vil bruge denne definition er, at den er kort og koncis, hvilket vi mener, er

gavnligt for forståelsen. Samtidig minder den meget om andre forfatteres definitioner [Klaus et al.,

23

2000; O’Leary, 2000], hvilket er gavnligt, da der så måske er ved at opstå en de facto definition af

ERP.

Vi vil i denne afhandling afgrænse os fra at se på implementeringen af in-house udviklede ERP

produkter. Dette gør vi, da vi har en klar opfattelse af, at det i dag er mest udbredt at købe færdige

ERP systemer.

3.1.2.2 Definition af implementering Begrebet implementering har ikke nogen fast definition i IT sammenhæng, hvorfor der derfor heller

ikke findes en fast definition af begrebet ERP implementering. Gennem tiden er implementering

blevet defineret som den rent fysiske installering af hardware og software [Pressman et al., 1984] og

som en løbende proces [Alter, 1979; Lucas et al., 1990; Markus et al., 2000]. Typisk ser forskerne,

der definerer implementering som en proces, den rent fysiske installering som en del af

implementeringsprocessen [Markus et al., 2000; Shields, 2001; Ross, 1999; Parr et al., 2000]. Selv

blandt de, der definerer implementering som en proces, er der ikke enighed om, hvor meget

implementeringsbegrebet dækker over. Atler (1979) mener, at en implementering dækker over en

række begivenheder, der ender ud i et system, der kan bruges effektivt, hvorimod Lucas et al.

(1990) mener, at en implementering er i gang, så længe der introduceres nye personer til systemet.

Endelig mener Markus et al. (2000), at en implementering begynder med den første tanke om

anskaffelse af et system og først ender, når det bliver erstattet med et andet. Derfor ønsker vi at

definere, hvad vi mener med en ERP implementering.

For at definere begrebet implementering vil vi tage udgangspunkt i tre modeller med forskellig

opfattelse af, hvornår en implementering starter og slutter. Vi vil beskrive disse tre modeller, der

deler implementeringsbegrebet op i faser, og derfor kaldes fasemodeller, og derigennem fastlægge

vores definition ved valg af én af modellerne. Samtidig vil vi bruge modellen til at beskrive hvilke

dele af implementeringsprocessen, vi vil beskæftige os med.

De tre modeller, vi vil beskrive, er Markus et al.’s (2000) 4-fase model, Parr et al.’s (2000) 3-fase

model og Ross’ (1999) 5-fasemodel. Der tages udgangspunkt i Markus et al.’s model, da den favner

bredest tidsmæssigt.

24

Figur 1 viser en sammenligning af de tre modeller og disses faser. Markus et al.’s ERP

implementeringsmodels første fase dækker perioden fra den første idé om anskaffelse af et ERP

system til beslutningen om at gå i gang med et ERP projekt er taget. Denne fase kaldes chartering

og indeholder bl.a. business case, valg af hard- og software, valg af projektleder samt beslutning om

at gå videre til næste fase. Parr et al.’s models første fase, planning, indeholder mange af de samme

elementer, men starter senere end Markus et al.’s model, der nævner den første idé som starten,

hvor Parr et al. først starter ved beslutningen om at se på ERP systemer. Ross’ første fase hedder

design. Denne fase indeholder bl.a. beslutning omkring valg af system, om systemets processer skal

ændres til organisationen, og i hvor stor udstrækning dette skal gælde, samt beslutning om at gå

videre.

Ross, 1999

Kilde: Egen tilvirkning

Markus et al., 2000

Parr et al., 2000

Planning

Chartering

Design Implementation Stabilization Transformation

Cont. Impr.

Onward & upward Project Shakedown

Project Enhancement

Afskaffelse Idé

Figur 1 Fasemodeller

Den anden fase i modellerne er der stor konsensus omkring; Markus et al. og Parr et al. kalder

denne fase for project fasen, og Ross kalder den for implementation. Denne fase indeholder bl.a.

den rent fysiske installering af hard- og softwaren i virksomheden. Derudover er der stor enighed

om, at der her udvikles en detaljeret projektplan, projektteams udvælges og trænes, business process

reengineering foretages hvis nødvendigt og test af systemet og data konvertering foretages. Fasen

slutter med, at virksomheden tager systemet i brug. Parr et al. lægger meget vægt på denne fase og

har delt den op i fem subfaser, setup, reengineering, design, configuration & testing og installation.

Projektfasen er den fase, der er bedst beskrevet i Parr et al. og Markus et al.’s modeller, hvilket kan

skyldes, at denne del af implementeringen er godt beskrevet i den eksisterende litteratur. Ross

beskriver i sin model, at dette er fasen, hvor virksomheden tager springet i det ukendte, og at det er

en tid med nedsat produktivitet.

25

Fasen efter virksomheden er gået live kalder Ross for stabilization, Parr et al. kalder den for

enhancement, og Markus et al. kalder deres fase for shakedown. Ross’ stabilization fase og Markus

et al.’s shakedown fase minder meget om hinanden, og beskriver perioden fra virksomheden går

”live” til virksomheden vender tilbage til ”normal operation”, hvor Parr et al.’s enhancement fase

strækker sig ind over de næste faser i de andres modeller. Parr et al. har i modsætning til i deres

project fase en meget vag beskrivelse af hvad, der foregår i denne fase. Ross skriver, at stabilization

fasen indebærer at rydde op i gamle processer for at tilpasse sig det nye miljø, uddannelse af nye

brugere, oprydning i data og bug fixing af softwaren. Disse punkter stemmer godt overens med det,

Markus et al. mener, indgår i deres shakedown fase. Denne fase skulle gerne være en tid med

stigende produktivitet i virksomheden [Ross, 1999].

Markus et al.’s sidste fase, onward & upward dækker over Ross’ sidste to faser, continuous

improvement og transformation. I denne periode af implementeringsforløbet er de typiske

aktiviteter relateret til vedligeholdelse og opgraderinger af systemet, indtil det med tiden afløses af

et nyt. Ross nævner i den første af faserne aktiviteter som tilføjelse af nye funktionaliteter samt

redesign af processer og implementering af nye strukturer og regler for at ”balancere” systemet.

Den sidste fase går meget på at ændre organisationens grænser til at omfatte integration til kunder

og leverandører, hvorved der opnås et bedre kendskab til kunders behov og et bedre samarbejde

med leverandørerne. Markus et al.’s fase indeholder bl.a. tekniske opgraderinger,

forretningsmæssige forbedringer og kontinuerlig brugeruddannelse og support. Ross og Parr et al.

skriver ikke, hvornår deres modellers sidste fase slutter, hvor Markus et al. specifikt skriver, at

deres sidste fase ikke slutter før afskaffelsen af systemet.

Vi har valgt at benytte Markus et al.’s fasemodel til at beskrive, hvad vi forstår ved en

implementering. Det står ikke klart, om Markus et al. selv mener, at en implementering dækker alle

fire faser, men det passer meget godt overens med Lucas et al.’s (1990) definition af

implementeringen som en løbende proces. Markus et al.’s model er væsentligt bedre beskrevet end

modellerne af både Ross og Parr et al. Ross’ model er beskrevet ved hjælp af udtalelser fra

virksomheder, hvilket betyder, at der skal læses mellem linjerne for at finde frem til, hvad de

enkelte faser indeholder. Dette giver et meget uklart billede af modellen. I Parr et al.’s artikel bliver

stort set kun project fasen beskrevet, hvilket gør at både første og sidste fase står meget vage og

uforklarede hen. De er nærmere beskrevet ved referencer til andre modeller end ved egentlig egen

26

beskrivelse; desuden virker disse referencer til tider mangelfulde. Derimod virker Markus et al. som

en meget god og velgennemarbejdet artikel med gode definitioner af hver enkelt fase samt gode

beskrivelser af arbejdet, der foregår i disse.

Da vi vælger at bruge Markus et al.’s model, vil vi afgrænse os fra at se på hele

implementeringsprocessen, da det ville betyde, at det undersøgte system skulle være afskaffet. Vi

vælger derfor kun at se på de tre første faser af modellen, ved at se på virksomheder, der befinder

sig i shakedown fasen23.

3.1.2.3 Definition af global ERP implementering Da der kan være forskellige opfattelser af, hvad der defineres som en global ERP implementering,

vil vi her komme med vores definition af en global implementering.

Ordet global kan oversættes til verdensomspændende [Becker-Christensen, 2001]. Dette betyder, at

det vedrører hele verden. Ordet global bruges i flæng, og burde ofte være erstattet af ordet

international, der betyder omhandlende flere lande [URL 6].

Der kan derfor argumenteres for og imod brugen af ordet global i ERP

implementeringssammenhæng, da det er meget få virksomheder som i realiteten er globale. Vi

ønsker dog stadig at bruge ordet, da det oftere og oftere bliver anvendt i ERP implementerings

sammenhæng.

For os vil en global ERP implementering betyde en implementering som foregår i to eller flere

lande. Ordet global kan, i ERP implementeringssammenhæng, gradbøjes således, at jo flere lande

og kontinenter en implementering foregår i, jo mere global kan implementeringen siges at være. Vi

vil dog i denne afhandling ikke skelne mellem de mere eller mindre globale implementeringer.

3.2 Succesbegrebet Enhver virksomhed, der implementerer et ERP system, har et formål med denne implementering.

Nogle ønsker at lave om på strukturen i organisationen, hvor andre ønsker en større 23 Begge virksomheder implementerer løbende i nye selskaber, hvorved de i flere tilfælde er i project fasen. Forløbet er her vurderet ud fra, at de i betydelige dele af virksomhederne er nået til shakedown fasen.

27

omsætningshastighed på deres varelagre. Formålene kan være lige så mange som antallet af

implementeringer. På lige fod med de forskellige formål med implementeringen, må det formodes,

at hver virksomhed også har deres kriterier for, hvornår deres implementering er en succes.

Derudover kan det formodes, at der er forskel på, hvad et bestyrelsesmedlem og en bruger af

systemet har som succeskriterier.

Som ovenstående indikerer, er succes et relativt begreb, der vil afhænge af konteksten og af de

personer, der skal dømme en given begivenhed. Det ønskes i denne sammenhæng at illustrere dette,

ved at gennemgå 4 forskellige syn, der har været brugt i forbindelse med informations system (IS)

projekter. Udgangspunktet for gennemgangen tages i artiklen Information systems failures – a

survey and classification of the empirical literature fra 1987, der er en grundlæggende artikel

indenfor feltet af succesbedømmelse af IS projekter [Hirschheim et al., 1987].

I de følgende afsnit gennemgås de fire forskellige syn på succes i forbindelse med IS projekter. Alle

syn tager udgangspunkt i failure og beskriver succes herudfra ud fra devisen om at, de udledninger

der ligger bag at vurdere fiasko i et givent system, også kan danne grundlag for at vurdere, om

systemet er en succes. I artiklen vurderes failurebegreberne i forhold til 8 dimensioner24. I

nedenstående tabel 1 kan det ses hvordan de forskellige failurebegreber forholder sig til disse

dimensioner.

Tabel 1 Comparison of IS failure c

onceptsIS failure criterion

Correspondence failure Process failure Interaction failure Expectation failure

Dimensionality Mainly one; summative/formative

Mainly one; summative/formative

Mainly one; summative/formative

Several; formative/summative

Measurement scale Discrete Discrete Discrete Continuous

Nature of failure Neutral Neutral Neutral Non-neutral

Temporal aspect Static Static Static Dynamic

Assessment procedure Formal Formal Formal Informal

Evaluation time frame Ex post/ex ante Ex post/ex ante Ex post/ex ante Ex ante/ex post

Participants Limited Limited Limited Extensive Evaluation process Context independent Context independent Context independent Context dependent

Kilde: Hirschheim et al., 1987.

24 Hvad der ligger i de 8 dimensioner kan ses i vedlagte appendiks.

28

3.2.1 Correspondence failure Under dette syn er et IS projekt en fiasko, hvis der ikke er overensstemmelse mellem

kravspecifikationen og det, som systemet kan yde. Dette syn var meget populært, da artiklen blev

skrevet i 1987 [Hirschheim et al., 1987]. Problemet med dette syn er, at hvis virksomheder ikke

skriver meget præcise kravspecifikationer, så kan det være svært at vide, hvad virksomheden

kræver. Til tider kan dette betyde, at der er forskellige punkter i kravspecifikationen, der ikke er

forenelige.

3.2.2 Process failure Dette syn fremhæver to relaterede aspekter, hvor resultatet er utilfredsstillende. For det første, hvis

et projekt ikke kan skabe et brugbart system, ses det som en fiasko. Disse problemer skabes ofte i

design, implementering og konfigurationen af systemet. Den anden og mere udbredte process

failure definition er når projektet sprænger budget og tidsrammer, hvilket også har en negativ effekt

på de globale fordele og gevinster, IS systemet forventes at medføre. Samtidig udstiller process

failure definitionen ledelsens manglende evne til at styre ressourcerne i processen og til at forudse

de problemer, der måtte opstå undervejs i processen.

3.2.3 Interaction failure Ved interaction failure argumenteres der for, at en lav anvendelse af systemet er et surrogat for en

fiasko. Derudover er parametre som brugernes attitude og tilfredshed med systemet også en

indikator på, om et IS har været en fiasko eller ej. Hvis brugerne benytter systemet ofte og til det,

som det er tiltænkt, er det ensbetydende med, at de har en positiv holdning overfor det, hvilket

tillige giver en mere effektiv arbejdsgang. Omvendt, hvis brugerne har en lav interaktion med

systemet, er det ensbetydende med en fiasko, da dette syn primært går på brugernes interaktion med

systemet som kriterium.

3.2.4 Expectation failure Expectation failure har, i modsætning til de ovenstående, et multifacetteret syn på, hvad succes er.

Da der i en virksomhed er mange forskellige grupper af mennesker, der skal arbejde sammen, er det

meget sandsynligt, at de ikke alle har det samme syn på, hvad succes er i en given kontekst. Hvad

der er succes for én gruppe, er ikke nødvendigvis succes for en anden gruppe. Expectation failure

29

definerer disse grupper som stakeholders. En stakeholder gruppe kan bestå af en til flere personer,

og de kan være enige eller uenige med en eller flere andre stakeholder grupper. Fiasko defineres

som ”…the inability of IS to meet a specific stakeholder group’s expectations”. Dette kan

oversættes til ”… informationssystemets manglende evne til at imødekomme forventningerne fra en

given stakeholder gruppe”. Grundet definitionens multifacetterede syn, er det derfor ikke nemt at

finde et entydigt svar på, om projektet har været en succes eller fiasko ud fra én given parameter.

Den enkelte stakeholder gruppe kan dog have et meget snævert syn på, hvad succes er, således at

succes for denne ene gruppe afhænger af en eller to for dem vigtige parametre.

3.2.5 De fire syn Som det fremgår af de fire forudgående afsnit kan succeskriterier vurderes på flere forskellige

måder. De tre første syn er lette at måle på og derved lette at forholde sig til. Til gengæld er de

meget unuancerede og éndimensionale. Det fjerde syn er modsat de tre forrige flerdimensional, men

til gengæld mindre målbart. Dermed kan succes anskues på flere forskellige måder, alt efter hvem

der anskuer begrebet. Hvor vidt det ene eller det andet syn er mest ”rigtigt”, afhænger af situationen

hvori succes skal bedømmes. Dermed er det op til den enkelte virksomhed at sætte de

succeskriterier op, der passer til de mål, den har sat.

3.3 Kritiske succesfaktorer I forbindelse med en global ERP implementering er de kritiske succesfaktorer de væsentlige

punkter, der skal være fokus på for at opnå succeskriterierne. Derved fungerer de kritiske

succesfaktorer som enablere for en succesfuld implementering. Begrebet succesfaktorer blev ifølge

Rockart (1979) først introduceret i 1961 af D. Ronald Daniel. Det blev efterfølgende videreudviklet

af forskere fra MIT’s Sloan School of management med John F. Rockart i spidsen. De definerede i

sin tid kritiske succesfaktorer som [Rockart, 1979]:

”… the limited number of areas in which results, if they are satisfactory, will ensure successful

competitive performance for the organization.”

Denne definition var ikke specifikt møntet på IT implementeringer. Rockhart ønskede at give ledere

et værktøj, som de kunne bruge til at definere, hvilke informationer, de havde brug for, for at opnå

30

deres mål. I dag har ERP implementeringsforskere taget dette begreb til sig og tilpasset det til deres

forskningsområde. Vi definerer derfor kritiske succesfaktorer i ERP implementeringer som:

”De fokusområder der, med tilfredsstillende resultater, vil sikre en succesfuld ERP

implementering”

3.3.1 11 kritiske succesfaktorer I 2001 foretog Nah et al. et review af kritiske succesfaktorer indenfor ERP

implementeringsområdet. Reviewet, som er baseret på 10 artikler, fremkommer med 11 kritiske

succesfaktorer25, som er kritiske for en ERP implementering. Disse 11 kritiske succesfaktorer er

blevet klassificeret i forhold til Markus og Tanis’ implementeringsmodel. Nah et al. undersøgte

efterfølgende i artiklen ERP implementation: Chief information officers’ perceptions of critical

success factors fra 2003 IT-chefers syn på de 11 kritiske succesfaktorer. I denne artikel udbyggede

de reviewdelen med yderligere to artikler. Under de forskellige kritiske succesfaktorer, vil der blive

præsenteret en rating, der er baseret på de medvirkende IT-chefers vurdering af faktorernes

vigtighed. De 11 kritiske succesfaktorer er udgangspunktet for den videre teoretiske analyse af de

væsentlige kritiske succesfaktorer i en global implementering, samt for den efterfølgende empiridel.

Disse 11 kritiske succesfaktorer vil i det efterfølgende blive beskrevet.

3.3.1.1 Appropriate business and information technology legacy systems Denne kritiske succesfaktor er vigtig i chartering fasen af implementeringen [Nah et al., 2001]. Et

godt og stabilt forretningsgrundlag er betydeligt for en ERP implementering. Dette betyder, at der

ikke skal bruges kræfter på at ”slukke brande” i forskellige afdelinger, og fokus kan derfor rettes

mod erhvervelsen af det nye system [Roberts et al., 1992]. De ældre systemer har også betydning i

den henseende, at de har deres egne procedurer liggende, som organisationen har indrettet sig efter.

Hvis det nye system har meget anderledes procedurer, vil dette kræve store organisatoriske

forandringer, hvis ikke der foretages en modifikation af ERP systemet [Holland et al., 1999]. I Nah

et al.’s undersøgelse i 2003 scorede denne kritiske succesfaktor lavest med en værdi på 3,46 på en

fempunktsskala blandt de medvirkende IT-chefer.

25 Se oversigt over faktorer og subfaktorer med referencer i bilag 1.

31

3.3.1.2 Business plan and vision Denne kritiske succesfaktor er vigtig for hele forløbet af implementeringen [Nah et al., 2001].

Investeringen i et ERP system bør foretages som et led i strategien til at nå frem til virksomhedens

vision [Buckhout et al., 1999]. Virksomheden skal fremsætte nogle klare mål for implementeringen,

der bør være identificerbare og følges gennem processen [Roberts et al., 1992; Holland et al., 1999;

Shanks et al., 2000]. Derudover bør virksomheden have en model for, hvordan organisationen skal

se ud efter implementeringen, og denne skal være i tråd med virksomhedens vision [Holland et al.,

1999].

En business plan skal indeholde de strategiske og umiddelbare fordele ved implementeringen. Den

skal derudover indeholde oplysninger om ressourceallokering, omkostninger, risici og en tidslinje

for projektet [Nah et al., 2001]. For at implementere et system bør der være et problem, der skal

løses. Opbakningen til implementeringen fra stakeholderne vil højst sandsynligt stige med behovet

for at få løst problemet. Behovet for at investere i et system bør være så stort, at det kan berettige

brugen af den tid og de penge, som en implementering vil kræve. Derudover bør investeringen

understøtte virksomhedens strategi [Falkowski et al., 1998]. Denne kritiske succesfaktor scorede

4.31 i Nah et al.’s (2003) undersøgelse, hvilket medførte en placering lige under midten.

3.3.1.3 Business process reengineering Business process reengineering (BPR) bør foretages løbende fra projektfasen i

implementeringsforløbet og fremefter. Ved implementering bør der foretages BPR, der skal aligne

virksomhedens arbejdsprocesser med ERP systemets processer [Holland et al., 1999; Bingi et al.,

1999; Murray et al., 2001; Shanks et al., 2000; Rosario, 2000; Sumner, 1999]. Nah et al. (2003)

pointerer endvidere, at der bør foretages løbende ændringer af arbejdsprocesser for at opnå et bedre

udbytte af ERP systemet.

Derudover bør virksomheder overveje, i hvilken grad ERP systemet skal modificeres, altså om

forretningsprocesserne skal tilpasses ERP modellen eller omvendt. Jo mere ERP softwaren ændres,

des større implementeringsomkostninger [Bingi et al., 1999]. Tilpasning af softwaren skal holdes på

et minimum [Holland et al., 1999; Roberts et al., 1992; Rosario, 2000; Shanks et al., 2000] eller helt

undgås [Bingi et al., 1999; Murray et al., 2001], da dette vil stille store krav til virksomhedens in

house ekspertise ved opdateringer og nyere udgivelser. Disse ændringer skal i så fald tilpasses

32

virksomhedens konfiguration. Murray et al. (2001) nævner derudover, at flere virksomheder ændrer

på ERP systemet uden at have det rette kendskab til de interne og interrelaterede

forretningsprocesser, det berører. Faktorscoren blev i undersøgelsen 4,22.

3.3.1.4 Change management culture and program Denne kritiske succesfaktor starter først i projektfasen, men løber derefter gennem resten af

implementeringsprocessen [Nah et al., 2001]. For at få opbakning til forandringer bør ledelsen gøre

problemerne ved status quo synlige. Når de forskellige stakeholders kan se behovet for forandring,

vil de også være mere villige til at foretage disse [Falkowski et al., 1998]. Ved en ERP

implementering bør der arbejdes med kulturen, medarbejderne og organisationen før, under og efter

implementeringen [Falkowski et al., 1998; Rosario, 2000].

Derudover bør organisationen oplyses om, hvad forandringerne i virksomheden vil indebære for

medarbejderne [Falkowski et al., 1998]. Dette betyder også, at medarbejdernes frygt og

bekymringer skal imødegås, hvilket kan gøres gennem regelmæssig information omkring

implementeringen [Rosario, 2000]. For at forandringer skal kunne finde sted, er det vigtigt, at

ledelsesstilen lægger op til disse forandringer [Falkowski et al., 1998]. Desuden bør der benyttes

forandringsagenter, for at lette ændringen i kulturen, som også skal finde frem til de brugere, der

har brug for støtte [Rosario, 2000].

For at brugerne ikke står på bar bund, når de skal til at bruge det nye system, er det vigtigt med

træning og uddannelse i systemet, samt at blive fortrolig med dette [Bingi et al., 1999; Murray et al.,

2001; Holland et al., 1999; Roberts et al., 1992; Shanks et al., 2000; Sumner, 1999]. Denne træning

og uddannelse bør også indeholde informationer omkring, hvordan deres arbejde med systemet vil

influere resten af virksomheden [Bingi et al., 1999; Murray et al., 2001; Roberts et al., 1992; Shanks

et al., 2000]. I forbindelse med uddannelse og træning af medarbejdere bør der især ses på IT

afdelingens behov for efteruddannelse [Sumner, 1999].

I forbindelse med organisations- og kulturforandringerne bør virksomhederne overveje at etablere

en støtteorganisation, som skal imødekomme brugernes behov og understøtte forandringerne [Nah

et al., 2003]. Denne kritiske succesfaktor ligger nummer fem ud af 11 i IT-chefernes vurdering af

vigtigheden af de kritiske succesfaktorer. Selve scoren blev 4,5.

33

3.3.1.5 Communication Effektiv kommunikation er en vigtig del i hele implementeringsforløbet. Kommunikationen er

effektiv, når den foregår målrettet og løbende til de forskellige grupper. Pålidelig og konsistent

information, samt feedback på medarbejdernes arbejde og henvendelser fordrer desuden succes

[Falkowski et al., 1998]. Denne information er kommunikation af resultater, fremskridt, fremtidige

aktiviteter, forventninger, estimater og udsving fra planen, hvorved alle involveret i projektet hele

tiden har mulighed for at følge med i, hvor i projektforløbet, virksomheden befinder sig [Holland et

al., 1999; Rosario, 2000; Sumner, 1999]. Det er også essentielt med den rette kommunikation til

stakeholderne. Det rette informationsniveau til stakeholderne vil motivere dem til at gå aktivt ind i

forandringsprocessen [Falkowski et al., 1998].

Projektledelsen har en central rolle i kommunikation under en implementering, da denne står som

den formelle reklame for projektets fremskridt til resten af organisationen [Holland et al., 1999].

Det er vigtigt at have kontrol med brugernes feedback og reaktioner under implementeringen.

Dårlig kontrol af og manglende reaktioner på disse informationer kan skabe huller i designet,

hvilket kan medføre tidsmæssigt omfattende møder og interviews og forsinkelser i

beslutningsprocesser [Rosario, 2000]. IT cheferne placerer denne kritiske succesfaktor midt i feltet

af de 11 kritiske succesfaktorer med en score på 4,39 [Nah et al., 2003].

3.3.1.6 ERP teamwork and composition Det er vigtigt gennem hele implementeringsprocessen at have et godt sammensat og samarbejdende

ERP team [Nah et al., 2001]. Virksomheder, der vil implementere et ERP system, skal vide, at de

bør afsætte nogle af deres bedste medarbejdere til implementeringen [Bingi et al., 1999; Shanks et

al., 2000; Falkowski et al., 1998; Buckhout et al., 1999]. Betydeligheden af dette kan næppe

overdrives [Bingi et al., 1999]. Udover at sætte de bedste medarbejdere på et ERP team er det

vigtigt, at dette team er balanceret sammensat. Dette betyder, at der skal være et godt miks af folk

med IT og forretningsmæssig forståelse [Shanks et al., 2000; Sumner, 1999]. Brugerne skal

derudover involveres i design og implementering af forretningsprocesserne [Holland et al., 1999].

For at dette team kan få så gunstige forhold at arbejde under som muligt, bør medlemmer af ERP

teamet være tilknyttet fuldtid til implementeringen og ikke have andre forpligtigelser i

organisationen [Shanks et al., 2000; Nah et al., 2001]. For at en implementering skal blive en succes

34

er det vigtigt, at medarbejderne i virksomheden stoler på hinanden, og er villige til at dele

information med hinanden [Stefanou, 1999]. Et godt ERP team består således af folk med teknisk

og forretningsmæssig forståelse, som er gode til at arbejde sammen, hvilket kan være svært at finde

i virksomheden. Det kan derfor være nødvendigt at bruge konsulenter til at dække nogle af de

ovenstående behov [Bingi et al., 1999; Sumner, 1999; Shanks et al., 2000]. Denne kritiske

succesfaktor var IT cheferne enige om var vigtig – den scorede tredje højest med 4,65.

3.3.1.7 Monitoring and evaluation of performance Projektets fremgang måles ved løbende overvågning af milepæle og mål. Hermed holdes opnåede

resultater op imod projektmålet [Murray et al., 2001; Roberts et al., 1992; Rosario, 2000; Sumner,

1999]. Denne overvågning foretages i shakedown og onward and upward faserne af projektet [Nah

et al., 2001]. Roberts et al. (1992) nævner to dimensioner for observering af evaluering. Et,

projektbaserede mål, hvor aktiviteter og events bliver sat op imod slutdatoer, omkostninger og

kvalitet af resultatet. To, operationelle mål (udbytte), hvor der ønskes opretholdelse af et vist niveau

af inventar, kundeservice, produktionstider, produktivitet etc.

For at en projektledelse skal kunne udføre en effektiv indsats, skal den have informationer om

systemets ydeevne. Her lægges der vægt på rapportering og uddannelse af medarbejdere i brug af

rapporteringsapplikationer og værktøjer [Sumner, 1999]. Derudover er det væsentligt i forhold til de

involverede, at indsatsen og belønningen stemmer overens [Falkowski et al., 1998]. Endvidere vil

tidlige tegn på succes minimere skepsis overfor projektet [Rosario, 2000]. Overvågning af indsatsen

ved udveksling af information i projektteamet og analyse af feedback fra brugerne er også en vigtig

del i denne kritiske succesfaktor [Holland et al., 1999]. Denne kritiske succesfaktor blev ikke

vægtet så højt af IT cheferne og opnåede den anden laveste score som er på 4,19.

3.3.1.8 Project champion Tilstedeværelsen af en projektsponsor er vigtigt gennem hele implementeringsprocessen [Nah et al.,

2001]. Ved en ERP implementering bør virksomheder derfor udnævne en projektsponsor; en person

som til enhver tid vil argumentere for fordelene ved implementeringen [Shanks et al., 2000]. Denne

projektsponsor skal sørge for at gøre projektet synligt og reklamere for det [Sumner, 1999].

Sponsoren skal også have evnen til løbende at løse konflikter og håndtere modstand mod såvel

systemet som de nye arbejdsgange [Stefanou, 1999].

35

Der er lidt uenighed omkring, hvor i organisationen denne projektsponsor skal komme fra. Shanks

et al. (2000) mener, at denne person ikke nødvendigvis behøver at komme fra topledelsen,

hvorimod Falkowski et al. (1998) mener, at sponsoren netop skal komme fra topledelsen, så

vedkommende har magt til at kunne gennemføre de ændringer, der måtte komme i løbet af

implementeringen. Rosario (2000) pointerer, at sponsoren skal ville projektet. Vedkommende skal

være i stand til at skære igennem bureaukratiet og kunne bruge både pisk og gulerod til at opnå de

ønskede resultater. Sidst men ikke mindst skal han være med hele vejen gennem implementeringen

[Rosario, 2000]. Denne kritiske succesfaktor scorede 4,67, og var den næst vigtigste ifølge IT

cheferne, som deltog i Nah et al.’s undersøgelse i 2003.

3.3.1.9 Project management God projektledelse er essentiel i alle IT projekter og ikke mindst i ERP projekter. Projekters succes

bliver ofte vurderet på bl.a. opfyldelse af scope og overholdelse af tidsramme og budget. Det kræver

en god projektledelse igennem hele projektperioden at opnå dette. Det er væsentligt for projektet at

give en person eller gruppe, i form af en projektleder eller styregruppe, ansvaret for at tilvejebringe

en succesfuld implementering [Rosario, 2000]. Derudover er det afgørende fra starten at have et

klart mål for implementeringen samt en detaljeret plan, som tidligere nævnt i business plan and

vision, til at opnå disse mål. Det er i denne sammenhæng vigtigt, at der findes en klar afgrænsning

af implementeringen [Holland et al., 1999; Shanks et al., 2000].

Der skal være en fast håndtering af grænserne for implementeringen, så der undgås for mange

diskussioner om ”lige at inkludere denne ene funktionalitet også” [Rosario, 2000]. Skulle der

fremstilles ændringer, skal enhver af disse vurderes i forhold til forretningsfordele, og for så vidt

muligt implementeres på et senere tidspunkt [Nah et al., 2003; Sumner, 1999]. Endvidere skal

forespørgsler om udvidelse af et projekt vurderes i forhold til tid, omkostninger og hvorledes disse

ændringer har indflydelse på forretningen [Sumner, 1999]. Projektplanen er den formelle definition

af projektet i form af definering af milepæle og den kritiske vej [Holland et al., 1999]. Det er

vigtigt, at disse milepæle og øvrige deadlines for projektet er realistiske sat [Murray et al., 2001;

Shanks et al., 2000].

For at tidsplan og budget skal kunne overholdes, skal udvidelse af scopet undgås. Derudover er det

en god ide at se fremad og tage beslutninger i tide, inden tingene begynder at eskalere. Derved er

36

sandsynligheden for, at store milepæle bliver nået til tiden større [Rosario, 2000]. En ERP

implementering medfører omfattende ændringer i flere dele af virksomheden, herunder

omstrukturering af jobdefinitioner. Der bør derfor foranstaltes en koordineret træning af alle berørte

parter. For at holde fokus på de personmæssige ændringer, der vil forekomme, skal Human

Resource afdelingen aktivt involveres i implementeringen [Falkowski et al., 1998]. Projektledelse

vejer tungt i undersøgelsen med en score på 4,59, og er således den fjerde vigtigste kritiske

succesfaktor for IT cheferne [Nah et al., 2003].

3.3.1.10 Software development, testing, and troubleshooting Softwareudvikling, test og fejlfinding er vigtigt, og kører fra projektfasen. Før systemet indføres i

virksomheden, skal den overordnede ERP arkitektur være fastsat og tilpasset de specifikke krav, der

er i den enkelte virksomhed. Derved undgås det, at der skal foretages løbende konfiguration

igennem projektforløbet [Nah et al., 2003]. Brugen af passende modelleringsmetoder, arkitekturer

og værktøjer kan være med til at reducere omkostningerne ved en implementering, da

dokumentation af arbejdsprocesser og sammenhænge gør det lettere at konfigurere systemet. Dette

kan samtidig øge brugeraccepten [Murray et al., 2001; Scheer et al., 2000]. Det er i denne

sammenhæng afgørende at finde frem til folk, der kan benytte disse teknikker og værktøjer

[Rosario, 2000].

Omfanget og raffineringen af brugertest processen bestemmer ofte, hvor smertefuld overgangen fra

det eksisterende til det nye system bliver [Rosario, 2000]. Fejlfinding er tillige kritisk for, hvor

problemfrit systemet vil køre [Holland et al., 1999]. Et ERP system kan sjældent levere hele den

funktionalitet, en virksomhed efterspørger. Derfor kan det være nødvendigt at integrere ERP

systemet med andre programmer, der er specifikke for den enkelte virksomhed, for at opnå fuld

valuta af implementeringen. Dette kan betyde, at virksomheden selv er nødt til at integrere dette

specifikke program med ERP systemet, medmindre der findes middleware på markedet, der kan

håndtere integrationen systemerne imellem [Bingi et al., 1999]. Denne kritiske succesfaktor er lavt

prioriteret og er med en score på 4,20 den niende vigtigste i undersøgelsen.

3.3.1.11 Top management support Topledelsens support er klassificeret som en af de væsentligste kritiske succesfaktorer i en

implementering af flere forskere, og er vigtig gennem hele forløbet. Topledelsen skal være aktiv og

37

involveret i hele processen, og sætte den som højeste prioritet på dagsordenen [Bingi et al., 1999;

Buckhout et al., 1999; Nah et al., 2001]. At topledelsen er engageret, entusiastisk og støttende

overfor implementeringen, sender et stærkt signal om prioriteringen, der vil smitte af ned gennem

organisationen [Shanks et al., 2000; Sumner, 1999]. Det vil samtidig signalere, at der er

fundamentale ændringer på vej [Murray et al., 2001]. Sumner (1999) pointerer at denne støtte ikke

kan overdrives.

Derudover er det vigtigt at topledelsen er villig til at allokere de ressourcer, der er nødvendige

[Holland et al., 1999]. Her er det specielt betydeligt med bemandingen; at der bliver sat nok

medarbejdere på, og at disse er sat på projektet på fuld tid [Roberts et al., 1992; Shanks et al.,

2000]. I Nah et al.’s (2003) undersøgelse indtog denne kritiske succesfaktor med en score på 4,76

førstepladsen.

3.3.2 De globale udfordringer Nah og Lau og deres medskribenter Kuang og Zuckweiler tager i deres artikler fra henholdsvis

2001 og 2003 ikke direkte stilling til, i hvilke situationer de nævnte succesfaktorer gør sig

gældende. Vi antager som udgangspunkt derfor, at disse kritiske succesfaktorer er universelt

gældende i alle ERP implementeringer, hvorfor alle, der implementerer et ERP system – stand alone

eller globalt etc. – bør kende til disse kritiske succesfaktorer. Det efterfølgende litteraturstudie vil

tillige med Nah et al.’s (2003) gennemgå, hvad der i litteraturen anses for at være vigtigt indenfor

de enkelte kritiske succesfaktorer og herunder fremhæve, hvor der ligger globale udfordringer. Det

kan derfor umiddelbart virke som en gentagelse af den tidligere gennemgang af de kritiske

succesfaktorer, men har netop til formål at be- eller afkræfte antagelsen om, hvorvidt de kritiske

succesfaktorer er universelt gældende. Denne be- eller afkræftelse, vil vi vende tilbage til i afsnit

3.3.3.

Virksomheder søger i højere grad end tidligere at integrere ERP systemer på tværs af landegrænser.

Hvor virksomheder førhen kun implementerede et ERP system lokalt, er virksomhederne i dag

begyndt at implementere deres ERP systemer globalt [Ghosh et al., 2003]. Grunden til denne

udvikling skal til dels findes i udviklingen indenfor telekommunikation. En anden og måske mere

presserende grund kan findes i den stadig større og hårdere globale konkurrence.

38

Den internationale konkurrence har gjort, at virksomheder i højere grad bliver globale, for at kunne

følge med. Dette sker som følge af, at afstandene ”mindskes” i form af klare forbedringer indenfor

transport og telekommunikation.

Forfattere/faktorer A

ppro

pria

te b

usin

ess a

nd in

form

atio

n te

chno

logy

lega

cy sy

stem

s

Bus

ines

s pla

n an

d vi

sion

BPR

Cha

nge

man

agem

ent a

nd c

ultu

re

Com

mun

icat

ion

Cul

ture

ER

P te

amw

ork

and

com

posi

tion

Mon

itori

ng a

nd e

valu

atio

n of

per

form

ance

Polit

ics

Proj

ect c

ham

pion

Proj

ect m

anag

emen

t

SW d

evel

opm

ent,

test

ing

and

trou

bles

hoot

ing

Top

man

agem

ent s

uppo

rt

Ghosh, S. 2002

Ghosh, S. et al. 2003

Hanseth, O. et al. 2001 Hill, R. et al. 2001

Huang, S. et al. 2004 Light, B. 1999 Madapusi, A. et al. 2005

Sarkis, J. et al. 2003

Sheu, C. et al. 2003

Total 2 5 6 7 3 4 8 1 3 3 7 6 5

Tabel 2 Matrice over globale kritiske succes faktorer

Kilde: Egen tilvirkning

Virksomheder, der vælger at forfølge en global strategi, får også et behov for at koordinere deres

aktiviteter på tværs af landegrænser. Til dette formål vælger virksomheder ofte at implementere et

ERP system, som giver virksomhederne muligheden for at arbejde effektivt i en globaliseret verden,

som følge af den opnåede integration af virksomheden. Der tænkes her på fordele som

arbejdsprocesser og procedurer, der standardiseres over hele virksomheden, hvorved samspillet

afdelinger imellem effektiviseres.

39

Den hårde internationale konkurrence gør, at virksomheder er nødt til at se på deres

forretningsstrategier, herunder IT-strategien, og sørge for at disse understøtter hinanden.

Effektivisering er et meget brugt ord i denne proces, og en måde hvorpå, der ofte kan effektiviseres,

er ved at implementere et globalt ERP system.

En af de største fordele ved et globalt ERP system er integreringen af virksomheden, hvad enten

virksomheden vælger at integrere alle moduler, eller kun integrerer de finansielle moduler.

Integreringen medfører en større gennemsigtighed gennem hele organisationen, og eliminerer noget

af den asymmetriske information, som førhen har præget mange organisationer.

En global implementering kan siges at være et specialtilfælde af en ERP implementering, og derfor

kunne det være interessant at undersøge, om der gælder nogle specielle kritiske succesfaktorer for

disse udover de ovennævnte kritiske succesfaktorer, der menes at gælde for alle ERP

implementeringer.

Jf. kriterierne i afsnit 2.3.1 gav søgningen 16 artikler, hvoraf 7 blev sorteret fra, jf. tredje punkt

ovenfor. Af de ni artikler, der efterfølgende vil blive anvendt til vores studie, indeholder seks af

dem ordet global, to indeholder ordet international og en indeholder ordet multinational.

Analysen af de udvalgte artikler i litteraturstudiet viste, at der findes kritiske succesfaktorer, som

kan siges at være specielle for globale implementeringer. I tabel 2 kan ses, hvilke af de forskellige

kritiske succesfaktorer, der understøttes af artiklerne i litteraturstudiet. De kritiske succesfaktorer

for en global implementering vil efterfølgende blive gennemgået.

3.3.2.1 Appropriate business and information technology legacy systems Denne kritiske succesfaktor er, ligesom i den oprindelige undersøgelse, ikke synderligt godt

underbygget i undersøgelsen. Kun to artikler nævner ældre systemers påvirkning i forbindelse med

implementering af ERP systemer.

I artiklen af Huang et al. (2004) identificerer vestlige projektledere integrating legacy systems with

ERP som en kritisk succesfaktor. Dette underbygges yderligere ved en statistisk analyse26, hvor

igennem de finder frem til en kritisk succesfaktor de kalder for integration and communication 26 Foretaget i en europæisk virksomhed, der opererer i 60 forskellige lande verden over.

40

between legacy system and ERP. Der bliver ikke givet en uddybende forklaring på, hvad denne

kritiske succesfaktor dækker over, dog kan det ses gennem statistikken, at faktoren bygger på fire

variabler, hvoraf to direkte omhandler enten kommunikationen mellem systemer eller konvertering

af data fra det gamle til det nye system. De sidste to variabler fokuserer på kommunikation til

medarbejderne omkring det nye system og evnen til at tilpasse sig det nye systems processer.

Evnen til at tilpasse sig et nyt system illustreres af Light (1999). Virksomheden valgte ikke at

udføre BPR i sin amerikanske division, da dette ville forsinke ERP projektet. Casen illustrerer, at

gamle systemer, der skal erstattes, kan have stor indflydelse på ERP projektet som helhed, og at

virksomheder og konsulenter bør være opmærksomme på dette. Som det antydes, handler den

kritiske succesfaktor både om de legacy systemer, som erstattes, og de legacy systemer, som stadig

vil være i brug efter implementering. De der erstattes, påvirker implementeringsprocessen på den

måde, at medarbejderne har været vant til at gøre tingene på en bestemt måde, hvor de nu skal lære

nye arbejdsprocesser.

I den globale sammenhæng kan der under denne kritiske succesfaktor være flere legacy systems,

der skal erstattes af ERP systemet. Derved vil denne udfordring være af en noget større art, hvis de

forskellige afdelingers legacy systems ikke tidligere er bygget op omkring og ikke har understøttet

de samme processer.

3.3.2.2 Business plan and vision Virksomheder, der opererer globalt, har i lige så høj grad som nationale virksomheder brug for at

udarbejde strategier for en kommende ERP implementering. Flere af artiklerne om globale

implementeringer pointerer vigtigheden af, at der i en virksomhed er overensstemmelse imellem

den globale forretnings- og ERP strategi [Huang et al., 2004; Light, 1999; Madapusi et al., 2005;

Sarkis et al., 2003 og Sheu et al. 2003].

Da hovedformålet med at implementere et ERP system i en global virksomhed som oftest er, at

integrere de forskellige divisioner i større eller mindre grad, kræver denne integration, at

virksomheden har udarbejdet en tilstrækkelig detaljeret forretningsplan inden implementeringen af

ERP systemet sættes i gang [Madapusi et al., 2005; Sheu, 2003], hvilket også var tilfældet hos Nah

41

et al.. Derved søges det at undgå misfits27, hvis omfanget øges ved globale implementeringer.

Kritiske succesfaktorer som kultur, sprog, ledelsesstil, politikker, reguleringer og skikke skaber

nationale forskelligheder og spiller ind på, hvorledes virksomhederne udfører deres forretning.

I Huang et al.’s (2004) undersøgelse, fandt de, at ERP projektledelsesproblemer bl.a. skyldes

konflikter med forretningsstrategien. Texas Instruments (TI) fandt det ligeledes vigtigt at udarbejde

en indgående strategisk plan og skabe sammenhæng imellem IT og forretning [Sarkis et al., 2003].

TI havde succes med at lave en global model til hele forretningen, så de dermed kunne udnytte den

gennemsigtighed i hele organisationen, dette medførte. Dette bevirkede, at der skete en omdannelse

af, hvordan forretningen blev ledet og gennemført. Sheu et al. (2003) fremhæver, at mange

forretningsmodeller i ERP systemer er bygget op omkring vestlige praksiser, der kan være meget

forskellige fra de asiatiske. Derfor er det vigtigt, at der fokuseres på disse nationale forskelligheder

som det første i en global implementering.

Det nye og udfordrende i denne kritiske succesfaktor set i det globale perspektiv ligger i

vigtigheden af den strategiske alignment af forretnings- og ERP strategien. En udfordring, der er

tilføjet en ekstra dimension i og med, at dette foregår i flere forskellige lande og verdensdele. Dette

bevirker, at der opereres indenfor forskellige kulturer, sprog og nationalspecifikke krav etc., der

stiller større krav til den strategiske planlægning og udførelse af ERP implementeringen.

3.3.2.3 Business process reengineering Seks ud af de ni artikler nævner BPR i forbindelse med ERP implementering. Dette er en stærk

indikation af, at BPR tillige er vigtig i globale ERP implementeringer. I Nah og Lau’s to

undersøgelser er denne kritiske succesfaktor også stærkt underbygget [Nah et al., 2001; Nah et al.,

2003]. Ved implementering af et ERP system, bør det søges at ændre systemet så lidt som muligt

[Ghosh, 2002; Huang et al., 2004]. Også i globale virksomheder er grunden til dette, at det vil lette

virksomhedernes opgave mht. vedligeholdelse af systemet. Virksomheder modificerer i dag ikke

ERP softwaren, medmindre det er nødvendigt for at leve op til statslige lovkrav, eller det hindrer

virksomheden i at køre effektivt [Ghosh, 2002; Light, 1999].

27 Gabet imellem funktionaliteten, der tilbydes i ERP systemet og det, der forventes af virksomheden, der indfører det.

42

Hydro Agri Europe’s (HAE’s) implementering af et ERP system resulterede i, at mange forskellige

afdelinger af divisionen hver især tilpassede ERP systemet til deres behov. Dette ønskede HAE

ikke, men det skete som følge af manglende styring af implementeringen fra divisionens side. Dette

har bevirket lange ventetider hver gang, der kommer en ny version, da disse alle skal tilpasses de

enkelte afdelingers systemer samt kunne ”snakke” sammen indbyrdes [Hanseth et al., 2001].

Netop dette var, hvad TI ønskede at undgå, da de skulle foretage deres globale implementering,

hvorfor de tog en beslutning om hellere at lave om på arbejdsprocesserne, end lade projektet løbe

løbsk ved at lade de forskellige divisioner og afdelinger tilpasse systemerne individuelt. Dette

lykkedes grundet et stærkt lederskab [Sarkis et al., 2003]. Eksemplet fra HAE viser betydningen af,

at udføre så få forskelligartede ændringer i de forskellige afdelinger, hvis der ønskes integration.

Derudover viser det, at det specielt i globale implementeringer er essentielt at have styr på

tilpasninger fra centralt hold, da der her kan være mange divisioner og afdelinger at holde styr på.

Den vigtigste kritiske succesfaktor i globale implementeringer er ifølge flere forskere, at BPR

foretages så hurtigt og effektivt som muligt [Ghosh, 2002; Huang et al. 2004; Hill et al., 2001].

HAE valgte at foretage BPR uden at skelne til ERP systemets processer, hvilket betød, at der ikke

rigtig skete noget, før systemet blev installeret og tvang BPR igennem [Hanseth et al., 2001]. Som

følge af strategien om ikke at tilpasse systemet, var det nødvendigt med et massivt BPR projekt hos

TI, for at opnå målet omkring globale standardprocesser [Sarkis et al., 2003]. Derudover bør

virksomheder rationalisere deres forretningsmodeller og processer [Sarkis et al., 2003]. Set i en

global sammenhæng bør virksomheder indenfor de forskellige forretningsområder søge at opnå så

standardiserede processer som muligt, hvilket vil mindske tilpasninger. Derfor vil der være et

udbredt behov for at gennemføre et globalt BPR projekt.

Som ved et nationalt perspektiv er BPR en essentiel del af en succesfuld udgang af en ERP

implementering. Udfordringerne bliver på det globale plan noget større og langt mere komplekse,

da der er flere afdelinger, der skal have tilpasset deres processer indbyrdes. Da disse afdelinger

ligger i forskellige lande, vil der være store udfordringer i form af forskellig arbejds- og

landekultur.

43

3.3.2.4 Change management culture and program De fleste forfattere er enige om, at change management i forbindelse med ERP implementering er

vigtigt, da denne kritiske succesfaktor er nævnt i syv ud af ni artikler omkring globale

implementeringer og i ni ud af 12 tilfælde i Nah og Lau’s artikel fra 2003. Tre af artiklerne omkring

globale implementeringer nævner, at brugernes støtte til implementeringen har betydning [Ghosh,

2002; Hill et al., 2001; Huang et al., 2004]. Modstand fra slutbrugere og funktionelle ledere kan

føre til at implementeringen slår fejl. Især i globale implementeringer er det essentielt med støtte fra

hele organisationen, da der er mange flere forhold, der kan gå galt [Ghosh, 2002].

Medarbejderes manglende vilje til forandringer er tillige et af de problemer, der skal tages hånd om

i en global ERP implementering [Hill et al., 2001; Huang et al., 2004]. En af metoderne til at fjerne

denne modstand mod systemet er som det også konstateres af Nah et al. at involvere brugerne i

implementeringen [Sarkis et al., 2003; Hill et al., 2001], samt at træne og motivere dem[Ghosh,

2002; Huang et al., 2004]. Her er det blandt andet vigtigt, at de lærer de nye måder at køre

forretningen på [Hill et al., 2001]. Derudover bør der oprettes støttegrupper til brugerne, så de kan

få hjælp til deres problemer. Formålet med dette er at højne brugernes tilfredshed med systemet

[Sarkis et al., 2003]. Brugerne skal vide og forstå, at produktiviteten kan falde umiddelbart efter

”go-live”, så de ikke har urealistiske forventninger til, hvordan fremtiden bliver [Sarkis et al.,

2003].

I en global implementering kan der være stor forskel på det generelle uddannelsesniveau i de

forskellige lande, en virksomhed ønsker at implementere i. Derfor kan der nogle steder være et

større behov for uddannelse og træning i det nye system end andre steder [Sheu et al., 2003].

Udover træning bør virksomheder også benytte sig af forandringsagenter på alle niveauer i

organisationen [Ghosh, 2002]. Vælger virksomheden at bruge forandringsagenter bør disse have

visse magtbeføjelser over de personer, de skal påvirke [Hanseth et al., 2001].

Endvidere kan afdelinger, der før ikke har snakket med hinanden, blive tvunget til at arbejde

sammen i en global ERP implementering. Integrationen og det deraf følgende samarbejde betyder

derfor, at virksomheden skal arbejde hårdt for at skabe et fællesskab mellem disse afdelinger, så de

føler, at de deler den samme baggrund, kultur og identitet. Dette kan kun opnås gennem samarbejde

44

på tværs af afdelingerne [Hanseth et al., 2001]. Udover de ovenstående tiltag er det også vigtigt, at

virksomheden står fast på den kurs, der er lagt [Light, 1999].

Udfordringerne er her i den globale sammenhæng først og fremmest at få støtten fra hele

organisationen. Derudover er det vigtigt at være opmærksom på det forskellige uddannelsesniveauet

der kan forekomme.

3.3.2.5 Communication Effektiv og målrettet kommunikation er endnu en kritisk succesfaktor i en global ERP

implementering, om end det kan være sværere at opnå i denne sammenhæng. Modsat en national

implementering, kan der her være flere barrierer i form af bl.a. sprog og kultur. Telefonmøder eller

videokonferencer over lange distancer kan være meget anderledes og ofte vanskelige. Det kræver

tålmodighed og flid hos de forskellige parter, for at dette kan fungere [Ghosh, 2002].

At kommunikation også er væsentlig i en global sammenhæng, understøttes af Hanseth et al.’s

(2001) undersøgelse af HAE’s SAP R/3 implementering, hvor kommunikationen ud til de

forskellige enheder virkede dårligt. Der var stor modstand mod de omfattende ændringer, der skulle

foretages, og projektet havde svært ved at komme videre pga. hindringer som kompleksitet og

kulturforskelle. Endvidere var der stor uforståenhed omkring, hvad dette projekt gik ud på, og at det

ikke bare var "endnu et IT projekt". For at undgå en sådan situation, bør det kræves, at ledende

medarbejdere i projektet definerer, hvad projektet indebærer, og hvad det skal føre med sig. Dette

inkluderer en definition af, hvornår projektet ses som værende en succes. Derudover pointeres det,

at i et projekt af denne størrelse og spredning28, er kommunikation på tværs af organisationen

afgørende.

Huang et al. (2004) konkluderer, at opbygning af god kommunikation og koordinering blandt de

forskellige forretningsenheder er en kritisk succesfaktor i den vestlige verden, og inkluderer

kommunikationsfærdigheder i en af deres i alt syv kritiske succesfaktorer – Clear ERP strategy,

training programme, communication skills and coordination capability.

28 Artiklen beskriver implementeringen i en ud af seks parallelle implementeringer i deres Europæiske division af HAE.

45

De afgørende globale udfordringer er her at opnå en effektiv kommunikation med folk fra andre

kulturer, og for så vidt muligt søge at undgå, at der opstår problemer grundet de kulturelle og

sproglige barrierer, hvilket både Ghosh (2002) og Hanseth et al. (2000) behandler i deres artikler.

3.3.2.6 ERP teamwork and composition Denne kritiske succesfaktor er en af de bedst underbyggede af de globale succesfaktorer i globale

ERP implementeringer. 7 ud 9 artikler underbygger denne kritiske succesfaktor, hvilket set i

sammenhæng med Nah og Lau’s artikel, gør denne kritiske succesfaktor til en af de bedst

underbyggede. Virksomheder skal rekruttere motiverede medarbejdere med de rette evner til at stå

for ERP implementeringen. Virksomheder skal være klar til at vælge, træne og holde på de rette

medarbejdere til at lette implementeringen, hvilket er en af de største udfordringer som globale

virksomheder står over for [Madapusi et al., 2005].

Ved globale implementeringer kan det være nødvendigt at udstationere medarbejdere gennem

længere tid uden familie og venner. Derudover skal disse folk være i stand til at adoptere en helt ny

kultur, hvilket ikke alle mennesker er lige egnede til [Ghosh, 2002]. Når de rette medarbejdere er

fundet, er det nødvendigt, at de bliver fuldstændigt fjernet fra deres gamle ansvarsområder, og kun

skal dedikere deres tid til ERP implementeringen [Sheu et al., 2003], hvilket tidligere er blevet

pointeret. Dette betyder også, at folk kun skal stå til ansvar for deres leder i forbindelse med

implementeringen, og ikke deres oprindelige leder [Huang et al., 2004].

Gennem Huang et al.’s (2004) statistiske analyser kan det ses, at det er vigtigt, at virksomheder

opsætter krydsfunktionelle arbejdsgrupper i forbindelse med ERP implementeringer. HAE opnåede

som en ekstra gevinst af, at forskellige afdelinger arbejdede sammen på tværs, at de fandt nye

måder, hvorpå de kunne samarbejde [Hanseth et al., 2001]. Dette kunne være et stærkt signal om, at

disse krydsfunktionelle arbejdsgrupper ikke kun skal finde sted inden for de forskellige afdelinger,

men også afdelingerne imellem især i globale implementeringer.

Derudover er det vigtigt for virksomheder at finde frem til de medarbejdere, der forstår sig på både

ERP software samt forretningsmetoder og statslige krav, så disse kan blive indarbejdet i ERP

softwaren [Ghosh, 2002]. En måde at komme rundt om denne problemstilling på, er ved at hyre

konsulenter, der forstår sig på dette [Light, 1999]. At bruge anerkendte konsulenter til at hjælpe

46

med ERP implementeringen kan vise sig at være en meget god investering [Huang et al., 2004;

Sarkis et al., 2003]. Udover hjælp fra konsulenter kan ERP leverandøren spille en meget stor rolle i,

hvor let ERP implementeringen bliver, især den tekniske del [Huang et al., 2004]. Derudover bør

der bruges konsulenter i hele implementeringsprocessen og ikke kun ved de første afdelinger, der

tager ERP systemet i brug. I modsat fald kan det have store konsekvenser for resten af

implementeringsprocessen [Sheu et al., 2003].

Udfordringen ligger globalt i at rekruttere og holde på de rette medarbejdere til implementeringen.

Ud over at de skal være motiverede for opgaven, skal de også være i stand til at agere i og omstille

sig til de forskellige kulturer, de kommer til at arbejde i. Teammedlemmerne kommer til at

samarbejde med mennesker fra andre virksomheds- og landekulturer, hvilket de også skal være i

stand til.

3.3.2.7 Monitoring and evaluation of performance Denne kritiske succesfaktor er kun nævnt i én ud af de ni globale artikler i denne analyse, hvilket

stærkt indikerer, at det ikke er en kritisk succesfaktor, der lægges så stor vægt på i litteraturen. Det

er den samme tendens, som i Nah et al.’s (2003) artikel, hvor den også lå lavt i prioritet hos de

adspurgte IT chefer.

Denne ene forekomst findes i TI’s ERP implementering [Sarkis et al. 2003]. Her valgte TI at

outsource driften af deres ERP system til Andersen Consulting29, der også var konsulenter på ERP

projektet. De medarbejdere i TI, der fremover skulle stå for drift og vedligeholdelse af ERP

systemet, blev ansat i Andersen Consulting, hvorfra deres primære opgave var TI’s ERP system. TI

og Andersen Consulting virksomhedskulturer og politikker krævede et meget stringent og formelt

brug af målbare data – metrics – i deres ledelse og evaluering af projekter, hvilket også var tilfældet

i TI’s ERP implementering. Troskaben til denne politik, tilskriver de som en af hovedårsagerne til

deres succesfulde implementering.

At denne kritiske succesfaktor angives som en af hovedårsagerne til, at de opfattede deres ERP

implementering som en succes, skal måske findes i deres virksomhedskulturer, hvor de lægger

29 Der i dag har skiftet navn til Accenture.

47

meget vægt på denne målbarhed til styring af projektet. Dermed er dette eksempel ikke universelt

og generaliserbart.

3.3.2.8 Project champion I globale sammenhænge er der tre af artiklerne, der beskæftiger sig med projektsponsorer. Når der

skal vælges og implementeres et ERP system, vil det berøre hele virksomheden og dermed også alle

funktionsområderne i virksomheden. For at tilstræbe, at så mange medarbejdere som muligt bliver

glade for systemet, er det vigtigt med tilstedeværelsen af en projektsponsor [Ghosh, 2002]. Denne

sponsor er en betydelig person, der skal motivere alle parter og sikre, at alle kan se nytten af

systemets indførelse.

Ghosh (2002) og Madapusi et al. (2005) pointerer, ligesom Falkowski et al. (1998) som før nævnt,

at denne sponsor skal være fra topledelsesniveauet i virksomheden. Dette er vigtigt, da han har den

tilstrækkelige magt i virksomheden til at tage kritiske beslutninger og udføre hurtige ændringer

igennem projektforløbet. Samtidig skal denne person holdes ansvarlig for, at projektet forløber efter

planen, og at der dermed bliver foretaget en effektiv udrulning af ERP systemet. Som

projektsponsor er det også væsentligt at have tilstrækkelig indsigt i virksomheden og det rette

engagement.

Hos TI havde projektsponsoren og lederen af ERP projektet over 20 års erfaring i virksomheden på

forskellige niveauer i organisationen [Sarkis et al., 2003]. Han havde en bred viden indenfor flere

forskellige forretningsområder indenfor TI og dermed stor viden om processerne indenfor disse.

Derudover besad han teknisk viden om store virksomhedssystemer. Fordelen ved at have en mand

af denne kaliber og erfaring indenfor samme virksomhed er den store troværdighed, der må antages

at være om hans person og faglige kunnen. Dermed er han en god sponsor af et globalt ERP projekt.

Udfordringen som projektsponsor i den globale sammenhæng er at finde en person, der, udover at

besidde de rette kvalifikationer, er synlig nok i virksomheden til at nyde den rette anerkendelse.

3.3.2.9 Project management Denne kritiske succesfaktor er, med syv artikler, en af de bedst understøttede kritiske succesfaktorer

i forbindelse med globale implementeringer, som det også er tilfældet i Nah et al.'s (2003)

48

undersøgelse. Et godt projekt team og god projektledelse er vigtig i ERP implementeringer [Huang

et al., 2004]. Projektledere skal være stærke nok til at skabe tillid til slutbrugerne ved at adressere

problemområder og skabe fornuftige måder at arbejde rundt om problemerne på [Ghosh, 2002].

Endvidere indikeres det i Huang et al. (2004), at det kan være fornuftigt at opstille en styrekomite

på tværs af de nationale afdelinger. Denne styrekomite skal underrettes om projektets udvikling,

give projektledelsen støtte til budget og software forandringer, tage beslutninger omkring

virksomhedens politikker og strategier, løse flaskehalsproblemer samt sende brugerrepræsentanter

ud til at støtte kerneprojektmedlemmer med implementeringen.

Den organisatoriske og tekniske del af implementeringen bør ikke deles op i to sideløbende

projekter [Ghosh et al., 2003]. Derudover bør der, som tidligere konstateret, skabes en klar

definition af projektets omfang og føres kontrol med, at det ikke vokser i størrelse, så budgettet

sprænges [Huang et al., 2004]. Manglende projektplanlægning vil især i globale ERP

implementeringer skade processen som følge af tværnationale forskelligheder [Sheu et al., 2003].

Hill et al. (2001) fremhæver at en japansk ERP implementering har tilbøjelighed til at være meget

detaljeret med hensyn til kravspecificering og designfasen, men kræver færre anstrengelser med

tests og i overgangsfaserne. Derudover er der, måske endnu mere vigtigt, færre overraskelser ved

”go-live”, og selve projektdelen af implementeringen er væsentlig kortere.

I forbindelse med projektplanlægningen er det vigtigt at udarbejde en realistisk tidsplan og sætte

realistiske milepæle, og derefter tilstræbe at disse overholdes [Huang et al., 2004; Madapusi et al.,

2005]. Dog, hvis implementeringen står ved en korsvej, er det vigtigt at evaluere sine muligheder,

samt at ændre retning, hvis dette er nødvendigt. Derfor er det også hensigtsmæssigt at have

indbygget slack i budgettet til sådanne situationer [Sarkis et al., 2003].

Ved en global implementering bør projektledelsen være klar over, hvornår forskellige lande har

ferier, så uhensigtsmæssigheder undgås [Ghosh, 2002]. Derudover er det vigtigt at koordinere

implementeringen på tværs af alle afdelinger og involverede parter [Huang et al., 2004; Sarkis et al.

2003].

49

I forbindelse med globale ERP implementeringer bør virksomheder tillige udnytte de metanationale

fordele, de har til rådighed, især med hensyn til den tekniske del. Hvis en virksomhed foretager en

implementering i Danmark, og har en afdeling i Indien, hvor der sidder folk med IT kompetencer,

kan det være billigere for virksomheden at lade den indiske IT kompetente medarbejder se på

problemet ved at sende dataene til ham. Dette ville også være billigere end at hente ham til

Danmark, hvor der i så fald kunne opstå en række andre problemer i form af

immigrationsvanskeligheder og kulturelle problemer [Ghosh, 2002; Ghosh et al., 2003]. God brug

af disse metanationale fordele, hvis de er til stede inden for organisationen, er en nem måde at spare

penge på i en global økonomi [Ghosh et al., 2003].

Overordnet set ligger de største udfordringen for projektledelsen i den globale ERP implementering

hovedsagligt i det større scope og de større forskelligheder, der findes ved at implementere i

kulturelt forskellige lande.

3.3.2.10 Software development, testing, and troubleshooting Indførelsen af et ERP system i en global sammenhæng har som før nævnt til stadighed det formål at

integrere virksomhedens afdelinger og divisioner rundt om i verden. Konfigurationen af den

overordnede arkitektur er derfor en vigtig del af implementeringen, hvor den tekniske del af

implementeringen ikke skal køre sideløbende med, men som en del af den store ERP

implementering [Ghosh et al., 2003].

Virksomheden skal identificere sine krav til et ERP system rent teknisk30, og være opmærksom på

denne del af implementeringen. Ghosh et al. (2003) mener, at dette er gået lidt tabt, da man er gået

fra at se en ERP implementering som et IT projekt til at se det som en forretningsinvestering.

Derudover vil en omhyggelig konfiguration have den direkte konsekvens, at virksomheden kan

høste fordelene ved ERP systemet [Madapusi, 2005]. Her er integrationen af systemer en vigtig del

af processen, da der ingen garanti er for, at et ERP system kan understøtte alle de ønskede

funktioner i alle divisioner i virksomheden. Nogle gange kan det derfor være nødvendigt at

integrere nogle selvudviklede applikationer med ERP systemet for at øge integrationen af

virksomheden [Hanseth et al., 2001].

30 Her tænkes der på de krav til server, klientmaskiner, netværkets båndbredde og udnyttelser samt support og backup

50

Inden implementeringen påbegyndes og ERP systemet tages i brug, er det afgørende at integrere

alle de ønskede funktioner [Ghosh, 2002] og få konverteret dataene fra de nuværende systemer til

ERP systemet [Huang et al. 2004]. Der kan her være store udfordringer i at standardisere f.eks.

produktinformationer for hele virksomheden over landegrænser og verdensdele. I TI’s tilfælde,

krævede det en stor IS og forretningsmæssig indsats at standardisere produktnumre indenfor hele

virksomheden i form af ændringer i databaser og de programmer, der var tilknyttet databaserne

samt at få ændringerne kommunikeret ud til kunderne [Sarkis et al., 2003].

De to store udfordringer globalt set ligger i konfiguration og integration af virksomhedens

afdelinger, samt at få opbygget en fælles datastruktur.

3.3.2.11 Top management support En kritisk succesfaktor, der også i den globale ERP litteratur er vægtet højt, er topledelsens

billigelse og support til projektet [Hill et al., 2001; Huang et al., 2004]. Topledere skal være aktivt

involveret i projektet for at anerkende og arbejde for det operationelle og strategiske potentiale, der

ligger i investeringen [Light, 1999]. Her pointeres det tillige at ved aktiv udmeldelse og synlig

involvering, giver det en stærk indikation fra ledelsen af, at dette projekt har top prioritet. Et

eksempel herpå er TI, hvor direktøren og bestyrelsesformanden i deres kvartalsmæssige

satellittransmissioner til hele virksomheden berettede om vigtigheden og status for projektet [Sarkis

et al., 2003]. Hermed viser de synligt, at der fra højeste niveau er støtte til projektet. Et andet

eksempel fra litteraturen er hos NCQ, hvor ERP projektet blev ledet af de administrerende

direktører i de forskellige divisioner [Sheu et al., 2003].

Udover støtte og involvering fra højeste niveau i virksomheden, er det også vigtigt, at der bevilges

de nødvendige ressourcer til projektet, som tidligere angivet. Det er her optimalt, at medarbejdere er

tilknyttet projektet på fuld tid, som det er tilfældet i NCQ. Dette betyder, at medarbejderne arbejder

100 % på implementeringen, da de ikke har andre opgaver og ansvarsområder, de skal holde styr på

i projektfasen.

3.3.2.12 Politics Dette er en af de to nye kritiske succesfaktorer, som er blevet identificeret i forbindelse med globale

implementeringer. Der er tre artikler, som beskæftiger sig med denne kritiske succesfaktor. Et af de

51

store problemer i en global ERP implementering er, at systemet skal leve op til de forskellige landes

love og regler [Ghosh, 2002]. Virksomheder søger ofte at opbygge en finansiel database, der kan

tilfredsstille flere landes love og regler. Landene har forskellige regler og love for regnskabspraksis,

samt for hvordan forskellige dokumenter skal håndteres. Dermed vil forsøg på at rette databasen til

for ét land resultere i, at et andet lands love og regler ikke overholdes grundet disse ændringer

[Ghosh, 2002]. Dette medfører betydelige vanskeligheder for virksomheder, der ønsker at foretage

en global implementering.

Derudover har lande forskellige regler indenfor miljø, skat og infrastruktur, hvilket kan påvirke

ERP implementeringen [Hanseth et al., 2001]. Især skatteområdet er noget, som virksomheder

spekulerer i. Forskellige skattesatser i landene gør, at virksomheder udvikler komplekse

forretningsprocedurer for at spare på skatteudgifterne, hvorved globale implementeringer

kompliceres [Sheu et al., 2003]. Toldsatser udgør også et område, som komplicerer

implementeringen for virksomheden. Lande, der har handelsaftaler med hinanden, har

toldformularer, import/eksport toldsatser og godkendelsesprocedurer, der er forskellige fra de, der

gælder for lande, der ikke findes handelsaftaler imellem. Dette er ERP systemer ikke kodet til at

kunne håndtere, og dette kræver derfor omfattende modificering af systemet [Sheu et al., 2003].

Udover indbyrdes forskelligheder landene imellem omkring love og skatter spiller også landenes

diplomatiske forbindelser en rolle i forbindelse med ERP implementeringer. Et unikt eksempel er

det diplomatiske forhold mellem Taiwan og Kina. Kinesisk lov forbyder taiwanesiske virksomheder

at eje selskaber i Kina. Derfor er taiwanesiske virksomheder nødt til at oprette skuffeselskaber i et

tredjeland, og lade dette selskab eje den kinesiske virksomhed. Dette vanskeliggør ERP

implementeringen, da systemerne ikke er sat op til at kunne klare sådanne diplomatiske forhold

[Sheu et al., 2003].

Politik på virksomhedsniveau kan også spille ind på ERP implementeringen. Nogle

virksomhedsledere ønsker ikke at få den fulde integration af virksomheden, som systemerne

understøtter. Integrationen, der ellers er en af grundstenene og fordelene ved et ERP system, ønskes

ikke, da virksomhedslederne er bange for, at hvis alle afdelinger får adgang til al information, vil

nogle føle sig forfordelt31 og kræve, at flere ressourcer flyder deres vej [Sheu et al., 2003]. Dermed

31 I betydningen at give nogen en mindre del end det, de har krav på, el. for lille en del i forhold til andre.

52

udnytter virksomhederne ikke ERP systemerne fuldt ud og kan ikke høste de forventede frugter

[Sheu et al., 2003].

Virksomhedernes ansvarsfølelse overfor de ansatte kan være endnu en barriere til en succesfuld

implementering. I nogle lande, f.eks. Taiwan, forventes det, at virksomheden omrokerer på folk, så

de kan forblive i arbejde, eller at virksomheden tager sig af dem på anden måde. I de fleste lande er

der ikke tradition for, at virksomheder udviser generel interesse eller følger op på, hvordan det går

fyrede medarbejdere [Sheu et al., 2003]. Det er derfor vigtigt, at virksomheden kender forholdene

på dette område i de lande, hvor de opererer, hvis de ønsker, at medarbejderne ikke skal modarbejde

implementeringen som følge af medarbejderusikkerhed.

3.3.2.13 Culture Karakteristisk for denne anden nye kritiske succesfaktor er de forskelligheder, der præger kulturen i

de forskellige lande, hvor en global ERP implementering finder sted. Da flere og flere virksomheder

spreder deres forretning over hele verden, vil de ofte møde disse kulturelle forskelle og nye

udfordringer i projektet. Qua denne spredning af forretningen vil der være forskel på kulturen i den

generelle forstand. Der tænkes her på de vaner, trosretninger og skikke, der skaber og differentierer

de forskellige befolkningsgrupper og samfund fra hinanden [Ghosh et al. 2003; Huang et al., 2004].

Forskning indenfor globale ERP implementeringer fremhæver og lægger vægt på, at denne

forretningsmæssige og kulturelle inddragen har stor indflydelse på implementeringen [Ghosh, 2002;

Hanseth et al., 2001; Sheu et al., 2003]. Den er vigtigere end den tekniske udfordring af

implementeringen [Sheu et al., 2003].

Projektlederne og –medarbejderne skal være i stand til at håndtere de kulturelle forskelle i en

hvilken som helst international implementering [Ghosh, 2002]. Sheu et al. (2003) nævner en

undersøgelse, hvor det pointeres, at det kan føre til en katastrofe, hvis ikke der tages hensyn til

forretningskultur, produktionsmetoder og kundeefterspørgsel. Derudover viser de også, at lederstil

har indflydelse på implementeringen32.

En del af den kulturelle forskel lande imellem er sprog. Udfordringerne i forbindelse med sproget

har både et teknisk og et kommunikationsmæssigt aspekt [Sheu et al., 2003]. Det tekniske aspekt 32 Beskrevet under faktoren Top management support.

53

går på, hvor mange sprog33 systemet understøtter, samt emner som hvordan et navn skrives ind i

systemet. Hvis en implementering i f.eks. Taiwan kræver, at systemet kan håndtere engelsk, vil der

være visse standarder som eksempelvis på hvilken måde et navn skrives i systemet, der kunne skabe

modstand fra medarbejderne imod ERP implementeringen [Sheu et al., 2003]. Rent

kommunikationsmæssigt kan der opstå misforståelser, når der skal implementeres i forskellige

lande, hvilket kan resultere i valg af forskellige ERP udbydere, når hovedkvarteret og divisionerne

ikke taler samme sprog [Sheu et al., 2003]. Dette kan have den yderligere konsekvens, at

integrationen af systemerne imellem de forskellige divisioner begrænser sig til de finansielle og

regnskabsmæssige moduler.

Til sidst kan der være forskel på medarbejderfærdighederne i de forskellige divisioner verden over.

Uddannelsesniveauet kan, som nævnt i change management culture and program, have indflydelse

på, hvor lang tid uddannelse i systemet tager og dermed øver det indflydelse på

implementeringsperioden [Sheu et al., 2003].

Generelt har de kulturelle aspekter af en implementering stor indflydelse i en global sammenhæng.

De har også en indflydelse på, hvilke kritiske succesfaktorer, der skal fokuseres på [Huang et al.,

2004]. Dermed kan den kulturelle kritiske succesfaktor anskues fra flere forskellige vinkler. For det

første er de mere generelle kulturforskelle som tro og skikke mere eller mindre selvstændige

elementer, der skal tages hensyn til i den globale implementering. Her skal man som ansvarlig for

implementeringen være meget opmærksom på disse forskelle i kulturen, da der i visse situationer

skal handles anderledes i en situation i Kina end i hovedkvarteret i Danmark. Derudover ligger der

implicit i nogle af de øvrige kritiske succesfaktorer også kulturelle udfordringer34. Et oplagt

eksempel er under kommunikationsfaktoren, hvor noget så enkelt som sprog både kan give

kommunikationsmæssige og tekniske problemer eller udfordringer for de involverede parter. Rent

datamæssigt ligger der her også udfordringer i og med, at der f.eks. kan være så store sprogmæssige

problemer for medarbejdere i et land, at de skal have oversat systemet til deres lands sprog. Derfor

skal man i alle henseender i en global implementering have de forskellige kulturelle aspekter in

mente.

33 Single (f.eks. engelsk) og double (f.eks. kinesisk) bite sprog. 34 Se bl.a. business plan and vision og communication.

54

3.3.3 Opsummering på de kritiske succesfaktorer I det forrige afsnit 3.3.2 antog vi som udgangspunkt, at de kritiske succesfaktorer, der præsenteres i

Nah et al.’s (2001 og 2003) artikler, var universelt gældende for alle ERP implementeringer. Ved

gennemførelsen af teoristudiet af de globale artikler, blev denne antagelse bekræftet, da de 11

kritiske succesfaktorer alle blev underbygget heri, hvilket fremgår af tabel 2. Endvidere blev det

fremhævet, at der i flere af de kritiske succesfaktorer ligger ekstra udfordringer i den globale

kontekst.

Det er dog ikke alle subfaktorer fra Nah et al.’s (2003) studie, der bliver underbygget, hvilket tillige

fremgår af bilag 2. Faktor 7: Monitoring and evaluation of performance har den laveste

repræsentation med 1 ud af tre subfaktorer. Tendensen er den samme som i den empiriske

undersøgelse [Nah et al. 2003], hvor denne kritiske succesfaktor ikke havde så høj en prioritering

hos de medvirkende IT chefer. De to andre kritiske succesfaktorer, hvor ikke alle subfaktorer er

repræsenteret i den globale litteratur, er Communication og Software development, testing, and

troubleshooting. Her er der henholdsvis to ud af seks og to ud af fem subfaktorer, der ikke er

repræsenteret. At disse subfaktorer ikke er underbygget i de globale artikler, skal ikke ses som, at de

ikke har nogen relevans i den globale sammenhæng, men blot det faktum, at forfatterne ikke har

haft fokus på disse områder. Til gengæld er der skabt fokus på yderligere relevante aspekter i den

globale sammenhæng. Under business plan and vision tilføjes subfaktoren alignment of business

and ERP strategy. Communication har fået tilføjet communication among different cultures og

under project management er der tilføjet metanational advantages35.

3.3.4 Klassifikation af de kritiske succesfaktorer i den globale kontekst Klassifikationen af de globale kritiske succesfaktorer foretages på baggrund af Nah et al.’s rating,

antallet af referencer i litteraturen36 samt de nye globale udfordringer. Dette fremgår af tabel 3.

Klassificeringen skal ikke ses som et fravalg af nogen kritiske succesfaktorer, men ud fra en

vurdering af, at det kan være svært, hvis ikke umuligt, at holde lige meget fokus på alle 13 kritiske

succesfaktorer, vil den være en indikation af, hvilke kritiske succesfaktorer, der er vigtigst for

virksomhederne i forbindelse med deres globale ERP implementering.

35 Se bilag 2. 36 Med hovedvægt på de globale referencer.

55

Ud fra de tre vurderingskriterier vurderes det, at de kritiske succesfaktorer Appropriate business

and information technology legacy systems, Monitoring and evaluation of performance, Software

development, testing and troubleshooting, Communication samt Project champion er mindre

væsentlige i forbindelse med den globale ERP implementering.

Tabel 3 Sammenligning af referencer for Nah et al. og de globale artikler

ER

P te

amw

ork

and

com

posi

tion

Cha

nge

man

agem

ent c

ultu

re a

nd

prog

ram

Proj

ect m

anag

emen

t

Bus

ines

s pro

cess

ree

ngin

eeri

ng

Top

man

agem

ent s

uppo

rt

Bus

ines

s pla

n an

d vi

sion

Soft

war

e de

velo

pmen

t, te

stin

g an

d tr

oubl

esho

otin

g

Proj

ect c

ham

pion

Com

mun

icat

ion

Mon

itori

ng a

nd e

valu

atio

n of

pe

rfor

man

ce

App

ropr

iate

bus

ines

s and

info

r-m

atio

n te

chno

logy

lega

cy sy

stem

s

Cul

ture

Polit

ics

Gennemsnitlig rating 4.65 4.50 4.59 4.22 4.76 4.31 4.20 4.67 4.39 4.19 3.48 Antal referencer (af 12) 9 9 7 8 8 7 6 6 6 6 2 Antal referencer (af 9) 8 7 7 6 5 5 6 3 3 1 2 4 3 Antal referencer (af 21) 17 16 14 14 13 12 12 9 9 7 4 4 3 Global væsentlighed 1 1 1 1 1 1 2 2 2 2 2 1 1 Kilde: Egen tilvirkning

Anm.: Gennemsnitlig rating samt Antal referencer (af 12) er fra Nah et al.’s artikel fra 2003, hvor Antal referencer (af

9) henviser til de globale artikler. Global væsentlighed: 1 = væsentlig, 2 = mindre væsentlig.

De tre førstnævnte har en lav rangering i Nah et al.’s (2003) undersøgelse. Derudover ligger der

vurderingsmæssigt ikke markant større udfordringer i disse kritiske succesfaktorer set i den globale

kontekst. Dette kan skyldes, at de kritiske succesfaktorer har at gøre med de mere tekniske aspekter

af en ERP implementering, hvilket umiddelbart skaber færre udfordringer i forhold til det

organisatoriske i at integrere en verdensomspændende virksomhed i ét og samme system.

Derudover er de to førstnævnte kritiske succesfaktorer ringe repræsenteret i litteraturen, hvilket

også er med til at indikere, at disse kritiske succesfaktorer ikke har topprioritet. Communication har

ligeledes et lavt antal af referencer i litteraturen og har en middelmådig klassificering hos Nah et al.

(2003). Derudover er udfordringerne generelt af kulturel karakter.

Til trods for at Project champion har en god rating i Nah et al.’s undersøgelse, vurderes også denne

kritiske succesfaktor til at være mindre væsentlig i den samlede ERP implementering, om end

56

vigtigere end de tre førstnævnte. Af de globale artikler, er der kun 1/3 af dem, der beskæftiger sig

med den kritiske succesfaktor. Af disse forfattere, er det kun Madapusi et al. (2005), der eksplicit

definerer denne champion som værende fra topledelsen og bemyndiget til at tage store

projektmæssige beslutninger. Endvidere er der ikke konsensus omkring, hvorvidt project champion

nødvendigvis skal komme fra toplederniveau i Nah et al.’s (2003) undersøgelse. Hos Sarkis et al.

(2003) fremgår det heller ikke eksplicit, hvorvidt deres sponsor er fra topledelsen, om end

vedkommende har en lang karriere i virksomheden. Derudover kan det i nogle af artiklerne være

svært at se, hvorvidt der menes project champion eller top management support, da disse to kritiske

succesfaktorer på dette punkt har tendens til at ”smelte lidt sammen”.

De resterende kritiske succesfaktorer vurderes som værende væsentlige for den globale ERP

implementering. Culture og Politics er ikke antalsmæssigt stærkt repræsenteret i litteraturen, men

som de to nye aspekter og på grund af deres, specielt for kulturfaktorens vedkommende, markante

relevans i en global kontekst, vurderes disse til at være væsentlige. De andre seks kritiske

succesfaktorer er i litteraturen godt repræsenteret og har ydermere fået en høj prioritet i Nah et al.’s

(2003) undersøgelse, med undtagelse af Business process reengineering. Denne kritiske

succesfaktor anses dog netop som værende essentiel i en global ERP implementering, da der her er

tale om, at flere forskellige sites skal til at køre på en fælles platform og dermed have ens

forretnings- og IT- processer. Ud over det ovenstående ligger der som redegjort for i afsnit 3.3.2.3,

nye og større udfordringer indenfor de kritiske succesfaktorer i den globale kontekst, hvori

væsentligheden har sin berettigelse.

3.4 Delkonklusion I den første del af afhandlingen blev den historiske udvikling bag begrebet ERP gennemgået og

følgende definition blev fastsat: ”ERP systemer er informationssystemer, der understøtter online,

integreret, realtime transaktionsregistrering, databearbejdning og rapportering i forbindelse med

afvikling af virksomhedens forretningsprocesser ved hjælp af en central database, ofte i en

client/server IT-arkitektur.” Derudover blev det fastlagt, at en global ERP implementering

omhandler en virksomhed, der har afdelinger i to eller flere lande, hvori de implementerer et ERP

system. Jo flere lande, jo mere global en ERP implementering. Endvidere betragtes en

implementering som gående fra den første tanke omkring indførelsen af et (nyt) ERP system, til at

dette system afløses af et nyt.

57

Med udgangspunkt i Hirschheim et al.’s (1987) artikel Information systems failures – a survey and

classification of the empirical literature, præsenteredes efterfølgende fire syn på succes/fiasko for at

redegøre for begrebets relativitet. De fire syn er correspondence failure, der diskuterer

succes/fiasko ud fra kravspecifikationen, process failure, der typisk tager udgangspunkt i tid og

budget, interaction failure, hvor succes/failure måles ud fra brugernes interaktion med systemet

samt expectation failure, der har et multifaceteret syn på succes/failure og tager udgangspunkt i, at

der kan findes flere stakeholdergrupper i en virksomhed, der har forskellige syn på, hvornår de

opfatter en implementering som en succes eller en fiasko.

Desuden blev der i den første del af afhandlingen, på baggrund af to litteraturstudier foretaget af

henholdsvis Nah et al. (2003) samt opgaveskriverne, fundet 13 kritiske succesfaktorer, der har

betydning indenfor en global ERP implementering, hvor de globale udfordringer indenfor de

forskellige kritiske succesfaktorer blev fremhævet. Ud fra en vurdering af disse ekstra udfordringer

i den globale kontekst, de kritiske succesfaktorers rating i undersøgelsen af Nah et al. (2003), samt

antallet af referencer i litteraturen, blev disse kritiske succesfaktorer defineret som mere eller

mindre væsentlige. De kritiske succesfaktorer Appropriate business and information technology

legacy systems, Monitoring and evaluation of performance, Project champion samt Software

development, testing and troubleshooting blev identificerede som mindre væsentlige, hvor de

resterende kritiske succesfaktorer Business plan and vision, Business process reengineering,

Change management culture and program, Communication, ERP teamwork and composition,

Project management, Top management support, Politics samt Culture defineredes som væsentlige i

den globale kontekst.

58

4 Den empiriske del Nærværende afsnit repræsenterer afhandlingens empiriske del, hvor det undersøges, hvordan to

bestemte virksomheder håndterer deres globale ERP implementeringer og derved, hvad de har haft

fokus på. Dermed har afsnittet til formål at behandle problemformuleringens fjerde punkt. Det

første afsnit (afsnit 4.1) vil omhandle vores forventninger til den empiriske undersøgelse. De to

følgende afsnit (afsnit 4.2 og 4.3) præsenterer de to cases for henholdsvis LEGO og Grundfos,

hvorefter vi i afsnit 4.4 på baggrund af de to cases præsenterer hvilke kritiske succesfaktorer de i

LEGO og Grundfos har fokuseret på i deres globale ERP implementeringer.

Casene vil primært bygge på de foretagede interviews af Henrik Weis Aalbæk og John Bjørn

Nielsen37. I de tilfælde hvor der er anvendt sekundære kilder, i form af hjemmesider og udleveret

materiale fra virksomhederne, vil dette være angivet. LEGO og Grundfos’ udgangspunkt for at

indføre ERP systemer i deres koncerner har været meget forskellig. LEGO har været igennem et

forløb på over 10 år, hvor de har skiftede ERP system to gange, hvor Grundfos fra dag ét har kørt

med det samme system. Casenes opbygning tager udgangspunkt i virksomhedernes erfaring og har

derfor ikke den samme opbygning ud over den indledende præsentation. Det er bevidst valgt at

opbygge casene ud fra virksomhedernes historie, da det ønskes at være åben overfor feltet.

4.1 Forventninger til feltet I forbindelse med de kritiske succesfaktorer forventer vi at casevirksomhederne har fokus på de i alt

13 kritiske succesfaktorer, vi er kommet frem til i vores teoretiske del. Det formodes at de fem

kritiske succesfaktorer, vi har klassificeret som mindre væsentlige, ikke har så stor vigtighed for

virksomhederne i den globale kontekst, hvorved de ikke i samme omfang bliver omtalt af

informanterne som værende væsentlige. I lighed med denne betragtning forventes det, at de

væsentlige kritiske succesfaktorer har stor betydning for informanterne og casevirksomhedernes

succesfulde ERP implementeringer.

Derudover forventes det at virksomhederne har opstillet nogle mål for, hvornår de klassificerer

deres ERP implementering som succesfuld. Her formodes det, at de i større eller mindre grad har

opstillet specifikke kriterier, der skal påfyldes for at implementeringen har været en succes.

37 Transskribering af interviewene er vedlagt i bilag 6 og 10.

59

4.2 Case – LEGO LEGO ligger i Billund og blev grundlagt i 1932 af tømrermesteren Ole Kirk Kristiansen. På det

tidspunkt blev der produceret trælegetøj. I 1934 kom Ole Kirk Kristiansen på navnet LEGO ved at

sammensætte ”leg godt”, uvidende at dette på latin betyder jeg sammensætter. LEGO blev ved

årtusindeskiftet kåret til ”århundredets legetøj” af både Fortune Magazine og British association of

toy retailers [URL 7].

Ole Kirk Kristiansen producerer trælegetøj efter mottoet, ”Kun det bedste er godt nok”. I 1949

kommer de første LEGOklodser til verden. De bliver senere videreudviklet og i 1955 kommer de

LEGOklodser, som vi kender i dag. Samtidig lancerer LEGO deres første ”LEGO system i Leg”

koncept ”Leg og lær”, hvor budskabet er, at børn skal lære gennem leg [URL 7]. Siden har LEGO

udvidet produktsortimentet med produktlinjer som Technic38 til de teknologiintereserede og lidt

ældre børn, Duplo til de mindre børn – som er klodser, der er dobbelt så store som almindelige

LEGOklodser – og til de mindste lancerede LEGO i 1995 Primo [URL 7]. LEGO etablerede i 1968

den første Legopark og siden hen er yderligere 3 parker blevet etableret. LEGO har bestyret disse

parker ind til sidste år, hvor LEGO valgte at afhænde de 4 parker for at fokusere mere direkte på

LEGO’s kerneprodukter [URL 7].

Siden etableringen af LEGO er virksomheden gået i arv, først til sønnen Godtfred Kirk Kristiansen

senere til barnebarnet Kjeld Kirk Kristiansen, som er den nuværende ejer. LEGO er gået fra at være

en lille trælegetøjsproducent til at være verdens fjerdestørste legetøjsproducent med 7300 ansatte,

og i 2005 havde virksomheden en omsætning på 6.704 mio. dkr. [URL 7].

I de senere år har LEGO imidlertid været ude i en mindre storm som følge af svigtende salg og

dårlige regnskaber, hvilket har medført betydelige nedskæringer og omstruktureringer i LEGO

koncernen [Bilag 6]. LEGO havde i år 2004 deres hidtil dårligste for LEGO med et negativt resultat

på 1931 mio. dkr.. I år 2005 gik det atter frem ad og årets resultat endte på 505 mio. dkr. [URL 7]. I

år går det rigtig godt for LEGO, og de ligger i salg langt over det forventede, hvorfor årets resultat

forventes at give et overskud.

38 Som sidenhen er blevet erstattet af Mindstorm.

60

LEGO er i dag repræsenteret i mange lande verden over; de har salgskontorer i Asien, Afrika, Nord-

og Mellemamerika og ikke mindst i Europa. Produktionen af de ca. 15 mia. emner pr. år finder sted

i Danmark og Schweiz og færdigpakkes i disse to lande samt i USA og Tjekkiet.

4.2.1 Baggrund Baggrunden for LEGO’s seneste ERP implementeringsproces kan ses som en tiårig lang

evolutionsproces, hvor LEGO gennem tiden oparbejdede en masse erfaring indenfor ERP området.

Denne tiårige periode, der strækker sig fra 1994 til 2004, kan deles op i tre faser, hvor tredje fase

igen kan deles op i del et og to. Dette var ikke en bevidst rejse, men afspejler den viden, som LEGO

har opbygget omkring ERP systemer. Fase et begyndte med implementeringer af stand alone

systemer i salgsselskaberne i Schweiz og Danmark og siden hen resten af Europa. Filosofien var at

implementere SAP og tilpasse det til hvert enkelt selskab.

”Jeg glemmer aldrig forsiden på det, der hedder LEGO review, som var vores personaleblad

dengang der, midt i 90’erne - billedet af en stor pizza fyldt med glade italienere: Yes, vi fik alle

vores specialønsker opfyldt” Henrik Weis Aalbæk

Det var mantraet dengang, at LEGO var kompleks og hver enhed var speciel. Derfor fik hver enkelt

enhed lov til i høj grad at bestemme, hvordan opsætningen af SAP systemet skulle være. Dette

mantra blev der senere gjort op med [Bilag 7, slide 17]. I 1995 begyndte en langvarig krise for

LEGO. Med krisen kom et ønske om at integrere de forskellige salgselskaber, så lagrene rundt

omkring kunne ses alle steder fra. Grunden til dette ønske var, at nogle salgsselskaber godt kunne

ligge inde med varer, som manglede andetsteds. Dette var uhensigtsmæssigt for LEGO. Derfor

lancerede man i vinteren 95-96 fase to. Fase to gik derfor ud på at lave en såkaldt logistik backend,

hvor det var meningen at alt, hvad der hidrørte logistik og økonomi skulle samles på en server i

Billund, som de enkelte salgsselskaber så havde adgang til. Man valgte at samle alle de forskellige

SAP systemer, hvilket betød massive integrationsproblemer, da der var så mange forskellige

installationer. Dette medførte, at de, der stod for at lave dette backbone, fravalgte at integrere

økonomidelen. Det blev ikke den store succes, da der ikke var styr på masterdata og varenumre.

Konsekvensen af dette fravalg medførte, at det ikke var til at sige, hvor meget, der var solgt af en

bestemt vare i en bestemt region. Alt efter hvor man sad, havde man forskellige tal. Det betød, at de

61

tal, som lederne sad med på møder ikke var til at stole på, hvilket for dem naturligvis var meget

frustrerende. Derudover havde LEGO gennemført en regionalisering af deres forretningsenheder,

der medførte at 25 % af alle funktionærer blev fyret. Dette sammen med andre faktorer såsom

nødvendig opgradering af det daværende SAP system, logistiske problemer i form af manglende

eller for mange leverancer og Euroens indførelse, førte frem til fase tre, en implementering der blev

døbt LEGO Light. LEGO havde på dette tidspunkt opbygget så stor en viden omkring ERP

systemer, så de nu vidste, hvad det var, de ville have. LEGO Light startede primo december 1999.

Mantraen fra 1994 om at LEGO var kompleks og hver enhed var speciel, blev skudt ned. Det var

underdirektør med ansvar for corporate finance, Stig Toftgaard, som i slutningen af 1999 gik til

koncernledelsen med budskabet om, at LEGO var simpelt, og at LEGO skulle tænke globalt. Med

LEGO Light søgte ledelsen at skabe et globalt system med globale processer og global ledelse. I

første omgang, det der kan betegnes som del et, havde man fra LEGO’s topledelses side valgt at gå

over til Oracle for at ryste organisationen godt og grundigt.

Overgangen til Oracle var dog meget problematisk, og efter 8 måneder valgte LEGO at gå tilbage

til SAP, og dermed startede LEGO Light del to. Grunden til, at LEGO Light deles op i del et og del

to er, at LEGO, selv om de skiftede ERP system i forløbet, valgte at bibeholde den originale

tidsplan for dette. Dette betød, at SAP blev udrullet i 33 juridiske enheder over tre måneder i

sommeren 2001. LEGO har i dag implementeret SAP i alle koncernens selskaber med undtagelse af

fire. I tre af dem, fordi de er for små, og den fjerde fordi LEGO ikke ejer nok af selskabet. Systemet

er bygget sådant op, at der står en central server i Billund, som alle selskaber er koblet på. Dermed

har LEGO opnået det, de ville i forbindelse med deres seneste ERP implementering. De har fået et

globalt system, med globale processer og global ledelse, der kan levere hurtig, pålidelig, relevant og

konsistent information [Bilag 6].

4.2.2 LEGOs erfaringer LEGO er igennem deres 10 årige ”ERP rejse” blevet klogere på, hvad det vil sige at implementere

et globalt ERP system. De erfaringer, Henrik Weis Aalbæk og LEGO har samlet, fortæller om,

hvordan de er nået til, hvor de er i dag.

62

4.2.2.1 It’s a long Journey Ifølge Henrik Weis Aalbæk kan LEGO’s opnåede succes tilskrives fem elementer [Bilag 7, slide

21]: management commitment, organisation mature for change, masterdata and processes, regain

trust and credibility og protect and develop.

4.2.2.1.1 Management commitment Topledelsen engagement har hos LEGO været vigtigt for at kunne gennemføre ERP

implementeringen. Det er den i alle implementeringer jf. følgende udtalelse:

”Det gælder om, uanset hvor stor ERP implementeringen er, at ledelsen er med. Og er der nogen

der kan falde dig i ryggen, så er det din ledelse. Falder den dig i ryggen, så er du sådan set på

skideren. Den kan til gengæld hjælpe dig, hvis der er nogle andre, der falder dig i ryggen…”

Henrik Weis Aalbæk

At topledelsens engagement er vigtigt i en ERP implementering bakkes op fra LEGOs topledelse.

LEGO Light, den seneste ERP implementering, har været oppe at vende på alle direktions- og

bestyrelsesmøder i den tid, hvor SAP blev rullet ud globalt [URL 5]. Daværende direktionsmedlem

Poul Plougmann sad desuden med i alle ledelsesmøder i forbindelse med udrulningen af systemet.

Dermed fik teamet, der stod for implementeringen, hele ledelsens sendetid [Bilag 6]. Ledelsen

sørgede også for at allokere de ressourcer, der var behov for, hvad enten det var økonomisk eller

bemandingsmæssigt [URL 5].

LEGO har lært, at det at implementere et ERP system i større grad har med forretningen og

forretningsprocesser at gøre og i mindre grad IT. Det er derfor vigtigt at løfte en ERP

implementering ud af de traditionelle IT-mæssige rammer og ind i en forretningsmæssig kontekst

[URL 5].

4.2.2.1.2 Organization mature for change Poul Plougmann blev hentet til LEGO for at rette op på den skrantende økonomi. En af de første

ting, han gjorde, var at fyre 1200 medarbejdere globalt, hvilket skete under strømligningsprojekt der

blev kaldt LEGO Fitness, i februar 1999. Dette projekt medførte, at størstedelen af organisationen, i

forbindelse med projektfasen af implementeringen, var i gang med at komme sig over de mange

63

fyringer, hvorfor organisationen ikke nåede at etablere nogle faste arbejdsrutiner inden SAP

systemet blev implementeret. Det var derfor en organisation i opbrud, da systemet blev udrullet.

Dette var LEGO meget bevidste omkring, og ønskede at udnytte dette, da en organisation i opbrud

ikke har lige så mange kræfter til at kæmpe imod forandringer. Det var derfor et perfekt tidspunkt at

lave om på processerne i virksomheden, så de passede til SAP systemet.

Derudover skal en organisation, ifølge Henrik Weis Aalbæk, gerne være intellektuelt klar til at tage

imod det ERP system, som kommer ind i virksomheden. Medarbejdere skal trænes og uddannes i

systemet, så de ved, hvad det er, de sætter gang i. Der kan i et globalt ERP system opstå såkaldte

butterfly effekter, hvor en umiddelbart lille ændring kan have store konsekvenser.

4.2.2.1.3 Masterdata and processes LEGO havde ikke styr på deres masterdata, og dette var som ovenfor nævnt en af hovedgrundene

til, at de valgte at gå i gang med LEGO Light. Den manglende tillid til masterdata medførte en

generel mistillid til det forrige system, ikke bare hos topledelsen, men i virksomheden globalt set.

Masterdata er derfor en af Henrik Weis Aalbæks kæpheste. Det er her, de fleste ERP

implementeringer går galt ifølge ham.

”Mega kæphest, master data and processes. Få bygget strukturen. Jeg vil vove påstand,

hovedparten af de SAP implementeringer, der går galt, de går galt på noget af det her, det her er en

af dem; at de simpelthen ikke sætter sig ind i de strukturer, de vil lægge dem i, og det er sådant

noget banalt som, hvordan er den juridiske selskabsstruktur, hvad bruger vi companykoden til og

hvor mange salgsfunktioner har vi?” Henrik Weis Aalbæk

LEGO har gjort sig den erfaring, at det er vigtigt, at den globale forretningsstruktur, de har lagt sig

fast på, skal kunne understøttes af standardapplikationen af det ERP system, der ønskes

implementeret. Er dette ikke tilfældet, skal forretningsstrukturen laves om, eller der skal findes et

nyt ERP system.

Dernæst er det vigtigt at få styr på, hvad der menes med et varenummer og kundenummer. Hvad

ligger der i et begreb som omsætning; er det med eller uden moms, med eller uden rabat osv.!?

Dette havde LEGO meget spredte opfattelser af, afhængigt af, hvor i den globale organisation, man

64

sad. LEGO har derfor brugt meget tid og energi på at få lavet en ordbog, hvor der står en definition

til de forskellige begreber. Disse begreber skal gælde globalt i systemet, så det samme begreb ikke

har to forskellige fortolkninger. Gennemførelsen af ovenstående har medført, at LEGO i dag har

meget pålidelige masterdata.

4.2.2.1.4 Regain trust and credibility Før LEGO Light var der ikke mange, der havde tillid til det system, som kørte. Grunden til dette

var, som tidligere nævnt, at ledelsens tal ikke var konsistente. Alt efter hvilket land man sad i, fik

man forskellige tal. Men det var ikke kun ledelsen, der kunne mærke det. LEGO havde store

problemer med deres logistik. Nogle ting blev ikke sendt, hvor andre ting blev sendt to gange,

hvorfor tilliden til systemet verden over helt ned til manden på gulvet var minimal.

LEGOs nye system skulle derfor genoprette tilliden og troværdigheden hos medarbejderne. Dette

har man formået ved bl.a. at få styr på masterdata og processer.

”… hvis du vil bevare din troværdighed, så skal du også kunne håndtere din historik.”

Henrik Weis Aalbæk

LEGO vidste, da de startede med LEGO Light, at der ville komme en del omorganiseringer i

fremtiden. Derfor valgte de at lave SAP systemet meget fleksibelt. LEGO har siden starten af

implementeringen omorganiseret ca. en gang i kvartalet, og har som følge af det fleksible setup

været i stand til at håndtere deres historik i den forbindelse. De har i dag fået genskabt tilliden til

systemet og forretningen. Ledelsen finder de tal, der er i systemet, så troværdige, at der på LEGOs

intranet opgives henholdsvis det fakturerede salg og de igangværende ordrer, sat i forhold til det

budgetterede salg. Disse tal har alle medarbejdere adgang til.

4.2.2.1.5 Protect and develop LEGO valgte fra start af at der skulle laves så få ændringer til standardapplikationen som

overhovedet muligt. Dette har betydet, at de i stor grad har undgået at lave det, de kalder ”rød

kode”, hvor der direkte ændres i SAP kildekode. Dette betyder, at de samme processer kører ens,

65

uanset i hvilket LEGO selskab man befinder sig. LEGO har valgt at gøre dette, da der ikke er stor

forskel på produktet i hverken produktionsselskaberne eller salgsselskaberne.

LEGOs SAP system udvikles løbende, hvilket er nødvendigt for at få det optimale ud af ERP

systemet. Dette sker med den globale forretningsstruktur og de vedtagne principper in mente39. For

at sikre at der ikke bliver lavet ændringer med uforudsete konsekvenser, har LEGO en

ekspertgruppe, som skal tage sig af og vurdere de ændringer, der ønskes.

4.2.2.2 The path to victory is not the sexy route For LEGO har vejen til sejr været en 10årig lang rejse med flere stop og sporændringer undervejs.

Denne rejse har de kortlagt med fem punkter [Bilag 7, slide 22]: Overall structures and

requirements to flexibility, scenarios for overall structures and processes, finance, reporting,

master data, flow of good etc. models, dedicated team, big enough to solve the task, small enough to

be efficient, sustainable platform.

4.2.2.2.1 Overall structures and requirements to flexibility LEGO har brugt lang tid på at finde ud af, hvad de ønskede at opnå med det nye globale system. De

havde med de tidlige fejlslagne implementeringer fundet ud af, at det var vigtigt, at man gjorde sig

nogle grundige overvejelser omkring dette. LEGO ønskede et standardsystem, der kunne håndtere

den globale forretningsstruktur, de havde lagt sig fast på, uden at der skulle ændres ret meget i selve

koden. Derudover havde LEGO lavet nogle main principles. Et af disse var ”globality”, systemet

skulle være globalt, og da LEGO nu40 anså deres forretning som værende simpelt, ønskedes det, at

standardisere så mange forretningsprocesser globalt som muligt. Formålet med disse main

principles var at opstille nogle principper, som skulle gælde globalt i systemet. Dette var uanset om

systemet hed Oracle eller SAP. Disse main principles har præget og præger den måde, LEGO

tænker på i forbindelse med deres ERP system [Bilag 8].

39 Se afsnit 4.2.2.2.1. 40 Se afsnit 4.2.1.

66

”… men mange af de main principles, der var lavet; de holdt hele vejen igennem. Ja, for det er igen

til det, jeg startede med at sige med ledelsen - find ud af, hvad I vil opnå, og det, man vil opnå, skal

være uafhængigt af, hvilken ERP platform man vælger. Mål først og så middel, hele tiden.”

Henrik Weis Aalbæk

Et af LEGOs main principles er ”simplicity”. Det gælder om til enhver tid at holde det så simpelt

som muligt i systemet. Dette er endnu en af Henrik Weis Aalbæks kæpheste. Det gælder om at

fokusere på de ting, man skal bruge, og ikke blive fortryllet af alle de mange features, et ERP

system har.

LEGO har udover at tage stilling til den overordnede struktur også forholdt sig til fleksibiliteten af

systemet. De vidste, da de startede ud med LEGO Light, at der ville komme en del

omorganiseringer, hvorfor det var vigtigt at have et fleksibelt system, hvilket ville gøre det lettere

for dem at håndtere deres historik.

4.2.2.2.2 Scenarios for overall structures and processes Med kravene til den overordnede struktur på plads udarbejdede LEGO forskellige scenarier for,

hvordan den overordnede struktur og model kunne designes [Bilag 8]. Dermed designede de

forskellige overordnede modeller for finans, reportering, masterdata osv. Disse modeller skulle

illustrere, hvilke forskellige veje, de kunne vælge at gå. Der skal, ifølge Henrik Weis Aalbæk, under

alle de forskellige scenarier tages hensyn til de ovenstående besluttede principper og den

fleksibilitet, der ønskes.

4.2.2.2.3 Finance, reporting, master data, flow of good etc. models Dernæst valgte LEGO blandt scenarierne de modeller, som de mente, passede bedst til det, de

ønskede af deres system. Det handler om, ud fra de udvalgte modeller at skabe en overordnet

sammenhængende model, samt at detaljere disse udvalgte modeller yderligere.

”Dette handler om at udarbejde en overordnet sammenhængende model for virksomheden, hvor

masterdata, logistik, finans, performance rapportering, planlægning versus aktuel m.m. integreres”

Henrik Weis Aalbæk [Bilag 8]

67

LEGO ønskede at få deres værdikæde i til at hænge sammen gennem ERP systemet. Simplicity var

et af nøgleordene i denne proces. LEGO havde med deres tidligere systemer oplevet, hvor

komplekst et ERP system er, og ikke mindst hvor komplekst det bliver, når selskaberne globalt

kører med forskellige standarder. Derfor gik LEGO meget op i at gøre det så enkelt som muligt.

”Simplicity handler i det forretningsmæssige om at reducere udfaldsrum. F.eks.

betalingsbetingelser, rabatter, leveringsbetingelser, det vi kalder value added services.” Henrik

Weis Aalbæk

Det betød, at LEGO tog nogle svære beslutninger om at skære ned på value added services. LEGO

havde før 140 forskellige måder at udregne rabatter på og flere hundrede betalingsbetingelser i dag

er de ned på henholdsvis to og et par håndfulde. Dermed skulle LEGOs kunder acceptere nye

betingelser, hvilket medførte at LEGO tabte nogle af disse kunder. De vigtigste af disse er siden

kommet tilbage i folden.

4.2.2.2.4 Dedicated team, big enough to solve the task, small enough to be efficient LEGO Light var et projekt, der i høj grad var besat af de ”gamle” drenge. Projektlederne var folk,

der før havde vist, at de kunne håndtere projekter og kunne arbejde sammen. De enkelte

projektledere fik frie hænder til at finde folk i hele LEGO koncernen. LEGO Light handlede som

før antydet meget om at skære ind til benet, hvorfor LEGO også valgte at have et forholdsvist lille

team til at løfte opgaven, for at folk ikke ville gå i vejen for hinanden. Det handlede ifølge Henrik

Weis Aalbæk meget om effektivitet. Det betød, at de, der deltog i LEGO Light i projektfasen,

arbejdede omkring 100 timer om ugen i omkring et halvt års tid. Henrik Weis Aalbæk konstaterer,

at folk, der arbejder med i et sådant projekt skal være hårdhudede. Motivationen for at deltage i

LEGO Light skal måske ikke så meget findes i bonusen på 15 % af årsgagen, men mere i at

projektet fik al topledelsens sendetid.

Udover de interne medarbejdere hyrede LEGO også eksterne konsulenter. Disse blev kigget

grundigt i kortene, før det blev besluttet, om den enkelte konsulents kompetence kunne bruges

[URL 5]. Derudover blev SAP Danmark brugt som en værdifuld sparringspartner.

68

I forbindelse med udrulningen havde LEGO et team, der rejste rundt og implementerede SAP. Først

i Europa, siden i USA og Asien. Under implementeringen i Asien løb LEGO ind i nogle kulturelle

problemer. Medarbejderne i Asien er meget høflige og ønsker ikke at være til besvær; dette selv om

de ikke forstår, hvad der bliver sagt. LEGO har derfor løbende med udrulningen placeret danskere

derude.

4.2.2.2.5 Sustainable platform LEGO ønskede en platform, der kunne udvikles løbende, da de, som tidligere nævnt, vidste, der

ville komme en del organisationsforandringer som følge af den globale forretningsstruktur, de

havde valgt. Samtidigt ønskede de, at platformen skulle kunne holde i mange år. Hos LEGO har

fleksibiliteten som tidligere nævnt været vigtig, da de har foretaget mange

organisationsforandringer.

”Omkring sustainable er der også change processen - d.v.s. hvordan ændres strukturer, processer

og systemer - verden står jo ikke stille, så en change process er vigtigt for ikke langsomt men sikkert

at ende i kaos igen.” Henrik Weis Aalbæk [Bilag 8]

Men det har desuden været vigtigt for LEGO at have styr på deres masterdata, hvorfor der i

forbindelse med f.eks. varenummerstrukturen ikke er nogen fleksibilitet. Her mener Henrik Weis

Aalbæk, at det kan betale sig at være ”religiøs” [Bilag 8]. Derudover pointerer han, at dette punkt

hænger tæt sammen med Overall structures and requirements to flexibility.

”… den der, korrelerer meget med den her (slide 22 – rød og orange klods, red.). Hvis du laver

noget, der er meget rigidt, så er det meget svært at ændre…” Henrik Weis Aalbæk

4.2.2.3 Project management I forbindelse med projektledelse har LEGO erfaret, at det er vigtigt ikke at se en global ERP

implementering som et IT projekt, men at det bør ses som et stort globalt forretningsmæssigt

projekt, der influerer hele virksomheden [URL 5].

69

”Vi har klart lært, at det at implementere SAP har meget lidt med IT at gøre, men utroligt meget

med forretning og forretningsprocesser at gøre” [URL 5]

LEGO valgte at køre en muteret form for ASAP41 implementeringsmetode. At det gik hurtigt kan

ses på implementeringstempoet henover sommeren 2001, hvor 33 juridiske enheder i Europa blev

koblet på.

I forbindelse med LEGO Light har topledelsen valgt at bakke stærkt op omkring projektledelsen.

Poul Plougmann, daværende medlem af direktionen, gik ud og sagde: ”Hvis I er uenige med

projektledelsen, er I uenige med mig” [Bilag 6]. At topledelsens mandat til projektledelsen har

været vigtigt kan ses i citatet af Henrik Weis Aalbæk under Management commitment.

LEGO ønskede at stå fast på deres main principles [URL 5]. Topledelsens engagement og mandat

til projektledelsen har betydet at dette har været muligt.

LEGO føler, at de har haft en god historie i forbindelse med økonomien i projektet. Deres erfaring

er, at der skal ses kritisk på, hvordan økonomien er skruet sammen, samt hvordan den optimeres

bedst muligt. Der skal dog være vilje til at frigøre de ressourcer, både økonomisk og

mandskabsmæssigt, som projektet kræver [URL 5]. Det har gennem hele forløbet været vigtigt at

holde budget og tidsramme uden at gå på kompromis med kvaliteten, hvilket er lykkedes [URL 5].

4.2.2.4 Efterrationaliseringer Gennemførelsen af LEGO Light er generelt betragtet som en succes. Henrik Weis Aalbæk gør dog

opmærksom på, at der er visse ting, som LEGO ikke har været så gode til i projektfasen af

implementeringen. Disse er dokumentation, uddannelse og kommunikation.

4.2.2.4.1 Dokumentation En af de ting, som LEGO gjorde mindre godt i forbindelse med deres ERP udrulning, var som

nævnt at få dokumenteret. Derfor skal LEGO i gang med et større dokumentationsprojekt. De er i

dag meget afhængige af 5-7 håndfulde medarbejdere, da disse ligger inde med en meget stor viden

41 Accelerated SAP

70

omkring deres SAP system. Dokumentationsprojektet skulle gerne gøre LEGO mere uafhængig, da

det i dag ikke ville være rart, hvis ti af disse medarbejdere skulle vælge at forlade virksomheden.

4.2.2.4.2 Uddannelse Set i bakspejlet har uddannelsen af medarbejderne i SAP systemet haltet hos LEGO. Uddannelse og

efteruddannelse er to punkter, som LEGO har fået slag for i en intern medarbejderundersøgelse og

Henrik Weis Aalbæk erkender gerne, at det ikke er LEGOs stærke side.

”Vi er gode til at uddanne lige når vi går live, men så sker der ikke mere” Henrik Weis Aalbæk

Grunden til, at der ikke finder mere efterfølgende træning sted, er, at de medarbejdere, som ville

være i stand til at stå for dette, hurtigt bliver ført med over i den næste udrulning. Den manglende

uddannelse medfører at nogle medarbejdere "by passer" systemet, dog typisk ikke af ond vilje.

Dette er ikke hensigtsmæssigt, og derfor bør medarbejderne undervises i deres del af systemet, både

så de lærer at bruge systemet, men også så de ved, hvad de sætter i gang af processer i

virksomheden, mener Henrik Weis Aalbæk.

4.2.2.4.3 Kommunikation Kommunikation er også noget, som LEGO har fået slag for i deres medarbejderundersøgelse.

Henrik Weis Aalbæk mener, at der har været en del kommunikation omkring implementeringen,

men at det sikkert ikke har været nok. For at gøre kommunikationen så god som muligt, mener han,

at det er nødvendigt at fortælle noget konkret til medarbejderne; fortælle dem, hvad dette kommer

til at betyde for dem og ikke alt muligt andet, da det dybest set ikke interesserer dem.

”Vær ærlig og fortæl noget konkret. Vi kan slamdunke folk med præsentationer og – lige som jeg

gjorde lidt ved Jer her – 400 power point, og folk de sidder og kigger; betyder det noget for mig?

Hvis det ikke gør det, så hører jeg jo sådan set ikke efter. Så kommer der lige pludselig noget, der

betyder noget for mig, det hører jeg ikke, fordi det gjorde de første 17 slides ikke. Hvor skulle jeg

vide fra, at det var slide 18, der gjorde det?” Henrik Weis Aalbæk

71

At kommunikation er vigtigt oplevede LEGO, da de skulle rulle ud i USA. De havde bedt chefen

om at være til rådighed for implementeringsteamet en uge op til selve installationen, så de kunne

forventningsstyre ham. Det havde han opfattet som at hele fabrikken skulle lukkes i den uge. Da

LEGO har en omsætning i USA på 5 millioner US$ om dagen, ville det betyde et tab på US$ 25

millioner. Det blev hurtigt gjort klart for chefen, at dette ikke var meningen, og arbejdet blev hurtigt

genoptaget.

4.2.3 Succes Henrik Weis Aalbæk karakteriserer i dag deres implementering som succesfuld, selv om der har

været ting, der kunne have været gjort bedre jf. ovenstående. Der findes i organisationen flere

forskellige holdninger til, om implementeringen har været succesfuld eller ej.

”Succes dømmer jeg på, at vi er kommet fuldstændig i kontrol af værdikæden. Alle de

masterproblemer vi havde, de er væk, vores fragtsystem, det virker, vore data er troværdige…”

Henrik Weis Aalbæk

Før LEGO gik i gang med at implementere, var der opstillet nogle succeskriterier. Disse handlede

om at være indenfor budget og tidsramme uden at gå på kompromis med kvaliteten [URL 5; Bilag

6]. Derudover havde LEGO kriterier om at få det til at virke, minimal downtime og at de ikke skulle

tabe omsætning som følge af implementeringen. Disse mål nåede LEGO stort set til fulde. Det

eneste, der kan sættes en finger på, er, at det nogle steder trak ud med at få systemet op og køre, så

det først kørte tirsdagen efter den weekend, hvor selve installationen fandt sted.

4.3 Case – Grundfos Grundfos blev grundlagt i Bjerringbro i 1945 af Poul Due Jensen, der i starten kaldte sin

pumpevirksomhed Bjerringbro Pressestøberi og Maskinfabrik. Først i 1967 efter flere navneskift,

fik virksomheden sit nuværende navn, Grundfos [URL 8]. Grundfos, der i dag er en af verdens

førende pumpeproducenter med en produktion på over 10 millioner pumpeenheder om året,

producerer og sælger pumper, elektromotorer og avanceret elektronik til styring af pumper og

pumpeanlæg over hele verden gennem deres salgs- produktionsselskaber.42 Hovedprodukterne

42 Se bilag 11.

72

udgør cirkulationspumper, dykpumper og centrifugalpumper, hvor Grundfos i dag er verdens største

producent af cirkulationspumper. De dækker ca. 50 % af verdensmarkedet for denne pumpetype

[URL 8].

Cirkulationspumpen blev introduceret i 1959. Året efter åbnede Grundfos for første gang et selskab

uden for Danmark med etableringen af en pumpefabrik i Tyskland. I 1975 blev Poul Due Jensen’s

Fond oprettet og Poul Due Jensen overdragede sit ejerskab af Grundfos Koncernen til fonden.

Fonden ejer i dag ca. 85 % af aktiekapitalen i Grundfos Holding AG, hvor den stiftende familie ejer

ca. 12 % og de resterende ca. 3 % ejes af virksomhedens medarbejdere. I 1977 dør Poul Due Jensen

og hans søn Niels Due Jensen overtog bestyrelsesformandsposten i fonden. Tre år efter oprettedes

den første koncerndirektion med Niels Due Jensen som koncernchef; en post han i 2003

overdragede til Jens Jørgen Madsen [URL 9]. I dag sidder Niels Due Jensen som næstformand for

bestyrelsen for Poul Due Jensen’s Fond, samt som formand for koncernbestyrelsen i Grundfos

Management A/S.43

Som en del af Grundfos’ bestræbelse på at opretholde en førende position på markedet for pumper,

indviede de i årene fra 1990 til 2001 et teknologicenter, et udviklingscenter samt Poul Due Jensen

Academy. Derved står Grundfos i dag selv for forskning og fremstilling af nye materialer, maskiner

og værktøjer til produktionen samt udvikling af nye og forbedringer af eksisterende produkter.

Derudover står Grundfos også selv for størstedelen af uddannelsen af deres medarbejdere i

akademiet [URL 9].

Rent virksomhedsmæssigt er Grundfos i dag organiseret omkring Poul Due Jensen’s Fond og

handler i overensstemmelse med dennes formål:

” Fondens formål er at sikre og udbygge det økonomiske grundlag for Grundfos-koncernens

fortsatte vækst. Fondens formue eller udbytte må udelukkende anvendes til fondens formål, det vil

sige udbyttet skal geninvesteres i Grundfos-selskaberne.” [URL 8]

Fonden har aktiemajoritet i Grundfos Holding AG og dermed også i det danske hovedkvarter,

Grundfos Management A/S i Bjerringbro, hvor koncernen styrer de forskellige

43 Grundfos Management A/S er navnet på det danske hovedkvarter i Bjerringbro. Se bilag 12.

73

forretningsudviklingscentre samt salgs og produktionsselskaberne rundt om i verden44. Det er også

herfra, virksomheden styrer deres ERP system, hvor de i 2001 oprettede SAP Competence Center

(SAP CC), hvorfra al styring og tilpasning af deres SAP ERP system foregår [Bilag 10].

I Grundfos føres forretningen efter værdisættet BE>THINK>INNOVATE, hvor der er fokus på

ansvar overfor medarbejdere, virksomheden og verden. Derudover mener de, at fremsynethed er

grundlaget for fornyelse, ved engagement og ved selvstændigt tænkende medarbejdere. ”Vi tænker

– og så handler vi.” [URL 10]. Dette skal være med til at skabe den innovative sjæl i Grundfos.

I 2005 havde Grundfos koncernen deres hidtil bedste år med et nominelt overskud før skat på 1.254

millioner kr. ved en omsætning på 13,42 milliarder kr. Ultimo 2005 beskæftigede Grundfos 13.369

medarbejdere over hele verden [URL 8].

4.3.1 År 2000 problemer Grundfos påbegyndte deres globale ERP implementering i slutningen af 90’erne. Baggrunden for

denne beslutning bunder primært i, at flere af deres vesteuropæiske salgsselskaber stod overfor år

2000 problemer. Dette skulle der findes en løsning på. Grundfos valgte derfor efter flere

overvejelser og diskussioner om, hvorvidt de skulle køre i ét eller flere systemer, at implementere ét

centralt SAP R/3 system i koncernen. At valget faldt på SAP R/3 begrunder John B. Nielsen

således:

”… det var ikke en tilfældig beslutning, at det lige blev SAP, kan man sige. Vi havde så her i

Grundfos i Bjerringbro kørt SAP R/2 i mange år, helt tilbage fra slutningen af 80’erne, så det, så

produktet fra SAP, det var sådan set velkendt. R/3 var så ikke, men det var R/2. Så det var jo, efter

nøje overvejelse kan man sige, at det blev besluttet, at det var SAP R/3, vi skulle bruge til at løse de

år 2000 problemer, der var i salgsselskaberne.” John B. Nielsen

Beslutningen om et samlet system viste sig at være det rigtige for Grundfos. Gennem perioden op til

de første implementeringer i 1998/199945, blev det mere og mere tydeligt for forretningen, hvilke

fordele, der var forbundet med at køre i ét system. Her nævner John B. Nielsen forhold som

44 Se bilag 11 og 12. 45 Se Roll out plan i bilag 13, slide 9.

74

transparens i forretningen, nemheden hvormed de kunne køre tværgående processer mellem

selskaberne, samt den sammenhængende integration, der kunne opnås selskaberne imellem, som de

største fordele. Derudover pointerer han også, at hvis man vil opnå harmonisering og

standardisering, så er det langt lettere, når man kører under ét system. Her er det også lettere, når

der skal opdateres. Derudover er der økonomiske fordele ved at drive ét samlet system fra centralt

hold.

Disse forhold blev løbende bekræftet i takt med, at flere og flere selskaber blev koblet på SAP

systemet. Her begyndte de at savne den transparens, de havde opnået med implementeringen, i de

selskaber, der endnu ikke var koblet på systemet [Bilag 10]. Også på det IT-mæssige område

oplevede de en effektivitet, hvormed de kunne indføre SAP i de forskellige selskaber.

John B. Nielsen nævner endvidere den løbende globalisering og snakken om indre markeder og

supply chain processer på tværs af landegrænser og kontinenter som et incitament til at køre i ét

stort system. Til forskel fra i dag, hvor alt der vedrører SAP er samlet i én organisation, var

Grundfos tidligere mere decentralt styret, og der var dermed en noget større autonomi i koncernens

selskaber rundt om i verden. Hvis selskaberne overholdt deres budgetter og leverancer til kunderne,

blandede man sig fra centralt hold ikke så meget i, hvordan de kørte deres forretning.

4.3.2 Implementeringsstrategien Med beslutningen om at samle hen ved alle46 koncernens selskaber i det samme SAP R/3 system,

gik startskuddet til en lang række af succesfulde SAP implementeringer verden over. En vigtig

grund til, at det i starten gik så godt med at implementere SAP, skyldes, at ledelsens besluttede og

meldte ud, at de skulle have SAP i selskaberne på forskellige gældende betingelser. Dermed var der

et mandat fra øverste sted. Havde der ikke været det, havde det ikke kunnet lade sig gøre, vurderer

John B. Nielsen.

De første implementeringer i Sydeuropa i slutningen af 90’erne blev foretaget i løbet af ca. fem

måneder af et fast team af SAP konsulenter, der dermed kunne udnytte deres erfaringer fra

implementering til implementering. I 2001 samlede Grundfos alle deres erfaringer og viden om

SAP i én SAP organisation med base i Bjerringbro – SAP Competence Center (SAP CC). SAP CC 46 Produktionsselskabet i Sydkorea er det eneste selskab, hvor der pt. ikke er planer om at indføre SAP. Se bilag 10.

75

består i dag af 83 medarbejdere, hvor godt 20 ikke er fysisk placeret i Bjerringbro. Samlingen af

SAP medarbejdere i organisationen SAP CC betyder, at de forskellige selskaber i dag ikke har deres

egen IT afdeling med SAP medarbejdere; og alle justeringer i SAP systemet foretages dermed også

kun af medarbejdere fra SAP CC. Dermed er der hele tiden fra centralt hold styr på, hvilke

ændringer, der foretages og konsekvenserne af disse ændringer [Bilag 10].

Efter kompetencecenterets oprettelse blev de efterfølgende implementeringer foretaget af et til

lejligheden sammensat ERP team bestående af medarbejdere fra SAP CC og medarbejdere fra

forretningen i det pågældende land. I denne sammenhæng pointerer John B. Nielsen vigtigheden af

at have en lokal forretningsejer for projektet, der har indgående kendskab til processerne i det

pågældende selskab:

”Man skal ha’ nogle fra forretningen, fra supply chain, fra produktionen, som tager ejerskab for,

hvordan skal en proces afvikles i SAP. Det må ikke være noget, som nogle SAP konsulenter sidder

og finder ud af med yngste fejedreng eller brugerne, hver enkelt bruger hver for sig. Der skal være

nogen, der har et procesejerskab i forretningen for, hvordan det bliver sat op.” John B. Nielsen

Denne sponsor skal således også være bemyndiget og i stand til at specificere, hvordan processerne

skal se ud i SAP, og skal kunne sige god for, hvordan SAP konsulenterne skal sætte SAP op til at

håndtere disse processer. Grundfos har her konstateret få tilfælde47, hvor overgangen til SAP har

været besværliggjort af manglende ejerskab af projektet fra den lokale ledelse. De har dog ifølge

John B. Nielsen været forskånet for diverse ”horror stories” om, at en virksomhed ikke har kunnet

levere varer i 14 dage.

Ud over det manglende ejerskab i et selskab har kulturelle forskelle også spillet ind på ERP teamet

og implementeringerne. Her har de i Grundfos konstateret, at der er forskel på, hvorledes et ERP

team skal arbejde. I Vesteuropa og i Nordamerika er medarbejderne selvstændigt tænkende, og

forventes at være det. Derimod har de i andre dele af verden været ude for, at flere ting skal op og

vende på direktørniveau, da medarbejderne ikke tør at påtage sig ansvar og tage beslutninger i

projektet. Derudover betragtes det som et nederlag at sige, at man ikke har forstået, hvad

47 Tilfælde, der ifølge John B. Nielsen ligger seks til syv år tilbage.

76

implementeringen indebærer, og dermed siger medarbejderne ”ja” og ”amen” til alt, selvom de ikke

har forstået konsekvenserne af implementeringen [Bilag 10].

4.3.2.1 Forretningsmodellen Grundfos har fra dag ét haft som agendapunkt at genbruge så meget som muligt fra implementering

til implementering. Ved alle deres implementeringer opererer de ud fra en forretningsmodel for at

sikre harmonisering og standardisering af SAP implementeringerne selskaberne imellem. Denne

standardisering uddyber John B. Nielsen med følgende:

”… ikke at hyre en hel hær af programmører til at udvikle SAP på en måde, det aldrig var tiltænkt

at blive brugt på.”

Forretningsmodellen indeholder nogle helt specifikke krav til, hvad et selskab skal gennemgå i

deres implementering, og har været en kritisk succesfaktor for at kunne nå ud til over 40 lande siden

starten i 1998. Første skridt er at få forretningsrepræsentanten til at kortlægge alle selskabets

processer i et proceskort, hvor de ”mapper” op imod det, der kan understøttes af SAP systemet.

Dernæst udføres en fit-gab analyse og efterfølgende rapport. Af denne analyse fremgår det, hvilke

processer SAP kan understøtte. De processer, der ikke umiddelbart kan understøttes, gennemgås, og

det besluttes, om der skal laves om i standard SAP, eller om selskabet skal tilpasse forretningen til

systemet. Jo mere specifikt et marked selskabet opererer i, og jo tættere de er på slutkunden, jo

større er tendensen til at foretage tilpasninger af SAP og udvikle egne programmer.

De har i Grundfos foretaget en del tilpasninger i SAP, men har tilstræbt at lave så få forskelligartede

tilpasninger som muligt i de forskellige selskaber. Derudover har de også mange egenudviklede

programmer, der kører ved siden af og i samspil med SAP. Udgangspunktet er, at er der tale om

standard forretningsprocesser, så tilpasses forretningen SAP. Her pointerer John B. Nielsen, at der

er forskel på at producere 30.000 cirkulationspumper eller fem trykforøgningsanlæg om dagen. Når

det er blevet besluttet, hvilke tilpasninger og procesændringer, der skal foretages, konfigureres SAP,

og de nødvendige programmer udvikles. Efterfølgende udføres tests af dataload samt integrations-

og brugertilfredshedstests. Sidste skridt inden go live er uddannelse af brugere og superbrugere.

77

Disse ovenstående faser gennemgås i alle SAP implementeringer, men der foreligger ikke templates

over, hvorledes en fit-gab rapport skal udformes, og hvordan en brugertilfredshedstest skal udføres.

Det er op til de enkelte selskaber at udforme disse.

Ud over denne forretningsmodel har de i Grundfos oparbejdet en projektorganisationsstruktur, hvor

”SAP og forretning møder hinanden”. John B. Nielsen pointerer i deres implementeringer

vigtigheden i dette sammenspil imellem de to parter, så SAP ender ud med at understøtte

forretningen, og de derfor ikke kommer ud for, at de i forretningen efter go live står og mangler en

funktionalitet, der ikke er taget højde for i konfigurationen af SAP. Denne integration af IT og

forretning sikrer de i Grundfos gennem den rigtige sammensætning af ERP teamet med folk fra

både SAP CC og fra den lokale forretning.

4.3.3 Den succesfulde udrulning Siden de første implementeringer i maj ’9848 har Grundfos implementeret SAP R/3 i over 40 af

deres selskaber, og der er i dag lidt under 6000 brugere tilknyttet systemet verden over. John B.

Nielsen betegner Grundfos’ mange implementeringer som værende en overordnet succes, da

koncernen som nævnt har været forskånet for diverse ”horror stories” om, at et selskab har været

ude af stand til at servicere deres kunder. De eneste krav, der ifølge John B. Nielsen blev stillet fra

ledelsens side, var, at de skulle kunne servicere kunderne og levere til tiden, så de dermed ikke led

under, at Grundfos skiftede system. Derudover fandt de i Grundfos, ifølge John B. Nielsen,

succeskriterierne meget åbenlyse. Han nævner drift, stabilitet og tilgængelighed til systemet som

succeskriterier. Dette kræver som udgangspunkt, at der er styr på infrastrukturen og performance af

systemet, hvilket Grundfos glemte i starten:

”Vi havde nogle performanceproblemer i systemet tilbage i, ja det er snart mange år siden ik’, men

man er så fokuseret på applikationen, man er så fokuseret på at få beskrevet, hvad er det for nogle

processer, finde løsninger i MG’en, få skrevet nogle programmer, der kan lukke de sidste huller i

funktionaliteten, som man synes mangler ik’ og den dag man så hælder 600 brugere på, så sidder

de og triller tommelfingre, fordi det tager 10 sekunder at komme tilbage for hvert museklik…”,

John B. Nielsen

48 Se bilag 13, slide 9 for diagram over udrulningsplan op til år 2000.

78

Den manglende fokus på dette område begrunder han med, at det ikke er noget ledelsen eller andre

medarbejdere finder spændende at arbejde med. Det er dog noget, der er nødvendigt, ellers kan

resten være ligegyldigt [Bilag 10].

Selvom der fra centralt hold ikke har været dikteret nogen succeskriterier, er det John B. Nielsens

indtryk, at de forskellige selskaber har haft deres egne kriterier. Her nævner han bl.a.

produktionsselskaberne i Bjerringbro, der havde som succeskriterium, at alle fabrikkerne skulle

afvikle deres processer på noget nært præcis samme måde.

4.3.3.1 De store udfordringer Set tilbage på de over 40 implementeringer, Grundfos indtil videre har foretaget i deres selskaber

rundt om i verden, ligger en af de største udfordringer ifølge John B. Nielsen i, at finde balancen

mellem at fastholde standardiseringen og harmoniseringen i systemet, kontra det at lave de

tilpasninger og udviklinger på systemet, som er nødvendige for, at man kan drive pumpeforretning i

det pågældende land. Grundfos har opnået denne balancegang ved hjælp af en central governance

struktur som overdommer i de diskussioner, der løbende opstår i implementeringsprocessen.

Derudover pointerer John B. Nielsen også, at man må gøre sig klart, at ikke alle selskaber og

medarbejdere kan få deres specifikke krav opfyldt. Dette har givet lidt modstand i de forskellige

selskaber; en modstand, han mener, altid vil være der. Modstanden fra lederne i selskaberne har

ikke ligget i, at der skulle implementeres SAP, men at de ikke har fået deres egen SAP organisation,

hvor de selv kan designe og styre systemet. Netop viljen fra koncernens side til at centralisere SAP

organisationen er ifølge John B. Nielsen nødvendig for at det skal lykkes at køre i ét stort system. Er

den ikke til stede, tror han ikke på at det kan lykkes.

4.3.4 Fremtiden Siden midten af 90’erne, hvor de første overvejelser om implementering af et centralt SAP system i

Grundfos så dagens lys, er Grundfos kommet langt i forløbet med at udrulle SAP i alle deres

selskaber verden over49; en udrulning der til stadighed er i gang. Den overordnede succes fra starten

af i implementeringerne og de tydelige fordele, de første selskaber på system oplevede, har ført til,

49 Se bilag 13, slide 15-17.

79

at det i dag ikke er et spørgsmål om at overbevise selskaberne om, at de skal på. Til dette forklarer

John B. Nielsen:

”… nu står de nærmest i kø for at kunne komme på, kan man sige. Så nu er det et spørgsmål om at

prioritere, hvem skal på før andre…” John B. Nielsen

Ud over de sidste planlagte implementeringer, er der også planlagt opdateringer af SAP systemet.

Seneste opgradering af deres SAP platform foretog Grundfos i 2002, så de i dag kører R/3 version

4.6c. Næste mål er mySAP ERP 2004, som pt. er skemalagt til ultimo 2006 eller primo 2007 [Bilag

13, slide 5]. Dermed befinder Grundfos koncernen sig, set ud fra en implementeringslivscyklus,

både i en projektfase i de selskaber, der endnu ikke har implementeret SAP, samt i en driftsfase i de

selskaber, hvor en udrulning har fundet sted.

4.4 Sammenfatning af cases Sammenfatningen af casene har til formål at præsentere de kritiske succesfaktorer, vi i den

empiriske del er kommet frem til. Præsentationen deles op i to kategorier værende kritiske

succesfaktorer, der har været mere (afsnit 4.4.1) eller mindre (afsnit 4.4.2) væsentlige i de globale

ERP implementeringer. I de tilfælde hvor en kritisk succesfaktor kan underbygges af begge cases,

ved at virksomhederne direkte eller indirekte har haft fokus på en bestemt kritisk succesfaktor, vil

denne blive kategoriseret som væsentlig. Hvis en kritisk succesfaktor kun er understøttet af den ene

case, vil den blive kategoriseret som mindre væsentlig. Derudover sammenfattes succeskriterierne

for de to virksomheder.

4.4.1 De væsentlige kritiske succesfaktorer De væsentligste kritiske succesfaktorer i den empiriske undersøgelse er central ERP organisation,

ERP teamwork and composition, minimum customization, alignment of business and ERP strategy,

topledelsens support og project management. Rækkefølgen indikerer ikke en

prioriteringsrækkefølge eller rangordning.

4.4.1.1 Alignment of business and ERP strategy Casene fra begge virksomheder understreger vigtigheden af at have overensstemmelse mellem ERP

og forretningsstrategien. LEGO erfarede dette qua deres forrige systemer. LEGO sørger i dag for, at

80

der er overensstemmelse mellem disse strategier. Dette gøres ved først og fremmest at sige, at den

overordnede forretningsmodel skal være indeholdt i standardapplikationen af det valgte ERP

system. Derudover er der nedskrevet nogle main principles, der gælder i systemet for at sikre en

yderligere overensstemmelse mellem de to strategier.

Grundfos genbruger fra starten af, qua deres forretningsmodel, så meget som muligt fra gang til

gang. Derudover vælger de bevidst at koble alle virksomheder på det samme SAP system. Dette

betyder, at Grundfos i dag har et globalt SAP system, der understøtter virksomhedens

forretningsprocesser. I forbindelse med udrulning af deres ERP implementering bliver der for hvert

nyt selskab udført en fit-gap analyse. Dette skal sikre, at systemet understøtter virksomhedens

forretningsprocesser.

4.4.1.2 Central ERP organization LEGO og Grundfos har i dag begge en central ERP organisation. I LEGO består SAP

organisationen af 30-40 mand, hvoraf halvdelen er placeret i Enterprise Architecture i Billund under

Henrik Weis Aalbæk. Hele deres SAP løsning kører på den samme centralt baserede database, med

én undtagelse50.

Hos Grundfos har de siden starten opereret med en central SAP organisation, hvor de i 2001

oprettede SAP CC. Dermed har de ikke IT afdelinger i de forskellige selskaber, hvor medarbejdere

sidder og retter i SAP funktionaliteten. Alle rettelser foretages af SAP CC konsulenter. Grundfos

har ligeledes ét centralt SAP system, hvor de har outsorcet driften af serverne til CSC. John B.

Nielsen fremhæver viljen til at ville centralisere deres SAP organisation som en væsentlig grund til,

at det er lykkes at implementere og køre ét centralt SAP system i Grundfos.

4.4.1.3 ERP teamwork and composition Et velfunderet ERP team er også vigtig i en global ERP implementering. I LEGO er mottoet

”Dedicated team, big enough to solve the task, small enough to be efficient.” De havde et fast team,

der tog rundt og implementerede, hvor projektlederne var prøvede medarbejdere, der havde bevist,

50 Som følge af russisk lov skal dataene fysisk ligge i landet, hvorfor Rusland har deres egen server, der spejles med dem i Billund.

81

at de kunne arbejde sammen. Derudover fik Henrik Weis Aalbæk frie hænder til at finde de bedste

projektmedarbejdere, uanset hvor de sad i organisationen.

Inden oprettelsen af SAP CC i Grundfos var det et fast ERP team, der tog rundt og implementerede

SAP i de sydeuropæiske selskaber. Med oprettelsen af SAP CC bliver teamet sammensat ad hoc fra

implementering til implementering. Ud over SAP konsulenterne er der også teammedlemmer fra

den lokale forretning. Vigtigst for Grundfos er, at der er en lokal forretningsejer af projektet på

holdet, der har indgående kendskab til selskabets forretningsprocesser. Dette er vigtigt for at sikre,

at alle de nødvendige forretningsprocesser bliver dækket ind af SAP systemet.

4.4.1.4 Project management I LEGOs LEGO Light implementering kører de en muteret form for SAPs værktøj ASAP, hvorved

de implementerer SAP i 33 juridiske enheder over sommeren 2001. Dette lykkes ved at køre stramt

på overholdelsen af tidsplanen og økonomien uden at gå på kompromis med kvaliteten.

Projektplanen for implementeringen af Oracle i LEGO Light projektet overholdes, selv ved skiftet

tilbage til SAP midt under projektforløbet. Derudover har LEGO et ekspertteam, der vurderer alle

forslag til ændringer i SAP systemet. Dette sikrer, at der ikke laves ændringer, der får uforudsete

konsekvenser.

Grundfos kører i deres implementeringer med en fast forretningsmodel, hvor alle projekter skal

igennem alle faserne. Der ligger ikke faste skemaer over, hvordan de forskellige faser skal udføres.

Det er op til det enkelte selskab og ERP team at beslutte, hvorledes det skal foregå. Det er vigtigt

for koncernen, at der er lokalt ejerskab under implementeringen. Dette sikrer, at der er taget stilling

til alle forretningsprocesser inden SAP konfigureres og udrulles.

4.4.1.5 Minimum customization Standardisering og enkelthed er vigtige kodeord hos LEGO. Det er vigtigt fra starten af at lægge sig

fast på en forretningsstruktur, der kan indeholdes i standardapplikationen af det ERP system, der

ønskes. Det gælder her om at undgå at lave for meget ”rød kode”. Derudover gør de sig mange

tanker om rigiditeten kontra fleksibiliteten af systemet. Hvis de ved, at de skal omstrukturere i en

bestemt del af systemet, er det vigtigt at lave det fleksibelt fra starten. Hvis processen ikke løbende

omorganiseres, er systemet på det punkt tilsvarende rigidt.

82

Enkelthed over hele linien opnår LEGO ved at reducere deres betalingsbetingelser og

rabatordninger til et minimum over hele forretningen. Endvidere er processerne gjort så simple og

ensartede som muligt, hvor f.eks. en kundeordre behandles og ser ens ud, uanset om den bliver

modtaget og behandlet i USA eller Danmark. Derudover er de meget opmærksomme på kun at

implementere de SAP processer, der reelt er brug for.

Standardisering og harmonisering har hos Grundfos været vigtigt for at kunne køre hele koncernen

under ét SAP system. Dette gør det ikke mindst billigere at drive samt at opdatere. Det er tilstræbt at

køre så meget standard SAP som muligt og dermed ikke at udvikle SAP på en måde, det aldrig er

tiltænkt at blive brugt på. Dette betyder tillige, at der laves så få forskelligartede tilpasninger af SAP

som muligt.

Der hvor Grundfos har valgt at lave ændringer, er i de tilfælde, hvor et selskabs processer er meget

forskellige fra standarden. Der er som eksempel forskel på, om man laver 30.000

cirkulationspumper eller fem trykforøgningsanlæg om dagen. Derudover ønsker Grundfos ikke at

lave om på, hvordan der sælges pumper på de forskellige markeder. De laver derfor ikke om på

rabatordninger og betalingsbetingelser i de forskellige lande.

4.4.1.6 Top management support Topledelsens engagement er i LEGO altafgørende, idet den er primus motor for motivationen af

medarbejderne i ERP implementeringsteamet. Det er lettere at få ting gennemført, når topledelsens

mandat ligger bag. Derudover allokerer den de nødvendige økonomiske og bemandingsmæssige

ressourcer for at implementeringen kan gennemføres. Topledelsens engagement afspejler sig

tydeligt i LEGO Light fasen, hvor implementeringen er oppe at vende på alle direktions- og

bestyrelsesmøder i udrulningsfasen. Topledelsens engagement sikres i LEGO ved at gøre ledelsen

opmærksom på, at ERP projektet er et forretningsprojekt og ikke et IT projekt.

Topledelsen i Grundfos går fra starten ind og dikterer, at koncernens selskaber skal køre SAP under

ét system, efter de har indset fordelene ved denne harmonisering. Derudover er der lokal

bemyndiget ejerskab af SAP implementeringen i de forskellige selskaber. I de tilfælde, hvor den

lokale ledelse ikke er stærk nok, oplever de en mere træg indførelse af SAP. Topledelsens synlige

support er i dag ikke så vigtig som i starten, da selskaberne har set fordelene ved systemet og gerne

vil have det indført.

83

4.4.2 De mindre væsentlige kritiske succesfaktorer De nedenstående kritiske succesfaktorer er kun i mindre grad underbyggede af den empiriske

undersøgelse, da det kun er den ene af de to cases der omhandler disse. Disse er ”master data and

processes”, ”regain trust and credibility” og ”organisation mature for change”. I alle tilfælde er det

kun casen fra LEGO, der underbygger disse. Tillige med de væsentlige kritiske succesfaktorer, har

rækkefølgen hvori de kritiske succesfaktorer er nævnt ingen prioriteringsmæssig betydning.

4.4.2.1 Masterdata and processes At have styr på sine masterdata er vigtig i en global ERP implementering. For at få styr på

masterdata har LEGO udarbejdet en ordbog, der klart definerer, hvad der menes med f.eks.

kundenummer, omsætning, varenummer, osv. Derudover indså LEGO, at de var en simpel

virksomhed, og at deres processer i virksomheden var meget ens. Derfor vælger LEGO at

simplificere deres processer, så de samme processer køres ens i alle dele af verden.

4.4.2.2 Organisation mature for change At have en organisation, der er moden til forandringer, kan gøre det nemmere at implementere.

LEGO gennemførte i 1999 en massiv fyringsrunde, der rystede organisationen grundigt. Det betød,

at de, der stod for LEGO Light, var meget bevidste om, at der skulle implementeres, før

organisationen nåede på plads.

4.4.2.3 Regain trust and credibility Det er vigtigt at have styr på sine strukturer og processer i det implementerede ERP system. Hos

LEGO oplever de, at det er vigtigt, at medarbejderne har tillid til de strukturer og processer, der

ligger i systemet, da de ellers vil omgå systemet. Dette betyder, at de ikke performer på det niveau,

som kan forventes.

4.4.3 Succeskriterier LEGO har som succeskriterier at systemet skal virke, at der skal være minimal downtime og at der

ikke skal tabes omsætning som følge af implementeringen. Derudover er det et væsentligt

succeskriterium, at implementeringen bliver gennemført indenfor budget og tidsramme.

84

De eneste succeskriterier, der er centralt dikteret fra ledelsen i Grundfos er, at de skal kunne

servicere kunderne og levere til tiden. Derudover menes succeskriterierne ifølge John B. Nielsen at

være åbenbare. Drift og stabilitet, herunder gode svartider i systemet er nogle af de mere centrale

kriterier. Derudover nævnes tilgængelighed og at systemet skal leve op til de krav, de eksterne

kunder stiller. Det er i denne forbindelse vigtigt for Grundfos, at kunderne ikke skal mærke, at der

skiftes system. Der er ikke opstillet nogen officielle økonomiske kriterier. De forskellige selskaber i

koncernen har i flere tilfælde opstillet deres egne specifikke succeskriterier. Som eksempel har

produktionsselskabet i Bjerringbro som kriterium, at alle fabrikkerne skal afvikle deres processer på

noget nært præcis samme måde.

4.5 Delkonklusion I afhandlingens andel del, casedelen, blev der gennemført casestudier i to virksomheder, LEGO og

Grundfos. I de to cases blev virksomhederne præsenteret, og der blev foretaget en gennemgang af

deres globale ERP implementering, herunder hvilke kritiske succesfaktorer de havde fokuseret på

under implementeringerne. Her fremgik det, at begge virksomheder fokuserede meget på alignment

of business and ERP strategy, en central ERP organisation, ERP teamwork and composition,

Project management, minimum customization, samt top management support. Derudover fandt

LEGO det væsentligt at koncentrere sig om tre øvrige områder som de kalder henholdsvis

masterdata, organisation mature for change og regain trust and credibility.

Endvidere blev det gennemgået, hvilke succeskriterier de to virksomheder selv opstillede i

forbindelse med deres globale SAP implementeringer. For LEGO var det vigtigt at implementere

indenfor tid og budget, og at systemet efterfølgende skulle fungere med et minimum af downtime. I

Grundfos dikterede ledelsen, at systemet skulle kunne servicere kunderne og levere til tiden.

Derudover var kriterierne for succes drift og stabilitet, samt at kunderne ikke skulle kunne mærke

systemskiftet. Endvidere havde flere af de forskellige selskaber i koncernen opstillet deres egne

individuelle succeskriterier.

85

5 Analytisk generalisering Den analytiske generalisering vil tage udgangspunkt i den gennemgåede teori og empiri. Det vil

blive gjort klart, hvor empirien understøtter eller udbygger den eksisterende teori på området for

kritiske succesfaktorer i globale ERP implementeringer. Da der indenfor den akademiske verden er

stor konsensus omkring navngivningen af de kritiske succesfaktorer, bibeholdes denne.

Klassificeringen af de forskellige kritiske succesfaktorer sker ud fra, hvordan de er blevet

klassificeret rent teoretisk, og i hvor høj grad de kan understøttes af den empiriske undersøgelse.

Det skal her endnu en gang gøres klart, at klassificeringen af en kritisk succesfaktor som værende

mindre væsentlighed ikke skal tages som udtryk for, at den ikke er vigtig i forbindelse med en

global ERP implementering. Det er til stadighed vigtigt at tage hensyn til disse kritiske

succesfaktorer, hvis der ønskes en succesfuld implementering, om end de vurderes til at spille en

mindre central rolle set i forhold til den samlede implementering.

I tabel 4 præsenteres en samlet oversigt over de kritiske succesfaktorer og deres væsentlighed i

teori, empiri samt en samlet vurdering. Argumentationen for den samlede klassificering føres under

hver kritiske succesfaktor.

Tabel 4 Samlet klassificering af globale kritiske succesfaktorer

App

ropr

iate

bus

ines

s and

info

r-m

atio

n te

chno

logy

lega

cy sy

stem

s

Bus

ines

s pla

n an

d vi

sion

Bus

ines

s pro

cess

ree

ngin

eeri

ng

Cha

nge

man

agem

ent c

ultu

re a

nd

prog

ram

Com

mun

icat

ion

Cul

ture

ER

P te

amw

ork

and

com

posi

tion

Mon

itorin

g an

d ev

alua

tion

of

perf

orm

ance

Polit

ics

Proj

ect c

ham

pion

Proj

ect m

anag

emen

t

Soft

war

e de

velo

pmen

t, te

stin

g an

d tr

oubl

esho

otin

g

Top

man

agem

ent s

uppo

rt

Teoretisk 2 1 1 1 2 1 1 2 1 2 1 2 1 Empirisk 2 1 1 2 2 2 1 2 2 2 1 1 1 Samlet 2 1 1 1 2 2 1 2 2 2 1 1 1

Kilde: Egen tilvirkning Anm.: 1 = væsentlig, 2 = mindre væsentlig

86

5.1 Appropriate business and information technology legacy systems Hverken hos LEGO eller Grundfos har deres tidligere systemer haft indflydelse på deres globale

ERP implementering. Henrik Weis Aalbæk nævner i forbindelse med legacy systems, at det er

vigtigt at have en plan for, hvordan der holdes liv i disse, da der er opbevaringspligt af dokumenter

af forskellig varighed alt efter land. At LEGO og Grundfos ikke har anset deres legacy system som

havende en indflydelse på deres implementering, kan skyldes at begge før indførelsen har kørt med

SAP systemer igennem en årrække.

Denne kritiske succesfaktor klassificeres derfor som mindre væsentlig, da den teoretisk blev

klassificeret som dette og den empirisk ikke blev væsentligt underbygget.

5.2 Business plan and vision Begge virksomheder i den empiriske undersøgelse har haft stor fokus på at skabe og bibeholde

alignment af forretnings- ERP strategien i koncernerne. I LEGO afspejler det sig ved udarbejdelsen

af deres main principles som omdrejningspunkt for deres forretning og derved deres globale SAP

implementering. En fast strategi har været hele tiden at gøre sig klart, hvad de ville opnå med

implementeringen.

Hos Grundfos har de qua ledelsens udmelding om, at alle koncernens selskaber skulle kobles på ét

samlet SAP system fra starten, haft en fast strategi. Som følge af deres SAP CC og

forretningsmodel for deres SAP implementeringer, har de i hver udrulning meget fokus på

samhørigheden af koncernens forretnings- og ERP strategi.

En videre underbygning af den kritiske succesfaktor i casene er begge virksomheders centrale ERP

organisation, som er fremhævet under afsnit 4.4.1.2.; vigtigst er her viljen til at centralisere ERP

systemet for at opnå en central styring med systemet.

Den kritiske succesfaktor vurderes derfor at have en central betydning i en global ERP

implementering, da den er veldokumenteret i litteraturen og stærkt underbygget i de to casestudier.

87

5.3 Business process reengineering Denne kritiske succesfaktor blev stærkt underbygget af den empiriske undersøgelse, hvilket kan ses

af afsnit 4.4.1.5 minimum customization. Både LEGO og Grundfos har gjort sig store anstrengelser

for at holde tilpasningerne af systemerne på et minimum. LEGO og Grundfos har dog forskellige

syn på at tilpasse ERP systemet. LEGO ønskede så få tilpasninger som absolut muligt og ønskede

dermed at simplificere så meget som muligt i systemet, hvilket har betydet, at de samme processer i

LEGO køres fuldstændig ens, uanset hvor man befinder sig verden. Grundfos har lavet tilpasninger,

men har søgt at mindske antallet af disse. Grundfos har den filosofi, at jo længere væk fra kunden,

jo færre tilpasninger til systemet tillades. Grunden til LEGOs og Grundfos’ forskellige syn på dette

skal sikkert findes i deres produkter. LEGOs produkt er fuldstændig standardiseret, og produktionen

foregår ens alle steder. Grundfos derimod fremstiller både lav- og højteknologiske produkter.

Ved LEGO medførte den meget store fokusering på simplicity, at der skulle laves om på de

forretningsprocesser, der fandtes i virksomheden. At dette var tilfældet, mener Henrik Weis Aalbæk

ikke, at medarbejderne mærkede, da de på det tidspunkt var i gang med at komme sig over fyringen

af 1200 kolleger. At LEGOs organisation har været rystet oven på fyringen af de mange

medarbejdere har sikkert haft sin indvirkning på, hvor meget modstand de tilbageværende

medarbejdere har kunnet mobilisere. Hos Grundfos har de ikke stødt på nævneværdig modstand

mod de organisationsforandringer, der har fulgt i kølvandet af den globale ERP implementering.

Denne kritiske succesfaktor blev i det teoretiske studie klassificeret som væsentlig, og i det

empiriske studie var der stærk opbakning til subfaktoren minimum customization. Derfor

klassificeres business process reengineering som værende væsentlig i en global ERP

implementering.

5.4 Change management culture and program Kort inden LEGOs sidste implementeringsfase, LEGO Light, blev organisationen rystet godt og

grundigt grundet fyringen af de 1200 medarbejdere. Derved var forandringen af organisationen en

naturlig del af at indføre deres endelige SAP R/3 system i koncernens selskaber rundt i verden.

Endvidere støtter casen vigtigheden af uddannelse i forløbet, om end de i LEGO indrømmer, at de

kunne blive bedre til at efteruddanne deres medarbejdere.

88

I Grundfos har villigheden til forandringerne været til stede, siden de i Grundfos så fordelene ved at

implementere SAP. De indså i forbindelse med årtusindeskiftet, at de måtte finde en ny IT løsning

af flere af deres selskaber, hvorved implementeringen af SAP R/3 blev løsningen. Også vigtigheden

af uddannelsesområdet er Grundfos bevidst om, da det er et af punkterne i deres forretningsmodel.

Organisation mature for change og regain trust and credibility, som de i LEGO fandt som

væsentlige kritiske succesfaktorer under deres SAP implementering, er ligeledes elementer, der er

med til at underbygge denne kritiske succesfaktor empirisk.

Den kritiske succesfaktor klassificeres samlet som værende væsentlig i en global ERP

sammenhæng, med flere referencer i litteraturen samt en god underbygning i empirien.

5.5 Communication Under denne kritiske succesfaktor fremkom under det teoretiske studie den nye subfaktor

communication among different cultures. At dette er en reel udfordring kan underbygges med

erfaringer fra både Grundfos og LEGO. Begge virksomheder har haft erfaringer med, at

kommunikation med selskaber i østen kan være vanskelig. Hos LEGO kan nævnes en anekdote om

et møde, Henrik Weis Aalbæk havde med en gruppe asiatiske ledere, der var på besøg i Billund for

at høre omkring den kommende ERP implementering. Mødet varede to timer, hvorefter gæsterne

bukkede og sagde tak. Henrik fik efter mødet fortalt, at ingen af lederne kunne andet engelsk end

tak [Bilag 6]. Derudover har Grundfos erfaret, hvis der spørges til om de har forstået budskabet

siger de også ja, da det er et nederlag for dem at sige at de ikke har [Bilag 10]. Anekdoten og

erfaringen fra Grundfos illustrerer meget godt, at det er vigtigt at kende de sproglige kundskaber af

de medvirkende ledere. En tolk kunne være løsningen.

Kommunikation i forbindelse med ERP implementeringerne har ikke været noget, som hverken

LEGO eller Grundfos har haft nævneværdig fokus på, trods de ovennævnte episoder. LEGO

kommunikerede en del omkring projektet, men Henrik Weis Aalbæk erkender, at det ikke har været

nok, og at den information, der kom ud, ikke altid var korrekt [Bilag 6]. John B. Nielsen

konstaterer, at det altid er godt at kommunikere med medarbejderne omkring det, der skal ske

[Bilag 10]. Det vurderes derfor på grund af den ringe opbakning i teori samt det, at både LEGO og

89

Grundfos har gennemført deres implementeringer uden nævneværdig brug af kommunikation, at

dette er en mindre væsentlig kritisk succesfaktor i en global ERP implementering.

5.6 Culture De kulturelle problemer i forbindelse med LEGOs og Grundfos’ implementeringer har været

relative begrænsede. Som nævnt under communication har både LEGO og Grundfos stødt på de

sproglige begrænsninger, som især er til stede i Asien. Derudover har folk fra østen meget svært ved

at indrømme, at der er noget, de ikke har forstået, da det i deres kultur anses for at være et nederlag

og værende uhøfligt. For at overkomme disse kulturelle problemer har LEGO valgt at udstationere

danskere i de forskellige selskaber. Derudover har Grundfos oplevet, at medarbejderne i østen ikke i

samme grad tager selvstændige beslutninger, hvorfor der skal tages stilling til meget på

direktørniveau. Henrik Weis Aalbæk mener, at de største udfordringer i forbindelse med den

globale implementering hos LEGO har været i Billund, hvor der var medarbejdere, der ikke

ønskede at samarbejde [Bilag 6].

Culture blev i det teoretiske studie klassificeret som væsentlig, da det forventedes, at kultur ville

have en stor indflydelse på en global ERP implementering. Det empiriske materiale viser noget

andet; hverken LEGO eller Grundfos føler, at de kulturelle problemer har været uoverkommelige,

og har heller ikke gjort noget for at komme dem i møde. Da LEGO og Grundfos har haft

succesfulde globale implementeringer, klassificeres kultur som en mindre væsentlig kritisk

succesfaktor. Det skal dog her pointeres, at der som nævnt i afsnit 3.3.2.13 er kulturelle

udfordringer i andre af de kritiske succesfaktorer.

5.7 ERP teamwork and composition Som det blev fremhævet i casesammenligningen i afsnit 4.4.1.3, er ERP teamet et centralt punkt i de

to casevirksomheder. Hos LEGO var det prøvede projektledere, der fik ansvaret til at håndplukke de

bedste medarbejdere til deres team, og som samtidig havde den fulde opbakning og mandat fra

topledelsen til at træffe de nødvendige beslutninger. Derudover har ERP leverandøren været en god

og vigtig sparringspartner.

90

Betydningen af ERP teamet afspejler sig i Grundfos ved, at de er meget bevidste om

sammensætningen af holdet. ERP teamet består af SAP CC konsulenter og lokale medarbejdere,

hvorved der er et bevidst miks af IT og forretningsfolk i teamet. Det er vigtigt for Grundfos, at

forretningsdelen er repræsenteret ved en person, der har indgående kendskab til selskabets

processer. Ud over væsentligheden i den empiriske del, er den i litteraturen også stærkt

underbygget, hvorved den findes væsentlig.

5.8 Monitoring and evaluation of performance Denne kritiske succesfaktor finder kun ringe underbygning i både LEGO og Grundfos. I LEGO har

de afholdt en afteraction review procedure indenfor de forskellige teams, men ikke et forløb, der var

videre stringent. Derfor vurderes det, at det ikke har været kritisk for gennemførelsen. I forbindelse

med interviewet med John B. Nielsen blev vi forevist en nylig afholdt global

brugertilfredshedsundersøgelse. Udover denne havde de tidligere holdt nogle få undersøgelser i

Bjerringbro, men ikke nogen, der har haft videre betydning for implementeringerne. Den kritiske

succesfaktor er derfor af mindre relevans i den globale sammenhæng, da den tillige i teorien

tidligere er vurderet som mindre væsentlig.

5.9 Politics Begge virksomheder oplever, at der skal tages hensyn til lovkravene i de forskellige lande. Hos

LEGO nævnes det, at der har været visse problemer med at håndtere de mange forskellige landes

lovgivninger, blandt andet med hensyn til dokumentkrav. Her er det er vigtigt at være dækket ind

med revisorerne for at være på forkant med lovgivningen. I Grundfos benytter de nogle SAP

værktøjer, som giver et billede af forskellige landes legale krav51, som de skal tage specielt hensyn

til. Derudover har de i Grundfos ifølge John B. Nielsen forholdt sig til de forskellige

problemstillinger undervejs og har dermed ikke yderligere undersøgt forholdene forinden.

Gennemførelsen af interviewene gav ikke indtrykket, at denne kritiske succesfaktor havde

afgørende betydning for implementeringens udfald, om end de nævnte aspekter er vigtige at tage

hånd om. At det ikke spiller en større rolle i empirien, kan skyldes at begge virksomheder er danske.

51 Se bilag 10.

91

Danmark og dermed danske virksomheder har generelt gode diplomatiske forhold til de fleste lande

i verden.

Trods det faktum, at denne kritiske succesfaktor har sin berettigelse i den globale sammenhæng,

vurderes den ikke til at have afgørende betydning i det samlede billede.

5.10 Project champion Det er svært at vurdere, om LEGO eller Grundfos har haft en decideret projekt sponsor, da der ikke

er fuldstændig klarhed omkring begrebet. LEGO havde under LEGO Light direktionsmedlemmet

Poul Plougmans mandat til at gennemtrumfe de nødvendige beslutninger. Grundfos mener, at det er

vigtigt at have implementeringen lokalt forankret, da det giver den nødvendige magt til at

gennemføre implementeringen.

Project champion klassificeres som mindre væsentlig, da der som nævnt ikke er klarhed om

begrebet, og det er svært at vurdere om LEGO og Grundfos har gjort brug af det, som begrebet

dækker over. Eksemplerne fra LEGO og Grundfos illustrerer, at det mindst lige så meget er magten,

der har været vigtig, og den fås først og fremmest igennem topledelsen.

5.11 Project management LEGOs projektledelse har været vigtig for gennemførelsen af den globale ERP implementering. De

har i deres implementeringer fokuseret på at overholdt tidsramme og budget og været

opmærksomme på at holde sig indenfor projektets ramme. Derudover understøtter det også den

kritiske succesfaktor, at LEGO har et ekspertteam til at vurdere forslag til ændringer i SAP.

Hos Grundfos har de som sagt ved alle implementeringer erfarne SAP CC konsulenter til at lede

implementeringerne sammen med lokale ledere med stort kendskab til forretningen. Konsulenterne

har det fulde mandat fra topledelsen til at gennemføre implementeringen i de forskellige selskaber

jævnfør deres udarbejdede forretningsmodel.

Begge cases underbygger væsentligheden i denne kritiske succesfaktor tilstrækkeligt til, at den

klassificeres som værende væsentlig i en global kontekst. Dog skal det nævnes, at den i det globale

92

litteraturstudie fundne subfaktor metanational advantages ikke blev underbygget i nogen af de to

virksomheder, hvorfor denne subfaktor i sig selv ikke anses for at være essentiel i en global

sammenhæng.

5.12 Software development, testing, and troubleshooting Denne kritiske succesfaktor kan ud fra empirien underbygges med endnu en subfaktor, masterdata.

Erfaringerne fra LEGO viser, at det er vigtigt at have styr på sine masterdata, og at det er vigtigt, at

have defineret, hvad der menes med de termer, der bruges i ERP systemet. Derudover har både

LEGO og Grundfos gjort meget ud af at få deres processer i ERP systemet defineret. Grundfos

gjorde det gennem deres process mapping og fit-gap analyse, og LEGO har gjort det ved at se

grundigt på deres processer med nye øjne.

Denne kritiske succesfaktor anses, pga. den indsats, der gøres for at sikre strukturen i ERP systemet

hos både LEGO og Grundfos, som værende væsentlig, selv om den blev klassificeret som mindre

væsentlig i den teoretiske del af opgaven. Dog kan det ses ud af det globale litteraturstudie, at 2 ud

af 3 artikler nævner denne kritiske succesfaktor. Grunden til, at denne kritiske succesfaktor er

vigtigere i en global implementering, kan skyldes, at der er flere enheder, der skal spille sammen,

og at den høje grad af integrering i ERP systemet gør en global virksomhed mere sårbar. Henrik

Weis Aalbæk nævner, at han næsten er helt bange for den høje grad af integrering, for hvis systemet

går ned, så er det ikke kun i Billund, men globalt. Men denne pris er værd at betale, mener han, da

LEGO i dag som helhed står bedre rustet som følge af den globale ERP implementering [Bilag 6].

5.13 Top management support Topledelsens engagement er for LEGO og Grundfos altafgørende for, at deres SAP

implementeringer er lykkedes. De pointerer begge den afgørende vigtighed af, at de i begge

koncerner har haft topledelsens støtte og mandat til at gennemføre implementeringerne. De har i

begge virksomheder haft en meget synlig topledelse, der er gået ind og har sat SAP

implementeringerne som en top prioritet samt allokeret de nødvendige ressourcer til

gennemførelserne af projekterne.

93

Denne kritiske succesfaktor er både i litteraturen og i casevirksomhederne vurderet til at være den

vigtigste kritiske succesfaktor af dem alle.

5.14 Succes LEGO og Grundfos har ikke haft mange stringente eller nedskrevne mål for deres implementering.

At LEGO dog kørte stringent efter tidsrammen og ønskede at overholde denne, kan ses på baggrund

af deres valg om at bibeholde tidsrammen, da de midt i LEGO Light gik fra Oracle til SAP. Dette

tyder på at process failure begrebet stadig er en yndet måde at vurdere projekter på. Baggrunden for

dette skal nok findes i, at det er en nem måde at definere, om et projekt har været en succes. Dette

var dog ikke det eneste, de målte på52, hvilket indikerer, at virksomheder i dag er ved at få et mere

nuanceret syn på succes. Grundfos havde ud over kundekriteriet også kriterier for drift og stabilitet.

Der kan derfor argumenteres for, at virksomheder har taget expectation failure begrebet lidt til sig

og måler succes på baggrund af flere dimensioner. Ud over at måle på flere dimensioner har

virksomhederne også valgt at involvere medarbejderne ved at gennemføre

tilfredshedsundersøgelser. Dermed er der flere stakeholdergrupper, der får lov til at give deres

mening til kende. Grundfos lå i deres medarbejderundersøgelse generelt højere end den peergruppe

af virksomheder, som de havde målt sig op imod. Hos LEGO fik de slag for uddannelse,

efteruddannelse og information. I begge tilfælde havde medarbejdernes stemme ikke gjort videre

indtryk i opfattelsen af implementeringerne som værende succesfulde.

Om de få succeskriterier har haft nogen indflydelse på, hvordan hhv. LEGO og Grundfos har kørt

deres implementering, er svært at sige. Hos LEGO tyder det på, at den store fokus på at være inden

for tidsrammen, har haft den indflydelse, at project management og project timelines.

52 Målte som tidligere nævnt blandt andet også på ”minimum downtime” og ikke at tabe omsætning.

94

6 Konklusion Formålet med denne afhandling har været at undersøge, hvilke kritiske succesfaktorer, der er

vigtige i en global ERP implementering ud fra teori og praksis. Baggrunden for denne

problemformulering er de mange historier om kuldsejlede ERP implementeringer og den stadig

stigende globalisering af markedet, der kræver, at virksomheder opererer globalt, og derved også i

mange tilfælde har selskaber i flere forskellige lande, som de ønsker at integrere i et samlet system.

Afhandlingen er delt op i en teoretisk del, en empirisk del og den analytiske generaliseringsdel,

hvor teorien sammenholdes med empirien, for at give en samlet vurdering af, hvilke kritiske

succesfaktorer globale virksomheder skal fokusere på.

For at kunne svare på, det ovenstående er der i problemformuleringen opstillet fire punkter, der skal

besvares. Disse punkter vil her blive besvaret.

Som det første i den teoretiske del af afhandlingen blev ERP begrebets historiske udvikling

gennemgået, og begrebet blev defineret som følger: ”ERP systemer er informationssystemer, der

understøtter online, integreret, realtime transaktionsregistrering, databearbejdning og

rapportering i forbindelse med afvikling af virksomhedens forretningsprocesser ved hjælp af en

central database, ofte i en client/server IT-arkitektur.” Derudover blev det defineret, at en ERP

implementering er global, når den foretages i to eller flere lande. Jo flere lande, der implementeres i,

jo mere global vurderes en implementering at være. Endvidere blev det med udgangspunkt i en 4-

fasemodel udarbejdet af Markus og Tanis [Markus et al., 2000] defineret, at en ERP

implementering i denne afhandling betragtes som gående fra den første tanke om indførelsen af

systemet, chartering, over project og shakedown til onward and upward fasen, hvorefter systemet

afløses af et nyt.

Sidste begrebsafklaring handler om succes, der betragtes som værende et relativt begreb. Med

udgangspunkt i Hirschheim et al.’s (1987) artikel, Information systems failures – a survey and

classification of the empirical literature, præsenteredes succes ud fra failure begrebet. Dette blev

gjort ud fra devisen om, at de udledninger, der ligger bag at vurdere fiasko i et givent system, også

kan danne grundlag for at vurdere, om systemet er en succes. Der blev redegjort for fire syn

værende correspondence failure, der diskuterer succes ud fra opfyldelse af kravspecifikation,

process failure, der omhandler tid og budget, interaction failure, hvor udgangspunktet er brugernes

95

interaktion med systemet samt expectation failure, der har et multifacetteret syn på begrebet.

Expectation failure tager udgangspunkt i, at der kan findes flere stakeholdergrupper i en

virksomhed, der har forskellige syn på, hvornår en implementering opfattes som en succes.

Efter begrebsafklaringerne blev der identificeret 13 kritiske succesfaktorer, der havde betydning for

en global ERP implementering. Disse kritiske succesfaktorer blev identificeret ud fra to

litteraturstudier. Det første studie er foretaget og præsenteret i Nah et al.’s artikel ”ERP

Implementation: Chief information Officers’ Perception of Critical Success Factors” fra 2003, hvor

forfatterne fremkom med 11 kritiske succesfaktorer. I denne artikel tager de ikke eksplicit stilling

til, hvorvidt de angivne kritiske succesfaktorer gælder i en global sammenhæng. Derfor blev der i

afhandlingen foretaget en supplerende artikelsøgning ud fra tre søgekriterier:

Artiklerne skal indeholde betegnelsen ERP eller Enterprise resource planning i titlen

Artiklerne skal indeholde ordet global, international eller multinational i titlen

Artiklerne skal omhandle implementering af ERP systemer

Ud fra disse kriterier fremkom 9 brugbare artikler, der efterfølgende bekræftede de 11 kritiske

succesfaktorer som værende væsentlige i globale ERP implementeringer. Derudover blev der

identificeret to nye kritiske succesfaktorer. De 13 kritiske succesfaktorer er: 1 Appropriate business

and information technology legacy systems, 2 business plan and vision, 3 business process

reengineering, 4 change management culture and program, 5 communication, 6 ERP teamwork and

composition, 7 monitoring and evaluation of performance, 8 project champion, 9 project

management, 10 software development, testing, and troubleshooting, 11 top management support,

12 culture og 13 politics. De to sidstnævnte kritiske succesfaktorer blev identificeret under det

globale studie.

Ud over to nye kritiske succesfaktorer, blev der identificeret en række nye subfaktorer. Under

business plan and vision blev de kritiske succesfaktorer alignment of business and ERP strategy

tilføjet, under communication tilføjedes Communication among different cultures, og project

management fik tilføjet subfaktoren metanational advantages. Endvidere blev kulturfaktoren opdelt

i tre subfaktorer, general culture, corporate culture og technical. Den politiske kritiske succesfaktor

blev inddelt i henholdsvis government/corporate politics og national rules and demands.

96

Efter denne identifikation af de globale kritiske succesfaktorer, blev de globale udfordringer

indenfor alle de kritiske succesfaktorer identificeret. Ud fra disse udfordringer, antallet af referencer

i de to litteraturstudier samt en rangering efter betydelighed foretaget i Nah et al.’s studie, blev de

klassificeret i to grupper efter væsentlighed – væsentlige og mindre væsentlige. Dette fremgår af

tabel 4.

Tabel 4 Samlet klassificering af globale kritiske succesfaktorer

App

ropr

iate

bu

sine

ss

and

info

r-m

atio

n te

chno

logy

lega

cy sy

stem

s

Bus

ines

s pla

n an

d vi

sion

Bus

ines

s pro

cess

ree

ngin

eeri

ng

Cha

nge

man

agem

ent c

ultu

re a

nd

prog

ram

Com

mun

icat

ion

Cul

ture

ER

P te

amw

ork

and

com

posi

tion

Mon

itorin

g an

d ev

alua

tion

of

perf

orm

ance

Polit

ics

Proj

ect c

ham

pion

Proj

ect m

anag

emen

t

Soft

war

e de

velo

pmen

t, te

stin

g an

d tr

oubl

esho

otin

g

Top

man

agem

ent s

uppo

rt

Teoretisk 2 1 1 1 2 1 1 2 1 2 1 2 1 Empirisk 2 1 1 2 2 2 1 2 2 2 1 1 1 Samlet 2 1 1 1 2 2 1 2 2 2 1 1 1

Kilde: Egen tilvirkning Anm.: 1 = væsentlig, 2 = mindre væsentlig

I den empiriske del blev der foretaget to semistrukturerede interviews og udarbejdet to cases for

henholdsvis LEGO og Grundfos. Virksomhederne blev valgt ud fra følgende tre kriterier:

4) Det skulle være danske virksomheder

5) De skulle have foretaget en global ERP implementering, hvor hovedkvarteret som minimum

skulle være i shakedown fasen jf. Markus et al.’s (2000) 4-fase model

6) Den foretagede implementering skulle have været succesfuld

De to cases blev sammenlignet på baggrund af LEGO og Grundfos’ fokus på de 13 kritiske

succesfaktorer. Via den empiriske del fandtes således jf. ovenstående tabel frem til seks kritiske

succesfaktorer, der var væsentlige, hvor de resterende var mindre væsentlige. De kritiske

succesfaktorer change management program culture and program, culture og politics blev modsat

97

klassificeringen i den teoretiske del vurderet til at være mindre væsentlige, hvor det modsatte var

tilfældet med software development, testing and troubleshooting.

Den empiriske undersøgelse indikerer endvidere, at der i virksomhederne foretages

succesvurderinger ud fra process failure og expectation failure begreberne. Process failure, da det

blandet andet blev sat som mål at overholde tidsramme og budget i LEGOs globale implementering.

I Grundfos havde de et multifacetteret syn på succes, hvor de forskellige selskaber i koncernen

havde flere individuelle stakeholdergrupper, som hver havde deres mål for succes i forbindelse med

SAP implementeringen.

Til sidst kan det konkluderes, at der ud fra den teoretiske og empiriske del samlet set fandtes

følgende syv væsentlige kritiske succesfaktorer i en global ERP implementering: business plan and

vision, business process reengineering, change management culture and program, ERP teamwork

and composition, project management, software development, testing, and troubleshooting, samt

top management support.

98

7 Perspektivering I forbindelse med udarbejdelsen af denne opgave er to emner blevet diskuteret meget. Det er

emnerne succes og kultur i forbindelse med ERP implementeringer. Succes, da det er et svært

definerbart begreb, og kulturen pga. dens umiddelbare indflydelse på andre kritiske succesfaktorer.

7.1 Succes i forbindelse med ERP implementering Vi fandt det fra starten relevant at diskutere begrebet succes, grundet vores hovedtema i

afhandlingen – kritiske succesfaktorer. Efter at have fundet frem til vores teoretiske udgangspunkt

til emnet ved Hirschheim et al.’s (1987) artikel om failure begrebet, fandt vi for alvor ud af, hvor

mange facetter begrebet indeholder. Vi måtte indse, at hvis succes i forbindelse med besvarelsen af

vores hovedspørgsmål skulle gennemarbejdes, ville det kræve langt flere ressourcer og omfang af

afhandlingen end vi ønskede. Derfor har behandlingen af succes begrebet ikke fået den

opmærksomhed i afhandlingen, som begrebet er berettiget til, da vores interesse lå i

implementeringen af ERP systemer og i hvorfor virksomheder til stadighed i større eller mindre

udstrækning ikke formår at komme helskindet igennem en implementering.

7.2 Kultur En af de nye kritiske succesfaktorer, som identificeres i denne afhandling, er kultur. Det kunne

derfor være interessant at se på, hvorledes kultur har indflydelse på de i denne afhandling

præsenterede kritiske succesfaktorer. Hvilke kritiske succesfaktorer har et kulturelt islæt, og hvad

betyder dette for, hvordan virksomheder skal håndtere disse kritiske succesfaktorer.

De empiriske data tyder på, at det er let for danske virksomheder at implementere globale ERP

systemer i Asien, da asiatere typisk er meget autoritetstro. Dette er ikke tilfældet for medarbejdere i

danske virksomheder jf. samme empiriske data. Det kunne være interessant at undersøge, om

asiatiske virksomheder støder på større problemer, når der skal implementeres globale ERP

systemer i Danmark. De empiriske data indikerer, at dette kunne være tilfældet. Det kan derfor

tænkes, at kultur vil spille en større rolle i asiatiske virksomheder, som ønsker at foretage en global

ERP implementering i Danmark end i danske virksomheder der ønsker at implementere i Asien.

Der kan derfor gælde forskellige kritiske succesfaktorer i globale ERP implementeringer, alt efter

hvor virksomheden har sit hovedkvarter.

99

8 Appendiks: Dimensioner til vurdering af failurebegreber

Dimensionality

Hvor de tre traditionelle fiasko syn har meget endimensionale definitioner af hvad succes er, har

expectation failure et multidimensionalt syn på hvad succes er. De traditionelle er relativt nemme at

måle og på baggrund af disse målinger kan der så konkluderes. Ved expectation failure forholder

det sig anderledes, da det er svært at bedømme om et projekt har været succesfuldt medmindre alle

stakeholder grupper erklærer at de alle synes projektet har været en succes. Derimod er det her

relevant at se på hvilken stakeholder gruppes syn der vælges. Der kan være stor forskel på hvad

ledelsen ser som en succes og hvad manden på gulvet opfatter som en succes.

Type of measurement scale

Der findes to typer af skalaer en diskret og en kontinuert skala. De tre traditionelle syn bruger den

diskrete skala, hvilket betyder at succes og fiasko kan ligge meget tæt op ad hinanden, da der findes

en prædefineret punkt hvor succes bliver til fiasko eller omvendt. Derfor har disse syn et meget

sort/hvidt syn. Expectation failure derimod bruger en kontinuert skala. Dette betyder et gradvist

skift fra dårlig til godt eller fiasko til succes. Dette syn har et knapt så sort/hvidt syn, da de færreste

implementeringer er komplette succeser eller fiaskoer.

Nature of failure assessment

De tre traditionelle syn antager at, hvis en implementering ender i en fiasko så vil det ramme alle

stakeholder grupper i lige hårdt også kaldet en neutral vurderingsmåde. Expectation failure

derimod, antager at nogle grupper bliver ramt hårdere end andre af en forfejlet implementering,

denne vurderingsmåde kaldes non-neutral. Dette betyder at nogle stakeholder grupper isoleret set

kan opfatte den forfejlede implementering som en succes.

Temporal aspect

Dette syn opererer med to alternativer, statisk og dynamisk. Ved et statisk syn antages det at når en

implementering først er blevet målt og klassificeret som en fiasko, vedbliver den med at være en

fiasko. Dette alternativ foretrækkes af de tre traditionelle syn. Ved et dynamisk syn, ses

implementeringen som en dynamisk proces, hvor der undervejs læres af fiaskoen. Derved kan der

100

senere rettes op på disse fejl, så en implementering kan blive en succes. Expectation failure har

dette dynamiske syn.

Nature of assessment procedure

Vurderingsproceduren kan gå fra at være formel til uformel på en kontinuert skala. De tre

traditionelle syn er meget formelle i deres tilgang, da de er formaliseret i den måde de bedømmer

projekter på. Expectation failure er relativ uformel i dens måde at bedømme projekter, da den går på

forhandlinger imellem forskellige stakeholder grupper i virksomheden. Der bruges dog også

formaliseret data, men mest til at underbygge forskellige synspunkter.

Assessment time frame

Under dette aspekt ses der på, om en vurdering primært ser på fortid, nutid eller fremtid. Dette

betyder at vurderinger vil falde i to analyseklasser ex ante og ex post. De tre traditionelle syn

benytter primært metoder, hvor de ser tilbage på, hvordan tingene er gået med bl.a. budgettet og

tidsplanen – altså et efterrationaliseringssyn også kaldet ex post. Expectation failure har den mere

omvendte måde at gribe tingene an på, ved at se på, hvad der skal foretages i fremtiden af f.eks.

ændringer i organisationen og tekniske implementeringer for at imødekomme stakeholdernes

forventninger.

Participants

Hvem skal bestemme om et givent projekt er været en succes/fiasko? Ved de tre traditionelle syn er

det typisk en relativ lille gruppe personer som kommer med deres vurdering baseret på målinger.

Ved expectation failure er det derimod alle stakeholdergrupper der er med i evalueringen af

projektet. De traditionelle syn har en begrænset gruppe til at evaluere, kaldes disse for limited.

Expectation failure har mange grupper med i evalueringen og kaldes derfor extensive.

Evaluation process.

En evalueringsproces kan antages at være enten context-dependent eller context-independent. De tre

traditionelle syn antager at evalueringsprocessen er context-independent, da de ikke tager hensyn til

den kontekst der bliver implementeret under men kun ser på de målinger de har foretaget.

Expectation failure synet antager at evalueringsprocessen er context-dependent, dvs. at succesen af

en given implementering afhænger af den kontekst i hvilken der er blevet implementeret.

101

9 Litteraturliste

9.1 Bøger Becker-Christensen, Christian: Politikens nudansk ordbog, 18. udgave, 2001, Politikens forlag A/S

Fog, J: Med samtalen som udgangspunkt, 2004, 2. udgave, Akademisk Forlag

Goodfellow, R.: Manufacturing resource planning, MRP II, 1994, Manufacturing Business

Excellence Limited

Heldbjerg, G.: Grøftegravning i metodisk perspektiv : et videnskabsteoretisk og metodologisk

overblik, 2003, Samfundslitteratur

Jacobs, F., Whybark, D.: Why ERP? A primer on SAP implementation, 2000, Irwin McGraw-Hill

Lucas, H. C., Ginzberg, M. J., Schultz, R. L.: Information systems implementation: Testing a

structural model, 1990, Ablex publishing corporation

Luscombe, M.: MRP II: integrating the business: a practical guide for managers, 1993,

Butterworth-Heinemann

Maaløe, E.: Casestudier: Af og om mennesker i organisationer, 2. udgave, 2002, Akademisk forlag

A/S

Markus, M., Tanis, C.: The enterprise systems experince – from adoption to success, Kapitel 10 I

Framing the domians of IT research: Glimpsing the future through the past, 2000, Pinnaflex

educational ressources Inc.

Neergaard, H.: Udvælgelse af cases i kvalitative undersøgelser, 2001, Samfundslitteratur

102

O’Leary, D.: Enterprise resource planning systems. Systems, life cycle, electronic comerce, and

risk, 2000, Cambridge university press

Pressman, J. L., Wildawsky, A; Implementation: How great expectations in washington are dashed

in Oakland, 3. Edition, 1984, Berkeley: University of California press

Rikhardsson, P., Kræmmergaard, P., Møller, C.: ERP - danske erfaringer med implementering og

anvendelse, 2004, Børsen

Russell, R., Taylor, B.: Operations management, 1998, Prentice-Hall, Inc.

Shields, M. G.: E-business and ERP – Rapid implementation and project planning, 2001, John

Wiley & sons, Inc.

Yin, R. K.: Case study research: Design and methods, 3. edition, 2003, Sage Publications

9.2 Artikler Alter, S.: Implementation risk analysis, TIMS studies in the management sciences 13, 1979, p103-

119

Bingi, P., Sharma, M. K., Godla, J.: Critical issues affecting an ERP implementation, Information

Systems Management, 1999, vol. 16, issue 2, p7–14

Buckhout, S., Frey E.,& Nemec, J., Jr.: Making ERP succeed: Turning fear into promise,

IEEE Engineering Management Review, 1999, vol. 19, 116–123.

Falkowski, G., Pedigo, P., Smith, B., & Swanson, D.: A recipe for ERP success,

Beyond Computing, September 1998, p44–45

Ghosh, S.: Challenges on a global implementation of ERP software, IEEE, 2002, p 101-106

103

Ghosh, S., Ghosh, S.: Global implementation of ERP software - Critical success factors on

upgrading technical infrastructure, IEEE, 2003, p 320-324

Hanseth, O., Ciborra, C., Braa, K.: The control devolution: ERP and the side-effects of

globalization, The data base for advances in information systems, special issue on ERP systems,

vol. 32, no. 4, Fall 2001, p 34-46

Hill, R., Vadney, T.: Going global with ERP, The Journal, July 2001, p 26-33

Hirschheim, R., Lyytinen, K.: Information system failures – a survey and classification of the

empirical literature, Oxford surveys in information technology vol. 4, 1987, p 257-309, Oxford

university press

Holland, C. P., Light, B., & Gibson, N.: A critical success factors model for enterprise

resource planning implementation, Proceedings of the 7th European Conference on Information

Systems, 1999, Bind 1, p273–297

Huang, S., Chen, H., Hung, Y., Ku, C.: Transplanting the best practice for implementation of an

ERP system: A structured inductive study of an international company, Journal of computer

information systems, Summer 2004, p 101-110

Klaus, H., Rosemann, M., Gable, B.: What is ERP?, Information Systems Frontiers, 2000, vol. 2,

issue 2, p141-162

Light, B.: Realizing the potential of ERP systems: The strategic implications of implementing an

ERP strategy: The case of global petroleum, Electronic Markets, vol. 9, issue 4, 1999, p 238-241

Madapusi, A., D'Souza, D.: Aligning ERP systems with international strategies, Information

systems management, Winter 2005, p 7-17

Murray, M., & Coffin, G.: A case study analysis of factors for success in ERP system

Implementations, Proceedings of the Seventh Americas Conference on Information Systems,

104

Boston, 2001, p1012–1018

Møller, C. et al.: A comprehensive ERP bibliography – 2000-2004, Working paper nr. 129, The

Aarhus School of Business, Department of Information Science, 2004

Nah, F., Lau, J., & Kuang, J.: Critical factors for successful implementation of enterprise

Systems, Business Process Management Journal, 2001, vol. 7, issue 3, p285–296

Nah, F., Zuckweiler, K., Lau, J.: ERP Implementation: Chief Information Officers' Perceptions of

Critical Success Factors, International Journal of Human-Computer Interaction, 2003, vol. 16 Issue

1, p5-22

Parr, A., Shanks G.: A Model of ERP Project Implementation, Journal of information technology, 2000, vol. 15, issue 2, pp 289-303. Roberts, H. J., & Barrar, P. R. N.: MRPII implementation: Key factors for success, Computer

Integrated Manufacturing Systems, 1992, vol. 5, issue 1, p31–38

Rockart, J. F.: Chief executives define their own data needs, Harward business review, Marts-april

1979, p81-93

Rosario, J. G.: On the leading edge: Critical success factors in ERP implementation

Projects, Business World (Philippines), May 17 2000, 27

Ross, J. W.: Working paper: The ERP revolution, CISR WP No. 307, Sloan WP No. 4086,

Massachusetts institute of technology, august 1999

Sarkis, J., Sundarray, R. P.: Managing large-scale global enterprise ressource planning systems: a

case stydy at Texas Instruments, International journal of information management, vol. 23, 2003, p

431-442

Scheer, A., & Habermann, F.: Enterprise resource planning: Making ERP a success,

Communications of the ACM, 2000, vol. 43, issue 4, p57–61

105

Shanks, G., Parr, A., Hu, B., Corbitt, B., Thanasankit, T., & Seddon, P.: Differences in

critical success factors in ERP systems implementation in Australia and China: Acultural

analysis, Proceedings of the 8th European Conference on Information Systems, 2000, Vienna,

Austria, p537–544

Sheu, C., Yen, H. R., Krumwiede, D.: The effect of national differences on multinational ERP

implementation: an exploratory study, TQM & business excellence, vol. 14, no. 6, Aug. 2003, p

641-657

Stefanou, C. J.: Supply Chain Management (SCM) and organizational key factors for

successful implementation of Enterprise Resource Planning (ERP) systems, Proceedings of

the Americas Conference on Information Systems, 1999, Milwaukee, WI, p800–802

Sumner, M.: Critical success factors in enterprise wide information management systems

Projects, Proceedings of the Americas Conference on Information Systems, 1999, Milwaukee, WI,

p232–234

9.3 Rapporter PLS Rambøll Management, ”IT i praksis 2003”, 2003, 8. årgang, 1. oplag

106

9.4 Hjemmesider

NR. URL Navn Dato

1 http://www.standishgroup.com/sample_research/

PDFpages/extreme_chaos.pdf Standish Group 15-06-06

2 http://www.standishgroup.com/sample_research/

PDFpages/q3-spotlight.pdf Standish Group 15-06-06

3

http://www.it-

cortex.com/Stat_Failure_Rate.htm#The%20Con

ference%20Board%20Survey (2001)

IT-Cortex 15-06-06

4 http://www.standishgroup.com/chaos/beacon_24

3.php Standish Group 15-06-06

5 http://www.sap.com/denmark/company/custome

rsuccess/lego.pdf SAP Danmark 15-06-06

6 http://en.wikipedia.org/wiki/International Wikipedia 15-06-06

7 http://www.lego.com/info/pdf/LEGO_company_

profile_DK.pdf LEGO 15-06-06

8

http://www.grundfos.com/web/homeDK.nsf/Me

nuDocuments/742ACB7D36495C11C1256E4E

0031F156?OpenDocument

Grundfos 15-06-06

9 http://net.grundfos.com/doc/webnet/report2005/

dk/historic.htm Grundfos 15-06-06

10

http://www.grundfos.de/web/homeDK.nsf/vDoc

uments/EDC1664ECFC547E1C1256C1C00461

2BE?OpenDocument

Grundfos 15-06-06

11 http://net.grundfos.com/doc/webnet/report2005/i

mages/selskabsoversigt.jpg Grundfos 15-06-06

12 http://net.grundfos.com/doc/webnet/report2005/i

mages/ledelsesstruktur.jpg Grundfos 15-06-06

13 http://pdf.borsen.dk/pdftmp/08353b9a74eecefcc12702baaea3f72b.pdf

Børsen 15-06-06

9.5 Andet Møller, C., Kræmmergaard, P., Rikhardsson, P., Møller, P., Jensen, T. N., Due, L.: A comprehensive ERP bibliography 2000 – 2004, WP no. 129, The Aarhus school of business, Department of information science, 2004

107

Erhvervsøkonomisk Institut Forfattere: Kandidatafhandling Morten Gunnersen Cand.merc.(dat.) Las Øhlenschlæger Olsen Vejleder: Pernille Kræmmergaard Jensen

Væsentlige kritiske succesfaktorer i globale Enterprise Resource Planning

implementeringer

Bilag

Handelshøjskolen i Århus

2006

Indholdsfortegnelse Bilag 1: Subfaktorer i stand alone ERP implementeringer ...........................................................1 Bilag 2: Subfaktorer i globale ERP implementeringer...................................................................4 Bilag 3: Adviseringsbrev ...................................................................................................................7 Bilag 4: Svarmail LEGO ...................................................................................................................8 Bilag 5: Spørgeramme for LEGO.....................................................................................................9 Bilag 6: Interview hos LEGO..........................................................................................................10 Bilag 7: Slides fra LEGO.................................................................................................................41 Bilag 8: Uddybende svarmail fra LEGO .......................................................................................53 Bilag 9: Spørgeramme for Grundfos..............................................................................................55 Bilag 10: Interview hos Grundfos...................................................................................................56 Bilag 11: Selskabsoversigt – Grundfos...........................................................................................76 Bilag 12: Ledelsesoversigt – Grundfos ...........................................................................................77 Bilag 13: Grundfos præsentation ...................................................................................................78 Bilag 14: Lydfiler fra interviews.....................................................................................................88

Bilag 1: Subfaktorer i stand alone ERP implementeringer Factor 1: Appropriate business and information technology legacy systems

1. Business setting Holland, Light, and Gibson, 1999; Roberts and Barrar, 1992

2. Legacy system Holland et al., 1999 Factor 2: Business plan and vision

1. Business plan or vision Buckhout, Freya, & Nemec, 1999; Holland et al., 1999; Rosario, 2000; Wee, 2000

2. Project mission or goals Roberts and Barrar, 1992; Shanks et al., 2000 3. Justification for investment in ERP Falkowski, Pedigo, Smith, and Swanson, 1998

Factor 3: Business process reengineering (BPR)

1. BPR Bingi, Sharma, and Godla, 1999; Holland et al., 1999; Murray and Coffin, 2001; Roberts and Barrar, 1992; Shanks et al., 2000; Wee, 2000

2. Minimum customization Murray and Coffin, 2001; Rosario, 2000; Shanks et al., 2000; Sumner, 1999

Factor 4: Change management culture and program 1. Recognizing the need for change Falkowski et al., 1998 2. Enterprise-wide culture and structure

management Falkowski et al., 1998; Rosario, 2000 3. User education and training Bingi et al., 1999; Holland et al., 1999, Murray

and Coffin, 2001; Roberts and Barrar, 1992; Shanks et al., 2000

4. User support organization and involvement Wee, 2000

5. IT workforce re-skilling Sumner, 1999 6. Commitment to change—perseverance Shanks et al., 2000

and determination Factor 5: Communication

1. Targeted and effective communication Falkowski et al., 1998; Wee, 2000 2. Communication among stakeholders Holland et al., 1999; Shanks et al., 2000 3. Expectations communicated at all levels Holland et al., 1999; Rosario, 2000; Shanks et

al., 2000; Sumner, 1999 4. Project progress communication Holland et al., 1999; Sumner, 1999 5. User input Rosario, 2000

Factor 6: ERP teamwork and composition

1. Best people on team Bingi et al., 1999; Buckhout et al., 1999;

1

Falkowski et al., 1998; Rosario, 2000, Shanks et al., 2000; Wee, 2000

2. Balanced or cross-functional team Holland et al., 1999; Shanks et al., 2000; Sumner, 1999

3. Full-time team members Shanks et al., 2000 4. Partnership, trust, risk-sharing, and Stefanou, 1999; Wee, 2000

incentives 5. Empowered decision makers Shanks et al., 2000 6. Business and technical knowledge of team Bingi et al., 1999; Shanks et al., 2000; Sumner,

members and consultants 1999 Factor 7: Monitoring and evaluation of performance

1. Track milestones and targets Murray and Coffin, 2001; Roberts and Barrar, 1992; Rosario, 2000; Sumner, 1999

2. Performance tied to compensation Falkowski et al., 1998 3. Analysis of user feedback Holland et al., 1999

Factor 8: Project champion

1. Existence of project champion Shanks et al., 2000; Stefanou, 1999; Sumner, 1999

2. High level executive sponsor as champion Falkowski et al., 1998; Murray and Coffin, 2001 3. Project sponsor commitment Rosario, 2000

Factor 9: Project management

1. Assign responsibility Rosario, 2000 2. Clearly establish project scope Holland et al., 1999; Shanks et al., 2000 3. Control project scope Rosario, 2000; Shanks et al., 2000 4. Evaluate any proposed change Sumner, 1999; Wee, 2000 5. Control and assess scope expansion Sumner, 1999

requests 6. Define project milestones Holland et al., 1999 7. Set realistic milestones and end dates Murray and Coffins, 2001; Shanks et al., 2000 8. Enforce project timeliness Rosario, 2000 9. Coordinate project activities across all Falkowski et al., 1998

affected parties Factor 10: Software development, testing, and troubleshooting

1. Configuration of overall ERP architecture Wee, 2000 2. Appropriate modelling Murray and Coffin, 2001; Scheer and

methods/techniques Habermann, 2000 3. Vigorous and sophisticated testing Rosario, 2000 4. Troubleshooting Holland et al., 1999 5. Integration Bingi et al., 1999

2

Factor 11: Top management support 1. Approval and support from top Bingi et al., 1999; Buckhout et al., 1999; Murray

management and Coffin, 2001; Shanks et al., 2000; Sumner, 1999

2. Top management publicly and explicitly Shanks et al., 2000; Wee, 2000 identified project as a top priority

3. Allocate resources Holland et al., 1999; Roberts and Barrar, 1992; Shanks et al., 2000

3

Bilag 2: Subfaktorer i globale ERP implementeringer53

Factor 1: Appropriate business and information technology legacy systems

1. Business setting Huang et al., 2004 2. Legacy system Light, 1999

Factor 2: Business plan and vision

1. Business plan or vision Madapusi et al., 2005; Sheu, 2003 2. Project mission or goals 3. Justification for investment in ERP Sarkis et al., 2003 4. Alignment of business and ERP strategy Huang et al., 2004; Light, 1999; Madapusi et al.,

2005; Sarkis et al., 2003; Sheu et al., 2003 Factor 3: Business process reengineering (BPR)

1. BPR Ghosh, 2002; Hanseth et al., 2001; Hill et al., 2001; Huang et al., 2004; Sarkis et al., 2003

2. Minimum customization Ghosh, 2002; Hanseth et al., 2001; Huang et al., 2004; Light, 1999; Sarkis et al., 2003

Factor 4: Change management culture and program

1. Recognizing the need for change Ghosh, 2002; Hill et al., 2001 2. Enterprise-wide culture and structure Hanseth et al., 2000;

management 3. User education and training Ghosh, 2002; Huang et al., 2004; Light, 1999;

Sarkis et al., 2003; Sheu et al., 2003 4. User support organization and involvement Ghosh, 2002; Hanseth et al., 2000; Hill et al.,

2001; Sarkis et al., 2003 5. IT workforce re-skilling Hill et al., 2001; Sarkis et al., 2003 6. Commitment to change—perseverance Ghosh, 2002; Hill et al., 2001; Huang et al.,

and determination 2004; Light, 1999; Sarkis et al., 2003 Factor 5: Communication

1. Targeted and effective communication Ghosh, 2002; Hanseth et al., 2000 2. Communication among stakeholders Huang et al., 2004 3. Expectations communicated at all levels Hanseth et al., 2000 4. Project progress communication 5. User input 6. Communication among different cultures Ghosh, 2002; Hanseth et al., 2000

53 Faktorerne markeret med fed skrift indikerer de tilføjede faktorer i forhold til Nah et al.’s (2003) undersøgelse.

4

Factor 6: ERP teamwork and composition 1. Best people on team Ghosh, 2002; Huang et al., 2004; Madapusi et

al., 2005; Sarkis et al., 2003 2. Balanced or cross-functional team Ghosh, 2002; Huang et al., 2004 3. Full-time team members Huang et al., 2004; Sheu et al., 2003 4. Partnership, trust, risk-sharing, and incentives Ghosh et al., 2003 5. Empowered decision makers Hanseth et al., 2000; Huang et al., 2004 6. Business and technical knowledge of team Ghosh, 2002; Huang et al., 2004; Light, 1999;

members and consultants Sheu et al., 2003 Factor 7: Monitoring and evaluation of performance

1. Track milestones and targets Sarkis et al., 2003 2. Performance tied to compensation 3. Analysis of user feedback

Factor 8: Project champion

1. Existence of project champion Ghosh, 2002; Madapusi et al., 2005; Sarkis et al., 2003

2. High level executive sponsor as champion Ghosh, 2002; Madapusi et al., 2005 3. Project sponsor commitment Madapusi et al., 2005; Sarkis et al., 2003

Factor 9: Project management

1. Assign responsibility Huang et al., 2004; Sheu et al., 2003 2. Clearly establish project scope Ghosh et al., 2003; Hill et al., 2001; Huang et al.,

2004; Madapusi et al., 2005 3. Control project scope Ghosh, 2002; Huang et al., 2004; Madapusi et

al., 2005; Sarkis et al., 2003 4. Evaluate any proposed change Ghosh, 2002; Sarkis et al., 2003 5. Control and assess scope expansion requests Ghosh, 2002; Sarkis et al., 2003 6. Define project milestones Huang et al., 2004 7. Set realistic milestones and end dates Huang et al., 2004 8. Enforce project timeliness Madapusi et al., 2005 9. Coordinate project activities across all Ghosh, 2002; Huang et al., 2004

affected parties 10. Metanational advantages Ghosh, 2002; Ghosh et al., 2003

Factor 10: Software development, testing, and troubleshooting

1. Configuration of overall ERP architecture Ghosh, 2002; Madapusi et al., 2005; Sarkis et al., 2003

2. Appropriate modelling methods/techniques Ghosh et al., 2003 3. Vigorous and sophisticated testing 4. Troubleshooting 5. Integration Ghosh, 2002; Hanseth et al., 2000; Huang et al.,

2004; Sarkis et al., 2003

5

Factor 11: Top management support 1. Approval and support from top management Hill et al., 2001; Huang et al., 2004; Light, 1999;

Sarkis et al., 2003; Sheu et al., 2003 2. Top management publicly and explicitly Huang et al., 2004; Light, 1999; Sarkis et al.,

identified project as a top priority 2003; Sheu et al., 2003 3. Allocate resources Light, 1999

Factor 12: Politics

1. Government/corporate politics Sheu et al., 2003 2. National rules and demands Ghosh, 2002; Hanseth et al., 2001; Sheu et al.,

2003 Factor 13: Culture

1. General culture Ghosh, 2002; Huang et al., 2004; Sheu et al., 2003

2. Corporate culture Hanseth et al., 2001; Huang et al., 2004; Sheu et al., 2003

3. Technical Sheu et al., 2003

6

10 Bilag 3: Adviseringsbrev Virksomhed Århus den 20. april 2006 Gade og nr. Postnr. og by Att.: IT direktør navn

Vi er to cand.merc.(dat.) studerende fra Handelshøjskolen i Århus, der er i gang med at skrive vores

afsluttende hovedopgave på studiet. Vores emne for opgaven er implementering af ERP systemer –

nærmere bestemt: Hvad er de væsentlige kritiske succesfaktorer i en global ERP implementering?

Vi henvender os derfor til Dem, da virksomhedens navn har foretaget en global ERP implementering

indenfor de sidste 5-6 år. Netop det globale aspekt er det centrale i vores hovedopgave, hvilket gør

virksomhedens navn interessant for os.

I denne forbindelse ønsker vi at foretage et interview med en person i virksomheden, der har haft en

central rolle i forbindelse med den globale implementering af Jeres ERP system. Vi håber på at

interviewet kan finde sted medio maj 2006.

Vi vil tillade os at kontakte Dem sidst i uge 17, for at høre nærmere om muligheden for Deres

deltagelse.

Ønsker De yderligere information inden da, er De meget velkommen til at kontakte os.

Med venlig hilsen

Las Øhlenschlæger Olsen Stud.merc.(dat.) Mail: las_o@stofanet.dk Mobil: 2272 5000

Morten Gunnersen Stud.merc.(dat.) Mail: mg@skjoldhoej.dk Mobil: 6168 1500

7

11 Bilag 4: Svarmail LEGO Mail fra Henrik Weis Aalbæk, omkring deltagelse i vores undersøgelse, herunder hans baggrund hos LEGO – modtaget d. 25. april 2006 Hejsa Jeg har via Jan Amtoft modtaget beskrivelsen af jeres hovedopgave.

Jeg stiller gerne op til interview i denne sammenhæng.

Mine forudsætninger for at gøre dette er:

• Jeg sidder som leder afdelingen Enterprise Architecture med reference til Jan. Vi har det

forretningsmæssige ansvar for globale strukturer, processer og masterdata.

• Har været i LEGO Koncernen siden 1987.

• Har været med i alle vores 3 implementeringer (d.v.s. standalone, 1. forsøg i centralisering,

LEGO Light / Planning2 play hvor vi lavede den "rigtige globale løsning"

• Jeg var teamlead med ansvar for arkitektur, finansmodel og masterdata for den globale løsning

• Kommer oprindeligt fra finance - via 5 år i CH som direktionsassistent – tilbage til

ledergruppen i finans - via et par store projekter til Enterprise Architecture.

• Jeg er ikke tekniker - så hvis i vil vide noget om servere, netværk og andet isenkram skal i have

fat i en anden.

• Er foriøvrigt ikke selv cand. Merc men HA + HD-R

Vil i foreslå nogle datoer - så skal jeg vende tilbage med et forslag til tidspunkt - jeg forventer at vi

kommer langt på 1 - 1½ time.

Jeg ser frem til at høre fra jer.

Henrik Weis Aalbæk

Director, Enterprise Architecture

8

12 Bilag 5: Spørgeramme for LEGO - Baggrundsspørgsmål:

o Informantens baggrund og rolle i den nationale og globale ERP implementering54 o Præsentation af deres ERP implementering og udrulning

Udrulningen af ERP systemet Lande og moduler Central/decentral styring Top-down el. bottom-up Graden af integration og samarbejde på tværs af afdelinger Motiver bag ERP implementeringen

• Forretningsmæssige • Økonomiske

- KSF’erne i den globale implementering: o Væsentlige fokuspunkter i forbindelse med global ERP implementering

Appropriate business and information technology legacy systems Business plan and vision Business process reengineering Change management culture and program Communication ERP teamwork and composition Monitoring and evaluation of performance Project champion Project management Software development, testing, and troubleshooting Top management support Culture Politics

o Udfordringerne i en global implementering Stand alone vs. global implementering

- Succesbegrebet: o Succesopfattelse af den globale ERP implementering

Succeskriterier for vurdering af implementeringen • Økonomiske/hårde/målbare kriterier • Bløde kriterier

o Medarbejder-/stakeholdertilfredshed Personer involveret i opstilling og vurdering af disse kriterier

- Afsluttende spørgsmål: o Er der noget vi ikke har været inde omkring, som du mener, kunne være interessant for

vores opgave?

54 Henrik Weis Aalbæk havde oplyst om disse forhold i en forudgående mail, hvorfor vi under interviewet ikke spørger ind til dette. Se bilag 4.

9

13 Bilag 6: Interview hos LEGO Transskribering af interview med Henrik Weis Aalbæk fra LEGO d. 10. maj 2006. Lydfilerne til dette interview er vedlagt i bilag 14. HWA: Henrik Weis Aalbæk MG: Morten Gunnersen LØO: Las Øhlenschlæger Olsen Lydfil 1 LEGO MG: Men altså, vi ku’ meget godt tænke os…, hvis du ku’ starte sådan lidt ud med at fortælle os om

Jeres implementering… hvordan I har gjort det. HWA: Ja, altså vi ku’ egentligt gøre det… hvis jeg må ta’ det som en, det jeg vil kalde en tiårig

evolution. Vi startede i egentligt i ’94, hvor jeg implementerede i vores schweiziske selskab inden SAP var blevet sådan et globalt corporate… platform, men mere sådan en stand alone.

Ophold i interview, hvor HWA henter pc med slides Lydfil 2 LEGO 0:00:00 HWA: … organisationen og hvad er formålet, og hvorfor har vi implementeret SAP tre gange… jeg vil

nok være meget dømmende også, lige sagt til Jeres båndoptager, jeg vil nok være meget dømmende på noget af det vi gjort. Men man skal lige huske, at dømmer selvfølgelig historien på sin tidsakse. Dvs. at den viden vi havde i 1995, var altså en anden viden vi hvad i 2001. Vi har egentligt dybest set implementeret SAP tre gange, altså tre filosofier.

… 0:01:04 HWA: … jeg så lige Egmont… den der bladudgivelsesting… de har lige stoppet deres. Det får SAP

sikkert nogle slag for. Jeg har den holdning at, jeg har ikke aktier i SAP, men altså det er typisk implementeringsmetoden, ambitionerne og viden der dræber det. Det er sjældent softwaren i sig selv. Software er jo bare et stykke software. Den kan jo ikke ødelægge noget i sig selv.

… 0:02:24 HWA: Det der er, når I kigger på en ERP implementering, der er altså, hvad vil man opnå og hvor er

organisationen henne i forhold til det man vil opnå. Har man en organisation som vi havde frem til, jeg startede i 1987, der havde vi en meget autonom organisation, sådan en procesplatform.

10

Og så i 1987 der var det jo altså ikke så hot som det er nu. Der var hver enkelt land, hvert et selskab, var sådan ligesom sin egen. De valgte hvad de ville ha’, de lavede den kontoplan de ville ha’, de kørte med de varenumre… de kørte med det de ville.

Der var en snært af integration indenfor fabrikkerne og enkelte salgsselskaber havde fundet ud af at holde sammen, men ellers var det meget sådan noget Silvan – gøre det nemt at gør’ det selv… med den viden vi har nu, er det jo fuldstændigt galt ik’, men omvendt, dengang der fandtes der ikke globale applikationer, der fandtes ikke netværk der ku’ bære det, uden det kostede spidsen af en jetjager. Så med den viden og den teknologi der var dengang, så var det nok ikke helt ved siden af. Med nutidens briller lyder det fuldstændigt ude i hampen.

HWA: Så sker der det, at vi begynder i LEGO at implementere SAP. Det gør vi omkring ’94. Det

bliver gjort to steder. Det bliver gjort i vores danske salgsselskab, som er fusioneret ind og slet ikke findes mere, som en modvægt til et stort 40 mands selvudviklet projekt, altså udvikler selv ERP lignende platform til vores europæiske salgsselskaber – et projekt der hed IBIS… Schweiz, hvor jeg sad som direktionsassistent, hvor vi valgte ud fra en evaluering med et schweizisk produkt vi havde i forvejen, SAP og så et tredje jeg faktisk ikke kan huske hvad det hedder og kom fra, valgte vi rent faktisk at køre SAP. På det tidspunkt var SAP ikke en platform. Det var ikke LEGOs ERP platform, det var et, jeg var i et tysksproget område tæt på… der var SAP sådan et ikke… det gik vi i gang med. Det vi implementerede først, som jeg kommer tilbage til på en af de næste slides, det var egentligt bare at ta’ den filosofi vi havde om, at alle selskaber var deres egen og sig selv… ligger vi bare SAP ind til dem alle sammen… så laver vi det lige så forskelligt som vi er i stand til. F.eks. det italienske. Jeg glemmer aldrig forsiden på det der hedder LEGO review, som var vores personaleblad dengang der i midt 90’erne, billedet af en stor pizza fyldt med glade italienere: Yes vi fik alle vores specialønsker opfyldt. Det var mantraen. I kan godt høre, at det er ikke der vi kommer fra nu, men det var mantraen og det fortsatte så op gennem 90’erne.

0:04:29 HWA: Så skete der det, at vi begyndt på krisen. Vi opdagede også, at i og med at de enheder kørte så

autonome, så kunne vi ikke se lagrene. Der kunne godt ligge en masse af den her City Police her (viser en kasse LEGO). Dem ku’ vores daværende tyske direktør godt have 100.000 på lager af, som han ikke ku’ sælge og de manglede den i Italien eller Frankrig eller i… det er ligegyldigt. Efter julesæsonen, når man tæller lagrene op opdager man: Hold da kæft, der er en masse vi ikke fik solgt. Så begyndte man at lave det der hed SAP Backbone, det kom der sådan lige omkring 95-96. Der tænkte vi, nu laver vi en integreret logistik backend. Salgsselskaberne ligger stadig hvor de ligger, men vi tager varerne fra dem. Vi lavede sådan en central SAP løsning, hvor vi på en fælles server i Billund alle lagrene. Det vi gjorde forkert – jeg var lige kommet hjem fra Schweiz dengang – det vi gjorde forkert, jeg var ikke med i projektet, det var ikke for at undskylde, men det vi som organisation gjorde forkert, det var selvfølgelig at vi samlede, altså lavede vi foreningsmængden af alle de der stand alones ønsker og så prøve at lægge det ind. Det var skide svært, det var pløk umuligt. Hvad gjorde vi så? Det var logistik der drev projektet. De fravalgte jo alt integration. De fravalgte bl.a. – jeg sad i ledergruppen af økonomi dengang – de fravalgte økonomiintegrationen. Hvor sjovt er det så at køre ERP platform. Det blev noget forfærdeligt juks. Vi havde ikke styr på masterdata, med varenumre –

11

det er der jeg bruger meget af mit liv lige nu – de underliggende strukturer var simpelthen ikke gode nok.

0:05:41 – Slide The latest decade – the “management phases” HWA: Det der lige skal siges det var, at det skete i forlængelse af, at Keld Kirk, vores ejer og

hovedaktionær, han var syg… han var væk fra virksomheden i 7, 8, 9 måneder. Da han kommer tilbage i 95 – jeg var stadig i Schweiz på det tidspunkt – tænkte han: det er ikke sjovt nok at være legetøjsdirektør, så han startede noget det hedder, han kaldte det Compass Management, noget med noget kompas og retninger… Det gik så for langsomt for organisationen at ændre sig… Jeg mener stadig, at intentionen var rigtigt, der var bare ikke sat magt og ledelse bag ordene. Så kom speeding up, det er selvfølgelig et klassisk trick, når tingene går for langsomt, så kører vi op i gear. Parallelt med det her, var vi altså ved at rulle ud på den der centrale, altså evolution 1 lå heroppe (se øverst slide 9-11). Lige nu her i fase to, evolutionstrin 2, der har vi fælles cluster her i Billund, men stadig med foreningsmængden med en masse… og intet centralt ansvar. Forfærdeligt rod vil jeg sige bagefter. Vi var også ved at tabe det hele, vi var lettere ude af kontrol. Så skete der det, vi havde vores bedste år i 1993, altså rent økonomisk. Siden da gik det bare nedad… siden ’99 er vi så på vej opad igen.

0:07:06 HWA: I oktober ’98 ansætter Keld så Poul Plougmann. Det har I sikkert fulgt lidt med i dagspressen.

Der er sikkert skrevet mange cases på Handelshøjskolen om det. Han går ind, her hvor Keld har prøvet det her – det er mine ord det her, ikke Kelds, altså han prøver sådan at vække os: Nu må I simpelthen lade være med at sidde der og småsove… Nu prøver vi altså lige… fyrede 25 % af samtlige medarbejdere (slide 9: management structural changes). Det er mange – 1200 mennesker, de var så ikke funktionærer alle sammen. Det vi også gør, det er at vi begynder at regionalisere. Hvor vi før havde et salgsselskab, som en hel selvfungerende enhed med direktør, økonomichef, salgschef, logistikchef etc. i alle lande, så lavede vi nu en der hed Europa syd f.eks. Der samlede vi Frankrig, Spanien og Portugal og Italien. Ud over at vi havde haft bøvlet med den her platform, der var forskellig – der sad der trods alt dem der havde været med til at lave den og kunne finde sig selv en lille smule i det – nu var det hele samlet i Milano, så nu sad der lige pludselig nogle i Italien og skulle finde ud af var det de mente dem i Frankrig og i Portugal og i Spanien. Det blev svært, rigtig, rigtig, rigtig svært.

0:08:05 HWA: Derfor startede vi mandagen efter stormen i ’99, noget der hedder LEGO Light, som jeg vil

fortælle en del om. Det er så egentligt vores tredje evolution, det er den vi er på nu. Hvis jeg skal sige, den korte version, så har vi haft total stand alone, men meget drevet af, at det var sådan vores organisation og organisatoriske selvforståelse var: Jeg hedder Gerd Breide, jeg er direktør for LEGO GmbH i Tyskland. Jeg hedder… sådan var mantraen. Det har jo fungeret godt indtil nu, hvorfor sku’ man lave om på det. Når tallene begynder at blive røde her nede, så fungerer det bare ikke godt nok. Hvad der så sker efterfølgende er så, at vi i LEGO Light implementerede en del af værdikæden og Planning2play – det er vores, det er jo intern brug det her, er så der vi kørte SAP ind i distribution, jeg skal nok komme tilbage til nogle detaljer på det.

12

0:08:49 HWA: Det vi gør her: vigtige ord, meget vigtige ord (slide 9, 2. spalte: STANDISERING OG

GLOBALISERING, red.). Og her, sæt hele værdikæden sammen. Vi er nu faktisk så integreret, at jeg er begyndt at blive bange for det. Voldsom integration det svarer til at skille en automatgearkasse ad – et lille bitte tandhjul så virker intet! Det er lidt der vi er nu. Ikke fordi det er dårligt, vi er der, hvor mange misunder os at ville være.

0:09:08 HWA: Der blev et antal regioner. Nu nævnte jeg lige Europa Syd. Vi har også Europa Central, som

bestod af… Tyskland, Østrig og Schweiz på det tidspunkt. Europa Nord, som var Skandinavien og så Norge og Sverige, Finland, England, Belgien, Holland. America som bestod af Nordamerika. Parallelt med det lavede vi nogle administrative centre. Al økonomi skulle styres fra nogle enklaver.

… 0:09:39 slide 10 HWA: Det er meget vigtigt når man snakker ERP, hvor er organisationen henne, hvad er det man vil

opnå? Det vi ville opnå, altså, det vi gjorde i starten, som jeg har en slide, jeg desværre ikke kan finde lige for tiden, fra den 31. 8. 1998… Kjeld Møller Pedersen – HR og finansdirektør. Ham der er sundhedsprofessor… De kom her i, det må være i ’97. De besluttede engang i ’97, at nu er SAP vores ERP platform… Vores daværende direktør… Jeg skrev til dem: det var da godt nok dygtigt, nu har I taget 2 % af beslutningen. Det gir da ikke en bønne, hvad der står på logoet når du logger ind… Hvad er det vi vil med det. Hvis vi ikke gør det med masterdata og standardprocesser, så lad være med at rulle det yderligere ud. Det var altså inden LEGO Light, det var sådan der i mellemfasen. Det vi stod med dengang det var – og noget af det her er set sådan i bagklogskabens klare lys. Jeg vil ikke få det til at lyde som om, at det her var noget vi stod og var meget bevidst om… men nu ser vi lige fortiden igennem nutidens optik ik’.

0:10:26 slide 10 – legoklodserne HWA: … men her havde vi den her (rød klods) Lokal ledelse, processer og systemer… Sidst i 90’erne

(gul klods) nu fik vi global ledelse med lokale processer og systemer. Det vi gerne vil nå er det der (grøn klods – global ledelse, processer og systemer). Jeg ved godt det lyder lidt populistisk, men altså jeg er ikke konsulent, men det må I lige tilgive mig ik’ os’.

0:10:39 slide 11 HWA: Lige SAP filosofien. Det er den her slide der er lidt vigtig for Jer. Hvis vi kigger på vores

evolutionstrin… Det vi havde var stand alone boxes, landespecifik set-up, ingen standard, lokalt styret. Vi havde seks konsulentfirmaer også – forskellige konsulentfirmaer. Hvis I nogen sinde har mødt de der SAP konsulenter, de har jo alle samme deres egen religion. Enten fordi deres intelligens er på et eller andet niveau, eller fordi de fokuserer på noget bestemt. Der er meget forskel på, om du tager PA eller SAP Danmark eller IBM. Ikke at den ene er bedre end den anden, de er bare forskellige.

13

HWA: Så lavede vi den her central hardware (slide 11). Foreningsmængden af lokale set-up. Ingen eller nogen standard og ledelse, var der ikke så meget af på det her. Så kommer den her med LEGO Light ik’ hvor vi gør. Altså det her vi har, det er ikke populistisk – det er sådan. Jeg gik hverken ud i præsalg eller postsalg arbejde. Det vi så gjorde, det var at lave det her LEGO Light. Og det vi ville… vi har globaliseret vores processer og vores masterdata – og så noget meget meget vigtigt I skal skrive I Jeres rapport! Den der, den skal I simpelthen ha’ på hver, syv gange på hver side, i hvert fald hvis jeg var censor (slide 13 ordet SIMPLIFY). En ERP platform ka’ en million milliard ting. Uanset om I tager SAP eller Navision eller Baan eller Oracle eller JD Edwards eller… der skal I bruge lige præcis de 7 % der er vigtige. Ligesom I sidder og roder med Word og Excel. Det har simpelthen så mange knapper man ikke skal bruge til noget ik’ os’. Kunsten er lige at finde de syv man hele tiden skal bruge. Og så havde vi, men det var lige så meget det interne drevne af vores organisation, vi havde flyttet så meget rundt på folk… vi havde et vidensissue – vi sku’ ha’ løftet viden… er vi for øvrigt stadigvæk. Jo mere man integrerer, jo mere viden kræver det, er det gået op for os.

0:12:16 HWA: Og hvorfor gør man det her? Godt spørgsmål, ikke nødvendigvis med vores svar, men hvorfor

ERP, som var Jeres opgave. Simpelthen spørge ledelsen, hvad er det I vil? I IBM, da de var her før: Er det lige som i gamle dage man sagde i 90’erne? Hvis du køber IBM, så er du, det kan aldrig gå galt… eller så var det i 80’erne… Implementerer en virksomhed SAP fordi, at det gør alle de andre, det må jeg også hellere gøre. Det hørte jeg nede i country clubben eller på golfbanen: Lad mig komme hjem og købe noget SAP ik’? Altså, der er noget psykologi i det her også, og nogle gange også nogle mærkelige? andele. Det vi sagde her med et LEGO Light program, hvorfor vi. Det har ikke noget med nytte af at implementere SAP, det er hvorfor vi gør det tredje gang – vælger at bruge et ikke uvæsentligt tocifret millionbeløb, hvor vi for øvrigt fravalgte SAP og valgte Oracle ind imellem... Det gjorde Plougmann for øvrigt ved os. Jeg var dybest set uenig i beslutningen, specielt når man finder ud af, at det ikke virkede, jeg sad meget centralt i projektet. Det var rigtigt, det han gjorde at sige: Her er en organisation med en platform der ikke virkede… hvor nogen var vigtige, fordi de ku’ dreje… ik’ vigtig for organisationen, hvis man kan noget teknik som ingen skal bruge til noget. Nu prøver vi at skifte – meget klassisk CEO trick – nu skifter vi lige platform, så ser vi hvem der står. At han så valgte Oracle ABSA og det ikke duede, det er så en anden historie… det var jo ikke fordi vi ville tilbage og køre SAP. Fra det blev valgt og så de næste otte måneder, hvis vi sagde SAP, så blev vi fyret. Det mandede vi os op til at gøre til sidst nogle af os, gå ind og sige, det her det er simpelthen ikke godt nok. Vi kunne ikke få taget en salgsordre, det er ikke en uvæsentligt funktionalitet.

0:13:35 HWA: Men hvorfor vi kører LEGO Light, hvor vi kører tredje implementering. Man kan sige første

implementering, det tror jeg var forkort. Det var fordi vores ledelse troede, ved at vælge et standardsoftware… Vi havde ikke gennemskuet, vi køber en kæmpe stor skal, en kæmpe værktøjskasse, som vi skal tage det rigtige i brug af. I fase ét der opnåede vi faktisk ikke ret meget andet end at vi fik brugt… og bygget noget SAP viden op. I skud to, der havde vi fundet af nogle ideer med at hænge værdikæden sammen. Hvem der skulle standardiseres lidt, ellers kunne de ikke finde ud af det… og så i skud tre, der var det egentligt ved at gå op for mange af

14

os – der vil jeg godt have lov at spille hellig, for der sad jeg sådan set at råbte og skreg om at køre noget vi kaldte… global finance repair og alt muligt, forsøgte på at standardisere. Men det er bare det, når en ERP platform har kørt længe og mange har pillet i den, så er det Søren Jensemig svært at få det sat rigtigt sammen. Bare det at finde ud, hvad du har, er altså en udfordring, som kræver et intellekt som… det kan godt være at nogen kan, men vi kunne i hvert fald ikke.

0:14:23 HWA: Hvorfor så LEGO Light, hvorfor tredje gang? Det var simpelthen fordi, det der skete… fra

vores ledelse, altså Poul Plougmann og hans 13 direktører… sad og kunne ikke engang finde ud af, hvor mange varer vi havde solgt. Vi kunne sidde på et ledermøde om Europa Syd og sige: Har vi solgt 400 millioner, så siger vi, vi har solgt 400… du er ansvarlig for det ”jeg har solgt 500 millioner (mange huller, men budskabet er, at alt efter hvem man spurgte, kom de med forskellige salgstal for den samme region). Det var på det plan. Jeg var der ikke selv, selvfølgelig, men min chef, de topfolk der sad derinde, han sagde, da han kom ud, han var sikker på at aaargh… (frustreret over de forskellige tal)… Det der skete, ledelsen, fordi de fik de forkerte tal – de ved ikke noget om masterdata og processer. De ku’ bare se de tal vi får… vi kan lige så godt rafle, og det var egentligt der, det var det der startede LEGO Light og tredje implementering. Der var mange andre ting der ville have tvunget os til det. Vores leverings… det var ved at falde fra hinanden under fødderne på os. Varer kom ikke ud eller retur, eller os’ så som de ud to gange. En masse dumme ting. Vi skal også lige huske at der er noget der hedder Euro… plus vi kørte en 3.1 H version, der sku’ opgraderes… så der var sådan forskellige ting der bankede på, og det går man jo ikke ind til sin topledelse om…

0:15:22 HWA: … det vi sku’ ha’, det var netop rationalet og det at vi havde lavet de her regioner. Det var

simpelthen blevet for fragmenteret… Vi skal lavet noget, der ku’ hjælpe med at centralisere. Det vi jo godt vidste nogle af os, jeg sad i økonomi dengang… vi lavede et administrativt center i Schweiz og et i London og et i Milano. Ikke for at være kynisk men det hele er i Billund nu alles zusammen. Vi havde nu ikke kunnet samle det hurtigere, da det ikke måtte falde fra hinanden bag ved os… dataproces og ikke besluttede på et tidspunkt – altså så kyniske var vi ikke, man vi ku’ bare se, ok, hvis vi lige lukker øjnene… hvis vi skal bruge flere penge, hvad er så det næste… det vi havde centraliseret, det ku’ dårligt nok bære… derfor når I skriver Jeres opgave, når I interviewer andre, eller sidder og grubler over det med hinanden, spil ledelse og sig: Hvad vil vi opnå med at køre ERP? Hvis alle bare siger: jamen, det gør alle de andre – fint nok… så det lige en om’er ik’!

0:16:15 HWA: Det vi så valgte at sige… det var det her, der ligesom ramte os, det var det ledelsen sagde… Jeg

kan stadig huske det møde, det skete på… det var det her de ville ha’ (slide 15), de ville ha’ noget information. Konsistent, relevant, pålidelig og så skal vi ha’ det hurtigt. Konsistent betyder, hvis jeg kigger på min omsætning i mit koncernregnskab… og hvis jeg åbner min salgsrapport ned og kigger på Europa Central og kigger over i min ledelsesrapport, så er det stadigvæk det samme tal. Det der viste sig, det var, at vi var ikke engang enige om, hvad ordet omsætning bestod af – og også rabat… men typisk, at de store problemer ligger i de nemme

15

løsninger. Altså, lad os nu lige blive enige om, hvad er salget. Er det i bruttosalg, før eller efter rabatter, og hvilke rabatter der skulle med. Så vi er kloge… Det der, det var rent semantik. Vi kørte det i nogle måneder… jeg var med i projektgruppen hen mod ’99. Det vi lavede det var en ordbog. Varenummer – vi havde 10 eller 12 ord for ordet varenummer. Det var meget forskelligt, hvad folk lagde i det. Den vildeste det var vores indkøbsafdeling. Uanset hvad de fik i hænderne, så var det et Edb-nummer. Det var nok det mest tåbelige at kalde noget. Alle numre er da Edb-numre. Det var så et Edb-nummer, det var deres revision på det. Nogle kaldte det en værdigvare. Så det er en færdigvare, jamen hvis det er en færdigvare, hvad er det her så? (her viser han en æske med LEGO og en enkelt klods). Det var i hvert fald ikke en færdigvare. Og sådan kan man blive ved, så derfor – vi lavede ordbog. Så da vi lavede LEGO Light, hvor vi reimplementerede alle kontinenter minus Afrika. Der bøvlede vi faktisk stadigvæk med den der – slide 15. Det der var hele headlinen med det her, det var simplicity. Det vil jeg lige illustrere med én ting, og så får I lov at spørge.

0:17:54 HWA: Når vi lavede noget mindset… Vi kom fra basic… (slide 16 – Stig Toftgaards originaltegning,

der døde på en løbetur i USA sidste år). Leder af US America siden sept. 2003). Det var ham der var som lå som leder her. Han siger: vi kommer nok fra noget der virkede, for LEGO har tjent mange, så et eller andet er der gået rigtigt. Så kan vi begynde at raffinere på det her – så ku’ vi selv være den del af at sidde at, du skal lige regne på den sidste pico promille, komma, smart ik’? Og så har vi fået non-management – ledelsen som svigtede, så har vi kaos. Det her var de budskaber han gik til Poul Plougmann og topledelsen med (slide 17). Mindset er at LEGO er meget komplekst. Niks, LEGO er meget simpelt! Den med italienerne: we are something special here - fuck (refererer til deres blad og pizzaen ca. 4 min) Vi er alle globale, hvor svært kan det være!? Jeg ved godt det er meget populistisk, men det har simpelthen båret mig de sidste syv år det der. Siden oktober ’99, lige omkring år 2000.

0:18:36 HWA: slide 18. Vi vil fra data kaos til noget konsistens information. Vi vil fra komplekse processer –

jeg vil ikke sige vi har simple processer. Vi har fået simplere end vi var før. Men at drive en koncern af vores størrelse, med 100.000 kunder og temmelig mange varer fordelt på mange geografiske lokationer. Det er jo ikke simpelt i ordets bogstaveligste forstand, men det gælder om at gøre det så enkelt som muligt. Så skal vi fra simple til globale løsninger… (Fremefter slide 19) ikke koncentrere dig om defence speaches, hvis du kommer fra corporate – i stedet for at vi skal ud og forklare dem hvorfor det skal være sådan, så kommer vi og siger: jamen sådan er det, så skal de forklare os hvorfor det skal være specielt. Bare lige vende bevisbyrden, og det ku’ vi gøre fordi vi fik et mandat. Meget vigtigt når man skal implementere ERP – specielt hvis det skal være globale standarder. Få et mandat fra topledelsen, ellers så får du simpelthen en i ryggen… afhængig af hvor brutale de er derude. Jeg har aldrig haft et mandat ala det vi havde. Poul stillede sig op og sagde til ledergruppen: hvis I er uenige med projektgruppen, så er I uenige med mig. Det var også ham de kaldte den smilende dræber her, men det havde folk en vis… Det kan godt være at frygt er dårlig, men vi brugte det virkelig til en hjælp… funktionen var klar. (slide 21) Det hele startede med at de havde tabt troen… langt ind for at få fat i den… og så skal man passe på. (-> slide 22) Vejen til sejr her, det er sådan meget populistisk. Hvad er det vi vil ha’ og hvor fleksibelt skal det være (nederste rød klods)? Noget er også er vigtigt når

16

vi snakker ERP – hvilken struktur bygger den på. Vi tænkte heldigvis var der lavet økonomistruktur på det vi har nu, der ville komme mange omorganiseringer, vi har omorganiseret en gang i kvartalet siden da, hvordan får du din historik med eller kan du lave en George Orwell ligesom i 1984 eller kan du omskrive historien til nutiden eller hvordan får du… Der er ikke noget værre, hvis du vil bevare din troværdighed, så skal du også kunne håndtere din historik. Hvad med scenarier, hvad vej kan vi gå, hvilke modeller, altså det er alle mine kæpheste. Man skal have nogle modeller, man kan kommunikere til folk. Teamet: stor nok til at løse opgaven, lille nok til at være effektive. Standardpåstanden i de der ERP implementeringer… kommer til at mangle ressourcer. Fint, nu skal jeg lige fortælle hvilke 30 % vi ikke skal ha. Der bliver typisk pakket alt muligt rundt om, der fjerner fokus fra det der i virkeligheden skal ske. Det er ikke dårlige mennesker vel, men det er bare dybt spild af ressourcer. Skidt med deres tid, det er bare 30-50 mand. Det er et spørgsmål om penge. Men hvis de 50 mand forstyrrer Jer der skal løse opgaven, så er det meget heldigt det ikke… derfor den der, korrelerer meget med den her (slide 22 – røde og orange klods ). Hvis du laver noget der er meget rigid, så er det meget svært at ændre…reimplementere løbende… Altså vores ligger et eller andet sted midt imellem. Da vi solgt LEGOLAND parkerne, der havde vi jo tænkt meget over, hvordan bygger du noget godt og bygger op? … noget på, hvis du skal have noget ud igen.

0:21:19 MG: Grunden til at I så begyndte på LEGO Light, det var så både, hvad skal man sige, nogle

forretningsmæssige og nogle økonomiske perspektiver der lå i det? HWA: Ja, vi har lavet nogle organisatoriske centraliseringer, for at spare mange penge, altså 1200

mand får mange penge i løn om året. Vi har lukket en masse bygninger og alt muligt. Vi ku så bare se, at vores ERP platform understøttede ikke det vi havde gjort rent forretningsmæssigt – ergo, på den igen. Ved siden af det lå der alle de der argumenter der nok var kommet på et eller andet tidspunkt med opgradering og Euro. Der var nogle dræbere der ku ha hugget fra siden. Nu gentager jeg mig selv, det der med, at den, platformen vi havde, som var foreningsmængden af alle de her ønsker fra de decentrale, den var ved at falde fra hinanden, altså det virkede bare ikke.

MG: Det vil sige, der var meget… aware…? HWA: Ja, altså ERP platformen blev valgt fordi at vi skulle ha et middel til at understøtte det mål, og

målet vi havde, det var at spare penge. Og det var sådan set gjort, vi havde jo opsagt alle de her mennesker, vi havde gjort en hel masse, og vi vidste godt, at det var trin ét af X. Vi var nødt til at gøre det

0:22:26 MG: … og dermed var I også mere eller mindre… I var også klar over, hvilken vej I var nødt til at gå

med hensyn til LEGO Light? HWA: Ja, det var simplicity, globality, standardization.

17

MG: og dermed så prøver I også at få Jeres forretningsstrategi og ERP systemet til at passe? HWA: Ja, altså et konkret eksempel er, at vi gik ud og… vi lavede det vi kaldte main principles – seks

gange seks slides indenfor seks hovedområder, der fortalte hvordan vi ville køre vores forretning. En af dem hed simplicity bare. Den skal I lige se, den siger det hele… Det her er de originale main principles. Simplicity, det kan jeg godt sige… Vi kom fra en verden, altså forretningsmæssigt, vi kom fra en verden med lidt over 3000 artskonti og over 2000 cost centre. Vi fjernede 80 % af dem i begge dimensioner. Vi kom fra en verden, hvor vi havde over 140 forskellige rabatter, rabattyper, og dermed også 140 artskonti i kontoplanen der omhandlede rabatter. Der var da ikke et øje i hele verden der ku’ finde ud af, hvad der stod på de konti. For hvert land havde vi en egen, det er hedder calculation model, altså her er min brutto prislistepris, og så gangede vi det med rabatter og moms og alt sådan nogle ting. Jamen hvorfor ha’ mere end én? Vi er for øvrigt endt med to, vi endte med to, for vi ku’ ikke kunne finde ud af at have både, en der kunne håndtere salestax. Nu er vi jo globale, så vi skal ku’ håndtere en i USA som har salestax, som er en hel anden måde at regne på, som i Europa, hvor vi har moms. Det ku’ vi ikke… det vil sige, der var det forretningsmæssige inpack. Det vil sige, at vi var ude ved alle vores kunder. Vi havde… med rabatterne, vi beregner det vi kalder net invoice price, bare for at se, hvor det ramler ind, hvor kravene fra forretningen, som vi så vil implementere via ERP platform, gør at forretningen går ud og gør noget. Vi ændrede massivt, vi tabte kunder på det også, vores terms and conditions. Vi havde, jeg kan ikke huske hvor mange hundrede betalingsbetingelser vi havde. Jeg troede slet ikke det var muligt at lave så mange kombinationer. Så blev det sådan, nu kører vi kun med et par håndfulde. Det kan godt være du har haft løbende måned 79 dage, løbende måned 30, så var de sure. Nogle lande tabte vi kunder i, de skabte sig. De kom tilbage igen de fleste af dem, dem vi ville ha’ af dem. Men der er sådan en, hvis du vil køre simplicity i din ERP implementering, blive enige med forretningen, så er der også nogle ting de skal gøre. Simplicity handler i det forretningsmæssige om at reducere udfaldsrum. F.eks. betalingsbetingelser, rabatter, leveringsbetingelser, det vi kalder value added services. Det kan da godt være, at du vil ha’ at vi sætter prismærker på og vender dem omvendt nede i kartonerne. Ikke for at være arrogant. Hvis folk ikke ved hvad det koster… Det er selvfølgelig et resultat af de der lande der før har været total autonome. De har opfundet deres egne paradigmer for, hvordan vi driver forretning. Det havde vi meget skænderi om, det der. Heldigvis ikke så meget mig, jeg sad lidt inde i projektet, men dem der sad ud imod kunderne.

0:25:29 LØO: Det vil sige, at man kan godt sige, at det egentligt har kørt meget decentralt helt ned til kunder,

hvordan de ville ha’ det i forhold til Jeres. Det var ligesom dem der styrede det…? HWA: Ja, det var det vi lavede op på LØO: … i stedet for at det var centralt styret fra Jer, der siger, nu går vi sådan, sådan og sådan? HWA: Det er selvfølgelig klart, at der er nogle regionale forskelle, man er nødt til at tage objektivt ind,

men der er utrolige mange ting… jeg er økonom, så jeg dømmer jeg altid sådan noget.

18

MG: Hvad med ERP systemet? I har også nogle salgskontorer ude i Østen og sådan noget, har I ik’…?

HWA: Jo, vi har i Japan, Korea, Hong Kong, Singapore, Taiwan, Sydafrika, hvis vi tæller den med til

Østen. MG: …der har I også ERP implementeret? HWA: Jo, det gjorde vi så i LEGO Light fase to. Det var fordi, da vi kørte over sommeren 2001 – vi

kørte for øvrigt 33 juridiske enheder på, på tre måneder… alle de store, men ikke Asien. Vi tog alle dem der var på vores gamle platform først, for de var ved at falde fra hinanden. Og så tog vi hen over ultimo 2001 og primo 2002, tog vi så konkret Japan, Korea, Hong Kong, Singapore, plus de fire LEGOLAND parker, som vi så godt nok solgte to år efter. Det er en detalje. Hvis vi havde vidst det dengang, så havde vi nok ikke gjort det, men sådan var det. Det gi’r nogle sjove udfordringer, ud over tegnsæt. Men det havde vi allerede før da vi gik imod Østeuropa. Der vender det og dingler lidt på hovedet. Men det gør også noget ved os at ligge på ét cluster: hvad er klokken? Altså jeg sad og lavede ledelsesrapporteringen fra 2002. Hvornår er det vi lukker bøgerne?

MG: Forskellige tidszoner… HWA: Ja, lige præcis. Når vi lukker bogen her og siger nu er det den 31. maj, hvis der er noget der

hedder det, kl. 23.59, jamen, så er det stadigvæk sådan sidst på eftermiddagen i USA og det er den 1. juni om morgenen i Japan. Der har vi altså valgt globalt og sige: vi lukker. Klokken falder i slag på et eller andet tidspunkt. Vi kan ikke arbejde med forskellige klokkeslæt. Vi havde problemet lidt da vi gik på med LEGO Light, det blev rigtig sjovt da vi fik Asien på... der gik det op for alle folk, at det var sådan. Vi har Asien, altså vi er konkret er vi selvfølgelig hele kontinental Europa, inklusiv Øst, helt over til Rusland. Og så er vi i Asien, i de lande jeg lige nævnte, så er vi selvfølgelig store i USA, Canada, selvfølgelig England… tror det er Hong Kong også. Vi har fire selskaber, der ikke er på. Det er en branch af vores Hong Kong selskab i Taiwan, og så er det en joint venture vi har med Dacta Pitsco i USA, og så er det Sydafrika og det er Mexico. Den ene er fordi vi ikke ejer nok af den, de andre tre simpelthen fordi de er så små. Der er så få mennesker, at inden vi får dem uddannet og forklaret hvad det er der foregår og får det implementeret. Det er det, det koster at drive deres platform de næste 40 år. Altså set økonomisk, så er du fra et væsentlighedskriterium, så er det fuldstændig ligegyldigt.

0:28:17 MG: Har I, i den forbindelse, når I nu har været i forskellige lande også været udsat for, nogle sjove

oplevelser, som man ikke lige måske i første omgang havde taget højde for. HWA: Det har vi. Jo, jo. Kommer du til Japan, så finder du ud af, at de kan faktisk ikke, jeg har

desværre aldrig selv været der, finder ud af, at de kan simpelthen ikke snakke engelsk. Det er lidt dumt når du kommer med en platform, der er på engelsk… Vi implementerede i Sverige. Jeg sad med økonomi i starten af LEGO Light. Der fik vi lavet en analyse af alle lande vi var i fra Price Waterhouse Coopers. Det er ikke noget, jeg sku’ sige, når den båndoptager kører, men

19

alligevel. Hvad for nogle regler har vi, som vi ikke må overtræde? Vi kan ikke køre en global ERP platform ud, uden at gnide op ad nogle bogføringsbekendtgørelser og forskellige småting. Det vi blev mødt med, der var selvfølgelig en intern modstand imod det her. Vi kommer og standardiserer og laver om i det her, det er ikke alle der er vilde med det. Så siger de, vores italienske kolleger, jamen the consultant said, this is legal requirement, det er lovkrav. Ja ja, men så laver vi bare en rapport hjemmefra. Det er en kutyme I har oparbejdet. Der opdagede vi, f.eks. i Sverige, der skulle vi… Forestil dig, at vi vil køre alt bogholderi fra Skandinavien til Billund. I Sverige, der skulle bogføringshandlingen foregå i Sverige. Der kan vi have virkelig svært ved at afskedige den sidste økonomimedarbejder. De skulle rent faktisk sidde i det svenske kongedømme og lave den her bogføring. I Frankrig, der skulle serveren, hvorpå dataene befandt sig, stå i Frankrig, og sådan ku du blive ved… Stort set hvert land har sine mærkelige ting. Kommer du over østpå, i Rusland lige nu, kører vi faktisk en spejlet ERP platform som er russisk, for der er så mange dokumentkrav til indkøb. Jeg ved ikke om det er af hensyn til korruption, for at undgå det eller for at fremme det, det kan jeg ikke helt gennemskue.

MG: Så de lovkrav, der er en del…? HWA: … det vi kom med. Vi blev reddet af, at de selskaber vi havde tilbage, ikke var ret

komplicerede. Mange af dem var bare sådan nogle gennemfaktureringsselskaber. De køber nogle varer og sælger dem, og har lidt markedsføringsomkostninger. Vi har fabrikker, med væsentlige større problemer. Nogle lande har meget perverse regler omkring beholdning og opgørelse. Men vi har jo ikke fabrikker her. Jeg tror vi er lidt reddet af, at vores selskaber var ukomplicerede.

MG: I har for det meste salgsselskaber. I har fire produktionssteder og tre…? HWA: Ja, vi har lige desværre lukket Schweiz her, så vi har kun produktion i Japan, i Tjekkiet og i

Billund og USA. Resten kører her (alt ud over produktion red.) LØO: Hvad med alle de der forskelle. Er det nogen I inden har været klar over eller er det nogen, der

er selvfølgelig altid nogle der overrasker. Er det nogle I bruger tid på at undersøge inden? HWA: Jo altså mange af dem forsøgte vi på at finde inden. Men jo, gu fanden blev vi overrasket. Vi

havde en oplevelse, der var jeg heldigvis ikke dernede… hvis du nu har, i dag, har vi alt bogholderi liggende i Billund for hele Europa på nær visse af de østeuropæiske, dem kan vi slet ik’. Vi kan jo ikke forstå, hvad de skriver til os. Men det kræver bl.a. noget med, at vi er nødt til at lave aftaler med myndighederne om, at vi kommer kørende med bilagene til Belgien. Vi må godt have bilagene heroppe, men hvis myndighederne forlanger det, så skal de bilag indenfor et døgn være i Belgien. Vi opdagede det i Italien, hvor vi heldigvis stadig havde bogholderiet dernede. Der kom det der hedder Fiscal Police. Bevæbnet med maskinpistoler går de ind, og så skal du altså tage fingrene af tastaturet, du må ikke røre din telefon, du sidder bare – det er ikke kun noget vi har, der er flere der har, så sidder du bare helt stille, så kommer de og reviderer det. Det har altså ikke noget med vores ERP platform at gøre. Det ville bare være lidt kompliceret at de kom ind, hvis der kun stod nogle computere og der ingen papir var. Hvor fa’en er det. Jamen det ligger oppe i Billund, vi sidder bare og kigger på noget bilag de har

20

scannet. Det ved jeg ikke rigtig hvordan… (hvordan myndighederne ville have reageret på det red.). Jeg tror jeg vil holde her, for ellers kommer der for mange af de der dumme anekdoter, der ta’r hele dagen om alt mulig mærkeligt.

0:31:59 MG: Du snakkede også om, at I, i forbindelse med Jeres udrulning havde været ude og snakke med

Jeres kunder og kommunikere en hel masse med dem omkring rabatter og des lige. HWA: Ja, altså terms and condition i ordets bredeste forstand. Primært rabatter, betalingsbetingelser og

leveringsbetingelser. MG: Hvad med internt i organisationen i forbindelse med…? HWA: Vi havde simpelthen en der var ansvarlig for change management, det der modeord I sikkert

bruger, når I skriver rapporter også. Vi havde utroligt meget kommunikation internt. Slet ikke nok, vi var ikke gode til det. Det er rigtig rigtig svært.

MG: Hvad er det man skal være opmærksomme på der? HWA: Mit billede er at fortælle noget konkret. Vær ærlig og fortælle noget konkret. Vi kan slamdunke

folk med præsentationer og – lige som jeg gjorde lidt ved Jer her – 400 power point, og folk de sidder og kigger, betyder det noget for mig? Hvis det ikke gør det, så hører jeg jo sådan set ikke efter. Så kommer der lige pludselig noget, der betyder noget for mig, det hører jeg ik’ fordi det gjorde første 17 slides ik’, hvor skulle jeg vide fra, at det var slide 18 der gjorde det? Fortæl noget rimelig konkret. Og konkret er jo selvfølgelig svært at kommunikere, for det ved du jo nogen gange sent. Tænk på de projekter der kører i en timebox. Vi fik jo af vide den 29. november, 28. november år 2000, at vi var færdige med Oracle og skulle implementere SAP. Jeg var selv en del af beslutningen, men ikke desto mindre, så fik resten, de 100 mand vi havde i teamet det først af vide, og vi implementerede som aftalt medio maj. Det gir sådan en timebox og køre i. Der er altså nogle ting, man gør så godt man kan. Og kommunikationen var, jamen altså. Det der gjorde vores rigtig svært, specielt i år 2000, hvor vi troede vi skulle køre Oracle, det var at vi står med en organisation, der lige er blevet fyret 25 % af. Det hele er blevet rykket rundt, mange nye folk, folk i nye roller. Angst. Plougmann svinger øksen. Var det hug et af, får den lige en tur mere i centrifugen og så tager den lige nogen hoveder, næste gang den kører rundt ik’.

MG: Var der også nervøsitet omkring, hvad skulle ERP systemet implementeres for? HWA: Jo, jeg tror der var nogen. Den begavede læser derude og kollega havde selvfølgelig opdaget, at

det var et skridt mod centralisering og standardisering og det gir typisk færre arbejdspladser. Det gir også muligheden, det var vi helt (klar red.) over i finans. Det gir mulighed for, at du ku flytte nogle ting, hvilket vi også har gjort. Noget der er standard, ku du flytte til Indien. Det er jo også trusselsbilledet stadigvæk. Hvor flytter ting hen ik’? Vi fik standardiseret vores interface til vores distributionscentre. Hvad er der sket? Vi har ét (europæisk red.) distributionscenter i

21

Jirny nær Prag (Tjekkiet red.). Da vi startede med at have alle de der decentrale salgsselskaber, der havde de alle sammen et lager. Så lod vi lageret fysisk ligge og tog det logisk fra dem. Det lavede vi lige imens LEGO Light, lige i foråret 2000, der havde vi så to distributionscentre i Frankrig, et i Lyon og et i Dunkerque der forsynede, det i Dunkerque forsynede Benelux og England, og det andet forsynede så Iberia (den Iberiske halvø red.) og Italien. Det tyske heroppe der ligger i Münstedt, der forsyner Tyskland og… og så i Billund, der forsyner Skandinavien. Det ku’ vi godt gå ind og standardisere. Det der er sket nu, det er, at vi har lavet et stort i Jirny ved Prag. Vi lukkede Dunkerque i februar, vi lukkede Lyon i sidste weekend, vi lukker Münstedt – og vi lavede for øvrigt et stort centrallager i Flensborg, det er også blevet flyttet. Vi lukker det i Münstedt og det i Billund i løbet af 2007. Det er fordi, nu har vi standardiseret, så kan du godt samle det et sted. Det begynder folk godt at ku’ se et mønster i.

0:35:18 HWA: Nogle ting ruller før øvrigt tilbage igen. Vi centraliserede customer service i London til hele

Skandinavien, det har vi svært ved, det har vi faktisk flyttet tilbage igen. Så nogle gange slår den lige tilbage. Ikke så meget pga. ERP platformen, men mere det der, hvor mange sprogstammer og viden kan du ha’ det samme sted. Vi har vores consumer service – det har ikke noget med ERP at gøre, de kører på noget andet – liggende i London, der servicerer alt ud over USA. Det er skægt at være derovre. De kan jo snakke finsk og fransk og tysk og spansk. Det er sådan en hel etnisk smelte deal, når du kigger derind. Altså, der er folk i alle størrelser og alle farver. Han og hun og midt imellem, altså der er hele farveladen derinde. Det er rigtig svært at samle. London er nok et af de steder man kan gøre det. Sådan et sted kan du ikke, det ku ikke ligge i Billund, for hvor vil du få de kompetencer fra, altså rent, bare sprog. Sproget er også en udfordring på en global ERP platform – anvendelsen, dokumentationen også. Altså nu har vi Tjekkiet meget med… tyskerne har skrevet deres over på tysk. Japanerne er nødt til at gøre det. Altså de få, der forstår engelsk oversætter så for de andre.

MG: Jeg har fornemmelsen af, at I er, LEGO i hvert fald har været en meget dynamisk virksomhed.

Også lidt det som du sagde med den der Compass ting der, altså at man skulle gøre det selv… tænk kreativt og sådan noget i den stil…

HWA: Der skete et klart skifte der i ’94, hvor vi, alle applikationerne lavede vi selv, hvis det er det du

mener – altså rent Silvan, gør det nemt og gør det selv. Altså det der med at købe noget fra hylden…

MG: Jeg tænker sådan mere, i forbindelse med Jeres nye implementering, der siger du så også, at I

holder tidsplanen stadigvæk, da I går fra Oracle og så over til SAP igen. Var det mærkeligt for Jeres organisation som sådan, at der var meget stramme tøjler på Jeres projekt?

HWA: Nej, jeg tror det der var mærkeligt for organisationen, hvis vi skal bruge det ord, det var

egentligt, at vi var vant til at lave vores egen løsning, selvom vi. Det var det der gik galt ved den første implementering. Så køber man en standardapplikation, og så slår man lidt på siden og dunker den i hovedet og så lavede det vi ville. Det vi sagde i LEGO Light der var at, jamen vi har jo købt en standardapplikation for at have en standardapplikation…, så alle afvigelser fra standard – det som nogle kalder rød kode, hvor du går ind i standarden lige og arbejder lidt

22

rundt derinde – det vil vi ikke ha’! Så vi ligger utrolig, selvfølgelig har vi lavet egne programmer. Det ender man altid med at gøre. Men i forhold til vores ERP platform har fået af vide også fra ekstern, der også har været inde og kigge på det, meget meget lav anvendelse af hjemmeskrevet. Jeg vil sige, hvis du skal implementere en ERP platform hurtigt, ud over det vi lige snakkede om med ledelsesbackup og alt det der. Få lavet en ordentlig model om, hvordan din forretning skal køre. Sørg for at den model kan være, kan rummes i din standardapplikation. Hvis ikke den kan det, så må du altså hjem og lave din model om, eller og så skal du have en anden applikation. Lad være med at begynde at forgribe sig på standardfunktionaliteten – og det var det vi gjorde første gang. Der sku’ den bare vrides. Det gjorde jeg også i Schweiz, da jeg sad der. Vi havde nogle konsulenter, der godt ku’ lide at skrive rap rap. Hvis der var noget vi ikke var tilfredse med, jamen så ku’ det lige pludselig noget andet ik’!? Du ligger løbende og opgradere, du får patch upgrades og alt muligt skrammel hele tiden. Hver gang du får det, skal du ind og teste og sikre, at det ikke afviger og ødelægger.

0:38:38 LØO: Dvs. så vil du hellere, i stedet for at pille i SAP’s ERP platform, så vil du hellere lavet et

program for sig selv? HWA: Nej, jeg vil hellere indrette min proces efter SAP’s måde at gøre det på, hvis det ikke er noget

der er virkelig vigtigt for mig. Altså, det kan godt være, der var nogle processer, hvor man siger: her er vi nødt og sige, at det sådan vi gør, det tror vi på er rigtigt.

LØO: Vil du så inden for det sige, det sådan vi gør det og sådan bliver det bare. Vil du så ændre det i

SAP, eller vil du hellere lave en hel ny applikation ved siden af? HWA: … som udgangspunkt så skriver vi ikke i SAP standardkode. LØO: Dvs. du vil hellere lave en egen applikation? HWA: Det man typisk gør, man laver det der hedder et user exit og så står du af det der funktionskald

– nu er jeg altså ikke programmør, men jeg kan godt customisere et SAP system – processen kører inde i SAP hertil, så har SAP nogle definerede exits, så går du herud, så har du et program, der får den til at. Det kan godt være, at den var firkantet, når du gik ud her, men den er altså rund, når den kommer ind igen. Det gælder om at bruge så meget som overhovedet muligt af den standard, man nu engang har betalt temmelig mange penge for at komme i besiddelse af. Det det med, at du noget liggende ved siden af. Der skal du have et helt vidt overblik over, du skal have nogle programmører. Hver gang du opgraderer og du rører ved det – du skal huske at det er der. Hvis der er noget der ikke virker og SAP opdager, man selv har pillet i det – selbershult. Hvorimod hvis du bliver inde i deres standard, så får du også hjælp af dem. Du er med på, når de udvikler noget nyt, så kan du tage det i brug, hvorimod hvis du har været inde og rode for meget rundt i det selv, så tør du ikke engang at opgradere. Jeg ved godt det lyder lidt overmoralsk og lidt helligt, men som udgangspunkt – et ERP system, det køber man, fordi man tror på værdien af integrationen. Det kan godt være, at man ikke får lige præcis det man får i alle trin. Der skal man tro på, at det man gir køb på..., det gør man, og så får man værdien af integration. Hvis man ikke accepterer det, så skal du ikke købe en integreret ERP platform. Så

23

skal man købe det de kalder best of breed og så bagefter sætte sig ned og gruble over, hvordan man får dem til at integrere.

Det er to meget forskellige måder at tænke på. Vi bruger selvfølgelig også eksterne

applikationer. Vi har lavet en business to business weborder applikation, hvor kunderne kan gå ind og finde varer på. Det er et lille firma oppe i Horsens, der har lavet det, der laver direkte funktionskald ned mod SAP – det fungerer skide godt. Man skal være religiøs, og så skal man en gang imellem lige glemme at komme i kirke.

MG: Nu siger du også det der med ikke at ændre i SAP. Når I ikke har villet ændre i SAP, hvad har

det så betydet for organisationen? HWA: Jeg tror ikke, de har oplevet det som om, at det var det vi ikke ville ændre i SAP. Vi havde den

fordel, en kynisk fordel, at vi implementerede en ny ERP platform i læ af, at hele organisationen lige var smidt op i luften. Det havde set helt anderledes ud, hvis vi havde gjort det fire år forinden. Går man ind og kigger på vores situation, så. Vi kommer og implementerer lige i bunden af at Poul har smidt en atombombe, fyret på alle sider, skudt til alle sider. Altså ikke fordi det var forkert, det var bare for at konstatere at det skete. Rykket folk rundt, nye jobs, ny organisation, folk flytter geografisk rundt mellem forskellige lande. Det er en organisation der er sådan i opbrud. Godt tidspunkt at rykke ind ik, fordi inden støvet lægger sig, så skal vi bare lige bestemme hvordan det skal lægge sig. Det er ikke bagklogskab det her, det snakkede vi meget om, da vi gjorde det.

MG: Så det er meget noget om at, en villig… HWA: … timing MG: … ja, timing, men også en villighed fra organisationen… til at ku’ ændre sig? HWA: Ja, måske ikke så meget villighed, måske mangel på kræfter til at kæmpe imod. Jeg ved ikke om

man skal opfatte som villighed, det vi var udsat for, men det er den der jeg kalder: organisation mature for change (slide 21)

LØO: Men det er så set i Jeres situation, at de har været så meget igennem inden, at folk siger ok, nu

er de trætte af at kæmpe imod det, så er det ligesom ok… HWA: Ja, eller også når folk det der punkt, jamen det betyder i virkeligheden ikke noget for mig, og

det er jo vigtigt, det er jo godt. Jeg skal bare have mine ordrer ind. Om varenummeret og kundenummeret står i venstre hjørne eller højre hjørne på skærmen, det var sådan noget vi kunne skændes om i gamle dage, det er jo ligegyldigt. Det med at få ordre ind skal foregå godt og effektivt. Selvfølgelig var der en fandens ævl og kævl og bøvl. Nu skal jeg ikke få det til at lyde som om at det kørte…men der var slet ikke. Vi kom igennem med det vi ville, stort set hele tiden.(meget top down styret, med lille indflydelse for brugeren red.) Jeg fornemmer ikke, at vi havde sådan nogle store set backs.

24

0:42:35 MG: Hvad med ude i Østen og i Asien… var det nemt for Jer at få implementeret derude? HWA: Det er aldrig nemt det her. Fordelen med asiatere er at, de forstår ikke engelsk, men de forstår

en ordre. Der er danskere meget værre. Jeg kommer og gir dig en ordre og så kommandere vi, ja ja, nu snakker vi lige om det (den danske medarbejder red.). Dernede er det… (de parerer ordre uden brok red.) Problemet er til gengæld, de siger dig jo ikke imod. Dvs. du ved jo, nu var jeg ikke selv med derude, men dem der var derude, de vidst jo nogen gange i realiteten ikke 100 % hvor de havde dem henne ud over at de vidste at de fysisk sad overfor dem.

MG: Jeg keder godt lidt problematikken. Jeg har prøvet at bo sammen med en som, han sagde bare ja

hele tiden, og så vidste man ikke, hvad han egentligt sagde ja til, fordi han ville ikke sige nej. HWA: Jeg har været på kursus med asiatere. Jeg har også haft koreanske kolleger heroppe og stået i to

timer og forklaret dem noget. De sagde ja, og så pisse interesseret ud. Da de så gik, fandt jeg ud af, at det eneste de kunne af engelsk overhovedet, både sige og forstå, det var ja. Kunne man få dem til at afbryde og sige de ikke forstod noget… (ikke et spm men en konstatering! Red.). Så derfor, det jeg tror der er udfordringen, hver eneste gang asiaterne er her og du så er rejst. Har de overhovedet fattet hvad du har efterladt dem? Men det kører nu egentligt godt derude, må jeg sige.

MG: Har I haft, nu siger du, at du ikke selv var derude, men har I haft… HWA: Nej, men vi efterlod danskere derude. MG: … og I har haft et team, der har rejst rundt. HWA: Ja, vi havde en squad der rejste rundt. Altså, jeg kørte ud af Billund var jeg med til at køre hele

Europa og så var jeg i USA i tre uger og køre USA op. Jeg var så ikke med, jeg havde fået et andet job, jeg var ikke med i Asien. Det passede mig for øvrigt også fint.

0:44:16 LØO: Det vil sige Jeres, I havde et grundlæggende ERP team som tog med ud, altså selvfølgelig, med

udskiftninger men ellers HWA: Ja MG: Hvordan fandt man frem til de folk, var det bare nogle der sådan sad i bestemte ledende

stillinger eller var det baggrund i kvalifikationer eller blev de hyret udefra HWA: Det var kvalifikationer, så lavede vi nogle stykker i projektet. Jeg kan huske jeg fik et par

stykker over der ikke kunne noget om SAP, det kunne de da var færdige med det. Nej, det var meget efter kvalifikationer, det samme med mit team, du ved, jeg fik besked på at finde de bedste uanset hvor de sad henne…Folk kan selvfølgelig sige nej hvis de ikke vil altså det er jo ikke det. Det er jo ikke diktatur vi lever i, altså. Men det var sådan at vi havde en projektleder

25

Søren Pagh Pedersen….og så var vi seks teamledere, med hver vores ansvar, vi fungerede, det var til gengæld valgt med omhu det var dem man vidste der både kunne og kunne fungere sammen.

MG: Var der også incitamenter for folk…. HWA: Altså økonomiske eller hva’? MG: …både og. HWA: Jahh altså, incitament, det var projektet, det vil jeg sige, vi fik al ledelsen sendetid. Det er

motiverende ikke? Vi havde 15% af årsgagen, var der stillet i udsigt til bonus. Hvilket ikke var ret meget i timen, hvis man regner timelønnen ud. Det er, sådan, fuldstændig ikke…og fik vi det og det snakker vi stadig den dag i dag selv om det er fem år siden, vi fik skabt sådan en musketerånd. Meget kynisk, dem der ikke kunne levere de blev (laver en cut-bevægelse med hånden). Gør det der på 5-6 måneder, så er du ikke fintfølende nok. Vi prøvede at registrere tid, det er jeg aldrig prøvet før, vi arbejdede 100 timer om ugen i et halvt år. Det gik op for mig da min kone og datter kom med tøj i en pose og så afleverede det og kørte igen. Min kone arbejde så heroppe dengang, det var der flere der oplevede, vi havde madrasser liggende. Altså ligesom når i skriver opgave ik’? Vi lavede bare, ERP projekt. Det var meget, meget høj lego vintage aktivitetsprojekt, mange af Keld’s drenge, de gamle legofolk der var i gang i ik’ os’

MG: Hvor højt op strakte denne her støtte til projektet sig HWA: Det var til Poul og Keld MG: Var der så en af dem der ligesom stod som… HWA: Poul MG: …det var Poul som ligesom… HWA: …sekunderet af Stig Toftgaard MG: Som stod og sagde at nu gør vi det her og det var ham der ligesom stod bag beskederne og

sådan noget HWA: Poul var på samtlige ledelsesmøder i de 16-18 måneder, helt fra vi startede i ’99 gennem

Oraclefasen, skiftet til SAP og indtil vi var færdige. Man kan sige meget om Poul Plougmann, han forlod os nok for sent, men der var han iskold

LØO: Det var også helt ned på laveste niveau os’?... HWA: Ja, jo længere du kommer du væk fra ledelsen…

26

LØO: …af dem der blev berørt af det HWA: …så er det klart der selvfølgelig er nogle ledere der mente de burde have været haft en central

rolle i projektet der ikke fik det. Du møder altid brødnid og nogle, vi kaldte det LEGO Light fordi det var sådan en Light town, nogle kaldte det LEGO dark fordi de ikke var med, altså det er meget vigtigt…man skal sørge for at blive så hårdhudet så man kan sige at nogle reaktionsmønstre er drevet af nogle motiver som du ikke kan gennemskue.

LØO: Jeg tænkte lige så meget på gennem syn, altså, supporten at den gik ned. Du siger han var med

på alle møder og sådan noget. Men også om det blev kommunikeret ned til alle. HWA: Hvis der var nogen der havde bøvl, så gik vi op til ham og sladrede, jo. Det gjorde vi ikke ret

meget, men den kunne godt bruges hvis der virkelig var noget der var ved at gå i hegnet ik’ os’? Men der var ledelsessupport i huset da vi skulle implementere i USA, kom vi derover jeg skulle så holde en uges ferie derover, det var så i den uge. Fløj derover så havde vi to dage på kontoret og så havde jeg så min familie med så havde vi så en uges ferie og så lå vi så derover og så fløj jeg hjem. Der kom vi ind, det kan jeg ikke huske, der havde de så besluttet de ville køre lagertælling. …det er stort derover, vi havde en plan om at lukke ned fredag aften efter arbejdstid, konvertere hele lortet over weekenden og så op og køre mandag morgen. Alle siger det ikke kan lade sig gøre men vi nåede det stort set mandag tirsdag alle steder. Vi havde så bedt om at få en uges buffer for at forventningsstyre Andrew Black lederen derover, og hans lederteam og sige altså, I er de største, hvis det her begynder at gå galt skal i bare være forberedt på at vi kan æde nogle dage ind. Det havde de forstået som at nu ville de stoppe alt og så bruge den uge til at tælle lager og vi solgte for 5 millioner $ om dagen. Og jeg starter med at komme ind af døren og sagde det der, nu var jeg en af de første der var derover ik’? Det der, der det dur bare ikke og det var midt i sommerferien alle var på ferie, fat i Andrew han var der heldigvis, direktøren, dem jeg lige kunne finde af lederteamet og sige det der det dur bare ikke. Der var Andrew der med det samme han lyttede på hvad jeg sagde og der var så kommet et par andre fra teamet. Du kan se det er fem millioner $ om dagen, dvs. det er 25 millioner $ i ugen. Så kigger han rundt ik’? Så overruler han hele sit lederteam, og sagde, gør som de siger. …gør de det i hvert fald ok, if the presidents says, så….

MG: …og her kan man godt mærke at kulturen er også den derovre…. HWA: Ja, hvis man kommer med sådan noget her og ledelsen er med dig de steder hvor magtdistancen

er høj, så kan man bruge den og ikke for at være aggressiv, men så kan du bruge den som enabler ik’? Hvorimod Danmark, vi danskere, vi er svære ik’? For vi kan godt, jeg er ligeglad med…

MG: Der skal man overbevises… HWA: Dem skal du vinde intellektuelt ik’ os’? Det gjorde vi også meget med. Jeg glorificerer det lidt

som folks militær tid ik’ os’. Der var meget bøvl i det. Der var også spændinger inde i teamet, vi fungerede rigtig, men der var selvfølgelig engang imellem, så var der…

27

00:49:20 MG: Det er vel meget naturligt hvis man bruger så meget tid sammen…. HWA: Også, hvis du prøver at arbejde 40 timer i træk og så sover du seks timer og så tager du en ny

arbejdsdag, på et eller andet tidspunkt så er du brugt op. Det hele det er deadline (banker gentagende gange i bordet). Jeg havde ikke kunne fjerne masterdata, dvs. at der altså var sekts uger, hvor det hele tiden var mig der var bagefter, der var rigtig meget, otte uger inden vi kom i gang. Vi havde altid statusmøde kl 8.30 hver morgen syv dage om ugen. Og det er klart at det giver et vist stress niveau, dvs. at folk reagere også noget mere. Og der kommer en ikke uvæsentlig kynisme ind også, meget kynisk, en der kan hjælpe mig? Får vi løst det her? Gør vi ikke (fløjter, ligesom ud af vagten). Ikke fordi, vi fyrede folk, men altså der bliver, der opstår sådan nogle cirkler, der er the inner circle, og der kommer de så, dem jeg ligger i den ydre cirkel, det var de der 30 % jeg snakkede.

MG: Hele projektet hvordan var det tænkt starten fra starten af, var der sådan meget, nu kør vi sådan

her og så ruller vi ud. HWA: Vi brugte sådan en muteret form af SAPs ASAP metode og deres implementeringsmetode, vi

havde en ide om at skulle skrive business blueprint som det hedder. Jeg havde så fået trumfet igennem at jeg er meget for tegne nogle tegniger, nogle koncepttegninger og sige ok, inden vi lige begynder lave blueplint, så skal vi lige være enige om, inden vi begynder at tegne bykort, skal vi lige være enige om globussen ik’. Det gjorde vi og det lykkedes meget godt. Og lidt kynisk planlagt for vi vidste godt at Oracle skulle smides ud og d. 28. mener det var d. 28. det var en tirsdag i hvert fald, det er ligesom med 11. september 2001, der er sådan nogle som man altid husker. Vi mødtes kl. 8.30 om morgenen, kaldte alle folk ind i lokalet kl. 9. Legofolk i det ene og Oraclefolk i det andet. Der var stående klapsalver, eller folk var helt vildt jublende. Ej, de var skide frustreret de havde arbejdet et halvt år med noget der ikke virkede og det bliver man simpelthen træt af. Og Oracle folkene, inden middag havde de forladt bygningen. Og så var der sådan en eftermiddag, hvor vi bare gik lidt rundt og kiggede på hinanden, hvordan skal jeg i grunden, hva’, ryddede op og sådan noget og som om morgenen. Morgenen efter mødtes vi 10 fra Lego og 10 fra SAP på Australia i Vejle, to dage. Lige op mod 1. december, så lavede vi, der havde vi sørenjensemende travlt.

MG: Der kørt i så stadigvæk videre på den tidsplan som i havde fra Oracle af? HWA: Altså, dvs. fordelen var så at meget af det arbejde vi havde lavet på Oracle, hvor vi havde

snakket processer og hvordan vi ville gøre, simplicity, meget af det kunne vi faktisk bruge. Altså den Oracle fase rent teknologisk var spild af tid. Men sådan hjerneransagelsesmæssigt for at blive for det gamle måde at lave SAP på der var den faktisk god.

MG: Så alt hvad der hed business processes og sådan noget, det var tænkt… HWA: Det skulle selvfølgelig laves om. For Oracle havde nogle mærkelige måde at gøre nogen ting på

men mange main principles, der var lavet, de holdt hele vejen igennem. Ja, for det er igen til det jeg startede med at sige, med ledelsen, find ud af hvad i vil opnå og det man vil opnå skal være

28

uafhængigt af hvilken ERP platform man vælger. Mål først og så middel, hele tiden. Det der med at købe SAP og SAP kan også det her, og hvad så, er det noget vi skal bruge, nej men, glem det

MG: Så det er så simpelt som muligt hele tiden? HWA: Hele tiden køre ned, det jeg viste jer der, vi fjernede det jo 2000 konti i vores artskontoplan,

hold strukturerne små og hold dem rene, det lyder som gen lag, det er det dybest set. MG: Hvis du nu skulle, du siger du har været med i hele implementeringsforløbet fra stand alone til

den globale implementering nu her, hvis du sådan i hovedtræk, skulle prøve at beskrive forskellen på stand alone og så den globale implementering, hvori liggende forskellene, sådan virkelig.

HWA: For os betyder det visibility, jeg kan slå op her (på computeren, red.). Jeg kan fortælle dig hvad

vi har. Jeg kan også fortælle hvis jeg skal sælge hvor den er henne, hvor mange vi har i hele verden. Jeg kan flytte mine processer fra, alle vores kan eksekveres alle steder fra, det er ikke bundet til et land mere. Vi lavede et princip i vores main principles, ship from anywhere to anywhere. Hvorfor jeg kan gå ind her, hvis jeg har privilegium til det, det kræver selvfølgelig at man skal rettigheder til det, og tage en salgsordre i Danmark og sige at jeg vil have varerne fra Tyskland. Man får den der, hvor alt kan foregå alle steder og alle kan lave alles job, altså inden de faggrupper de nu er. Der er der fordel, hvorimod det i stand alone kan blive så specielt at det er kun dem der er dernede der kan finde ud af det. Og det kan være meget godt at have en stand alone, hvis noget meget specielt og landespecifikt, men sådan noget som vores, hvad er der specielt ved det, det er at tage en salgsordre, kommer der EDI ordre fra Toy ’r’ us, den er ikke anderledes i Italien end den er i Finland. Vi har lavet en masse standard interfaces også, hvorfor vi bl.a. kan skifte DT operatør ud fra Mærsk til DHL, uden at vi opdager det i den anden ende.

MG: Hvor det andet det var meget at operere i blinde hvor nu så… HWA: Visibility, det er det modeord alle bruger, men det er for så vidt. Se værdikæden, vi kan se hvad

vi har i transit imellem stederne, vi kan ligge og crossdocke. Jeg mener klart der er et klart økonomiske rationale i at gøre det selv, jeg tror egentlig stadigvæk, selv om man kan sige det at køre en central installationen koster mange penge koster det stadigvæk bare på ERP udgiften væsentlig mindre køre at køre det decentralt, rent supportmæssigt, så tænk på hvilken supportorganisation der var for at køre det. …moms i Italien eller moms i Billund er ligegyldigt, bare der er en der kan fortælle mig hvad procenten er selvfølgelig og det giver nogle stordriftsfordele, bagsiden af medaljen er det vi lige var inde på kort, med kompleksiteten i integrationen, det der med det der automatgearkassebillede, jo mere du sætter det sammen, jo mere overblik kræves det

00:54:44 MG: Dvs. jo mindre skal der egentlig også gå galt før at….? HWA: Ja, da vi implementerede planning 2 play, hvor vi havde fornøjelse at køre økonomi og cost

inddeling, 1 April, ikke fordi der er noget symbol i datoen, 2004. Da vi implementerede nye

29

costingprincippper, en lang historie. Hvis vi havde fucket det op så kunne du ikke flytte en vare i legokoncernen, hverken i fabrikken eller på lagerne, hverken ind eller ud.

LØO: Det bliver meget sårbart? HWA: Ja, men jeg tror netto er du nok mindre sårbar, fordi du meget mere robust end alle de der

enklaver, men fordelen er ved det, er hvis Japan falder ud så er trods alt kun Japan. Hvorimod på den globale så det, det hele, vi har nogle procedurer, alt muligt mærkeligt og vi bor ved siden af en lufthavn. Jeg får også vores clusterfil, nu har jeg ikke meget forstand på hardware, vi har to steder i Billund, hvor vi har hardware som er lyslederkabelmæssig forbundet. Vi tabt det ene serverrum under stormen, det mærker du slet ikke til, de spejler hinanden, både data og kraft 100%. Hvis der er en der rigtig været ville han måske lige kunne mærke det at det sagde (laver en lyd), men altså der var ikke noget der gik i stå. Men det er klart der en intellektuel risiko, i at have det samlet, det bliver simpelthen sværere og større. Men jeg kan sige dig, det at have integrationen også på intercompany handel og du kan tage ordrer af sted, du kan se det lager, du kan ordrestyre, du kan maksimere, du kan flytte dine processer rundt som vi har gjort meget og du kan centralisere, ikke fordi centralisering er godt, men centralisering er godt hvis du spare penge ved det og hvis kunden ikke oplever det, hvis det er alle dine backoffice processer du centraliserer. Før havde vi en IT-mand i hvert selskab hvorfor skulle man det, vi havde en økonomichef i alle selskaber

MG: I har simpelthen været i stand til at luge ud i en masse… HWA: De der 25 % folk af funktionærerne der blev (afskediget, red.), vi tømte jo de der selskaber. Der

var en økonomi, administrations og logistik… MG: Det var der i lavede de der forskellige enheder, hvordan med hensyn til… HWA: Nej, jeg beskriver det sådan relativ unuanceret ik, det var nogle kolleger jeg vældig godt, det var

ikke det, det var ikke morsomt vel, men jeg kan godt se rationalet i det. Nu må i ikke gå herfra med et indtryk af jeg er voldsom kynisk, det føler jeg faktisk ikke jeg er. Men det er jo faktum, fact of life, det er sådan det er, det var sådan det var.

MG: Hvordan med hensyn til, jeg går ud fra at I i dage opfatter Jeres implementering som en relativ

succes HWA: Ja, det. Det kan du finde flere forskellige holdninger til, men det kan du tro at jeg gør. Nej, det

er der mange der gør, vi kan også se på alle de referencebesøg, vi har, der er mange der drømmer om at være der hvor vi er.

MG: Hvordan med den her succes her, hvordan har i defineret det? Var det for at nå de 4 mål som

ledelsen havde stillet op? HWA: En konsekvens af, det der skete var jeg blev bedt om, da vi var gennem LEGO Light så sagde

Stig til mig, nu må du. Det var dig der startede det her, nu har vi bestemt at vi skulle gøre det

30

her for at kunne få konsistent rapportering. Så sagde han at nu laver du lige ledelsesrapporten i to år. Han sagde ikke to år, sagde at nu skulle jeg gå i gang med det. Vi havde nogle projektkriterier om at nå nogle deadlines, om ikke at være nede for længe og få det til at virke og dem nåede vi til fulde. Men de økonomiske rationaler er svære at bevise ik’, for dem er der mange der gerne vil tage i alle mulige sammenhæng. Vi havde også det der blev kørt ind i produktionen, som nogen betragter som en katastrofe. Men det var nu stadigvæk mere ledelse, prøv at se, Jørgen Vig, han har fyret det meste af ledelsen derovre. Jeg mener som ERP implementeringer nu går. Om vi så som organisation har gjort det godt, det kan man altid diskutere, vi er aldrig gode uddanne, vi er rigtig dårlig til at uddanne…

MG: … også i forbindelse med ERP systemet her? HWA: Vi er gode til at uddanne lige når vi går live, men så sker der ikke mere MG: Er det fordi I ikke har haft nogen, til at støtte dem i den forbindelse, tiden efter HWA: Ja, plus at de mennesker vi har som kunne skrive det uddannelsesmateriale og uddanne, dem har

skyndsomt taget og brugt til det næste projekt. Dem der sidder tilbage de kan måske ikke. Vi har faktisk møde i morgen med et firma omkring, vi skal til at lave stort dokumentationsprojekt og det er simpelthen for at få det dokumenteret ordentligt, lige nu er vi meget afhængige af 5 – 7 håndfulde mennesker, jeg har halvdelen af dem. Der sidder også andre rundt omkring. Dvs. 20 -30 – 40 mennesker…

LØO: Dvs. hvis i morgen de siger…. HWA: Får vi 10 opsigelser samtidigt, det ville ikke være rart. MG: Hvis man endelig skulle gribe fat i noget der, ville i gerne have noget mere uddannelse af

superbrugere… HWA: Opfølgende uddannelse, helt sikkert, både superbrugere men også, altså vi lavede noget herude

vi kalder process expert network som anker herude. Det er for at holde eksperterne kørende og sikre procesudviklere at der kommer, change request, et ændringsforslag til en proces. Så det er nogen der har forstand på det tager stilling til om det er en god ide, og ikke nødvendigvis i ledelseslaget, da det ikke er sikkert at de ved noget om det. Men den almindelige bruger er….holde dem uddannede, hele tiden nyudannede cand.merc.

LØO: Dat HWA: Hvordan får jeg lynhurtigt, nu Jer til at gøre, hvordan jeg hurtigst fra at være veluddannede nye

til nogle der virkelig performer, der er jo en læringskurve, hvordan får man den stejl, rigtig stejl, både for Jeres skyld men lige så meget for firmaets, så vi får noget for pengene. En anden er også hvordan får man folk, hvis jeg nu er customerservicechef i London jeg har en fejlagtig opfattelse af går jeg og forkynder det til mine medarbjedere? Vi har lavet noget vi kalder processaudit, nu skal vi først dokumentere, så skal vi køre processaudit, ligesom en ISO 9000

31

certificering, bare vi kalder det ikke så fint. Så kigger hvordan gør i det? Det hjælper ikke vi laver en standard ERP implementering, standard processer og folk gør noget andet, bypasser eller, typisk ikke af ond vilje….

MG: Så I har ikke oplevet at der er nogen der decideret har prøvet sabotere… HWA: Jo, jo. Nej, sabotage er nok et stort ord tyveri er nok bedre…jeg har haft folk der har fået

politianmeldelser og afskediget dem… MG: …også i forbindelse med ERP systemet hvor de er gået ind og modarbejdet ERP systemet? HWA: Nej, det er mere hvor de har bedraget, de har fundet ud af med de privilegier de havde, kunne de

gøre nogle ting. Da det blev opdaget, der har de nok fortrudt hvad de har gjort MG: I forbindelse med succes også, har i da været ude og snakke med medarbejderne rundt omkring,

hvad de synes, omkring det nye… HWA: Nej, der har været nogle spørgeskemaundersøgelser, og det er typisk uddannelse og

efteruddannelse som vi har fået slag for….og så får man altid slag på informationer op til. Dvs. når vi laver vores puls, det har vi lige gjort her i hele firmaet. Spørg folk om de synes de får nok i løn, der er ikke mange der svarer jeg, nej jeg får simpelthen alt for meget. Der er nogle svar man kan udfylde i forvejen. Det er den får de nok information inden…

MG: Det gør de ikke… HWA: Det gør de jo aldrig. Ej vi er heller ikke gode til det, det er ikke for at sidde at sige vi er gode til

det, vel. Og fik vi nok uddannelse og blev vi godt efteruddannet og var det ordentligt dokumenteret? ...synes jeg egentlig vi fik meget af, uddannelse com ci com ca, dokumentation, skidt, efteruddannelse, rigtig skidt. Behøves i ikke lave nogen analyse på, det kunne man godt gøre

MG: Nu siger du det har været en succes i har vel også diskuteret… HWA: Succes dømmer jeg på at vi er kommet fuldstændig i kontrol af værdikæden, alle de

masterproblemer vi havde, de er væk, vores fragtsystem det virker, vore data er troværdige, alt det vi startede

1:02:05 MG: Så det er nogle meget nogle hårde kontante mål i har… HWA: Leverancerne, ja MG: …I har brugt til at måle op imod? Men det er ikke kun, hvad skal man sige, det er en masse

forskellige ting i er kommet rundt om

32

HWA: Ja, det bedste eksempel. Konkret eksempel bare lige for at sige noget om det der med trust. Kan i huske jeg startede med at sige at i 99, der havde de raflet om tallene. Vi vidste ikke hvad vores salg var, siden har vi lavet en finans by og kan måle salget helt ned til varenummer og kunde. Dvs. da jeg kom her til morgen, så kan jeg gå ind og se hvad salget har været i hele verden på varenummer, per kunde, totalomsætning, på nær de fire lande der ikke er på og de betyder ingenting. Det tal det stemmer indenfor ganske få tusindkronsedler med det tal der er bogført ovre i finans. Der hvor jeg sagde vi virkelig nåede troværdigheden, det er at vi på vores intranet nu, direkte læst derfra, så alle medarbejdere kan se det. Jeg ved godt det er en lille ting, men det viser noget om tilliden til tallene. Det ville det ikke have gjort for fem år siden. Der er den her nede, det er selvfølgelige fortrolige tal men det, den dernede ikke…den viser i forhold til det budget vi har, vi har lavet det så snedigt at vi ikke viser tallene. Men den her viser egentligt at i dag, dvs. i går, det by det loader det er d. 9. til og med i nat, vel at mærke dansk nat kl. 2, kan vi se at vi har faktureret 30 % af vores budget og ordrer hvor vi har varer til for 66, dvs. vi har stort set vores maj i hus nu. Den har så ligget heldigvis de sidste 4 måneder har den ligget herude (peger på noget der ligner 133 %)

MG: Jeg har hørt det går rigtig for Jer lige pt. HWA: Kan i forestille hvad det gør ved motivationen, vi begyndte at lave den her for 2 år siden, da lå

vi og rodede herude (peger mod noget der ligner 66%) nu har vi haft fire måneder i træk hvor vi har ligget herovre (igen de 133%). Alle medarbejdere enhver operatør, selv om de ikke har deres egen pc’er der står sådan nogle flyder hist og pist. Det der vigtigt her, udover at det går godt, det er selvfølgelig vigtig, men det at vi kan eksponere tallene inden for de sidste to til tre år er ingen diskussioner taget i et tekøkken, man kigger på sig selv, hvad skal vi gøre, seks år siden, hvad er det vi er gode til.

LØO: Det giver vel også en eller anden form for motivation til folk HWA: Det er blevet meget federe MG: Har det været vigtigt for Jer at få sendt de her tal ud, så folk har kunnet se at nu går det fremad

igen med troværdigheden også indenfor virksomheden HWA: Nej, jeg tror ikke det har været en stor bevidst troværdighedskampagne, altså det vi gjorde da vi

lavede management performancerapporten, den nye… stemte af. Finde fejlene, altså få det luget helt i bund…. Det der svært lige nu, det er, nu har alle vænnet sig til at masterdata virker og tallene stemmer, så er der ikke nogen der gider beskæftige sig med at det bliver ved med at være sådan. Du ved som varmt vand og lys, man aner ikke hvor glad man for det indtil den dag man ikke har det. Det er sådan gået lidt fra at være et mega fokusområde som ingen tør røre ved fordi det er noget lort, så begynder det at virke, så kommer alle 4. maj frihedskæmperne, nøj hvor er vi dygtige, så kan de finde noget nyt de kan blære sig, det er sådan et standardbillede jeg altid bruger. De kommer, vi ved godt hvem det internt i organisationen, de kommer dem der og begynder at interessere sig for det, så er det fordi det ikke er farligt mere, så er det (systemet, red.) ved at være på toppen. I vil også se at der er folk der spiller meget rollespil undervejs. Lego Light, da det rigtigt gik hedest til, det hele var ved at gå galt, der var der visse mennesker

33

dem kunne du bare ikke få øje, de skulle bare i derover. Da vi var lige ved at være færdige, der begyndte de at rende ind og fortælle Poul, hvor dygtige de havde været. Jeg synes det er til at brække sig over. Så plejer vi som regel bare at rykke videre til det næste. Når de kommer så festen rigtig ved at være ovre.

1:05:36 MG: Har så haft en, på ledelsesmøde, en diskussion af nu har vi nået alt det som vi ville i forbindelse

med HWA: Ja, ja, uha, vi har holdt afteraction reviews indenfor teamsene også. Ja, der kører vi en, ikke

stringent proces, det vil jeg ikke kalde det, men der har været MG: Der har i været inde og evaluere hvordan er det gået og sådan HWA: Ja, men det er stadigvæk nogle kriterier man sådan, nogle af kriterierne var ikke skrevet op i

forvejen. Men det var klart at vi skulle nå tidsplanen. Vi skulle ikke tabe omsætning vi skulle holde forretningen kørende og det nåede vi egentligt. Men det er klart der vil altid være nogen der ikke med i sådan et projekt her der føler der skete noget andet end det de ville have gjort, som brokker sig. Man kan aldrig køre et stort ERP og forandringsprojekt, der ikke er ca. en fjerdedel der har en eller anden dårlig fase undervejs så har du ikke rigtig fat i noget, hvis du ikke har sådan lidt tumult, så har du ikke fat dybt nok vel. Ikke fordi jeg vil søge krigen, men der skal være lidt…

MG: …der skal være opbrud et eller andet sted… HWA: …der skal være opbrud, ja, rigtigt, for ellers har man ikke rigtigt, hvad er det så vi er i gang

med MG: Du havde sådan en slide, jeg tror faktisk det er den du har til at ligge… HWA: Jeg har en, vi er lige gået lidt over tid, jeg har en aftale kl. 16 i hvert fald, hvor de kommer

herind, så skal i være…jeg ved godt jeg selv har stjålet noget af tiden MG: Ja, forhåbentligt varer det ikke så lang tid mere. Du havde en slide tror den ligger lige bagved

(et andet åbent vindue på computeren end den der var fremme) med nogle principper, er det sådan de fem ting, du vil sige, der sådan er det vigtigste i en forbindelse med…

HWA: …det er noget der er skrevet efter projektet. Det var ikke noget der var skrevet inden projektet,

det der var faktisk noget jeg lavede fordi jeg skulle holde et indlæg om det til foreningen af danske SAP brugere…

MG: …men hvis du nu skulle ud og…

34

HWA: Jeg vil bruge de der to der (slides 21 og 22) og den ene fortæller om, jeg vil sige den her…om forudsætningen har. Den anden fortæller dig om hvordan man kommer derhen. Men der er også forskel på ERP platforme, ERP systemer eller implementering undskyld. Er det noget du vil implementere i en virksomhed der har en adresse i en by. Der er ikke noget med tidsforskel, der ikke noget der hedder kultur, du har ikke, der er grænser for hvor indviklet det kan blive. Ikke for at nedgøre det, men det er en opgave eller står du med en hvor du skal køre ind i 50 selskaber, nogen der er presset, der er truet, der er opbrud, står du med en organisation hvor der er interne stridigheder? Fordelen, der er mange der kan have en mening om Poul Plougman, det har jeg da også selv, men fordelen ved Poul var der var ikke nogen der turde …kom de for voldsomt på tværs af ham så var det ud, det var der ellers mange der kom og der var også mange der kom ud, både retfærdigt og sikkert (også uretfærdig, red.). Det gælder om uanset hvor stor ERP implementeringen er at ledelsen er med. Og er der nogen der kan falde dig i ryggen så er det din ledelse, falder den dig i ryggen så er du sådan set på skideren. Den kan til gengæld hjælpe dig, hvis der er nogle andre der falder dig i ryggen, oversat, hvis du forstår at bruge den. Så kommer det med organisationen er den klar til det her, bøvler du stadigvæk med det, hvis du er vant til at have en organisation hvor de er, hvad min chefs far kaldte über die maur verdenen, altså hvor de sidder og arbejder i siloer, giver hinanden opgaverne sådan der (tegner på tavlen). Hvor du har ligesom den gamle stempelfest, du har en indbakke så ligger der nogle stykker papirer og nu er jeg ikke meget for offentlig forvaltning…det eneste jeg skal koncentrere mig om det er om…at folk der tænker meget i silo, det har vi selvfølgelig stadigvæk, det har alle organisationer. Det vi gør, det vi har gjort, det har gået op for mange det her…det her er der altså mange derude i vores hold der kan tale i mange flere timer end jeg kan også, men det der med at når jeg tager en salgsordre, vores franske salgsselskab nu i dag, dem satser vi på i nogle bestemte…så reserverer jeg vare…vores lager over i Jirny hopper fra. De varer jeg tog her dem kan Italienerne ikke sælge nu for dem jeg reserveret til mig. De sletter en ordre italerne, portugiserne gør eller England gør, selv om jeg ingen varer havde nu, så om ti minutter har jeg varer, de der sammenhænge, hvor det var sådan en butterfly effect, at hvis det er at de slår lidt med halen så…hvis jeg gør ind, hvis jeg går ind og snyder så snyder jeg jer, den der, fra at gå fra funktionel silotækning, det her er kun mature-…det er ikke noget med om man er truet og det er nemmere at lave store ændringer når man har et eller andet trusselsbillede, det havde vi så massivt ik, vi har været på til at være, nogle snakkede om salg ik’. Er organisationen klar til det? Både om den er mentalt klar til det burde vi så gøre noget, altså adrenalintrykket er simpelthen højt nok…

MG: Men om os den… HWA: Er den intellektuel klar til det her ik’ os’. Vi var lige inde på uddannelse før, vi har simpelthen

uddannet, jeg har lavet, vi gik gang med og forsøge forklare, slå lige skyklapperne ud, prøv at se når du tager en salgsordre, det er det her du sætter i gang. Der forestiller man sig at det der process expert network vi talte om, det kalder vi ”order to cash” for at folk kan forstå, at ordrerne er her, den proces vi taler om…og hele vejen ud. Det der interesserer os er forbindelsen mellem de to. Der skal foregå temmelig meget, de ligger et forecast ind herude, hvor meget vil jeg sælge i juni, juli og august, så skal jeg være klar at så starter de…-maskiner op på kornmarken, og det gør de, hvis de siger, jeg må hellere lige, jeg reserverer måske lige 100.000 ekstra, skidt med at jeg ikke sælger dem, …så ligger de på lager, den forståelse og

35

sådan, det er også en del af det her ik’. (banker på tavlen, organisation mature for change, slide 21) mega kæphest master data and processes, få bygget strukturen, jeg vil vove påstand, hovedparten af de SAP implementeringer der går galt de går galt på noget af det her, det her er en af dem, at de simpelthen ikke sætter sig ind i de strukturer de vil ligge dem i og det er sådant noget banalt som hvordan er den juridiske selskabsstruktur, hvad bruger vi company koden til og hvor mange salgsfunktioner har vi, nu bruger jeg en masse SAP-ord i sikkert ikke kan bruge til noget. Den her (peger på regain trust and credibility, slide 21) og den her er selvfølgelig meget skrevet til os. Vi var ude af, vi havde nægtelsen af den her, så der ved jeg ikke hvor generisk den er, den der tror jeg er meget generisk (peger på tavlen) den der forudsætter selvfølgelig du har lost trust og credibility, den skulle vi så regaine, den der generisk (banker på tavlen). Når du først har lavet din ERP platform, hvilken change proceduce kører du så, selv om du laver verdensflotteste platform så selvfølgelig skal den (videreudvikles, red.) . Lige så hurtig som du kan lave, lige så hurtigt kan du ødelægge den.

MG: Et eller andet sted så handler det om topledelsens engagement, det handler om organisationens

modenhed… HWA: …modenhed, har de viden til overhovedet gå ind i det, har organisationen overhovedet et team,

kan du stille hold… MG: …og BPR i samme proces HWA: …ja… MG: …at få det lagt om til det, og så handler det om at få styr på sine data… HWA: …ja… MG: …og så ikke mindst bevare troværdigheden omkring… HWA: …ja enten genetablere eller bevare den afhængig hvor man lige kommer fra og så finde

procedure på hvad gør vi så når projektet er ovre MG: dvs. du, hvis vi nu skulle se det så som en implementeringsproces, så starter den helt fra den

første idé og så skal den køres hele vejen indtil systemet engang… HWA …altså full life cycle, hvis jeg skulle skrive den opgave MG: …så det handler om at køre den hele vejen, den fortsætter hele vejen igennem HWA: …ja du har nærmest sådan, du har, du har nærmest sådan en livscyklus, dvs. du har din idé, så

har du dit project, så har du din udvikling/videreudvikling og så har du på en eller anden måde også din afvikling, hvordan kommer man ud af det igen, enten fordi du skal op og have noget nyt der kommer den vej der eller at du skal opgradere, ja, eller du skal lukke. Altså afvikling

36

her, vi skulle lige pludselig koble de der 4 parker plus 3 holdings ud ikke, de røg jo lige pludselig mod uendeligheden…vi skal lige passe på tiden

MG: Ja, lige til slut kunne jeg godt tænke mig at spørge om der er noget som du mener der kunne

være vigtigt i forbindelse med vores opgave, som vi måske ikke lige har været inde og snakke omkring

HWA: Altså jeg vil, med fare med at gentage mig selv, jeg vil meget gå meget op i at man skal være

objektive, det er fjerde gang jeg siger det, kriterierne for hvorfor vil man ERP. Er det integrationen man søger, er det økonomisk rationale i integrationen, altså integrationen er det målet eller midlet til at spare penge, det hænger uløseligt sammen, hvad er det ledelsen, vil vi køre SAP for so ein ding müss wir auch haben, vil man bruge en ERP implementering til at ryste organisationen…

MG: …det mener du godt, det sidste det mener godt man kan gøre med et vist rationale… HWA: …ja… MG: …men ikke den første, bare fordi, bare have ERP for at have ERP, det er ikke…. HWA: …det er et…vi har et lille firma, min kone kører, hvor vi sælger…, hvor vi også har Navision,

der kører vi ikke lagerstyring og indkøb. De der 24 hyldemeter, det kan hun overskue på bagsiden af en kuvert. Nå, men altså, man skal tage, altså de griner også af mig herude for, hvad vi render og laver her, hvorfor kan vi ikke engang have det derhjemme, min kone har også været ansat her, men vi har ikke brug for det. If it ain’t broke don’t fix it, altså lad være med at og så vil jeg sige i bør køre meget i det der med enkeltheden. Altså et ERP valg kan også være forførende. Og vi er lige så, vi har også det der akademiske gen som i har, vi kan godt lide at vise at vi har de mentale hestekræfter, vi kan godt det her, men lad være. Lad det være sådan lidt, jeg ved ikke om ikke kan skrive Jysk bonderøv i Jeres opgave, men der skal være sådan en bonderøvs tilgang til det

LØO: Ja, man kan tage den der KISS, keep it simple stupid HWA: Ja, KISS er et godt ord for det LØO: Der er ikke sådan noget, i og med vi kører meget på det globale ikke…. HWA: …jeg ville kigge meget på i bør nok komme lidt omkring risiko, både risikovurderingen ved

projektet, risikoen ved driften og risikoen ved ikke at gøre noget. Vi var ulige, vores risiko var hvis vi ikke gjorde noget, at det så også kunne være gået galt da vi gjorde det, det var så ligegyldigt. Har man point et point of no return eller kan man ændre noget…

MG: …altså noget med at have en business plan til at, at starte på eller sådan noget…

37

HWA: …ja, første mål må være, hvad er det vi vil opnå med det her, hvis vi gør det, hvad er risikoen ved det. Vi havde lange snakke om hvad gør det ved vores kunder, vi skal ud og forklare dem de her terms and condition. Meget omsætning koster det, 100 millioner i omsætning? Det er altså ikke sjovt at sidde og snakke om når det går ad helvede til. Så risikovurdering generelt, både etablering og drift. Jeg vil også sige noget med videns forankring i virksomheden. Vi har jo, nu skal jeg ikke sidde og lyde arrogant, vi har en vis viden inhouse, kan i godt høre.

MG: Har i mistet noget? HWA: Meget MG: På grund af at folk de er blevet ERP konsulenter nærmest? HWA: Da Oracle kom der var der mange af vores SAP der gik. Og så valgt vi at outsource hele vores

SAP customizer Accenture, det gik ikke ret godt, så nu har vi ansat dem vi skal bruge, ikke mindst pga Accenture. AP Møller og Mærsk har jo valgt en anden model, de har jo ekstern partner til det hele. Jeg forstår ikke de tør

MG: Mener I ikke at vedligeholdelse det er noget man skal outsource sådan… HWA: Det kan du godt, jeg mener meget personlig holdning, du skal have viden nok til at kunne gå i

dialog med din rådgiver… LØO: …ja, så du ikke bare lader det, så du har en vis idé om at… HWA: …ja, man skal i hvert fald kunne møde dem midt på banen. Derfor vil jeg nok også i et punkt

som vidensforankring, altså hvilket vidensniveau kræver det. Hvordan organisere man sig omkring at opretholde den, etablerer og opretholde det nødvendige vidensniveau også fordi problemet er du vil skulle etablere noget viden i starten, der har du et stort behov når du implementerer, du har sådan en pukkel, der kunne man godt sige man kunne få etableret det jeg der…kunne man få etableret den viden der ligesom er den her (markerer bundlinje i tegning) og købe det her oppe. Meget banal model, men spørgsmålet er, hvor meget vil du have herude og risikobetragtning har du nok til at gå i gang. Det havde vi jo, fordi vi havde prøvet 3 gange, kan man sige, 2 gange…

MG: …hvordan og hvorledes med Jeres…. HWA: …og hvordan ser det ud fremadrettet… 1:17:00 MG: Hvordan og hvorledes med Jeres gamle system, nu skal jeg nok prøve holde det meget, hvordan

har det påvirket Jeres nuværende eller Jeres sidste implementering her? HWA: Vi konverterede nogle af masterdataene uændret, vi har fået nogle, nu skal jeg lige skyde på

mig selv jeg har fået på nogle af kundeattributterne har jeg fået nogle skæverter med ind

38

MG: Jeg tænker også lige så meget, var der en del processer der har været fastlåste eller folk har haft, som har været vant til at gøre tingene på en måde…

HWA: Jo, vi havde nogle vi skole aflære noget på, ja, til gengæld fik vi også meget god viden med, jeg

er lidt efter vores gamle det var ikke ad helvede til vel, altså rent vidensopbygningsmæssigt, lærer du mere af…

MG: Det er så også fordi i har haft SAP før… HWA: …ja, det må være værre der lige kommer i det for første gang, puha MG: ja, for hvis de har en de her 20-30… HWA: …en lille detalje i bør have med det er for øvrigt at hvis man skifter til et ERP system så er der

opbevaringspligt og regler. Regnskabstal, så man skal holde liv den gamle, den har vi stadigvæk, man skal holde det gamle svin kørende bagefter…

LØO: …i fem år eller sådan noget? HWA: Ja, afhængig hvad land du er i, nogle lande er det 10 år, så hvis du kører en global en, så skal du

have en eller anden minimum grad af plan for hvordan du holder liv i det gamle, altså både servers, hvis du skal skifte teknologi og styresystem og pis og lort. Jeg har ikke ret meget forstand på det jeg ved bare det er noget bøvl.

MG: Ved du hvad jeg tror ikke vi har så meget mere HWA: Det tror jeg heller ikke, vi ikke andet end 5 minutter, nej vi kom lidt senere i gang, det passer

meget godt den tid vi har aftalt 1:18:20 LØO: Hvis du nu tænker det globale, hvad har været mest vigtigt for Jer, hvis du skulle nævne en eller

to ting? HWA: Jeg kan ikke nævne en ting, der kommer lige en svada. Performance: det skal gerne køre lige så

hurtigt i Japan og i USA, som det gør i Billund, for ellers ligger folk det fra sig. Sprog. MG: Hvad med kultur, har I haft problemer med kultur. HWA: Nej, min vurdering er, at de største kulturproblemer vi har haft, det har været i Billund. LØO: Dvs. den største udfordring indenfor kultur, det er sådan set internt. HWA: Ja, altså, selvfølgelig har vi haft noget bøvl med nogle kolleger, men det var ikke fordi de var… MG: Men det har mest også været pga. sprog, det har ikke været så meget pga…

39

HWA: Nej, generelt modvilje imod forandringer. Måske er der lige blevet fyret fire af dem de godt kunne li, det var lige da vi kom, og nogle andre motiver. Jeg føler ikke kulturen sådan har været. Altså, der har været noget fagligt svært i det, fordi, hvordan er moms setupet lige i Italien og hvordan med fakturaerne…

MG: Så det har lige så meget været med de forskellige love i de forskellige lande… HWA: Altså med et globalt setup og en central administration som vi har, der kræver det man er

rimelig godt dækket ind med sine revisorer, for ellers opdager vi jo ikke, at der kommer regelændringer. Hvordan sku vi opdage det? Så man skal ha’ en briefing mekanisme der fortæller en at, nu kommer der ny moms.

MG: Har det været nemt at lave forskellige setup for de forskellige lande? HWA: Ja, det vil jeg være arrogant nok til at sige. Altså, vi har ikke sådan fundet nogen, jo Rusland var

noget bøvl, fordi de kører det der parallelsystem. Hvis nogen siger, de ingen fejl har lavet, så enten er det gået enormt langsomt, eller og så sidder de og lyver for Jer. Altså, jeg glorificerer det lidt, I skal nok lige trække 30-40 % fra…

40

Bilag 7: Slides fra LEGO

LEGO Company10 year with SAP R/3 in LEGO Company

Henrik Weis Aalbæk

Slide 1

• LEGO Company - history & structure

• LEGO Company - the latest decade

• The LEGO Light Program

• Worth remembering

• Questions

Agenda

Slide 2

41

LEGO Company

- history and structure,

Slide 3

LEGO Company - history

• Founded in 1932 by Ole Kirk Christiansen

• ”LEG GODT” LEGO

• One global brand company

• 8000 employees

• Family owned Kjeld Kirk Kristiansen

Slide 4

42

Concept and product developmentDenmark and UK

Production:Moulding in Denmark and SwitzerlandProcessing in Denmark, Switzerland, CheckPacking in Denmark, Switzerland, US, Korea, Check Republic

Markets:More than 130 countries + Brand Retail

Where are we

Slide 5

LEGOLAND ParksDenmark, UK, US, Germany

LEGO Virtual

LEGO Lifestyle

LEGO Educational Division

We are more than toys

Slide 6

43

The three Generations

QualitySystem

Brand

Slide 7

LEGO Company

- the latest decade

Slide 8

44

The latest decade – the “management phases”

1995

LEGO Fitness

Compass ManagementSpeeding up Compass Management

LEGO Light Program start

LEGO Light Program Implement

Key words

“Waking up theorganization”

Majorstructural changes

1200 leaving(of <10000)

Standardizationand globalization

Integrating the valuechain even further

1996

1997

1998

1999

2000

2001

2002

Market regions established• Europe Cental• Europe South• ….Administrative centers established• Billund• Switzerland• Americas• …...

…..

2003

2004

Planning2Play

Slide 9

The latest decade – the philosophy evolve

1995

LEGO Fitness

Compass ManagementSpeeding up Compass Management

LEGO Light Program start

LEGO Light Program Implement

1996

1997

1998

1999

2000

2001

2002

…..

2003

2004

Planning2Play

Local management, Local management, processes and systemsprocesses and systems

Global Management, Global Management, processes and systemsprocesses and systems

Global ManagementGlobal Managementlocal processes and systemslocal processes and systems

Slide 10

45

The latest decade – the SAP philosophy evolve

1995

LEGO Fitness

Compass ManagementSpeeding up Compass Management

LEGO Light Program start

LEGO Light Program Implement

1996

1997

1998

1999

2000

2001

2002

…..

2003

2004

Planning2Play

Stand alone BoxesCountry specific set-upNo standardsLocal Managed

Central Hardware Global set-upGlobal standardsGlobal Managed

Central HardwareUnion of local set-upNo / some standardsManagement ?

Slide 11

LEGO Company

- the LEGO Light Program

Slide 12

46

• What was LEGO Light ?

– Optimize, Standardize and globalize• Business Processes• Masterdata

– Simplify

– Document, Educate and train current and new colleagues

The LEGO Light Program

Slide 13

• Why LEGO Light ?

– The management at all levels has lost confidence in • process platform• information platform

– Rationalizations from the merger of sales areas into regions andadministrative centers hard to achieve due to fragmented and different Business Processes and masterdata structures - facilitate centralization.

The LEGO Light Program

BasicallyEstablish a global, efficient and simpler

operational platform for LEGO Company.

Slide 14

47

The LEGO Light Program

GlobalStandards

LEGOLight

BusinessInformationWarehouse

Global Information√ Consistent√ Relevant√ Reliable√ Quick

Simplicity

Create the platform !

Simplify the Business Processes !

Bring order in the informationWarehouse !

tEnd ‘99 End ‘02

Slide 15

The LEGO Light Program - mindset

Back to Basic Business Model

BasicModel

Refinements+ non-management

CHAOS!

Slide 16

48

The LEGO Light Program - mindset

Back to Basic Mindset

LEGO iscomplex!

LEGO issimple!

We are special here!

We areglobal!

Slide 17

The LEGO Light Program - mindset

LEGO Light Headlines

Data “chaos” Consistentinformation

Complexbusinessprocesses

Simplebusinessprocesses

Specialities Global solutions

Slide 18

49

The LEGO Light Program - mindset

Implementation

Brutality Say no - in a competent way

Not democracy Main Principles

Not prove everything

Accept risk

Defence speeches Break the circle of details

Slide 19

• One Global Brand Company with• One Organization• One Chart of account• One Cost / profit center structure• One Global Customer hierarchy• One Material structure• One ………..

The platform consist among other things of

We now have to fight to remain as listed above!

Slide20

50

Worth remembering – it’s a long journey!

Management commitment Management commitment

Organisation mature Organisation mature for changefor change

Master data and processesMaster data and processes

Regain trust and credibilityRegain trust and credibility

Protect and developProtect and develop

Slide 21

Worth remembering – the path to victory is not the sexy route!

Overall Business structures Overall Business structures & requirements to flexibility& requirements to flexibility

Scenarios for overall Scenarios for overall structures & processesstructures & processes

Finance, reporting, Master Finance, reporting, Master data, flow of good etc. modeldata, flow of good etc. model

Dedicated teamDedicated teamBig enough to solve taskBig enough to solve task

Small enough to be efficientSmall enough to be efficient

Sustainable platformSustainable platform

Slide 22

51

Questions

?

Slide 23

52

Bilag 8: Uddybende svarmail fra LEGO Mail sendt til Henrik Weis Aalbæk med opklarende spørgsmål – sendt d. 2. juni 2006. Hej Henrik Onsdag d. 10. maj, var min makker og jeg i Billund for at foretage et interview med dig. Jeg henvender mig nu, da jeg har nogle supplerende spørgsmål, som jeg håber at du har tid og lyst til at hjælpe mig med. Spørgsmålene er: 1. Hvor langt nåede i med Oracle, nåede i at tage det i brug, i så fald hvor? 2. Er det muligt at få alle main principles oplyst og hvor vigtigt mener du disse main principles har været for Jeres implementering? Vi fik udleveret nogle slides som du bruger når du skal fortælle om Jeres implementering. (filen hedder FSD november 2004) Slide 21 3. Regain trust and credibility, skal dette ses i forhold til virksomheden, i forhold til systemet eller begge og hvad har det af betydning at man ikke har ovenstående? Slide 22 nævnte du var vigtig for os, desværre fik jeg mig set blindt på slide 21 under interviewet, derfor mangler vi lidt information omkring 3 af klodserne. Hvad de dækker over og deres betydning. Det er klodserne: 1. Scenarios for overall structures and processes 2. Finance, reporting, master data, flow of good etc. model 3. Sustainable platform Hvis du har lyst må du meget gerne skrive en mail med svar til de ovenstående spørgsmål. Hvis du mener at de ovenstående spørgsmål lettest kan besvares ved en telefonsamtale, er dette ikke noget problem, så skal vi bare lige have fundet et tidspunkt, hvor denne kan finde sted. På forhånd tak Med venlig hilsen Morten Gunnersen

53

Svarmail fra Henrik Weis Aalbæk til ovenstående mail – modtaget d. 7. juni 2006 Hej Morten Omkring Oracle - vi lavede vores 2001 budget i Oracle - d.v.s. vi implementerede budget delen af finans applikationen. Logistik, kalkulation, ordreflow m.m. blev ikke implementeret. Main principles vil jeg helst ikke sende til jeg - jeg mener klart at disse var og for en dels vedkommende stadig er med til at drive den måde vi tænker på. Specielt omkring simplicity og det at lave globale løsninger. Slide 21: Regain trust and credibility - dette går på strukturer, processer og systemer. Slide 22: 1. Scenarios for overall structures and processes Dette er forbrænderen til punkt 2. D.v.s. forskellige scenarier på hvordan man kunne lave sin overordnede struktur og model. 2. Finance, reporting, master data, flow of good etc. model Dette handler om at udarbejde en overordnet sammenhængende model for virksomheden hvor masterdata, logistik, finans, performance rapportering, planlægning versus aktuel m.m. integreres - d.v.s. vælge blandt scenarierne beskrevet i punkt 1 og detaillere disse yderligere. 3. Sustainable platform Sikre at de strukturer og processer der er lavet kan opretholdes over tid. F.eks. sikre at der er fleksibilitet hvor dette er krævet. Hos LEGO Koncernen har vi f.eks. omorganiseret mere end 1 gang om året siden vi implementerede - her er fleksibilitet vigtig. Modsat har vi visse ting som f.eks. varenummer struktur der er religion - her er der i grundstrukturen ingen fleksibilitet. Omkring sustainable er der også change processen - d.v.s. hvordan ændres strukturer, processer og systemer - verden står jo ikke stille så en change process er vigtigt for ikke langsomt men sikkert at ende i kaos igen. Jeg håber ovenstående svar hjælper jer videre Held og lykke med jeres opgave. Henrik

54

Bilag 9: Spørgeramme for Grundfos - Baggrundsspørgsmål:

o Informantens baggrund og rolle i den nationale og globale ERP implementering o Præsentation af deres ERP implementering og udrulning

Udrulningen af ERP systemet Lande og moduler Central/decentral styring Top-down el. bottom-up Graden af integration og samarbejde på tværs af afdelinger Motiver bag ERP implementeringen

• Forretningsmæssige • Økonomiske

- KSF’erne i den globale implementering: o Væsentlige fokuspunkter i forbindelse med global ERP implementering

Appropriate business and information technology legacy systems Business plan and vision Business process reengineering Change management culture and program Communication ERP teamwork and composition Monitoring and evaluation of performance Project champion Project management Software development, testing, and troubleshooting Top management support Culture Politics

o Udfordringerne i en global implementering Stand alone vs. Global implementering

- Implementeringsforløbet o Hvor Grundfos ligger i implementeringsforløbet (Markus og Tanis)

- Succesbegrebet: o Succesopfattelse af den globale ERP implementering

Succeskriterier for vurdering af implementeringen • Økonomiske/hårde/målbare kriterier • Bløde kriterier

o Medarbejder-/stakeholdertilfredshed Personer involveret i opstilling og vurdering af disse kriterier

- Afsluttende spørgsmål: o Er der noget vi ikke har været inde omkring, som du mener, kunne være interessant for

vores opgave?

55

Bilag 10: Interview hos Grundfos Transskribering af interview med John B. Nielsen fra Grundfos d. 24. maj 2006. Lydfilerne til dette interview er vedlagt i bilag 14. JBN: John B. Nielsen MG: Morten Gunnersen LØO: Las Øhlenschlæger Olsen Lydfil 1 Grundfos 0:00:00 LØO: Det vi egentligt gerne vil starte med at høre, det er din tilknytning til Jeres SAP implementering,

hvad rolle du har haft i det. JBN: Jamen jeg startede med at arbejde med SAP lige efter jeg var værdig med at læse, kan man sige.

Det var tilbage i slutningen af ’88, hvor jeg blev ansat i Birkerød i Mobil Oil’s danske filial, hvor jeg var et halvt år i som trainee. Nej jeg blev ansat i august der, hvor jeg så var et halvt år som trainee i en logistikafdeling, og i januar 1990, der startede vi et SAP projekt der i Birkerød. Så har jeg så været involveret i SAP projekter lige siden kan man sige. Jeg var 6 år i Mobil og havde ét år, hvor jeg var dels ekstern konsulent, dels var nede at vende på Danfoss i Nordborg, og kom så her til Grundfos i ’97, hvor jeg så har været siden, hvor jeg arbejdede som SAP konsulent indenfor PP/MM området primært. Jeg var med Grundfos i et år i USA, hvor jeg var med til at implementere SAP på fabrikken derovre. Jeg kom tilbage i 2001, hvor jeg fik ansvaret for én afdeling indenfor vores SAP kompetencecenter og i 2004 fik jeg så det overordnede ansvar for SAP i Grundfos koncernen. Så det er sådan set på stort set alle niveauer i det at arbejde med SAP og SAP projekter, at jeg har været involveret.

0:01:44 LØO: Dvs. det er med udrulninger også i de forskellige lande, som du siger med starten i USA? JBN: Ja. Jeg har sådan en lille standardpræsentation vi lige hurtigt kan gå igennem her. MG: Er det noget vi kan få adgang til? JBN: Den her? Ja, det kan I sådan set godt, det kan I egentligt godt. Ophold, hvor han henter de omtalte slides 0:02:22 JBN: Sådan som SAP ser ud i Grundfos i dag, så har vi lige sådan knap 6000 brugere på SAP fordelt

på det vi kalder salgsselskaber og produktionsselskaber. Produktionsselskaber det er fabrikker.

56

Grundfos management og business development center, det er faktisk, det er ledelsesselskabet her i Bjerringbro. Der er også et stort produktionsselskab med alle fabrikkerne her i Bjerringbro. De hører så under Production companies, men selve ledelsesselskabet, det er det der ligger under her. Så der er omkring 6000 brugere, knap og nap på SAP systemet i Grundfos (slide 4 red.)

Vi driver ikke selv vores servere, dem har vi outsourcet til CSC i København, hvor maskinerne

står derovre og det er ét stort system, så alle SAP brugere i Grundfos, hvad enten de sidder i Amerika eller Kina, eller hvor de sidder henne, de kører på nogle servere, der står i Tåstrup i København.

MG: Det vil sige, det er det man kalder et globalt system som kun kører på én central server? JBN: Ja, det er det, det er ét globalt system. Vi har ikke sådan mange SAP systemer. Et til hver region

og et til hver verdensdel, det er ét stort system vi har. LØO: Er det noget I sådan har været bevidst om fra starten af, at det skulle være ét centralt, stort

system? JBN: Vi startede ud med, at ha’ nogle overvejelser om, at vi på et eller andet tidspunkt, måske når vi

engang kom til at skulle rulle i USA om vi så måske der på et tidspunkt sku’ ha’ to systemer. Men jo tættere vi kom på udrulninger, f.eks. i USA, jo mere bevidste, jo mere sikre blev vi på, at hvis det overhovedet var teknologisk muligt, så var det det eneste rigtige at gøre, at køre på ét stort system. Det har vi bestemt ikke fortrudt, at vi har gjort det på den måde. For det første er det jo selvfølgelig langt billigere at drive ét system, selvom det system selvfølgelig er noget større og noget dyrere end fem mindre, men bundlinien er, at det er i hvert fald langt billigere, at drive et system.

Hvis man ønsker en hvis grad af harmonisering og standardisering, så er det også langt langt

nemmere at opnå det med ét system, fordi. Der er ikke noget at gøre, i mange tilfælde så er man nødt til at gøre tingene på én måde, kan man sige. Og det er også meget nemmere at, hvad skal man sige, sikre at man gør tingene på én måde, når det kun er ét sted man skal gøre det, i stedet for man skal til at gøre det, i stedet for at man skal til at gøre den samme ting i fem systemer f.eks. Så det er en bevidst beslutning, det er det.

0:05:06 JBN: Den her den viser sådan en lille smule om, hvordan udviklingen har været mht. SAP brugere og

hvilke Grundfos selskaber som henover de sidste år har implementeret SAP. Der hvor vi så er mht. selskaber som kører SAP, det er dem der er angivet med rødt her(slide 15 red.). Det er de salgsselskaber i SAP koncernen, der kører på det her SAP system. Dvs. at alle selskaber i Vesteuropa de kører SAP. I Østeuropa, der har vi indtil nu kun Østrig og Rusland. I Østen, der har vi Australien og New Zealand. Taiwan og Kina de kom på her for en uge siden faktisk, hvor de gik i luften. Vi har projekter kørende i Ungarn i salgsselskabet der plus vi har et projekt kørende i USA, hvor vi har købt en virksomhed derovre, en pumpevirksomhed i Houston i Texas og der kører vi så også et SAP implementeringsprojekt nu. De skal op at køre der.

57

LØO: Dvs. og resten det er salgsselskaber, hvor der så ikke er SAP inde endnu?(slide 15, hvor

landenavne er noteret med blåt, red.) JBN: Ja, de her Indien, Korea og hvad der ellers står, det er salgsselskaber, som kører andre systemer.

Det kan være, det er primært Scala. Jeg ved ikke om det er noget I har hørt om, men det er faktisk også et rimeligt stort system, udbredt system – ikke så meget i Danmark, men i resten af verden, der er det sådan set. Og de kører så Scala, de fleste af dem i hvert tilfælde, men det er sådan set planen, og det er også vedtaget, at de skal køre SAP på et tidspunkt. Det er et spørgsmål om tid, hvornår de kommer op at køre.

Og det er kortet for produktionsselskaberne. Der er ikke så mange steder hvor vi producerer

som vi sælger. Der er vi faktisk ved at være igennem. Kina de gik så også på SAP samtidigt med salgsselskabet her tidligere på måneden og de her to fabrikker vi har i Italien og Schweiz, det er sådan noget småtteri, det er slet ikke sikkert de skal bliver ved at ligge der og de kommer heller ikke på SAP, det gør de ikke. Det eneste sådan lidt større, det er faktisk Sydkorea som ikke kører SAP og som ikke umiddelbart er i planen, kan man sige.

SAP udrulningen i Grundfos. Ja, den er jo selvfølgelig ikke færdig, vi mangler stadigvæk en del

mindre, det her det er mindre salgsselskaber kan man sige, de betyder ikke så meget volumenmæssigt i det store billede. Så vi er faktisk kommet temmelig langt, det er vi.

0:07:53 JBN: Ja, mht. organisering af SAP i Grundfos, så har vi en central SAP organisation, som er baseret

her i Bjerringbro, hvor jeg er chef for den organisation med reference til vores vice president indenfor IT (Karsten Steen Sørensen, red.). Det er kun medarbejdere i den her organisation, der kan rette i SAP systemet, som kan kostomisere, ændre i programmer osv. osv. Vi har ikke, vi har udenlandske SAP medarbejdere, som er den del af denne her organisation, som ikke er fysisk placeret i Bjerringbro, men det er ikke sådan, at hver fabrik har deres egen lille IT afdeling som så piller lidt en gang imellem, det har vi ikke og det skal man nok heller ikke ha’. Vi er 83 medarbejdere totalt i SAP CC. SAP kompetence center, som vi kalder det, globalt, hvoraf de 20, par af 20 eller sådan noget, sidder udenfor landets grænser og resten sidder her i Bjerringbro.

LØO: Dvs. altså det CSC har med det at gøre, det er kun rent servermæssigt, de har ikke noget

medarbejdere derovre som er tilknyttet ud over det? JBN: Nej, det er rent drift. Det er at sørge for at holde strøm på computerne og sørge for at

databasesystemet og operativsystemer og sådan noget det fungere og er opdateret. Det er der snitfladen er, kan man sige, det er driftsfolk som tager backup’ere og ting og sager og sådan noget der ik’.

0:09:24

58

LØO: Så lidt omkring… sådan Jeres motiver bag at implementere SAP. Forretningsmæssige og økonomiske. Nu sagde du, at det var billigere at køre ét system. Hvor var Jeres motiv fra starten af, da I besluttede, at I ville køre SAP?

JBN: Det var, at en række af vores vesteuropæiske selskaber, de havde år 2000 problemer dengang i

slutningen af ’90’erne og der skulle findes et alternativ til det. Der blev det besluttet, at vi ville indføre SAP R/3 i de vesteuropæiske salgsselskaber. Og der var det jo så at vi havde de indledende diskussioner om, hvad så, sku’ man så ha’ ét system for de nordeuropæiske lande og sku’ man ha’ et andet for de sydeuropæiske lande osv. osv. Men vi har altid kan man sige, implementeret SAP, eller selskaberne i det samme SAP system.

Det er jo ikke sådan at der dengang i 1996 var en stor forkromet vision om, at Grundfos

indenfor de næste 10 år sku’ køre i én stor, på ét stort system, det var der ikke. Det kunne man sikkert heller ikke for 10 år siden rent teknologisk, det er jeg ikke sikker på at man kunne, men det kan man i dag, kan man sige. Så man kan sige, motivet til at starte med SAP, det var, det var sådan rimelig lav praktisk, at vi skal ha’ løst år 2000 problem ik’!? Men det har også noget at gøre med, at Grundfos dengang, det var nok mange større koncerner, var noget mere decentrale. Der var noget større autonomi i selskaberne rundt omkring i verden. Vi havde en fabrik i Frankrig og den havde nogle produkter, den skulle levere. Den skulle levere i henhold til nogle aftalte tider osv. osv. og bare den gjorde det, så var det godt. Så var der ingen der blandede sig så meget i herfra, hvordan de så egentligt fik det til at ske. Bare de fik leveret det de skulle og overholdt deres budgetter og sådan noget ik’, hvor man jo i dag meget mere jo, har gjort i nogle år jo, snakker om indre markeder og globalisering og supply chain processer på tværs af landegrænser på tværs af kontinenter osv. osv. Jo mere det sådan kom op, jo mere viste det sig at være en rigtig klog beslutning dengang, at køre i ét stort system. Det er langt langt nemmere.

0:11:43 LØO: Dvs. dengang der var, der kørte I meget autonomt med nogle af dem, nogle af Jeres selskaber? JBN: Ja, det gjorde de dengang, det gjorde de. Der var selvfølgelig standarder man skulle overholde

osv. ik, men der er helt klart en tendens til, at indenfor de sidste 10 år, at man fra centralt hold går ind og styrer nogle processer i selskaberne, end man gjorde for 10 år siden. Det er meget nemmere at gøre det, kan man sige, når man har et centralt system på den måde her.

MG: Var det så sådan at det var stand alone systemer, de første SAP systemer der kom ind i udlandet.

Altså du siger, at I havde nogle år 2000 problemer? JBN: Nej det var det ikke. Det var ét system som vi startede med og så gradvist hældt dem ind på. Så

vi har altid kun haft ét SAP system i Grundfos, som jo så er vokset og vokset og vokset med årene her.

LØO: Så lidt med fokuspunkter i Jeres ERP. Hvis du sådan skulle nævne nogle centrale ting, I har

fokuseret meget på.

59

JBN: Det er jo selvfølgelig først og fremmest drift og stabilitet. Det er jo at system kører og der er ordentlige svartider overalt i verden. Det er jo i hvert fald farligt at undervurdere betydningen af det. Hvis systemet ikke kører, så er det jo sådan set ikke ret meget værd, at det ville have været smadder smart, hvis det kørte jo. Det er jo noget man skal bruge meget tid på og det. Jeg ved ikke om det lige er den indfaldsvinkel at I har til det, det er jo nok en lidt anden indfaldsvinkel ik’ eller interesseområde ik’, men det er da i hvert fald meget væsentligt, at det er på plads, kan man sige.

0:13:28 LØO: … da I implementerede SAP, altså selve implementeringen i det, hvad der har været af

fokuspunkter der, for at nå de mål I nu havde der. JBN: Hvad forstår du med et fokuspunkt i den forbindelse der? LØO: Kritiske succesfaktorer, sådan som projektledelse, topledelsens arrangement og… JBN: Kritiske succesfaktorer i de første par år, det var at få implementeret de lande på SAP som

skulle, inden at det slog 1. januar 2000. Det var en meget kritisk succesfaktor kan man sige ik’. Jo, så et det jo selvfølgelig at kunderne, altså Grundfos’ slutkunder, de må jo ikke mærke, at man skifter system på den måde. Det skal jo foregå på en sådan måde, at kunderne ikke lider under, at man skifter system. Det har man jo hørt mange historier om, at nogle selskaber har haft kunder, som led under det.

Dernæst lå det så også som et agendapunkt, at vi skulle genbruge vores løsninger så meget som

muligt, fra det ene selskab til det andet, og vi har hele tiden opereret med det vi kalder business model, hvor vi sagde, jamen et salgsselskab i Grundfos, det skal implementeres på SAP på den og den måde. Hvad er der for nogle ordretyper, hvad er det for nogle fakturatyper, hvordan ser kontoplanen ud, hvordan ser costcenteret, profitcenter plan ud og hvordan virker rapporteringen, hvilke rapporter har man til rådighed og sådan noget, som vi kaldte vores business model? Der har det jo været en kritisk succesfaktor for at kunne nå alle de her lande på kort tid, det har været at fastholde, fastholdelse af standardisering i forbindelse med indførelsen af SAP i selskaberne, det har det været.

LØO: Dvs. så lidt kostomisering som muligt og så lidt ændringer af den grundlæggende SAP? JBN: Ja, så lidt forskelligartet kostomisering pr. selskab. Kostomisering det foregår ofte pr. selskab

pr. organisatorisk enhed, men sikre at man gør det på samme måde, for alle selskaberne. Og det igen, det er heller ikke trivielt, fordi der er jo en vældig stor kreativitet rundt omkring. Man er jo vant til at, jamen det skal foregå på den her måde. Så kommer der så nogle SAP folk og siger, nej I skal gøre det på en anden måde, og det er jo også en udfordring i sådan et SAP projekt, i hvert ERP projekt, hvis det er det man ønsker, hvis man ønsker harmonisering, hvilket jo nok de fleste gør efterhånden. Så det kan man sige, det er altså harmonisering og standardisering og også brug af standard SAP funktionalitet. Ikke at hyre en hel hær at programmører til at udvikle SAP på en måde, der aldrig var tiltænkt at blive brugt på. Det er også meget vigtigt, at man lader være med at gøre det.

60

0:16:14 MG: Dvs. I har prøvet simpelthen at tage så meget basis SAP og så bruge det, og så lavet nogle få

ændringer, der hvor det nu har været nødvendigt for Jer? JBN: Så få som muligt. Jeg er ikke sikker på at man kan sige, at vi har lavet få ændringer, vi har

stadigvæk mange ændringer. Vi har mange egen udviklede programmer som bruges ved siden af, på toppen og i samspil med standard SAP programmer, men så få som muligt. Det er i hvert fald også en kritisk succesfaktor. Både mht. at få, med implementeringstiden, men også mht. hele housekeeping af systemet siden hen – opgraderinger og patches og sådan nogle ting fra SAP ik’. Altså jo mere man selv har lavet, jo større problemer får man med den slags ting der.

Så er der også vigtigt, en kritisk succesfaktor, der er at man har nogle forretningsejere af de

processer, i selskaberne implementerer i systemet. Man skal ha’ nogle fra forretningen, fra supply chain, fra produktionen, som tager ejerskab for, hvordan skal en proces afvikles i SAP. Det må ikke være noget som nogle SAP konsulenter sidder og finder ud af med yngste fejedreng eller brugerne, hver enkelt bruger hver for sig. Der skal være nogen der har et procesejerskab i forretningen for, hvordan det bliver sat op.

LØO: og som også lige som står som sponsor for projektet i deres afdeling? JBN: Ja, du kan også kalde det en sponsor, men det skal være en der har ejerskabet af processen og

som er i stand til at beslutte og som er empowered til at specificere, hvordan kan det se ud, eller skal det se ud i SAP.

LØO: Den person, er det en I har valgt som, er det en fra topledelsen af i den afdeling, eller er det den

der er sådan mest kvalificeret til det? 0:18:11 JBN: Det er jo vidt forskelligt kan man sige ik’, men det jo som regel en fra ledelsen. Enten fra

koncernledelsen eller også fra ledelsen i et selskab, som har det ejerskab der, det er det. LØO: Har I så haft et ERP team, som er taget rundt de forskellige steder? JBN: Du mener SAP implementeringsteam eller hvad tænker du på? LØO: Ja, altså nu siger du I har, I havde nogle lokale, som ligesom stod for projektet, men har I haft

sådan en gruppe som har taget rundt de forskellige steder som en standard ERP gruppe, projektgruppe, som har taget rundt, eller er den sammensat fra sted til sted?

JBN: Det kan man sige, det har skiftet over tiden. I starten der, tilbage i slutningen af ’90’erne, der

var det f.eks. i Sydeuropa, der var det et fast team af en håndfuld SAP konsulenter, som tog rundt til de sydeuropæiske lande og implementerede SAP der i løbet af en tre, fire, fem måneder eller sådan noget. Men siden hen, så er det sådan mere ad hoc team, der bliver dannet af medarbejdere fra SAP kompetencecenter og medarbejdere fra forretningen i det pågældende

61

land, som så tilsammen danner det projektteam, der indfører SAP. Så det er ikke sådan, at vi har et fast hold af rejsende konsulenter, det går sådan lidt på skift blandt vores medarbejdere, det gør det.

0:19:44 LØO: Har der hele tiden været, fra starten af, sådan fra højeste led, sådan synlighed, at de mener at

projektet er vigtigt… at det var sådan fra toppen af, at det blev sagt ud, at vi skal have SAP og sådan og sådan?

JBN: Ja det må man sige… LØO: … altså at de har støttet og aktivt gået ind og sagt, sådan gjort det synligt for hele virksomheden

at…? JBN: Det kan man sige, at det er en del med det her med at tage ejerskab af processer, at forretningen

har ejerskab for projektet. Det er også vigtigt, og det har man også gjort i Grundfos. Man kan sige, Grundfos, det er jo så mange ting, det er mange selskaber. Der har da måske også været et eller to selskaber, hvor den lokale ledelse ikke gjorde det i tilstrækkeligt omfang. Der har da så også været nogle, heldigvis ret få eksempler på, at så blev overgangen til SAP, den blev sådan lidt mere træls end den måske kunne have været. Men langt overvejende, så har der været det ejerskab i forretningen som skal til for at implementere SAP. Og vi har generelt ikke haft problemer med vores go lives i SAP, det har vi ik’, med en enkelt eller to undtagelser, som ligger seks, syv år tilbage eller sådan noget. Vi har haft masser af go lives de sidste mange år. De er faktisk gået uden de helt store problemer. Vi har ikke i Grundfos været ude for de her horrer stories, hvor man ikke har kunnet levere i 14 dage, fordi man anede ikke hvorhenne på lageret varerne lå osv. osv. Det har vi været helt forskånet for faktisk.

0:21:16 MG: Hvordan har I været forskånet for det så? … Når I sådan fra selskab fra selskab, har I så

opbygget noget viden om, hvordan man skal gribe hele processen an med at få SAP ind i et selskab?

JBN: Ja, det har vi jo efterhånden mange års erfaring med i Grundfos. Vi har det i vores SAP

kompetencecenter. Der er mange af vores konsulenter, som har været med i 10 år eller mere ik’. Og man kan sige, at der er jo så også i forretningen jo en erfaring nu for, hvad er det lige der sker, når et selskab skal indføre SAP. Der er de selskaber som handler med det pågældende selskab, de har jo måske selv været igennem sådan en SAP implementering og koncernledelsen ved også godt, hvad det indebærer for sådan et selskab, så det er sådan set både IT-mæssigt, men så sandelig også forretningsmæssigt, at der nu er opbygget en lang erfaring for.

MG: Hvad har I så gjort Jer af erfaringer i den forbindelse? JBN: Jamen, det er jo de her kritiske succesfaktorer i virkeligheden, som vi lige har snakket om.

Hvad er det for nogle kritiske succesfaktorer og hvad skal man være opmærksom på ik for at undgå at falde i? Så det er jo sådan set dem.

62

0:22:23 LØO: Har I været ud for så mange kulturelle forskelle eller udfordringer, eller hvordan man skal sige

det? I og med… at I er et dansk selskab og I både i Østen og i Asien, har selskaber derude. JBN: Jo, det har vi. Der er nogle lande, der, eller lad mig sige, hvis man arbejder i Danmark, eller i

Vesteuropa og Nordamerika der er medarbejdere, der er folk i almindelighed, de er jo, selvstændigt tænkende og forventes også at være det. Men det er den menige medarbejder ikke sådan alle steder i verden. Der er nogle steder i verden, der er det meget få der er i stand til og tør efterspørges at kunne tage nogle beslutninger om, hvordan kan vi nu gøre det her ik’. Hvor mange ting skal op at vende på direktørniveau, før man kan få taget nogle beslutninger. Så der er lidt forskel på, hvordan sådan et projektteam skal arbejde i Vesteuropa og i Nordamerika i forhold til andre steder i verden. Så der er da helt klart kulturelle forskelle, det er der. I nogle lande der vil folk, de vil sige ja og amen til det hele. Spørger man om, har du forstået det her, ved du hvad det her indebærer osv. osv. så vil de sige ja og amen, fordi hvis ikke man gør det, så er det et nederlag, hvad enten de har forstået et klap af, hvad der blev sagt eller ej. Så der er sådan, der er nogle lande, hvor man skal, selvfølgelig arbejde på en lidt anden måde end så mange andre, hvor vi er vant til at komme i hvert fald. Så der er kulturelle forskelle, det er der.

LØO: Har I også været ude for at, forskellige landes love, at der har været nogle… der har vel været

nogle tilpasninger i forhold til…? JBN: Ja ja, det har vi. Der er nogle store forskelle, nogle legale krav, det er der. Der er pokker til

forskel på, hvordan lovene er skruet sammen i Rusland og i Nordamerika, så der er store legale forskelle, det er der.

LØO: Er det noget sådan, også både med det kulturelle og de andre ting, det er selvfølgelig nogle ting

man kan undersøge. Har I været på forkant med mange af dem? JBN: Nej, det synes jeg egentligt ikke man kan sige, det har vi sådan… jo, altså med legale krav, der

er jo nogle forskellige værktøjer SAP stiller til rådighed, for at give et billede af, hvad er kompleksiteten i lokale krav i Rusland f.eks. og det har vi så vidst på forhånd. Rusland de har nogle komplicerede legale krav. Men omkring det kulturelle, det har vi ikke sådan gjort, vi har ikke sådan gjort sådan det store ud af det. Det har vi sådan håndteret langs ad vejen kan man sige, det har vi. Vi har ikke sådan foretaget større studier af, hvad den russiske kultur er, det har vi fundet ud af langs ad vejen, efterhånden som vi derover af. Men det kan man måske sige på bagkant, at det var det måske lidt en fejl, at man ikke gjorde lidt mere ud af det, kan man sige. Men svaret må være nej, det har vi ikke gjort. Måske sku’ vi have gjort det.

0:25:34 MG: Men I er ikke stødt på nogen store problemer i den forbindelse? JBN: Jo, men altså ikke større end at man kunne overkomme dem. F.eks. det her med hvad, hvad er

beslutningsprocessen i et selskab. Den er altså noget anderledes i Rusland og i Kina end den er i Vesteuropa. Det har da gjort at projektet har haft en lidt anden gang i sådan nogle lande, end det har haft i andre lande.

63

LØO: Hvordan sådan med standardiseringen af forskellige ting lige da I begyndte at indføre SAP, er

det noget I også har haft meget fokus på? JBN: Ja, det har vi. LØO: Altså i og med, at I havde flere forskellige både produktionsselskaber og salgsselskaber som så

gradvist fik det indført. Du sagde i starten, at der var sådan lidt autonomitet i enhederne, før man endelig begyndte at…

JBN: Som jeg sagde før, vi har jo fra starten af arbejdet med det begreb, som vi kaldte en business

model, som er, hvordan kører man et selskab i Grundfos, når man er på SAP. Så det har vi arbejdet meget med, men man kan sige, det er jo ikke noget der er nemt at gennemføre 100 % kan man sige. I hvert fald ikke i de fleste selskaber. Hvordan skal man tilrettelægge produktionen, hvordan skal man prissætte overfor kunder, hvordan skal en faktura se ud, hvordan skal en følgeseddel se ud, når man printer den ud og sådan noget der? Der vil altid være en hel del forskel. Fysiske forskelle. Fabrikkerne ser ikke ens ud, lagrene ser ikke ens ud. Der er en hel række faktorer der gør at, man kan sige… Jo, inden i maven på SAP; den måde som det er kostumiseret på, der er ikke sådan de helt store forskelle, det er der nok ikke. Men den måde som processen gennemføres på i selskabet. Hvad er det en produktionsplanlægger gør, når vedkommende kommer ind kl. 8 om morgenen og hvad er så opgaverne til kl. 10 om formiddagen osv.? Altså på den måde er processerne, de er noget forskellige i Grundfos selskaberne. Og der er også nogen variation i den måde SAP er sat op på, kan man sige, til de forskellige lande.

LØO: Men inde i selve systemet, sådan noget som f.eks. varenumre, det er vel noget I har

standardiseret over hele linien. JBN: Ja ja, jamen det er det LØO: … og så at vide, at nettoomsætningen det ene sted, det er det samme som det andet sted, altså

der er de samme rabatter med. JBN: Ja, de der regler for, hvordan ting skal konteres f.eks., det er efterhånden kan man sige, eller det

er kommet på plads i forbindelse med de her SAP implementeringer rundt omkring. Der har da været forskel, når man f.eks. fakturer en kunde for fragt. Hvad er det så? Er det en del af omsætningen, eller er den en del af noget andet. Sådan nogle definitioner der, kan man sige. De er da i langt højere grad blevet standardiseret i takt med at vi har indført SAP. Det er de. Men vi kan ikke påstå at vi kører SAP på 100 % samme måde i alle Grundfos selskaber, det gør vi ikke. Altså der er jo muligheder for at sætte en fabrik op på forskellige måder, og det gør vi også i Grundfos, det gør vi. Der er så også forskel på at producere 30.000 cirkulationspumper om dagen til at lave fem store trykforøgningsanlæg om dagen ik’. Altså, det er jo en hel anden produktion, så der er jo, der er variation i det, det er der.

LØO: Dvs. der hvor det er nærliggende at det er integreret, der er så også stor integration?

64

JBN: Ja, der er harmonisering, det er der. Det er de samme programmer man bruger til at lave

indkøbsordrer med og det er den samme måde man laver varemodtagelser på. Men det kan jo godt være, at hvis man har en proces i SAP som kan udføres vha. otte transaktioner f.eks. ik’. Så kan det jo godt være, at der er nogle selskaber, der kun bruger de fire og hopper nogle andre over osv. osv. PÅ den måde er det ikke 100 % alignet procesmæssigt, det er det ikke.

LØO: Men kan du f.eks. gå ind og se inde i systemet herhjemme, kan du se, hvor meget der er på

lageret i Kina eller sådan noget. JBN: Ja ja, det kan man, det kan man sagtens gøre. 0:29:47 LØO: Så lidt sådan omkring succes. Jeg går ud fra, at I betragter det som en succesfyldt, altså SAP

implementeringerne som succesfulde!? JBN: Ja det gør vi! LØO: … hvad har I haft sådan af kriterier for, for at det sku’ være en succes? Nu nævnte du, altså der

sku’ være hurtige svartider og oppetid. JBN: Ja, jamen det er, det er jo så basale, sådan lidt mere teknisk betonede, at selvfølgelig, systemet

skal ku’ virke og det skal være tilgængeligt og det skal performe. Det er nogle meget vigtige succeskriterier. Og så er det jo at man skal, i det pågældende selskab skal man kunne gennemføre sine forretningsprocesser mindste lige så effektivt, som man gjorde inden man fik SAP og kunne levere og leve op til de krav som de eksterne kunder stiller. Det er nogle vigtige succeskriterier, det er det. Vi har ikke sådan opereret meget stringent med, at så skulle omkostningsniveauet indenfor nogle afdelinger af et selskab falde med 5 % om året, efter de har fået SAP osv. osv. På den måde har vi slet ikke været inde og definere succeskriterier på den måde, det har vi ikke… Det har været nogle grundlæggende og basale succeskriterier, det har det været, det har det.

LØO: De succeskriterier, er det nogen der sådan fra centralt hold er blevet defineret? JBN: Nej, det kan man ikke sige. Man kan sige, de er jo så åbenbare kan man sige, sådan nogle

succeskriterier. Det behøver man sådan set ikke nogen fra centralt hold til at gøre. Man kan sige, at de enkelte selskaber har nok haft nogle sådan meget specifikke succeskriterier kan man sige. F.eks. at svartiderne sku’ være lige så gode som i det gamle system osv. Der er nogle selskaber, specielt her i Grundfos her i Bjerringbro, produktionsselskabet, som succeskriterium har haft, at nu skulle alle processer i alle fabrikkerne her i Bjerringbro, afvikles på noget nært præcist samme må i alle fabrikkerne. Der har været sådan nogle selskabs eller fabriksspecifikke succeskriterier, men det er ikke noget som koncernledelsen har udstukket andet end selvfølgelig, vi skal kunne servicere kunderne og levere til tiden ik’. Men det ligger jo så underforstået i det, kan man sige, det gør det.

65

0:32:16 LØO: Hvad så med de folk som, som er blevet berørt af SAP, som bruger det dagligt er der sådan

nogle, er der mange der har været har alle været tilfredse, eller det kan jeg selvfølgelig ikke sige hvad. Har De indtryk af, har der været noget modstand på det, på den kant.

JBN: Nahh, johh altså der er altid nogle medarbejdere der sådan har lidt modstand mod forandringer,

kan man sige, altså sådan er det jo. Men, vi måler vores brugertilfredshed, det gør vi. Vi har faktisk lige fået lavet en, global en her med omkring 1000 brugere og superbrugere rundt omkring i verden, hvor man kan sige, vi har haft nogle overordnede kriterier vi har spurgt dem ind til i sådan et elektronisk spørgeskemaundersøgelse. Hvor vi har benchmarket os selv mod en peer gruppe som består af andre store danske koncerner og der kan man så se her at Grundfos ligger, ligger egentligt sådan set meget pænt. Vi ligger over fraktilerne, over 50 % fraktilen, kan man sige. Oven i købet 66 % fraktilen, inden for de fleste, nogle der ligger vi lige midt på. Så man kan sige på den måde så, det billede der i hvert fald tegnes her det er at brugere og superbrugere de er faktisk. I hvert fald mindst lige så tilfredse som de er i andre selskaber, kan man sige, og det er jo sådan. Noget nær det tætteste man kan komme på et nogenlunde objektiv mål for om det er godt, om der mangler noget. Det er selvfølgelig ikke det samme som det er godt nok at det er lidt bedre end de fleste andre steder. Det er i hvert fald ikke et alarmerende billede som bliver tegnet af sådan en undersøgelse her.

LØO: Er det nogle i laver løbende de der undersøgelser? JBN: Vi har løbende lavet sådan nogle undersøgelser for, her i Danmark i de danske selskaber. Men

det er sådan set den første og ind til nu eneste gang at vi har spurgt bredt i hele verden, i hele koncernen, hvordan brugeren der har oplevet det. Der har så været andre, der har været lokale undersøgelser af den her karakter, kan man sige, hvor selskaberne i Amerika har spurgt deres brugere, hvordan synes i SAP fungerer og sådan noget, men det er første gang vi fra centralt hold har lavet en, sådan, global dækkende undersøgelse, det er det. Det er det.

0:34:51 MG: Jeg tænkte, hvad med når i skulle implementere rundt omkring i verden, så siger du, så har det,

været sådan en, en blanding af nogle fra Jeres SAP kompetencecenter her og så folk ude lokalt…

JBN: Ja MG: Altså hvordan, her er det sådan mere eller mindre, i vælger nogle fra forskellige niveauer eller

er det sådan. Nogle bestemte folk, i sådan, i har Jeres gruppe her af SAP konsulenter JBN: …ja… MG: Det er ikke sådan, der er nogle grupper, der sådan er nogle grupper her i Danmark som ligesom

er med, som holder sammen hver gang, så det er den samme gruppe der rejser rundt JBN: Nej

66

MG: Sådan, så at, i har to eller tre forskellige grupper, hvor det er de samme mennesker altid. JBN: Nej, det bliver mikset fra gang til gang…det gør det MG: Hvad med når I skal ud lokalt er det så også, sammensætter i så også, hvad hedder det,

grupperne på en bestemt måde, derude så I er sikre på at I får, hvad skal man sige, så I får noget magt til at gennemføre det eller er det nogle der bliver fundet tilfældigt ude i selskaberne

JBN: Okay, du mener de lokale repræsentanter, de skal have magt, siger du ik, de skal være

empowered ik, de skal være beslutningsdygtige ik’. De skal den forretning, som der skal arbejdes med, de skal jo vide hvad der foregår. Man kan jo sige, det handler jo om, at der i sådan et selskab foregår nogle processer, der bliver taget nogle ordrer, der bliver lavet nogle plukkelister til lageret, der bliver lavet noget produktionsplanlægning og der bliver nogle produktionsordrer som skal sættes i gang. I virkeligheden, jo det er afhængig af, hvilket detaljeringsniveau, man opererer med så er det jo, jamen så kan sådan et selskab jo beskrives med 2-300 processer, hvis har man har beskrevet sådan en 2-300 processer, jamen så har man jo i virkeligheden mappet, hvordan det selskab drives og dem der laver det proceskort der, de skal jo selvfølgelig kende virksomheden de skal kende det lokale selskab ud og ind kan man sige. Og de skal også være beslutningsdygtige mht. når så vores SAP konsulenter, viser dem på skærmen, jamen ok, hvis det er sådan du, i siger Jeres proces forløber så kunne man gøre sådan, sådan og sådan. Så skal de jo så være i stand til at sige, jamen det er i orden, det kan vi godt. Så sætter vi flueben ved den proces og går videre til den næste. Det skal være kompetente folk, som deltager fra lokalt hold. Det skal det, det skal det.

0:37:36 LØO: Bliver den så set i forhold til Jeres overordnede business model? Så I har, når I nu kommer ud i

de lokale… JBN: Ja, så laver vi, det vi kalder, en fit-gap analyse ik os’ og så får vi en række gaps op og så må vi

så diskutere, hvordan man kan nå dem ik og så er det så at der nogle gange at der skal udvikles noget i SAP systemet fordi at der var noget ved forretningen, i det pågældende selskab, som vi ikke var støt på før, kan man sige, i nogle andre Grundfos selskaber.

LØO: Det vil sige så…vil i så helst lave et ekstra program for at tilpasse til den forretning eller, eller

lade forretningen lave om på deres processer? JBN: Det er, set fra SAP, så er det selvfølgelig nemmere, hvis forretningen laves om, kan man sige,

men det er ikke altid det er muligt og så må vi så lave noget ekstra udvikling i SAP systemet og generelt, jo tættere man kommer på slutkunderne, jo mindre kan vi komme og sige til forretningen i må lave om. Hvis det er den måde man sælger pumper på i Tyrkiet, så må vi jo gøre det. Jo tættere man kommer på sådan nogle interne processer i bogholderiet og økonomifunktioner ik’, der har vi meget mere mulighed for at sige dem at ”det ser altså sådan ud” ”kontoplanen ser sådan ud, det gør den”.

LØO: Det vil sige, jo mere centrale funktioner det er, jo mere tilstræber i at tilpasse det til SAP?

67

JBN: Jo, længere væk man kommer fra slutkunden, kan man sige, jo bedre mulighed har man for at sige, jamen i kan godt drive Jeres forretning sådan, fordi det er der andre Grundfos selskaber der gør ik’. Men det er svært når man er tæt på kunden, hvis rabataftalen med kunden er efter en given struktur, jamen, så er den bare sådan.

MG: Så dem har I ikke lavet om på, sådan, rundt omkring, i har ikke, hvad skal man sige, fået Jeres,

lavet Jeres rabataftaler om fra land til land. JBN: Nej, det har vi ikke, det ved jeg ikke om man ikke kunne. Men der vil man typisk sige, et

system, og SAP skal kunne understøtte, hvad der er af den slags. Det kan selvfølgelig, jo, det kan jo selvfølgelig, jo, blive så uhyrligt at man må sige, det her, det er galimatias. Men det synes jeg ikke vi er stødt på og SAP er også uhyre fleksibelt inden for lige f.eks. sådan et område omkring pricing. Ja, der er næsten ingen ende på, hvad man kan få SAP til at understøtte.

MG: Har SAP så, rundt omkring, har det medført nogle gedigne organisationsforandringer, rundt

omkring i Jeres selskaber, nu tænker jeg både selskaber, men også produktionsselskaber? Har man ændret processerne meget? Sådan, så man har valgt at lave om på processerne i forhold til systemet eller har man prøvet at lave systemet om til proces eller til den proces man havde i forvejen?

JBN: Igen, jo tættere man er på kunden, jo, mindre omfang finder det sted, jo, længere væk man

kommer fra kunden, i f.eks. bogholderiafdelinger, der er stor forskel på hvordan sådan en bogholderiafdeling fungerer før og efter SAP. Og så er der så nogle midt imellem, kan man sige, produktionsplanlægning, jo, det har også ændret sig en hel del fordi det ser anderledes ud, men det er ikke sådan, at det er vendt helt op og ned på hovedet, det er det ik’. Så det generelle svar er, at, jo tættere man kommer på kunden, jo mere tilpasser man systemet, det gør man.

LØO: Hvordan kan du sådan sige, her i Bjerringbro, hvor langt er i kommet med Jeres, i Jeres

livscyklus af systemet, det er jo indført nu, er det så gået over i tilpasninger nu og opgraderinger?

JBN: Ja, altså vi har jo løbende og vil jo også fortsat implementere SAP i forskellige selskaber, rundt

omkring i verden og der har vi jo så også parallelt med foretaget f.eks. opgraderinger og patches og sådan noget, så det er ikke, man kan ikke se det på den måde, nu er færdige med at implementere, nu går vi i gang med næste fase i livscyklus, det foregår sådan parallelt, ik’. Så vi har da opgraderet en tre gange eller sådan, de sidste, mens jeg har været her i Grundfos, men der har vi jo sideløbende, jo implementeret SAP i en række selskaber, så det er, jamen hvilken fase vi er i, vi er jo, vi er jo både i en driftfase og vi er så også stadigvæk i en go-live fase, fordi vi har selskaber, som er i gang med at implementere SAP, så det er begge dele kan man sige.

MG: Når I er ude og implementerer er det så en meget stringent proces I går igennem, når det er

sådan at I kommer ind i et selskab, og så, sætter I Jer ned med og så, siger I, nu skal vi have gjort det her, først skal vi lige have alle processerne på plads. Hvad gør I sådan for at forberede den omkringliggende organisation, til den implementering af SAP? Har i noget uddannelse af.

68

JBN: Ja, vi har en projektmodel som vi går ud efter, hvor vi som det første, vi gør i sådan et projekt, der laver vi det der proceskort, eller det er forretningsrepræsentanter der gør det primært som vi så mapper op imod det som vi nu kan understøtte med SAP systemet. Så laver den fit-gap fase, og så laver vi vores fit-gap rapport, som så viser dem, hvor har vi nogle ting i det pågældende selskab som vi ikke umiddelbart kan understøtte. Så går vi så en i en fase, hvor vi beslutter, hvad gør vi så ved dem, ændrer vi processerne i det pågældende selskab eller skal vi udvikle noget i SAP og dernæst så går man over til så at konfigurere SAP og udvikle de programmer de programmer der nu skal udvikles, teste dataload. Når man så mener man er, hvad skal man sige, er færdig med selskabet i et testsystem, så laver man nogle acceptance tests. Integrationstest og acceptance test med det pågældende og går derefter over til at uddanne, superbrugere, uddanne slutbrugere og når man er færdig med det så kan man gå live og det er sådan en nogenlunde fast projektfasemodel, som vi kører de projekter efter.

MG: Dvs. I kører efter en meget fast projektledelsesstruktur, hvad hedder det, den projektmodel der,

det er den I ligesom bruger når I er ude og… JBN: Ja, jeg ved som ikke man kan sige at den er stringent, men der er nogle helt klare faser som et

projekt skal gennemleve og der er nogle klare deliverables, der skal være en fit-gap rapport, der skal være en useracceptancetest, der skal være nogle dataloadtest, der skal gennemføres noget træning, så på den måde er der en rimelig stringent fasemodel, vi går ud efter. Men det er ikke sådan at vi har en fast template f.eks. for, hvordan skal man skrive en fit-gap rapport. Hvordan skal man beskrive, hvad der skal til for at man kan sige at man har lavet en useracceptancetest? Altså, der er vi ikke nede og have templates for det. Vi genbruger da selvfølgelig i stor stil fra det ene projekt til det andet, men det er ikke sådan. Det er så op, det kan man sige, op til det enkelte projekt og projektleder at, hvis man mener man skal beskrive en fit-gap rapport på en måde, jamen så gør man det, vi har ikke så mange templates for den slags deliverables, det har vi ikke. Men vi har en fasemodel, vi går frem efter og som følges, det har vi. Og vi har også en projektorganisationsstruktur som vi følger, det har vi, hvor vi har en SAP projektleder og nogle SAP konsulenter med på projektet og så har vi en forretningsprojektleder og nogle forretningsdeltagere på projektet, sådan, så SAP og forretningen ligesom møder hinanden, både projektledelsesmæssigt og på konsulentniveau, kan man sige

MG: Hvor vigtigt er det at man har både, hvad skal man sige, den forretningsmæssige forståelse og

så den SAP-mæssige forståelse. JBN: Det er selvfølgelig meget vigtigt, fordi det er, jo netop, jo et spørgsmål om at

forretningsdeltager i projektet skal komme med viden om, hvordan det her selskab drives og udarbejder sådant et proceskort over det ik’. Det værste der kan ske, det er jo, at tre dage efter man er gået live med SAP, at så kommer der nogle brugere og siger vi plejer at gøre sådan, sådan og sådan, hvordan gør vi det i SAP og så er aldrig nogen der har hørt om det før, det er jo, det er sådan noget der helst ikke skal ske.

LØO: Men det gør i så meget ud af, at sådant ligesom at få det hele med, i og med at I har de lokale

som har meget kendskab til de forskellige brugere, brugerflader og de forskellige funktioner der skal være i…

69

JBN: Det er den viden de skal stille med, det er, hvordan drives det pågældende selskab, det skal de stille med, den viden der.

MG: Hvad med rundt omkring i de forskellige lande, har i sådan stødt på at uddannelsesniveauet har

været forskelligt og derfor så skal der bruges større tid på uddannelse af SAP brugere et sted end der skal andre steder eller…

JBN: Jo, der er forskelle kan man sige, der er også sprogforskelle, altså, vi kører. SAP systemet, det

kører på engelsk i Grundfos i alle lande også i Kina og Frankrig og i Ungarn, det er engelske skærmbilleder man ser, så der er der selvfølgelig forskelle ikke, det er trods alt nemmere for amerikanske, engelske og australske brugere at finde ud af det og jo der er da også forskelle på uddannelsesniveauet rundt omkring, det er der da, men det er såmænd ikke fordi det er det helt store issue. Det tilpasser projektet sig jo så efter ik’ og nogle steder, ja, der tager det en uge at lære folk at lave produktionsplanlægning og andre steder tager det måske to uger, men det er jo igen, kan man sige, de lokale projektdeltagerers input der, der er vigtigt ik’, fordi, det skal de have et billede af, hvad er behovet for f.eks. uddannelse i det pågældende land, så jo der forskelle, det er der.

LØO: Har det skabt nogle problemer, nogle af de steder, hvor de så, i og med at du siger at nu kører i

engelsk alle steder, at de lande, hvor de, hvor medarbejderne har meget svært ved engelsk, hvordan…

JBN: Jo, det har det da nok, det har da nok skabt nogle problemer, det er ikke nogen problemer som

jeg så hører så meget til, det må man jo så finde ud af lokalt, hvad man så gør. Det der vel i praksis sker det er, at der medarbejdere der skal bruge SAP, de lærer så engelsk, i det omfang det er nødvendigt for at kunne betjene systemet ik’. Så, det tager så nok noget tid nogle steder, men det skal de så, det skal de.

LØO: Hvad er sådan de største udfordringer, hvis du skulle nævne nogle, sådan lige, ikke hurtigt,

men. Overordnet set, hvad er de største udfordringer i forbindelse med når i har lavet implementeringer?

JBN: Det er at finde balancen mellem at fastholde standardisering og fastholde harmonisering i

systemet contra det at lave de tilpasninger og udviklinger på systemet som er nødvendige for, at man kan drive pumpeforretning i det pågældende land ik’. Det er en meget vanskelig balanceagt, hvor jo mere man har en central governance struktur der kan, der kan sådan spille lidt overdommer i de diskutioner der er, jo bedre er det ellers så, hvis ikke man gør det, vil det være en langt større opgave at indføre SAP i over 40 selskaber med 6000 brugere som vi har det, hvis hvert eneste land, hver eneste fabrik, hver eneste afdeling i det pågældende land kunne og skulle have indfriet, hvert eneste krav de havde til et SAP system, så det tror jeg vil sige det er nok en af de største udfordringer, det er at finde den rigtige balance, den rimelige balance mellem standardisering og harmonisering på den ene side og så at levere et system der rent faktisk gør dem i stand til at drive deres forretning og sælge pumper det pågældende sted, det vil jeg fremhæve, hvis jeg skulle fremhæve en enkelt udfordring, det vil jeg sige.

70

0:50:17 MG: Ja, hvad hedder det, har I. I har fra centralt hold besluttet at i skulle have SAP, hvornår, nu siger

du i starten, der tog man bare SAP, fordi nu skulle i lige have klaret år 2000, hvornår blev det sådant en mere bevidst beslutning om at nu skal i have SAP i alle Jeres afdelinger rundt omkring i verden.

JBN: Man kan sige det var ikke en, det var ikke en tilfældig beslutning at det lige blev SAP, kan man

sige, vi havde så her i Grundfos i Bjerringbro kørt SAP R/2 i mange år, helt tilbage fra slutningen af 80’erne, så det, så produktet fra SAP det var, sådan set, velkendt, R/3, var så ikke, men det var R/2. Så det var, jo, efter nøje overvejelse, kan man sige, at det blev besluttet at det var SAP R/3, vi skulle bruge til at løse de år 2000 problemer, der var i salgsselskaberne. Før år 2000, jeg tror, som egentlig, at man kan sige, i takt med at man i forretningen fandt ud af at, hvis man kører alle selskaber på et stort SAP system, den utrolige transparens det gav i forretningen, den nemhed hvormed, man kunne skabe tværgående processer mellem selskaberne, den sammenhængende integration, der har kunnet, der kunne opnås mellem selskaberne på den ene side set med forretningssyn på, set med IT-mæssige øjne, den effektivitet, hvilken vi kunne indføre systemer i selskaberne med. Den erkendelse der kom der op gennem slutningen af 90’erne, førte til, man besluttede så at, jamen det ser faktisk, det vi, så gør vi det hele vejen rundt ik’. Da man fandt ud af den transparens man havde i de europæiske selskaber, da man havde haft den og var blevet sådan lidt vant til det, så savnede man det i høj grad i forhold til de selskaber der ikke var på SAP. Så det er vi, nu under stort pres for at få SAP ud i resten af selskaberne, så hurtigt som overhovedet muligt ikke. Så det er vel sådan en erkendelse der kom løbende over et par år fra forretningen.

0:52:34 MG: Dvs. at det er jeres topledelse der simpelthen har været inde over og sige nu kører vi det ud i

resten af verdenen også fordi at de har kunnet se nogle fordele ved det. JBN: Ja, det er den strategi vi har nu indenfor SAP området. Den er, jo, forankret og godkendt i

koncerndirektionen, med koncernchefen i spidsen, så det er det. LØO: Er det så dem der går ud og siger, de nye selskaber som nu skal linkes, at det sådan at de går ud

og siger oppe fra koncernledelsen af, nu skal i have SAP også, fordi sådan og sådan? JBN: Nej, det er det sådan set ikke, det er jo, igen altså nu står de nærmest i kø for at kunne komme

på, kan man sige. Så nu er det et spørgsmål om at prioritere, hvem skal på før andre, men det da selvfølgelige, klappet af med koncerndirektionen, hvilke selskaber der skal på før andre og sådan noget ik’. Det gør det.

MG: Men, hvis I ikke havde topledelsens støtte til at det her, det skulle gennemføres, hvordan ville

det så være, ville det så være nemt at komme ud og sige, altså lige nu, det kan måske være svært at se nu, hvor folk står i kø på den måde. Men f.eks. i ’98, hvor eller tidligere.

JBN: Der har du ret i, eller hvis det du mener, der var det også koncernledelsen som sagde til

selskaberne i skal køre SAP, i har ikke noget valg, det skal I og i skal i et system og i skal

71

underligge Jer, visse regler for harmonisering osv. Osv. Og hvis ikke koncernledelsen havde gjort det, så havde vi ikke kunne gøre det den gang, det havde vi ikke kunnet, nej.

MG: Hvis vi nu skulle forestille os at i stod i starten af Jeres, så er det meget vigtigt at man har

ledelsen med der JBN: Bestemt ja, det er det. Hvad enten det er et stort selskab eller et lille selskab, så er det vigtigt at

beslutningen om at nu skal vi køre SAP eller hvilket som helst andet ERP system, at det er forankret i koncernledelsen eller selskabsledelsen, at det er det vi vil og det er i nødt til at indrette Jer efter i nogen grad, det er meget vigtigt, ja.

LØO: Ja, så både at så er det så lettere at indføre det i de forskellige lande som måske ville have

modstand til det plus at. JBN: De ville nok ikke have så meget imod, have noget imod at køre SAP. De vil gerne have SAP

ind fordi det var jo, allerede på det tidspunkt, jo, hyped, der var en masse snak om det, det der er udfordringen det er at den lokale selskabsledelse vil godt have sin egen SAP organisation fordi så har de hånd i hanke med hvad der sker. Men de vil egentlig godt have lov til at bestemme præcis, hvordan skal systemet skrues sammen og designes og sådan noget. Det er mere sådan det diskussionen går på, gik på.

MG: Hvis nu vi skulle forestille os, at du sad som, hvad hedder det, som IT chef i et firma, hvor man

har kørt med mange forskellige systemer førhen, sådan, og man har besluttet at nu skulle man køre SAP, hvad vil du så sige ville være de ting, man fokusere på, i forbindelse med en SAP implementering?

JBN: Det er om man ønsker en harmonisering af sine forretningsprocesser eller ej, kan man sige, hvis

ikke der er en vilje til det så risikere man måske oven i købet at skyde sig selv lidt i foden, ved at køre selskaber ind i et stort SAP system, som i øvrigt har lov til at køre præcis som de vil, så risikerer man bare at lave ulykker for hinanden. Hvis en koncern bestod af 10 selskaber, som skulle køre ind og køre det samme SAP system, men i øvrigt havde 10 forskellige SAP organisationer, der sad og rettede i programmer og customizering og sådan noget, fordi sådan ønskede man at køre, så ville min anbefaling være at så skulle de ikke prøve i et stort system fordi, så risikerer de at ødelægge tingene for hinanden, forstyrre hinandens forretning. Nogen kommer til at ændre i et program, som de ikke vidste at andre for resten også brugte og lige pludselig, så virker det anderledes end det gjorde førhen, så viljen til at harmonisere forretningsprocesser og viljen til at centralisere SAP organisationen, det ville være, i mine være meget vigtigt at man har den eller så skal man ikke prøve med ét stort system, det tror jeg ikke, det tror jeg ikke på.

MG: Ville der være andre ting som du vil sige, at man skulle prøve at når man skal ud og ligesom

præsentere det for sine, hvad hedder det, datterselskaber eller produktionselsaber andre steder i verden at få dem ind på det, få solgt projektet til dem, at man så ligesom, skal man prøve at få noget ejerskab ude i de lokale i de lokale salgsselskaber prøve at forberede dem, via noget kommunikation eller hvordan…

72

JBN: Ja, det kan man jo altid gøre, jo ikke, det er jo altid en god idé, at fortælle dem, hvad det er for nogle tanker man går rundt med der ik’. Men det er, hvis det der er beslutningen er, skal vi køre alle vores selskaber i koncernen ind i et stort system eller skal vi ikke, så er det jo sådan nogle, nogle rimelige fundamentale ledelsesmæssige overvejelser man skal gøre sig fra centralt hold ik’. Ønsker vi, og kan vi harmonisere forretningsprocesser ik’. Ønsker vi at centralisere SAP organisationen ik’. Man vil jo træde nogle over tæerne ude i de enkelte selskaber sandsynligvis da, hvis man siger til dem, for øvrigt det her med udviklingen af ERP system det skal i ikke gøre mere selv, det gør vi fra centralt hold. Det vil der være modstand imod og hvis man ikke vil det så tror jeg ikke man skal forsøge sig med det, det tror jeg ikke. Ja

LØO: Det ved jeg ikke rigtig, har du…? MG: Nej, jeg har ikke rigtig mere. LØO: Er der noget sådan her som du mener, som vi ikke har snakket om nu, som du synes der er

vigtigt? Set i forhold til at vi snakker vigtige ting i en ERP implementering? JBN: Ja, vi har været inde på sådan de mere basale IT tekniske områder ik, som driften, oppetider,

svartider og sådan noget ik’. Performance det har man en tendens til at glemme, det gjord Grundfos også, vi havde nogle performanceproblemer i systemet tilbage i, ja det er snart mange år siden ik, men man er så fokuseret på applikationen, man er så fokuseret på at få beskrevet, hvad er det for nogle processer, finde løsninger i MG’en, få skrevet nogle programmer der kan lukke de sidste huller i funktionaliteten, som man syntes mangler ik’ og den dag man så hælder 600 brugere på, så sidder de og triller tommelfingre, fordi det tager 10 sekunder at komme tilbage for hvert museklik ik’. Nogle rimelig basale ting der, dem skal man sørme huske på at få med ik’ fordi, altså hele seizing af ens infrastruktur ik’ Utrolig vigtigt

0:59:35 LØO: Men det er vel noget CSC gør for Jer, nu så? JBN: Nahh, det gør vi selv, det gør vi selv og det er meget vanskeligt. SAP og andre

hardwareleverandørere de har nogle bud på det, nogle forskellige modeller man går igennem og der er aldrig noget af det der passer, altså, det er altid ca. halvt så stort som det skulle være og sådan noget ik’, så det er vigtigt at man er på forkant med de ting og, man kan sige, ja næsten, man har noget kapacitet i baghånden, til hver en tid, kan man næsten sige, så hele det område det er meget vigtigt. Det er så det som mange gange ledelsen ikke synes er så spændende og det er også noget der koster mange penge, mange gange og det er ikke, der er mange der ikke synes, det er så fancy at arbejde med det, men, men det er, hvis ikke det virker så kan man godt pakke resten sammen ik’. Så enkelt er det.

LØO: Det er vel sikkert også, det er en af de ting som egentligt, jo mindre det gør sig bemærket, jo

bedre er det JBN: Ja, det kan du sige, ja

73

LØO: Altså de der underliggende IT systemer, det er sådan noget som folk ikke tænker på og siger, det er ikke det der er spændende i forhold til hvordan forretningen kører, det er bare noget der kører og som man først finder ud af når det ikke kører, at så…

JBN: …Og det, det er ikke noget der bare kører, der skal være nogle meget kompetente mennesker,

som der måske heller ikke er så mange af rundt omkring. Der har et dybt kendskab til, hvordan man skal, hvad man skal gøre for at få de ting, der, til at spille.

MG: Hvad med sådan noget som, nu snakker du om kendskab, hvad med viden og sådan noget der,

er det noget der, er det noget, gør i, har i oplevet at mange folk har forladt jer, de har haft at gøre med SAP?

JBN: Nej, det har vi ikke MG: Eller gør i noget specielt for at ligesom at holde på de medarbejdere som, der nu har fået et godt

og dybt kendskab til SAP? 1:01:19 JBN: Ja, det vi jo mange gange har set, det er, at folk, som har været med som lokal deltager på et

SAP projekt. Mange af dem som har lyst og evner og gerne ville det, de blev så SAP konsulenter siden hen. Det tror jeg faktisk langt de fleste vores udenlandske medarbejdere, de er kommet ind i SAP kompetencecentreret på den måde der og der er også et par stykker her i Bjerringbro der er det. Men du har da ret i at markedet for SAP konsulenter det er stadigvæk sælgers marked i nogen grad i hvert fald og det er da heller ikke, jeg vil ikke sige det er et problem at finde SAP medarbejdere, man skal bare være opmærksom på der godt, at der kan godt gå nogle måneder fra man beslutter sig til nu må vi hellere se at få to pp folk mere ind, til de så rent faktisk er her ik’. Men vi har ikke problemer med i Grundfos at konsulenter forlader os, kan man sige, det…

LØO: Hvad med selve den viden som de forskellige medarbejdere har, gør i noget for at, hvis de nu, at

folk de forlader Jer, at den viden så ikke forsvinder med dem? JBN: Jamen, det gør den, altså det gør den jo LØO: …man kan vel også… MG: Vi tænker lidt på dokumentationen af Jeres forskellige processer eller dokumentation af noget

af det som, hvad hedder det… JBN: Jo, men vi dokumenterer da også, men man bare ikke tro, at fordi man dokumentere en hel

masse, at så er man immun overfor, det der, intellektuelle tab, det er at miste medarbejdere. Det er man ikke. Der vil altid forsvinde en hel del viden sammen med medarbejdere der forlader en, det vil der være. Men vi er hos Grundfos måske lidt heldigt stillet at det er en stor organisation og en stor SAP organisation, så der er masser af spændende opgaver og udfordringer for SAP konsulenter og så tror jeg de fleste, i hvert fald mange, arbejder som eksterne konsulenter, men kun i forholdsvis begrænset periode, fordi, jamen, så bliver man jo sendt af sted en uge til det

74

ene sted og næste uge er det et andet sted og man arbejder med en masse forskellig ting og har ikke så stor mulighed for at påvirke hvad det er for nogle opgaver og projekter man er med i, det er der nogen der sidder og bestemmer, kan man sige. Så når man sådan, der er tendens til at når eksterne SAP konsulenter bliver gift og får børn og bosætter sig, så kunne de egentligt godt tænke sig at blive ansat et sted som Grundfos eller Arla. De sådan lidt større koncerner, som har interessant SAP forretning kørende og, hvor arbejdsforholdene er nogenlunde velordnede, sammenlignet med i hvert fald med at arbejde som ekstern konsulent. Men stadigvæk er det, da man skal beregne sig forholdsvis god tid fra man beslutter sig til at man skal tage nogle nye medarbejdere ind til man så rent faktisk har dem og nogle gange, så tager vi da også nogen, som ikke, ikke har så forfærdeligt dyb SAP erfaring, men så træner vi dem op jo i løbet af et år eller to eller sådan noget ik’.

MG: Har i haft meget, mange store sådan, hvad skal man sige, SAP seminarer rundt omkring, sådan i

forbindelse med Jeres, hvad hedder det, implementeringer rundt omkring? I virksomhederne? JBN: Hvad mener du med SAP seminarer… MG: …ja eller, hvad skal man sige, uddannelse af både, hvad skal man sige både superbrugere, men

også den almindelige bruger som har med SAP systemet at gøre? JBN: Ja, der gennemføres træningsplaner og modeltidsplaner for alle slutbrugere i de pågældende

selskaber og det er så SAP projektteamet, der gennemføre det i det pågældende land. MG: Det er så folk der kommer herfra, som ligesom sætter sig ned og… JBN: …ja, de uddanner så de lokale superbrugere og slutbrugere i at bruge SAP systemet

efterfølgende ik’, det gør de. Det er en del af projektet, uddannelse, det er det.

75

Bilag 11: Selskabsoversigt – Grundfos

Kilde: URL 11.

76

Bilag 12: Ledelsesoversigt – Grundfos

Kilde: URL 12.

77

Bilag 13: Grundfos præsentation

Grundfos Ownership Structure

Slide 1

GMA –Services – ORGANISATION Group ManagementJens Jørgen Madsen

Carsten BjergCarlo Prola

Søren Sørensen

R&TPeter Elvekjær

CAB

DosingJes Munk Hansen

Building Services

Lars Fournais

JJM CP JJM CAB SSO

JJM

Industry–WW/WSHenning

Sandager

BDC: Business Development Center

PDJ AcademyKim Hansen

Corp. CommunicationSune Salling-

Mortensen

Group HRJørn Henriksen

Legal Dept.Christian Hartvig

Corp. Plan & Control

Flemming Juul Dam

Group ProductionK.Krægpøth

Group IS

Karsten S. Sørensen

Group SCM/Log.Lars Petersen

Group QualityNiels Møller

JensenGroup Architects

H.C. Baastrup

Group ServiceConni Simonsen

Grundfos Finance

Lars Sylvest”GMA Services”

GMA: GRUNDFOS Management A/S

Corp. Branding

Kim Klastrup

Slide 2

78

SAP R/3 at Grundfos

Slide 3

SAP R/3 in GrundfosSAP R/3 is implemented in 40 Grundfos companies.

Close to 6.000 users in total and still growing.

650GMA / BDC

Number of Users in R/3 (approximately)

5750Total

100Others

3 300Production companies

1 700Sales companies

Slide 4

79

SAP R/3 in GrundfosWe are running R/3 version 4.6c, plan to upgrade by end 2006 or early 2007.

Target version is mySAP ERP 2004 (or possibly mySAP ERP 2005).

Our version history:Roll out (1998/1999) on version 3.0fUpgrade to version 4.6b in 2000Upgrade to version 4.6c in 2002

Slide 5

SAP Hardware Outsourced to CSC

Internet/VPN

Firewall

ISDN BACKUP

ATM network

Internet/VPN

AT/T F/R

Grundfos infrastructure at CSC, Autum 2003

Router

Router

M20Q20Z20Test

Fail-over:P20

databaseand instance

Regatta

Firewall

Tape backupEMC Symetrix 8830

In sync with LPAEMC Symetrix 8730

In sync with RTVTape backup

Concentrator

UNIXservers

Windowsservers

CSC, Retortvej

IXOS primary IXOS failover

CSC, Lersø Park Alle

P20database

and instance

Batch-SpoolTest

RegattaUNIXservers

R/3 (S20 & U30)HR (D, T, U & P21)BW (Q, S & P22)

CRM (M, Q & P23)APO (M, Q & P24)

EBP (S & M25)IXOS & Backup

Fail-over:HR (P21)BW (P22)

IXOS & Backup

EBP (Catalog)CRM (IPC)

BW (ITS, IGS)

P, M, Q20P, D, T21P, M22

P23P24

IXOSTSM

P, M20P, D21

P, T, Q, M22P, Q, M23P, Q, M24

S25IXOSTSM

Headquater Group

Companies

Slide 6

80

Some history• The SAP 2000 project – European implementation

– Organization– Phases– Consulting– Results

• The Vision 21 project – US implementation– Organization– Phases– Consulting– Results

• “Recent” projects– GMX– APREG– GEF– GBJ– GMO / GMR

Slide 7

SAP 2000 Project – European project

Slide 8

81

Roll Out 2000 - Milestones

Jan 98 Feb 98 March 98 April 98 May 98 June 98 July 98 Aug 98 Sept 98 Oct 98 Nov 98 Dec 98

GBGBW PGF GFD

GNL GDK

Jan 99 Feb 99 March 99 April 99 May 99 June 99 July 99 Aug 99 Sept 99 Oct 99 Nov 99 Dec 99

BGE GNO BGPGPI

GWPGWS

GMAGBJ

GPSGIT GSV GBL

GSF

Slide 9

Other Go live

GMX – Mexico (sales company)

The NAMREG team has started GMX in about 3 months.It is a demonstration that the Business Model can be

implemented in few months.

Grundfos SAP team made of 4 consultants and 1 ABAP programmer.

The team was NOT full time in GMX.

Slide 10

82

Other Go liveGEF – Grundfos Environmental Finland (production company)

The GEF project started April 1 and went live November 1. I.e., Grundfos Business Model was implemented in a production company in 5 months including enhancements for traceability & batch handling.

Grundfos SAP team made of• 1 permanent SAP CC consultant based in GEF• 4 SAP CC consultants working part time in GEF.• 2 SAP CC consultants associated with the project on ad

hoc basis.• 1 external consultant working part time in GEF.

Slide 11

Other Go live

GBJ – Grundfos Bjerringbro

This project is by far the biggest R/3 project for Grundfos.About 10 factories, more than 2000 users.

Started beginning 2003, projected completed by end 2005.

Slide 12

83

Other Go live

2003 2004 2005

LA28/9

UP29/3

SQ1/12

CR27/9

CS + EBPFac.6+ 814/6

ShippingInternal salesDCFinance

Shipping -booking+carrierCustoms

CentralPurchasing

MFJun

AAMar

ELSep

200 6

MSDec

IFMay

TCDec

Assets

Årslev

GBJ – Grundfos Bjerringbro – Implementation plan.

Slide 13

Other Go liveAPREG project plan includes

Australia (live)New Zealand (live)

Taiwan (live)

China (planned go-live by April 2006)

Slide 14

84

Grundfos internationally

South AmericaBrazilArgentina

NorthAmericaCanadaUSAMexico

DenmarkUnited KingdomThe NetherlandsFinlandIrelandNorwaySwedenEstoniaLatviaLithuania

FranceItalyPortugalSpainBelgiumSwitzerlandGreeceUnited Arab Emirates

PolandThe Czech RepublicTurkeyHungaryAustriaRussiaUkraine

Southern Europe/Middle

East

Northern Europe

Asia and the PacificIndia

KoreaChina

Hong KongTaiwan

ThailandMalaysia

SingaporeIndonesia

Australia and New Zealand

Japan

Eastern Europe

Grundfos’sales companies

Germany

15

Slide 15

Grundfos internationally

Grundfosproduction companies

Acquired companies

North AmericaUSA

DenmarkEnglandFinland

FranceItalySwitzerland

HungaryRussia

Asia and the Pacific

TaiwanSouth Korea

ChinaGermany

SouthernEurope

Northern Europe Eastern Europe

Slide 16

85

Grundfos internationally – SAP in the future

SAP R/3 deployed:

GB, GDK, Baltic, GNL, GNO, GPI, GSF, GSV, GBL, BGE, BGP, GFD, GIT, GPH, GPS, GWS, GPO, GPU, GMX, GPA,

GNZ, GTS, GBJ, GBW, GEF, GMH, GMU, PGF, GTW, GWP, GMA, GFI, GDS, GMO, GMR

SAP R/3 being implemented:

GSH, GPC, GHU, GCB, New Business companies

SAP R/3 implementation scheduled:

GCZ, GPL, GMH-3, GSI, MXP, GCA

SAP Business One deployed:

GZA, GAM

Potential for SAP R/3 deployment:

GPM, GAS, GTH, GPK, GIN*)

GTR, GGD, GJK*), GBR*)

Potential for Business One deployment:

GUA, GHK, BGA, Philippines, Romania

*) Considered “very complex” by SAP AG, recommended to be last in the deployment schedule.

Slide 17

Grundfos Group IS

Group IS

Basis

Group Management

Sales &ServiceSystems

FinancialSystems

&HR

Manufact.Systems

BusinessIntelligence

Systems

ApplicationDevelopment

IT CustomerServices

IT Operations&

Infrastructure

Admin.IT Security

Special Proj.IT Strategies

Secretary

IT Infrastr. Proj.Mgmt.

ERP Infrastr. & Sys.Mgmt.

Desktop System Mgmt.

IT Opr., Server & Netw. Mgmt.

Service Agreements

IT Servicedesk

Office Development

Telephony Services

Intranet development

IT Asset Management

WWW

- Portals

- CAPS

- EDI

BW

SAS

e-Business&

-Innovation

Production

Companies

IT

Regional

ITSAP Authorizations Pilot Projects

SAP Competence Centre

Slide 18

86

SAP Competence Centre

Grundfos Group IS

Karsten S. SørensenGroup Vice President, IT

John B. NielsenManager SAP CC

Lars ChristensenManager SAP CC Sales & Service

SAP CC Manufacturing Christian Ø. ChristensenManager SAP CC Finance & HR

Claus Leth ChristensenManager SAP CC BI

Anette MühlbrandCommon Appl. & Processes

SAP CC Manufacturing IJan Bo Kudsk

PP, MM, QM, PM & SRM

SAP CC Manufacturing IIJohn B. Nielsen

Product Data, WarehousingABAP

Slide 19

87

Bilag 14: Lydfiler fra interviews Lyd cd med interviews fra LEGO og Grundfos Indehold: Bilag 14_Lydfil 1_Interview Lego_100506_Henrik Weis Aalbæk.mp3 Bilag 14_Lydfil 2_Interview Lego_100506_Henrik Weis Aalbæk.mp3 Bilag 14_Lydfil 3_Interview Grundfos_240506_John B. Nielsen.mp3

88