Implementering af ERP-systemer. - en værktøjskasse med råd og vejledning

Transkript

1 Implementering af ERP-systemer - en værktøjskasse med råd og vejledning

2 Forord 1. Forord Med denne publikation er det vores ønske at viderebringe Deloitte IT Solutions praktiske erfaringer med projekter for implementering af ERP-systemer. Vores erfaringer er blandt andet høstet ved gennemførelse af projekter hos en række danske virksomheder og offentlige institutioner. Vi har samlet disse erfaringer, idet vi har set mange virksomheder løbe sur undervejs i it-projekter ikke mindst ved implementering af et nyt ERP-system. Virksomheder undervurderer ofte indhold og ikke mindst omfang dels af de opgaver, som skal udføres, dels af de problemer og konflikter, som altid opstår undervejs. Mange virksomheder har ikke tilstrækkelige interne ressourcer til både at klare det daglige arbejde samtidig med indføring af et nyt ERP-system. Disse opgaver bliver ofte bare lagt oven på de daglige opgaver i virksomheden det klarer du lige. Dette får den konsekvens, at opgaver i tilknytning til ERP-systemet nedprioriteres i forhold til de daglige opgaver. Desuden omfatter ERP-projekter aktiviteter og begreber, som kan være ukendte for virksomheden, og som den derfor er uforberedt på og heller ikke har de rette forudsætninger for at kunne håndtere. Måske er hele projektbegrebet også nyt og ukendt for virksomheden. Resultatet af alt dette er en ond spiral med forsinkelser, gensidige beskyldninger mellem virksomhed og leverandør. Det resulterer i tab af tillid mellem virksomhed og leverandør, manglende opfyldelse af mål med det nye ERP-systemer osv. Denne spiral kan i yderste konsekvens ende i en voldgift eller retssag, hvor de eneste sikre vindere er de advokater, som bliver inddraget. Vores ønske og formål med publikationen er derfor at komme med råd og vejledning til gennemførelsen af it-projekter, således at man som virksomhed får et velfungerende ERP-system, der opfattes positivt af brugerne og som understøtter forretningen. God læselyst. 2

3 Indhold Indholdsfortegnelse 1. Forord...2 ERP-systemer Generelt om projekter og især om ERP-projekter Projekttankegang/-kultur Valg af implementeringsstrategier Faser i et implementeringsprojekt: Projektmodel Faldgruber undervejs Forhandling med leverandør Projektetablering Opnå opbakning Fastlægge succeskriterier Sammensætte og sammentømre det rette projektteam Projektorganisering Informere om mål, fremdrift, udfordringer mv Analysere og håndtere risikoområder Håndtere forandringer Håndtere projekthindringer Styre ændringer It-miljøer Specifikation og design Procesmodellering Standardfunktionalitet kontra tilpasning af forretningsgange Scope creep Udvikling, opsætning og test Udvikling og præ-opsætning hos leverandør Opsætning sammen med virksomheden Test Brugervenlighed Implementering Træning Datakonvertering Overtagelsesprøve, accepttest Driftsstart Efter driftsstart Supportorganisation ERP er som en rejse Case Deloittes tilgang til it-implementeringsprojekter Express for implementation TM Project Management Method TM Om Deloitte IT Solutions Afrunding...35 Publikationens indhold må ikke sælges, distribueres, gengives, fotokopieres, skannes eller på anden vis mangfoldiggøres hverken digitalt eller fysisk uden skriftlig tilladelse fra Deloitte Statsautoriseret Revisionsaktieselskab. Ansvarsfraskrivelse Alle oplysninger i publikationen er, som de fremstår og beskrives. Der tages forbehold for eventuelle fejl og misforståelser. Deloitte kan ikke drages til ansvar for skader, gener eller lignende, der måtte være opstået som følge af anvendelse af oplysninger i denne publikation. Alle de anførte produkter og tilhørende varemærker tilhører de respektive virksomheder. 3

4 ERP-systemer ERP-systemer En virksomhed har typisk behov for at registrere sine kunder og leverandører, at budgettere salg og indkøb, at håndtere salgs- og indkøbsordrer, at styre lager med varer ind, ud og mellem flere lagerlokationer, at opgøre varebeholdninger og værdi af varer i arbejde, at planlægge og styre produktion, serviceopgaver, distribution af varer mv., at registrere tidsforbrug, udlæg, rejser mv. for medarbejderne, at håndtere medarbejderdata samt at foretage økonomimæssige opgaver så som at modtage indbetalinger, at udføre udbetalinger, at opgøre og udbetale løn, at opgøre og rapportere afgifter, moms, intrastat mv., at bogføre og analysere på alle de regnskabsmæssige hændelser plus formentlig mange flere aktiviteter. Et it-system, der understøtter disse aktiviteter, betegnes ofte som et ERP-system. Begrebet ERP (Enterprise Resource Planning) er opfundet af analysefirmaet Gartner i 1990 erne. For at et system med rimelighed kan betegnes som et ERP-system, må det have følgende kendetegn: Systemet kommer fra en leverandør, som løbende udvikler og vedligeholder systemet. Systemet kan tilpasses forhold i flere brancher enten ved konfiguration eller tilretning. Systemet har en forholdsvis bred funktionalitet, dvs. det dækker flere områder i virksomheden. Systemet opleves af brugerne som integreret, dvs. systemet har ensartet brugergrænseflade, og registreret data er tilgængelig i alle områder af systemet. En overordnet opbygning af ERP-systemer er søgt illustreret nedenfor. ERP-systemer omfatter typisk funktionalitet inden for disse områder i virksomheden. Det skal bemærkes, at selvom to it-systemer begge betegner sig selv som et ERP-system, vil der ofte være meget stor forskel på disse systemer med hensyn til funktionalitet, brugergrænseflade, fleksibilitet, kompleksitet i implementeringsprojekt, anskaffelsesog driftspris mv. Desuden vil der være forskel på de to leverandører fx deres branchekendskab og referencer. Såvel valg som implementering af ERP-system er bestemt ikke simple opgaver. Funktionalitet rettet mod leverandører Indkøb Forecast Leverandør Funktionalitet rettet internt Udvikling Produktion Økonomi Finans Ordrebehandling Lager Projekter HR/Personale Funktionalitet rettet mod kunder Markedsføring Salg, CRM Forecast Service Tværgående funktionalitet Ledelsesinformation ebusiness Supply Chain Management Figur 1: Overordnet opbygning af ERP-systemer. 4

5 Generelt om projekter og især om ERP-projekter 2. Generelt om projekter og især om ERP-projekter Implementeringsprojektet udgør en væsentlig del af den samlede investering i forbindelse med anskaffelse af et nyt ERP-system. En simpel tommelfingerregel siger, at omkostninger til tilretning og implementering er licensprisen ganget med en faktor 2-3, se figur 2. Hertil kommer også de interne ressourcer, som virksomheden selv anvender og mistet indtjening for personer, der ikke kan udføre deres sædvanlige arbejdsopgaver. Desuden skal man som virksomhed anvende og leve med ERP-systemet i lang tid efter implementeringen. som har prøvet det før. Desuden er det ofte de tekniske og administrative aspekter af implementeringsprojektet, som får den største opmærksomhed, men det er ofte de bløde aspekter, som afgør, om it-projekter bliver opfattet som en succes. Det er derfor meget vigtigt, at ERP-systemet bliver opfattet som en succes, og at det bliver implementeret på en måde, som understøtter ens forretning. 31% 15% Gennemførelsen af it-projekter er ofte præget af problemer. I CHAOS-undersøgelsen har Standish Group set på over itprojekter. De har påvist, at ud af påbegyndte it-projekter bliver kun omkring en tredjedel (i 2004) gennemført med succes (grøn farve i figur 2 ) og 15% bliver aldrig fuldført (rød farve i figur 3). De resterende projekter (gul farve i figur 3) bliver i større eller mindre grad betragtet som en fiasko, fordi de overstiger budgettet, ikke overholder tidsplanen eller ikke opfylder de stillede krav. Det positive er dog, at andelen af succesfulde projekter er stigende fra 1994 til Som det fremgår af ovenstående, er det ikke så let at opnå et succesfuldt implementeringsprojekt. To væsentlige faktorer for at opnå et succesfuldt projekt er dels at anvende en velafprøvet metode til at gennemføre implementeringsprojektet, dels at have et projektteam, 53% 16% % 34% 2004 Projektet bliver aldrig fuldført og opfattes som en fiasko Projektet gennemføres delvist og opfattes ikke som vellykket Projektet gennemføres og opfattes som en klar succes Figur 3: Undersøgelse foretaget af Standish Group omkring gennemførelse af it-projekter. ERP-licenser udgør 25-35% af de eksterne omkostninger ERP-tilretning og implementering udgør 65-75% af de eksterne omkostninger Interne omkostninger Figur 2: En tommelfingerregel siger, at omkostninger til tilretning og implementering er licensprisen multipliceret med en faktor

6 Generelt om projekter og især om ERP-projekter 2.1 Projekttankegang/-kultur Men hvad er egentlig et projekt? Lidt akademisk defineres et projekt ofte som det at løse en specifik opgave (fx at implementere et nyt ERP-system) inden for en tidsmæssig afgrænset periode med fastlagt start- og sluttidspunkt (fx klar til driftsstart den 1. januar 2010 ved start af nyt regnskabsår) og ved hjælp af tilknyttede ressourcer (fx Per, Poul, Inge,...). Opgaven kan i starten af projektet ofte virke meget kompliceret og uoverskuelig, fordi der er tale om en ikke velkendt opgave, og den nødvendige viden er ikke kendt i begyndelsen. Projekter adskiller sig fra de daglige opgaver netop ved, at det er noget helt andet, der skal udføres. I projektet indgår følgende elementer: Selve opgaven det endelige resultat og mål. Interessenter de personer, som har interesse i resultatet og som kan påvirke undervejs. Ressourcer de personer, som skal udføre opgaverne for at nå det ønskede resultat og mål. Fremgangsmåde hvordan man har tænkt sig at gribe sagen an: Projektplanen. De fleste virksomheder overraskes over, hvor meget implementeringsprojektet kræver af interne ressourcer. Det overstiger ofte det, som man på forhånd har aftalt med leverandøren. Det er ikke nødvendigvis af det onde. Man skal bare være forberedt på det. I projekter vil man ofte opleve forløb for motivation og præstationsniveau i projektgruppen som illustreret i figur 4, hvor de enkelte perioder er karakteriseret ved: Etablering. Denne periode optræder, når gruppen sammensættes som overgangsforløb fra individualisme til gruppemedlemskab. Deltagerne afprøver lederens styring både formelt og uformelt. Oprør. Dette er den mest vanskelige periode, hvor deltagerne begynder at forstå, at opgaven er mere anderledes og vanskeligere, end de forestillede sig. Stemningen i gruppen bliver trykket, opfarende og frustrerende. Gennemførelse. Deltagerne forener loyalitet, ansvar og opgaver samt accepterer gruppen, gruppens regler og de individuelle forskelle hos de enkelte deltagere. Dette er den produktive periode. Afslutning. Projektet er succesfuldt afsluttet, og forankringen af resultaterne påbegyndes. Deltagerne skilles og vender tilbage til deres dagligdag. Varighed og omfang af oprørsperioden kan mindskes gennem etablering af team spirit og klar kommunikation om forventede mål og forventning. Disse forhold behandles mere detaljeret i afsnit 4.2 og 4.3. Såfremt man som virksomhed har gang i flere reelle projekter, betegnes det samlet som et program. Det kan i den forbindelse være en god ide at etablere et programkontor til at koordinere projekterne dels for at sikre, de følger de samme overordnede mål, dels fordi de ofte slås om de samme ressourcer, se figur 5. Programkontoret kan også hjælpe projektlederne med at planlægge og styre deres projekter. Typiske opgaver for et programkontor kan være: Foretage strategiske prioriteringer for at sikre, at alle igangsatte projekter er i overensstemmelse med den overordnede strategi. Etablere en god projektkultur fx uddanne projektledere. Give ledelsen overblik over de igangværende projekter. Koordinere afhængigheder mellem projekter. Støtte til de enkelte projekter fx for at fastholde fokus samt bidrage med metoder, risikostyring, kvalitetssikring og rapportering. Kommunikere den rigtige information på det rigtige tidspunkt til ledelse og medarbejdere, hvorved der skabes platform for ledelsesopbakning og brugerinvolvering. Moral Projekter er typisk funktionelt orienterede, og de har deres egne mål. Dette kan resultere i suboptimering i forhold til det overordnede mål. Præstationsniveau Med en overordnet styring af projektporteføljen sikres, at det fælles mål opnås, og at synergieffekter realiseres. Etablering Oprør Gennemførelse Afslutning Figur 4: Typisk forløb for projektgruppens motivation og præstationsniveau gennem projektforløbet. Figur 5: Effekt af at anvende et programkontor til at styre den samlede projektportefølje. 6

7 Generelt om projekter og især om ERP-projekter 2.2 Valg af implementeringsstrategier Et væsentlig aspekt er at fastlægge den overordnede fremgangmåde for, hvordan ERP-systemet skal tages i anvendelse i virksomheden dvs. implementeringsstrategi. Implementeringsstrategien bestemmer, hvornår det nye ERP-system kommer til at påvirke forretningen, kunder og medarbejdere. Implementeringsstrategien bestemmer også i høj grad tidsplan og ressourcebehov for projektet. Principielt kan der anvendes følgende forskellige strategier for implementering af et ERP-system: Big Bang-strategi. ERP-systemet og de tilhørende forretningsprocesser planlægges, konfigureres, tilrettes og implementeres i hele virksomheden i en samlet idriftsættelse. Som hovedregel kan følgende anvendes til at vælge blandt disse strategier: En Big Bang-strategi egner sig bedst til virksomheder, som har meget ensartede forretningsområder på tværs af datterselskaber, divisioner, afdelinger mv. og som har meget strømlinede forretningsprocesser. En faseopdelt strategi egner sig bedst til virksomheder med komplekse delprocesser og forholdsvis ensartede forretningsområder. En kombineret strategi egner sig til virksomheder med uensartede forretningsområder. Faseopdelt strategi vandfaldsmodel. ERP-systemet og de tilhørende forretningsprocesser deles op i mindre, gradvise idriftsættelser fx Økonomi Lager Indkøb Salg. Kombineret strategi. Big Bang-tilgang, der gradvis idriftsættes i virksomhedens datterselskaber, divisioner, afdelinger mv. fx Datterselskab B Datterselskab A Hovedkontor. Big Bang Fordele Omfatter en mere intens og afgrænset periode end en faseopdelt strategi De nødvendige ressourcer kan lettere estimeres Eksisterende systemer kan hurtigere elimineres og dermed forhindres, at skyggeløsninger lever videre Faseopdelt strategi vandfaldsmodel Ulemper Risikofyldt, da det det udsætter hele virksomheden for et stort pres i overgangsperioden Medfører ofte en række børnesygdomme pga. oversete detaljer Der kan opstå udfordringer i de områder af virksomheden, som adskiller sig fra normen Fordele Giver mulighed for at planlægge, tilpasse og kvalitetssikre forretningsgangen og systemets funktionalitet indenfor hver enkel arbejdsproces Sikrer en mere smidig overgang til det nye miljø og lettere koordinering med den daglige forretning Kombineret strategi Fordele Har fordele fra en Big Bang-strategi indenfor det område, hvor løsningen rulles ud, men med lavere risiko og bedre mulighed for at tilpasse implementeringsforløbet lokalt Ulemper Afhængigheder mellem de enkelte it-moduler vanskeliggør forløbet Har en tendens til at trække ud i tid, da projektet savner helhedsfokus og intensitet Kan føre til forandringstræthed i organisationen bliver vi da aldrig færdige? Kræver midlertidige grænseflader til og paralleldrift af eksisterende systemer Ulemper Har som ved faseopdelt strategi en tendens til at trække ud i tid og kræver dermed projektressourcer i en længere periode En vis grad af midlertidige grænseflader og paralleldrift kan ikke undgås

8 Generelt om projekter og især om ERP-projekter 2.3 Faser i et implementeringsprojekt: Projektmodel Et implementeringsprojekt vil typisk omfatte følgende faser, hvor betegnelser og indhold kan variere lidt i de forskellige projektmodeller og metoder: Forhandling med leverandør. Kontraktforhandlinger er ikke direkte en del af implementeringsprojektet, men væsentlige forhold for implementeringsprojektet fastlægges i disse forhandlinger. Projektetablering med afgrænsning og planlægning. I denne fase mobiliseres projektteamet fra både leverandør og virksomhed, og der foretages planlægning af projektet. Specifikation og design. I løbet af denne fase omsættes kravspecifikationen til systemdesign. Udvikling og opsætning samt test. I denne fase er det primært leverandøren, som er på banen med at tilrette og opsætte systemet. Virksomheden er dog også på banen i forbindelse med test. Implementering. Denne fase er intensiv for virksomheden med træning af slutbrugerne, datakonvertering, overtagelsesprøve og driftsstart. Efter driftsstart. Så kører toget. Desuden er der en række aktiviteter, som udføres i alle faser: Projektledelse, herunder ændrings- og projekthindringshåndtering Håndtering af forandringsproces Kommunikation. Baseret på denne faseopdeling viser figur 6 en mulig overordnet tidsplan, som i den aktuelle situation skal detaljeres yderligere. Det er vigtigt, at planen afspejler de aktuelle forhold fx de tilretninger, som skal udføres, de forretningsprocesser, som skal tilpasses og det nødvendige omfang af forandringsledelse. Den tidsmæssige udstrækning for projektet afhænger naturligvis af det aktuelle omfang og kompleksitet, men en udstrækning på 6-9 måneder må forventes. Projektet bør hverken gennemtvinges eller udstrækkes unødigt, idet begge dele let kan give et ikke succesfuldt projekt. Forcering kan medføre, at systemet ikke er tilstrækkelig testet, eller at brugerne ikke er trænet tilstrækkeligt inden driftsstart det kan medføre, at systemet opfattes som mangelfuldt. En for lang projektperiode kan medføre træthed i organisationen med holdninger som det bliver aldrig til noget. Tidsplanen skal på samme tid være ambitiøs og realistisk for både leverandøren og virksomheden. En simpel tommelfingerregel siger, at det interne ressourcebehov i virksomheden til projektet er omtrent det dobbelte af leverandørens ressourcebehov. Dette afhænger naturligvis af kompleksitet og omfang (fx antal brugere, som skal trænes i anvendelse af systemet), samt den aktuelle fordeling af opgaver mellem leverandør og virksomhed. Typisk vil det interne ressourcebehov i virksomheden variere meget igennem projektforløbet, se figur 7. Det er vigtigt, at leverandøren både har erfarne projektledere og en gennemprøvet projektmodel for gennemførelse af implementeringsprojektet med aktiviteter både for leverandøren og for virksomheden. Der vil være sammenhæng og afhængigheder mellem aktiviteter, skemaer, værktøjer mv. Dermed er leverandøren bedre i stand til at forudse og håndtere de problemstillinger, som sandsynligvis vil opstå undervejs i forløbet. Et forhold, man som virksomhed også skal være opmærksom på, er samspillet mellem virksomhedens egen projektmetode og leverandørens projektmodel. Forskellig anvendelse af begreber og sprogbrug er årsag til mange konflikter. Dette betyder, at der er rige muligheder for, at de to parter kan komme skævt ind på hinanden undervejs i implementeringsforløbet. Deloittes egne projektmodeller for gennemførelse af projekter generelt og specifikt for ERP-implementering beskrives i kapitel 9. Forhandling med leverandør Projekt kick-off Projektetablering med afgrænsning og planlægning Specifikation og design Udvikling og opsætning samt test Implementering Udrulning Træning af slutbrugere Datakonvertering Overtagelsesprøve Driftsstart Efter driftsstart Specifikation og design Udvikling og opsætning samt test Implementering: Udrulning Træning af slutbrugere Datakonvertering Overtagelsesprøve Driftsstart Måned Figur 6: Eksempel på overordnet tidsplan for et ERP-implementeringsprojekt. Aktiviteter vist med blå farve indgår ikke i selve implementeringsprojektet. Figur 7: Ressourcebehovet i implementeringsprojektet varierer meget i løbet af projektperioden. 8

9 Generelt om projekter og især om ERP-projekter 2.4 Faldgruber undervejs De mest udbredte faldgruber eller årsager til mislykkede it-projekter er: Forståelseskløft mellem virksomhed og leverandør bl.a. terminologi og baggrundsviden. Virksomheden agerer ud fra mangler i og viden om det nuværende system, mens leverandøren agerer ud fra muligheder i det nye system og kender ikke de nuværende mangler. Utilstrækkelig brugerinput og/eller involvering. Manglende fokus på forandringsledelse og modstand i organisationen. Utilstrækkelige og/eller upræcise krav til systemet. Ændring af krav undervejs i projektet scope creep (se afsnit 5.3). Manglende/utilstrækkelig ledelsesopbakning. Utilstrækkelig teknisk forståelse af både muligheder og begrænsninger. Utilstrækkelige interne ressourcer. Projektgruppen fungerer ikke godt nok samarbejdet knirker. Urealistiske forventninger. Uklare mål. Urealistisk tidsplan. Brug af ny og umoden teknologi. Midler til at undgå disse faldgruber er at: Udarbejde et detaljeret projektdefinitionsdokument, så der ikke er tvivl om, hvad der er med og specielt hvad der ikke er med i projektet. Dette omfatter også en procesoversigt med markering af hvilke systemer, der understøtter hvilke processer, så understøttelse ikke falder mellem to stole. Tilknytte en projektleder fra leverandøren, der forstår at føre projektet igennem i forhold til tid og mål kort sagt en projektleder, som har prøvet det før og som har gennemslagskraft. Anvende en projektmetode, som proaktivt tager hånd om de udfordringer og faldgruber, der med usvigelig sikkerhed vil opstå undervejs i forløbet. Have et projektteam, som har prøvet det før. Dette gælder især for leverandøren, men hvis man som virksomhed har medarbejdere, som tidligere har prøvet at gennemføre ERP-implementeringer, kan disse med fordel involveres i projektet. Få virksomhedens projektteam til at opbygge processer i systemet. Dette flytter teamet over i systemets tankegang ved at afprøve muligheder inden for systemet. Det giver hands-onforståelse i forhold til den ret abstrakte forståelse, der opnås ved at skrive rapporter. Leverandøren opnår også dybere indsigt i og forståelse af virksomhedens problemstillinger. Etablere standardiserede og effektive arbejdsgange gerne baseret på principper i ERP-systemet. Gøre sig klart, at der ikke kun tale om datadisciplin, men i høj grad også om procesdisciplin. Sikre, at projektdeltagerne oplever projektet og processen som fremgangsrig og berigende gennem aktiv involvering. Afklare og formidle, hvad det nye system betyder for den enkelte medarbejder i fremtiden. Etablere en fælles projektkultur med klare roller, opgaver, mål og ansvar. 9

10 Forhandling med leverandør 3. Forhandling med leverandør Forløbet for forhandling er helt individuelt. Det er dog væsentligt at understrege, at det - som i et hvert forhandlingsforløb - gælder om at opnå en kontrakt, som begge parter er tilfredse med, dvs. opnå en WinWin-situation. I modsat fald er kimen lagt til et dårligt forløb for implementeringen, hvilket der er utallige eksempler på. Såfremt den samlede ERP-løsning omfatter delsystemer fra flere leverandører, bør man som købervirksomhed forsøge at få en af de involverede leverandører til at være hovedleverandør med det samlede ansvar for hele systemet. Hvis man som køber har individuelle kontrakter med flere leverandører, som hver skal levere dele af den samlede løsning, opstår der masser af muligheder for, at leverandørerne kan begrunde forsinkelser og problemer med mangelfulde leverancer fra de øvrige leverandører. Kontrakten er det juridiske grundlag og fundament for projektet, som kan anvendes til at afgøre tvister og bilægge uenighed. Derudover er kontrakten i lige så høj grad et styringsredskab for projektet med procedurer, fremgangsmåder og spilleregler. Det et vigtigt, at begge parter primært opfatter kontrakten som et fælles styringsredskab, og at de ikke ser den som en hammer, der kan anvendes til at slå og knuse modparten med. Senest i forbindelse med kontraktforhandling bør man som virksomhed involvere en advokat med speciale indenfor it-kontrakter og it-ret for derved at sikre, at de juridiske forhold er tilpasset den aktuelle situation. Allerhelst bør advokaten involveres allerede før, udbuddet afsendes, således at kontraktoplægget i udbudsmaterialet bliver udformet mest hensigtsmæssigt ud fra de konkrete, individuelle forhold hvad enten det udarbejdes helt fra grunden eller baseres på en allerede udarbejdet standardkontrakt eksempelvis K01-standardkontrakten for kortvarige it-projekter. Såfremt K01 anvendes, bør der især være fokus på udformning af bilagene. Disse bilag fastlægger en række forhold omkring implementeringsforløbet. Bilagene omfatter følgende forhold: Tidsplan. Dette bilag fastlægger den tidsmæssig udstrækning og sammenhæng mellem aktiviteter i projektet, herunder også hvornår de forskellige leverancer skal foreligge. Kravspecifikation. Dette bilag omfatter kravene til det ERPsystem, der skal leveres, herunder også integrationer til andre it-systemer. Betalingsplan. Dette bilag fastlægger, hvornår betaling skal finde sted. Betalingstidspunkterne bør kobles til afslutning af bestemte aktiviteter, fx beståede prøver. Specifikation af udstyr, programmel og dokumentation med priser. Dette bilag fastlægger hardware fx servere, printere, scannere, netværk mv. og standardprogrammel fx ERPsystemet, database mv. samt tilhørende dokumentation, som er omfattet af kontrakten. Beskrivelser af tilknyttede ydelser med priser. Dette bilag beskriver de typisk timebaserede ydelser, der ikke direkte er en del af systemet fx tilrettelser af systemet, uddannelse, konvertering og projektledelse. Kundens deltagelse. Dette meget vigtige bilag beskriver omfanget af virksomhedens medvirken i projektet. Specifikation af vedligeholdelse med priser. Dette bilag beskriver omfang og indhold af den efterfølgende vedligeholdelse af systemet. Prøver. Dette bilag beskriver, hvordan afprøvning og godkendelse af systemet skal finde sted. Licensbetingelser. Dette bilag beskriver de betingelser, som er gældende for at anvende systemet. Servicemål og incitamenter. Dette bilag fastlægger de mål, som leverandøren skal opfylde fx svartider. Samarbejdsorganisation. Dette bilag fastlægger den fælles projektorganisation med roller, ansvar, kommunikationsveje og opgaver. Ændringsprocedure. Dette også meget centrale bilag fastlægger, hvordan ændringsforlag, som opstår undervejs i projektet, skal håndteres. Specifikation af optioner med priser. Dette bilag beskriver mulige udvidelser til løsningen. 10

11 Kontraktforhandling Implementering af ERP-systemer Projektetablering 4. Projektetablering 4.1 Opnå opbakning 4.2 Fastlægge succeskriterier Man får ikke en succesfuld implementering, hvis der ikke er opbakning til projektet og det nye system i ens egen organisation. Man skal derfor fra projektets start sørge for at informere organisationen om de kommende forandringer. Desuden skal ledelsen på en synlig måde involvere sig i og bakke op om det nye ERP-system. En effektiv måde til at sikre opbakning i organisationen er at involvere medarbejderne i det forestående projekt. Det giver en følelse af ejerskab og medindflydelse hos medarbejderne, som kan forebygge den ellers naturlige mistro og skepsis over for forandringer. Der bør fastlægges målbare succeskriterier for det kommende ERPimplementeringsprojekt. Hvad vil vi som virksomhed opnå gennem projektet? Hvad er forudsætningerne for at opnå disse mål? Man bør opstille både direkte kvantificerbare effekter af ERP-projektet og mere uhåndgribelige og bløde effekter. De kvantificerbare effekter omfatter eksempelvis: reduktion i tidsforbrug til drift af systemet, mindre tidsforbrug til ordremodtagelse mv. De mere uhåndgribelige og bløde effekter omfatter: færre fejl, bedre dokumentation, mere tilfredse medarbejdere mv. Succeskriterier og effekter kan anvendes undervejs i projektet for at vise, at man er på rette vej. 11

12 Projektetablering 4.3 Sammensætte og sammentømre det rette projektteam Når man skal udvælge, hvilke interne nøglepersoner der skal tilknyttes projektet, må man ikke nøjes med de næstbedste. Der er tale om et projekt, der vil påvirke de næste mange års arbejde i virksomheden, så man bør vælge de bedst kvalificerede til denne opgave. Også selv om det oftest er dem, som i forvejen har for meget at lave. Imidlertid er det så også vigtigt, at disse personer reelt får mulighed for at deltage i projektet. Det er ikke muligt blot at læsse denne opgave oven på deres øvrige opgaver. Derfor er det vigtigt, at man sørger for aflastning af andre opgaver, så længe projektet pågår. Der ligger en udfordring for projektgruppen omkring at få skabt sammenhæng mellem de processer, der går på tværs af afdelinger. Beslutninger, der træffes på et område, kan ofte have indflydelse på flere arbejdsprocesser, der ikke varetages af den samme procesejer. Under designanalysen anbefales det derfor at inddrage samtlige relevante procesejere. Kerneprojektgruppen skal være tæt på 100% allokeret til implementeringsprojektet. Kun herved opnås den nødvendige kontinuitet i arbejdet med at designe systemet (designfasen). Det er en god ide tidligt i implementeringsforløbet med en aktivitet, der uddanner projektteamet i det aktuelle ERP-system. På den måde får projektdeltagerne indsigt i, hvad systemet kan, og hvordan det fungerer. Formålet er at give projektdeltagerne et systemmæssigt overblik, så de kan vurdere, hvorvidt standardfunktionalitet kan anvendes i stedet for tilrettelser. Tilsvarende bør der også være aktiviteter for at sammentømre projektteamet og opbygge teamspirit. Dette skal opbygge forståelsen for teamets styrker og svagheder, laveste fællesnævner, standarden for teamets indsats, potentiale mv. Dette bør omfatte projektdeltagerne fra både virksomheden og leverandøren, således at de opnår en fælles forståelse og samhørighed vi skal sammen bringe dette projekt sikkert i mål. Man kan tale om, at projektteamet i lige så høj grad skal være opmærksom på energien i projektet, som de er tiden i projektet. Med den rette energi i projektet opnås ofte mere på kortere tid og med færre fejl. Tiden i projektet er kendetegnet ved rammen og strukturen, samt vaner og ritualer, som også er vigtige for projektet. En stærk kombination af tidsstyring og energistyring er målet for et stærkt projektteam. Der kan let opstå de og vi -holdninger i et implementeringsprojekt med udsagn og opfattelser som de leverer igen ikke det, som vi var blevet lovet, nu kan vi igen ikke komme videre, fordi de ikke har leveret osv. osv. En god metode til at undgå dette er at anvende en projekttilgang, hvor hele projektteamet i videst mulige omfang udfører opgaver i fællesskab. Dvs. projektdeltagere fra både virksomhed og leverandør opholder sig i samme lokale for at udføre opgaver med fælles input eksempelvis kortlægning og modellering af forretningsprocesser, afdækning af krav og behov, fastlæggelse af arbejdsgange, opsætning af systemet samt test og dokumentation af såvel opsætning som tilrettelser. Det bør også tilstræbes, at relevante støtteressourcer for de enkelte opgaver er umiddelbart tilgængelige, eksempelvis at der er udvikler(e) til stede ved testforløb, således at en konstateret fejl/mangel straks kan afhjælpes. Formålet med en sådan projekttilgang er: at opnå et hurtigt og effektivt projektforløb. at sikre en god kvalitet i projektets leverancer. at opnå en god kommunikationen i projektgruppen. at undgå misforståelser, som let opstår ved skriftlig kommunikation mellem fysisk adskilte parter. at få diskussion af det reelle behov bagved formulerede krav, hvilket evt. kan resultere i ændret arbejdsgang og krav, således at standardfunktionalitet i højere grad kan anvendes. at minimere skriftlig kommunikation i projektet. at få en hurtig afklaring af opståede forhold. at få høj grad af fællesskabsfølelse mellem virksomhed og leverandør. 12

13 Projektetablering 4.4 Projektorganisering Projektorganisationen skal afspejle den aktuelle størrelse og kompleksitet af implementeringsprojektet. Leverandøren vil naturligvis etablere sin egen projektorganisation, men man skal som modtager også etablere sin egen organisation for at klare de opgaver, som påhviler virksomheden. Figur 8 viser en mulig projektorganisation for virksomhedens del af implementeringsprojektet. Det skal imidlertid understreges, at virksomhedens og leverandørens projektorganisation bør koordineres og opfattes som en fælles organisation. Opgaver og ansvar for de enkelte enheder i projektorganisationen er beskrevet nedenfor. Styregruppe Styregruppen har det overordnede ansvar for det samlede projekts gennemførelse og succes i henhold til de opstillede målsætninger. Den træffer alle overordnede beslutninger på statusmøder, der som minimum afholdes sammen med de større milepæle i det samlede projekt. Både leverandør og virksomhed skal være repræsenteret i styregruppen og med deltagere, som har beslutningskompetence, dvs. typiske på topledelsesniveau. Projektets sponsor den budgetansvarlige leder styregruppen og har dermed det overordnede ansvar for det samlede projekt. Det vigtigste formål med styregruppen er at sikre projektgruppen de nødvendige vilkår, at træffe beslutninger omkring ændringsønsker, at løse konflikter mv. Specifikt er det styregruppens ansvar og opgave at: Etablere det kontraktmæssige grundlag. Udstikke den strategiske retning for det samlede projekt samt sikre, at den efterleves. Fremstå som synlig sponsor af det samlede projekt. Fastsætte det samlede projekts succesfaktorer og mål. Give projektledelsen og projektlederne for de enkelte delprojekter den nødvendige kompetence og autoritet til at kunne styre og lede henholdsvis det samlede projekt og de enkelte delprojekter. Behandle og beslutte i relation til fremlagte indstillinger fra projektledelsen. Foretage indledende ressourceallokering. de enkelte delprojekter. Projektledelsen bør være et fælles forum for både leverandørens og den interne projektleder. Såfremt de to personer ikke kan samarbejde, er der meget stor sandsynlighed for, at projektet kuldsejler. Den interne projektleder skal have kendskab til alle relevante forretningsområder i virksomheden og bør have projektledererfaring. Som udgangspunkt skal den interne projektleder have en scorekeeperrolle og efter behov gå ind som sparringspartner for de enkelte delprojekter. Specifikt er det projektledelsens ansvar og opgave at: Udarbejde overordnet projektplan og arbejdsplaner for de enkelte delprojekter inklusive tilhørende ressourcebudgetter. Lede og styre det samlede projekts fremdrift i henhold til disse planer og budgetter, herunder nødvendig risikostyring. Afholde nødvendige møder med projektets deltagere for at koordinere fremdriften. Sikre det samlede projekts leverancer, herunder gennemførelse af nødvendig og relevant kvalitetssikring. Sikre, at procedurer og standarder overholdes. Sikre opfølgning på og afhjælpning af identificerede problemer. Sikre nødvendig, rettidig og relevant kommunikation til de etablerede projektgrupper, styregruppen og den øvrige organisation. Agere sparringspartner for lederne af delprojekterne. Rapportere til styregruppen i form af statusrapporter i krævet format. Ændringsstyring Denne organisatoriske enhed har ansvar for behandling af forslag til ny eller ændret funktionalitet i systemet. Formålet med at opbygge en formel fremgangsmåde for håndtering af ændringsforslag er at: Gøre det muligt at fremsætte, få behandlet og vedtaget eller forkastet ændringsforslag af alle elementer i projektet. Sikre, at ændrede behov og muligheder løbende kan indarbejdes i leverancerne. Projektledelse Denne organisatoriske enhed har ansvar for gennemførelsen af det samlede projekt, herunder koordinering mellem og opfølgning på Styregruppe Infrastruktur Processer Konvertering Test Træning Forandringsledelse Ændringsstyring Projektledelse Figur 8: Organisering af det samlede projekt opdelt i delprojekter. 13

14 Projektetablering Ændringsstyringen udføres af projektsponsor og procesejerne for de omfattede forretningsprocesser. Disse må desuden koordinere med den it-ansvarlige og de systemansvarlige således, at de it-mæssige konsekvenser inddrages. Specifikt er det ændringsstyringens ansvar og opgave at: Evaluere modtagne ændringsforslag i forhold til system og processer. Beslutte, hvorvidt ændringsforslaget skal implementeres, forkastes eller eventuelt udsættes til senere beslutning. Overføre de ændringsforslag, der skal føres ud i livet, til den ansvarlige for pågældende område. Ændringsstyring behandles yderligere i afsnit 4.9. Delprojektgrupper De enkelte projektgrupper skal bemandes med medarbejdere fra de forskellige forretningsområder samt fra it-afdelingen. Disse organisatoriske enheder har det daglige ansvar for gennemførelsen af de respektive delprojekter. Hver delprojektgruppe ledes af en delprojektleder. På baggrund af de indgåede aftaler, samt de beslutninger, som styregruppen og projektledelsen træffer, skal delprojektgrupperne udføre disse som aftalt. De viste delprojekter omfatter: Infrastruktur, som håndterer forhold i tilknytning til servere, klienter, netværk. Dette udføres ofte af it-afdelingen i virksomheden. Processer, som håndterer spørgsmål fra leverandøren omkring fortolkning og afklaring af kravspecifikationen samt medvirker ved opsætning og implementering af systemet. Konvertering, som varetager interne opgaver i forbindelse med datakonvertering fx udlæsning af data fra eksisterende system og datavask, samt besvarer spørgsmål fra leverandøren omkring sammenhæng mellem data i eksisterende system og det nye system (betegnes ofte data mapping). Test, som planlægger, forbereder og udfører test af leverancerne. Træning, som omfatter de træningsaktiviteter, som virksomheden selv udfører, hvilket typisk er træning af slutbrugerne. Forandringsledelse, som håndterer forandringsaktiviteter og kommunikation. Specifikt er de enkelte projektdeltageres ansvar og opgave i deres respektive projektgrupper at: Medvirke til, at gruppens opgaver planlægges og udføres i overensstemmelse med den overordnede planlægning. Medvirke til, at planlægningen indeholder de nødvendige aktiviteter til at producere de for gruppen aftalte leverancer. Identificere behov for yderligere assistance/kompetence i den enkelte gruppe. Medvirke til, at nødvendig information til løsning af opgaven indhentes. Medvirke til at etablere og gennemføre nødvendigt samarbejde med øvrige grupper. 14

15 Projektetablering 4.5 Informere om mål, fremdrift, udfordringer mv. Vedvarende, omfattende og konsistent kommunikation er et vigtigt element for at få en omfattende forandring som implementering af et ERP-system til at blive en succes. Kommunikation omfatter såvel skriftlig og mundtlige budskaber, samt mindst lige så vigtigt, synlige handlinger fra ledelse og andre nøglepersoner. Som alt andet skal også kommunikation planlægges. En planlagt og velforberedt kommunikationsproces kan styrke fokus på de væsentlige forhold, håndtere negative reaktioner og skabe støtte til implementeringsprojektet. Kommunikationsplanen skal indeholde planlagte aktiviteter (fx informationsmøder, månedsbreve, website, spørgsmål/svarlister) og håndtering af uforudsete hændelser fx forsinkelser, kundereaktioner, ressourcemangel eller nedbrud af it-systemer. og kolleger, mens skriftlig information fx via opslagstavler, personaleblad, intranet og nyhedsbreve tillægges mindre troværdighed og betydning. Det er imidlertid vigtigt at understrege, at der undervejs fra afsender og frem til modtager er mange muligheder for misforståelser eller tolkninger af budskabet. Modtagerne opfatter eller oversætter ofte budskabet på en hel anden måde end tiltænkt, se figur 10. Dette kan i nogen grad håndteres gennem vedvarende, omfattende og konsistent kommunikation. Vanskeligheder ved kommunikation og forskellig opfattelse af budskab er beskrevet af H.C. Andersen i historien Det er ganske vist : En høne taber en lille fjer. Dette bliver gennem flere led til, at fem høns har plukket alle fjerene af sig for at vise, hvem af dem der er blevet magrest af kærestesorg til hanen. For de planlagte aktiviteter skal planen omfatte formidler (ansvarlig), modtagere, formål, kanal, starttidspunkt og frekvens, se figur 9. For de uforudsete hændelser kan der være tale om skabeloner for, hvordan disse situationer skal håndteres. Den direkte mundtlige kommunikation opfattes ofte som mest troværdig og vigtigst, dvs. fra nærmeste chef, topledelsen, tillidsfolk Nr. Titel Modtagere Formål Hovedbudskaber Kanal, medium Formidler Forfatter(e) Dato for første gang Frekvens Hvorfor? Hvad? Hvem? Figur 9: Planlægning af kommunikationsaktiviteter. Hvordan? Hvem? Hvornår? Med det nye ERP-system får vi mulighed for at... Det gamle system fungerede fint... og det kendte jeg! Mine opgaver bliver overtaget af ERP-systemet... Alle deadlines er overskredet... det kommer aldrig til at virke! Figur 10: Budskaber kan blive opfattet og fortolket meget individuelt. 15

16 Projektetablering 4.6 Analysere og håndtere risikoområder Risikohåndtering omfatter det at identificere risikoelementer og barrierer for ERP-projektet, samt hvordan disse skal håndteres. Dette skal medvirke til at skabe en tro på, at projektet kan gennemføres og at det vil medføre en forbedring for virksomheden. Når der tales om forfejlede it-projekter, er det ofte fordi, enten tidsplanen eller budgettet er overskredet. Man bør derfor i planlægningen af projektet og det gælder, hvad enten det er et stort eller lille projekt arbejde med nogle realistiske mål for både tidsplan og budget. Det skal pointeres, at man ikke nødvendigvis skal afsætte alt for megen tid til projektet, da det let kan gå hen og blive en sovepude for dem, der skal forestå leveringen af systemet. Derfor bør man opstille en ambitiøs tidsplan, men ikke en urealistisk. Når det handler om budgettet for et it-projekt, må man se i øjnene, at dette ofte bliver overskredet, når det drejer sig om større og mere komplekse projekter. Det er dog ikke desto mindre nødvendigt altid at fastsætte budgetter for it-projekter, inden man går i gang, så man har en rettesnor for, hvad projektet må koste. 16

17 Projektetablering 4.7 Håndtere forandringer Ved forandringsledelse forstås aktiviteter, der assisterer organisatorisk og personlig forandring fra en nuværende situation til en fremtidig ønsket situation, dvs. i denne sammenhæng anvendelse af det nye ERP-system. Ændringer i organisationen og forretningsprocesserne medfører typisk, at der sker forskydninger i organisationens eksisterende magtfordeling mellem medarbejdere og afdelinger. Disse magtforskydninger medfører ofte, at der skabes barrierer imod de ændringer, som projektorganisationen finder nødvendige for at opnå visionen. Det er derfor nødvendigt, at ledelsen går først og bakker fuldt og helt op om disse ændringer. Forandringsledelse skal håndtere både de rationelle og de emotionelle forhold/behov hos de personer, der er berørt af forandringen. Effektiv forandringsledelse giver forklaringer på og begrundelser for de kommende ændringer samt fortæller om de mekanismer, der skal til for, at den enkelte kan styre sin egen skæbne. Med udgangspunkt i adfærd skal forandringsledelsesaktiviteter hjælpe de involverede personer med at: Forstå situationen, projektet og organisations behov samt hvorfor ændringer er påkrævet. Tro på fremtiden og udviklingen som resultat af ændringen. Agere på en måde, som fremmer den ønskede udvikling. Forandringsforløbet kan vises som i figur 11. I den første periode kommer chokket, idet lynet slår ned med meddelelsen om den nye situation vi skal til at installere og anvende et nyt ERP-system. Mange ting sættes i stå trods ledelsens ønske om business as usual. Der opstår utilfredshed med forandringen, med det eksisterende kaos og den manglende håndtering af en række situationer. De følelsesmæssige reaktioner og handlinger tager over. På et tidspunkt bliver medarbejderne klar over, at forandringen er uigenkaldelig og måske egentlig også tiltrængt. Man bliver klar over, at en række dagligdagsrutiner nødvendigvis må forandres. På et tidspunkt kommer der forhåbentlig en erkendelse af, at forandringen giver fordele. Så kommer motivationen og den opadgående spiral med accept af og forståelse for situationen, hvorefter de rationelle reaktioner og handlinger igen tager over. Et væsentlig element til forandringsledelse er kommunikation til medarbejderne om deres fremtidige situation. Medarbejderne vil naturligt spørge sig selv: Hvad får JEG ud af det? Hvilken betydning får ændringerne for MIG? Vil JEG fortsat have et job? For at undgå frustration, rygter, åben såvel som skjult modstand mv. er det nødvendigt at håndtere og besvare disse spørgsmål. Markedsføring af det nye ERP-system er en vigtig opgave i forbindelse med forandringsledelse. Man skal således være opmærksom på, at der kan opstå en kløft imellem øvrige medarbejdere og medlemmerne af projektgruppen, som under projektarbejdet løbende opbygger en ejerfølelse for det nye system. For at skabe forståelse og medspil er det vigtigt at involvere øvrige medarbejdere dels gennem almindelig oplysningsarbejde, dels ved at involvere dem i udvalgte opgaver som eksempelvis arbejdet med udskrifter og rapporter. Udskrifter og rapporter betragtes ofte som ERP-systemets ansigt udadtil, og når dette ændres, er det en god idé at forberede medarbejderne på dette. Ofte ses det, at arbejdet med udskrifter og rapporter er en af de sidste opgaver, der bliver løst, inden et nyt ERP-system tages i drift. Organisationen har som følge heraf ikke tilstrækkelig tid til at vænne sig til det nye ansigt. Den sene afvikling af arbejdet med udskrifter og rapporter er imidlertid helt unødvendig, idet forudsætningerne for gennemførelse af denne aktivitet ofte er til stede, når ERP-systemet er valgt, og forretningsgangene i det nye system er fastlagt. Man bør få igangsat og afsluttet opgaven omkring udskrifter og rapporter så tidligt som muligt. Begyndelse på ny måde Begyndelse på ny måde Begyndelse på ny måde Ydelse Rationelle handlinger Drage i tvivl usikker Indrømmelser, undersøge Forstå, accept engageret Emotionelle handlinger Modstand, nervøsitet, chok Figur 11: Forløb af forandring med både rationelle og emotionelle reaktioner. skeptisk Forvirring, usikkerhed, resignation udforskende Tillid, tro, håb Tid 17

18 Projektetablering 4.9 Styre ændringer Både projektdeltagere og øvrige medarbejdere bør kunne foreslå ændringer undervejs i projektforløbet. Der bør dog anvendes en formel procedure for behandling af ændringsforslag. Ændringsforslag skal beskrives i et fastlagt skema figur 13 viser et eksempel som afleveres til den interne projektleder. Vedkommende sikrer behandling af forslaget, herunder tilbagemelding til forslagsstiller om den trufne beslutning for forslaget. Leverandøren skal vurdere konsekvenser af forslaget, herunder omkostninger. Derpå beslutter styregruppen, om ændringsforslaget skal udføres eller afvises. Udfyldes af projektleder efter modtagelse fra forslagsstiller Løbenr. for forslag 4.8 Håndtere projekthindringer Et væsentligt forhold for at opnå et succesfuldt projekt er rettidig og omhyggelig håndtering og afhjælpning af identificerede projekthindringer for derved at minimere den eventuelle skadelige indflydelse. En projekthindring kan defineres som: En hændelse, der opstår undervejs i projektet, og som vil standse eller forsinke den planlagte fremdrift af projektet. Hindringer kategoriseres typisk ud fra deres konsekvenser: Lille Den identificerede hindring vil kun i ringe grad påvirke projektets fremdrift. Afhjælpningen kan gennemføres på et senere tidspunkt. Mellem Den identificerede hindring kræver handling snarest. Høj Den identificerede hindring kræver omgående afhjælpende handling. I modsat fald vil den videre fremdrift af projektet ophøre. Hindringen har karakter af at være en show stopper. Der bør etableres formelle procedurer for registrering, dokumentation og behandling af identificerede projekthindringer, således at der kan foretages opfølgning af deres afhjælpning. Figur 12 viser det overordnede forløb for håndtering af projekthindringer. Modtaget dato Udfyldes af forslagsstiller Overskrift på forslag Beskrivelse af forslag Baggrund for forslag Fordele/effekt af forslag Tidspunkt, hvor forslag bør være gennemført Forslagsstiller Udfyldes af leverandør ved vurdering af forslaget Systemmæssige konsekvenser ved at genneføre forslaget Tidsmæssige konsekvenser ved at gennemføre forslaget Omkostning ved at gennemføre forslag Udfyldes efter behandling i styregruppen Accepteret af leverandøren Accepteret af kunden Dato Dato Navn Navn Figur 13: Skema til håndtering af ændringsforslag. Informere herom Identificere projekthindring Er hindring allerede kendt? Vurdere hindring Identificere ansvarlig for afhjælpning Dokumentere hindring Opfølge afhjælpning af hindring Afhjælpe hindring Forandringsledelse Figur 12: Forløb for håndtering af projekthindring. 18

19 Projektetablering 4.10 It-miljøer Der bør etableres følgende it-miljøer, jf. figur 14: Udviklingsmiljø, som anvendes af leverandøren til konstruktion, test og fejlrettelser. Testmiljø, som anvendes til test af de enkelte systemleverancer og det samlede system. Produktionsmiljø, som anvendes til den daglige drift af systemet. Desuden kan yderligere et separat miljø til datakonvertering være relevant. Leverandøren anvender udviklingsmiljøet til sin udvikling og test af systemet. Når leverandøren har konstateret, at en systemleverance fungerer som specificeret, informerer leverandøren virksomheden herom. Den pågældende systemleverance overføres derpå til testmiljøet. Samtidig ajourføres en udviklingslogbog med oplysning om, hvad der er overført, dato og hvem, der har udført overførslen. Virksomheden tester systemleverancen i testmiljøet i henhold til opstillede testscripts. Virksomheden dokumenterer resultatet af testen (de konstaterede fejl) og formidler dette videre til leverandøren. Leverandøren foretager nødvendige fejlrettelser i udviklingsmiljøet. Når leverandøren har konstateret, at en rapporteret fejl er rettet, informerer leverandøren virksomheden herom eventuelt samles et antal fejlrettelser i pakker. Den pågældende fejlrettelse pakke overføres til testmiljøet. Samtidig ajourføres logbogen med oplysning om, hvad der er overført, dato og hvem der har udført overførslen. Derefter gentager virksomheden testen. Dette iterative forløb gennemføres, indtil virksomheden kan acceptere leverancen som værende i overensstemmelse med specifikationen. Det iterative forløb dokumenteres i udviklingslogbogen. Systemleverancer overføres fra testmiljøet til produktionsmiljøet, når funktionalitet er testet og godkendt af virksomheden. Samtidig ajourføres logbogen med oplysning om, hvad der er overført, dato og hvem der har udført overførslen. Leverandør Virksomhed Er leverancen OK? Ja Testmiljø Er leverancen OK? Ja Udviklingsmiljø Produktionsmiljø Nej Nej Figur 14: De forskellige it-miljøer, som typisk indgår i implementeringsprojekter. 19

20 Specifikation og design 5. Specifikation og design 5.1 Procesmodellering Sælge produkter Styre ordrer Indkøbe varer Styre logistik En metode til at få overblik over de områder, som det nye ERP-system skal understøtte og også hvilke områder, det ikke skal understøtte, er at opstille en model over virksomhedens forretningsprocesser. Med denne analyse af virksomhedens forretningsprocesser kan bl.a. sikres, at kravene til det nye ERP-system kommer til at afspejle de forretningsmæssige behov og ikke bliver styret ud fra de teknologiske muligheder og kæpheste. Procesmodellen bør anvende virksomhedens egen terminologi. Figur 15 viser et udsnit af en sådan procesmodel med markering af hvilke it-systemer, der anvendes til at understøtte aktiviteter i de enkelte processer. Procesmodellen vist i figur 15 bør udbygges med aktiviteter og arbejdsgange. Modtage ordrer Kalkulere ordrepris og leveringstid Foretage kreditvurdering Bekræfte ordrer Styre og følge op på ordrer Fakturere ordrer Håndtere opkrævninger og tilgodehavender Håndtere og styre rabatter Håndtere og styre restordrer Håndtere og styre kreditnotaer Understøttet af ERP-system Understøttet af andet it-system Understøttet af ERP-systemet og andet it-system Ikke understøttet af it Figur 15: Eksempel på procesmodellering med markering af it-understøttelse. 20

21 Specifikation og design 5.2 Standardfunktionalitet kontra tilpasning af forretningsgange Når der investeres i et standard ERP-system, så køber man en række standardfunktionaliteter. Ofte understøtter disse standardfunktionaliteter en måde at gennemføre en arbejdsgang på, der er forskellig fra den måde, virksomheden gør i det eksisterende system. De eksisterende måder at gennemføre arbejdsgangene på er indgroede vaner, som det kan være vanskeligt for medarbejderne at forestille sig, kan gøres på andre måder. Det ses derfor ofte, at det nye økonomisystem bliver tilpasset den eksisterende måde at gennemføre arbejdsgange på. Denne metode skaber ofte meget store udviklingsprojekter, der er med til at gøre projektet mere tidskrævende, mere bekosteligt og komplekst. De standardsystemer, der findes på markedet i dag, er så udviklet, at det er muligt at tilpasse den eksisterende måde at gennemføre arbejdsgangene på, således at standardfunktionaliteten understøtter disse. Når designet defineres, er det væsentligt ikke at fokusere så meget på ændringer og tilpasninger, at man glemmer at tage hensyn til de dele af forretningsprocesserne, der er tiltænkt at skulle understøttes af standardfunktionaliteten. Ved alene at fokusere på tilpasningerne risikerer man at stå med et mangelfuldt aftalegrundlag, der igen kan skabe uhensigtsmæssig støj i projektet. Det anbefales derfor, at designbeskrivelsen beskriver alle forretningsprocesser og hele forretningsprocessen. Af beskrivelsen skal det fremgå, om der er tale om en tilpasning til systemet (ny udvikling). I implementeringsforløbet er fokus ofte kun rettet mod den meget lille del af de samlede behov, som kræver tilrettelser, se figur 16, ud fra opfattelse om, at standardfunktionaliteten jo bare fungerer. Fokus bør imidlertid også være rettet mod at sikre god implementering af de måske helt op til 90% af behovene, som kan dækkes med standardfunktionalitet fx ved at gennemføre en god slutbrugertræning. Disse 90% er ofte det, som giver succes med systemet.!! Ca. 90% af behov er opfyldt af standard ERP-system Reducere fokus på dette område Forøge fokus på dette område Ca. 10% af behov kræver tilpasning Figur 16: Fokus bør også være rettet mod at få standardfunktionaliteten til at fungere, idet den ofte dækker hovedparten af behovene frem for kun at rette fokus mod den langt mindre del af behovene, som kræver tilpasning af systemet. 5.3 Scope creep Et forhold, som nemt kan ske i forbindelse med implementering af et nyt ERP-systemer, er scope creep undervejs i forløbet. Scope creep er det fænomen, at der næsten ud af det blå kommer funktionalitet ind i løsningen, som ikke oprindelig var specificeret. Lidt lige som lommeuld, der opstår af sig selv ingen kan helt forklare, hvorfor systemet pludselig har fået den funktionalitet. Scope creep er en væsentlig årsag til forsinkelser og budgetoverskridelser. Desuden medfører scope creep ofte, at der tilføjes flere tilrettelser i systemet, således at det fjerner sig mere fra standardsystemet. En metode til at undgå eller i hvert fald reducere scope creep er at anvende ændringsstyring, jf. afsnit 4.9. Ændringsstyring sikrer, at alle ændringsønsker kommer frem i lyset, bliver begrundet og vurderet, inden de enten indføres eller afvises. Dermed skal det bestemt ikke være sagt, at det ikke er tilladt at ændre mening og blive klogere undervejs i projektforløbet. Der kan være mange gode grunde til at afvige fra den oprindelige kravspecifikation fx ved at modificere på forretningsproces for i højere grad at kunne anvende standardfunktionalitet i ERP-systemet, som først blev bragt på banen undervejs i forløbet. Men: Det skal være en gennemtænkt, besluttet og styret handling og ikke bare noget, der sker uden, at nogen er klar over det. 21

22 Udvikling, opsætning og test 6. Udvikling, opsætning og test 6.1 Udvikling og præ-opsætning hos leverandør Leverandøren forestår udvikling af nødvendige tilrettelser og den grundlæggende opsætning af ERP-systemet, således at kravspecifikationen opfyldes. Undervejs har leverandøren ofte behov for at afklare tvivlsspørgsmål dvs. virksomheden skal kunne reagere på disse henvendelser. Leverandøren bør ikke i lang tid foretage udvikling uden kontakt til virksomheden for afklaring, afstemning og præsentation af løsningsforslag. Finder sådan udvikling i mørke sted, er der stor risiko for, at det ikke opfylder det reelle behov, når virksomheden ser resultatet. 6.2 Opsætning sammen med virksomheden 6.3 Test Når leverandøren internt har verificeret, at ERP-systemet fungerer, som det skal (i hvert fald efter leverandørens opfattelse!), bør virksomheden og leverandøren i fællesskab gennemgå løsningen. Denne gennemgang kan med fordel tage udgangspunkt i den opstillede procesmodel, således at det sikres, at alle relevante områder behandles. Gennemgangen bør omfatte følgende aktiviteter i et integreret forløb: Gennemgå opsætning Designe og fastlægge arbejdsproces Evt. ekstra udvikling Teste Dokumentere arbejdsproces og opsætning Acceptere Dette sikrer dels vidensoverføring fra leverandør til virksomhed om, hvordan systemet er opsat og tilpasset, dels hurtig og effektiv håndtering af evt. misforståelser, fejl og mangler. Leverandøren har naturligvis ansvar for at levere et produkt, der opfylder de stillede krav. Dette sikrer leverandøren ved selv at foretage en række tests. Men virksomheden skal også selv teste, om det leverede opfylder de opstillede behov. Dette omfatter typisk følgende typer af tests: Test af funktionalitet er systemet i stand til at udføre den specificerede funktionalitet? Test af processer er systemet i stand til at understøtte de processer, som virksomheden har, og således som det er specificeret? Test af kapacitet og svartider (volumen eller stresstest) kan systemet håndtere de datamængder og opnå de svartider, som er specificeret? Test af funktionalitet og processer omfatter en række aktiviteter og overvejelser både før, under og efter testen. Det efterfølgende viser aktiviteter og overvejelser, som bør gennemføres i forbindelse med test. Det konkrete indhold og omfang af disse aktiviteter og overvejelser afhænger naturligvis af det aktuelle implementeringsprojekt, dvs. at det efterfølgende har karakter af en bruttoliste. 22

23 Udvikling, opsætning og test Aktiviteter, der skal gennemføres, før test gennemføres: 1. Opstille plan for gennemførelsen af testen (testplan) 1.1 Beskrive testprocedure, herunder testroller med opgaver og ansvar 1.2 Udarbejde skemaer for dokumentation af testforløb testdrejebog 1.3 Udarbejde skemaer for dokumentation af identificerede fejl 1.4 Fastlægge tidsplan for test 1.5 Identificere og udmelde testressourcer samt kontaktpersoner hos leverandøren 2. Udarbejde testscript. Disse skal trin for trin vise hvilke handlinger, der skal gennemføres 3. Fastlægge nødvendigt udstyr for test PC, printer, andet udstyr (fx stregkodeudstyr), server, netværk, applikation, interfaces 4. Udmelde tidsplan, sted mv. til testdeltagerne 5. Etablere testlokaler. Dette omfatter opsætning af hardware (PC er, printer, evt. andet udstyr fx stregkodeudstyr), netværk, forbindelse til server mv. (herunder teste, at det virker) 6. Etablere testmiljø 6.1 Installere system og evt. andre nødvendige programmer. Dette omfatter også test af, at alle applikationer kører 6.2 Opsætte testbrugere (herunder teste, at de kan logge på system og har de korrekte rettigheder) 6.3 Indlæse eller indtaste stamdata og transaktionsdata, som skal anvendes til test 7. Forberede/træne testpersoner 7.1 Introducere til den overordnede sammenhæng i og opbygning af systemet 7.2 Introducere til standardfunktionalitet, navigering mv. 7.3 Introducere og træne i funktionalitet for det aktuelle testområde 7.4 Introducere til testforløb, herunder testscripts og rapportering af identificerede fejl 7.5 Introducere procedure for ændringer (denne skal anvendes, hvis det konstateres, at et krav er opfyldt, men den leverede funktionalitet er alligevel ikke i overensstemmelse med ønsket forretningsgang) Aktiviteter, der skal gennemføres ved selve testen: 6.4 Brugervenlighed Generelt er brugernes forventninger til nye systemer steget, og brugervenlighed er langsomt men sikkert ved at blive et krav. Den traditionelle definition af brugervenlighed drejer sig om forhold, såsom at det skal være let at lære, let at bruge og effektivt at bruge jævnfør følgende definitioner: Let at lære Indlæringstiden: Den tid det tager brugere at lære at løse bestemte opgaver ved hjælp af systemet. Let at bruge Genindlæringstid: Den tid det tager brugere, som har været væk fra systemet eller som kun anvender det engang imellem, at løse bestemte opgaver. Effektivt at bruge Effektivitet: Den hastighed hvormed brugeren løser bestemte opgaver i forening med systemet. Effektiviteten afhænger eksempelvis af svartid og fejlhyppighed og ikke mindst kvaliteten af fejlmeddelelser. Af ovenstående punkter er effektiviteten vigtigst, når der tales om et nyt ERP-system, som skal anvendes flere gange dagligt af mange brugere. Indlæring og genindlæring er mere vigtig, når der tales om systemer, som brugerne kun anvender sjældent. Dette er tilfældet for nogle kategorier af brugerne af det nye økonomisystem, eksempelvis de brugere, som kun kommer til at bruge systemet i forbindelse med budgetlægningen mv. Der er ikke kun tale om funktionaliteter, når der snakkes om brugervenlighed af et nyt system. Der er desuden tale om forhold såsom sprog og motivation af medarbejderne. Det skal således vurderes, om det er tilstrækkeligt, at det nye økonomisystem anvender engelsk som sprog, eller om det er nødvendigt med skærmbilleder på dansk. God brugervenlighed kan være med til at øge brugerens selvtillid. En mindskelse af antallet af nederlag, som brugeren lider til et system, styrker både moral og motivationen hos brugeren. Samtidig giver en god brugervenlighed et mere effektivt samspil mellem menneske og maskine. 8. Gennemføre handlinger i testscripts 8.1 Dokumentere resultat af de enkelte trin i testscript (godkendt ikke godkendt) 8.2 Dokumentere evt. fejl i tilhørende fejlskemaer, såfremt et testtrin ikke kan godkendes 9. Gennemføre og dokumentere evt. sporadiske test dvs. ikke planlagte test 10. Korrigere systemet i henhold til de identificerede fejl samt gentage test i relevant omfang Aktiviteter, der skal gennemføres, når testen er gennemført: 11. Udarbejde sammenfattende og konkluderende testrapport 23

24 Implementering 7. Implementering 7.1 Træning Uddannelsesaktiviteterne har selvfølgelig til formål at give brugere den fornødne systemrelaterede kunnen, således at de daglige arbejdsopgaver i relation til systemet løses mest hensigtsmæssigt ved brug af færrest ressourcer. Derudover kan uddannelsesaktiviteterne betragtes som et væsentlig element i formidlingen og gennemførelsen af de organisatoriske og strukturelle forandringer, som systemet i sig selv kræver samt i opnåelsen af de ændringer, der i øvrigt er formuleret i udbudsmaterialet. Dvs. uddannelse og træning i brug af det nye ERP-system er en væsentlig faktor for at forankre systemet i organisationen. En tommelfingerregel siger, at 10-20% af udgifterne til ERP-implementeringen bør anvendes til uddannelse og træning. Uddannelse og træning har følgende positive effekter: Brugere anvender systemer således, som det er tiltænkt. Der opstår færre fejl. Der er mindre spildtid. Reduktion af modstand mod de forandringer, som ERP-systemet medfører. Reduktion af varighed og dybde af det effektivitetsfald i virksomheden, som typisk opstår lige efter driftsstart (se figur 19 på side 27). Uddannelsesforløb og materiale skal tilpasses den modtagende virksomhed, herunder: Tage udgangspunkt i den aktuelle systemopsætning. Tage udgangspunkt i de forretningsgange og processer, som man som virksomhed ønsker at anvende i forbindelse med det nye ERP-system. At målrette uddannelsen mod forskellige identificerede brugerroller, således at uddannelsesforløbet virker relevant og anvendeligt for deltagerne. Træning og uddannelse bør omfatte følgende elementer: Træning af projektgruppen meget tidligt i forløbet, således at disse aktivt kan deltage i arbejdet med at opsætte og teste systemet. Træning af superbrugerne. Dette finder løbende sted undervejs i projektforløbet, således at superbrugerne inddrages i projektet. Desuden intensiveres træningen i perioden frem til driftsstart. Træning af slutbrugerne. Dette finder typisk sted umiddelbart før driftsstart. Forløbet for træning af slutbrugere omfatter aktiviteter som vist i figur 17. Uddanne slutbrugere Afdække behov: Kurser, roller og personer Uddanne superbrugere: Train the Trainer Skitsere indhold af kurser Forløb for uddannelse Opsætte systemmiljø til undervisning Udarbejde undervisningsmateriale Gennemgå og vurdere materiale Udarbejde øvelser Figur 17: Forløb for uddannelse af slutbrugere. 24

25 Implementering Har meget stor viden om virksomhedens organisation, forretningsprocesser, kultur mv. Har generel PC- og computerviden Er god til at kommunikere et budskab forståeligt og enkelt Er forandringsvillig og positiv overfor systemet Er en respekteret og anerkendt person i organisationen Kender systemet i alle detaljer Anvender systemet, som det er tiltænkt Har en positiv attitude med hensyn til andre: Har lyst til at hjælpe Er en holdspiller Figur 18: Karakteristika for en superbruger. Det er væsentligt, at superbrugergruppen sammensættes af egnede brugere. Superbrugeren skal udvise motivation og engagement samt evne til at formidle svært stof, let forståeligt og tålmodigt, se figur 18. Samtidig er det essentielt, at organisationen/ledelsen aktivt og synligt bakker op om superbrugerorganisationen. Det betyder bl.a., at det for den enkelte superbruger aftales, hvor stor en del af arbejdstiden, der skal benyttes til superbrugerfunktioner, og at der afsættes tid og ressourcer til uddannelse og løbende erfaringsudveksling superbrugerne imellem. Typisk varetager leverandøren træning af projektgruppen og superbrugere. Derimod varetager virksomheden sædvanligvis selv træning af slutbrugerne, idet dette udføres af superbrugerne ved anvendelse og tilpasning af materialet fra superbrugeruddannelsen. Leverandøren kan naturligvis også foretage uddannelsen af slutbrugerne, men dette kan nemt blive en meget dyr løsning. Det kan desuden være et væsentlig element i forbindelse med forandringsprocessen, at man som virksomhed selv udfører træning af slutbrugerne. Det er bedre og mere troværdigt, at det er virksomhedens egne medarbejdere, som forklarer og begrunder eventuelle ændringer i forretningsgange end, at dette gøres af en ekstern underviser fra leverandøren. Det efterfølgende skema opsummerer forskellige metoder, som kan anvendes i forbindelse med træning af slutbrugere. I praksis bør anvendes elementer fra alle metoder. Metode Beskrivelse Forudsætninger Overvejelser Selvstudium fx e-learning Brugerne gennemgår selv kurser enten papirbaserede eller som e- learning. Der er høj grad af fleksibilitet Der skal etableres et e-learningsmiljø. Det skal være accepteret af ledelsen, at den enkelte bruger anvender tid til dette. Det kræver en høj grad af selvdisciplin. Det bør styres af en plan, som aftales med og opfølges over for hver bruger. Kurser i klasseværelse Brugerne deltager i formelle kurser med fast kursusindhold og plan. Der er typisk 5-8 deltagere pr. kursus. Der skal være et tilstrækkeligt stort antal brugere for, at denne model er økonomisk forsvarlig. Det skal være accepteret af ledelsen, at brugerne anvender tid til at deltage. Det skal være accepteret af ledelsen, at brugerne anvender tid til dette. De enkelte kurser skal planlægges og udmeldes i passende tid, således at de kan indpasses i de daglige opgaver. Sidemandsoplæring En erfaren bruger (typisk superbruger) oplærer en ny bruger on the job-træning. Det bør styres af en plan, som aftales med og opfølges over for hver bruger. Der er høj grad af fleksibilitet. Online dokumentation Brugerne har adgang til information, som kan støtte i forbindelse med den daglige anvendelse af systemet. Brugerne skal forinden have modtaget anden form for træning. Denne dokumentation skal være konsistent i indhold og ensartet i layout. 25

26 Implementering 7.2 Datakonvertering 7.3 Overtagelsesprøve, accepttest Datakonverteringsopgaven kan for udenforstående fremstå som en simpel operation. Vi ser dog ofte, at forventningerne til datakonvertering ikke holder, men at det bliver dyrere og tager længere tid. Datakonverteringen består typisk af: Analysefase bl.a. afklaring af hvilke data, der konverteres automatisk og hvilke data, der indtastes manuelt. Udvikling af konverteringsværktøjer til brug for automatisk konvertering. Gennemførsel af testkonverteringer inkl. kontrol af konvertering. Justering af konverteringsværktøjer. Gennemførsel af driftskonvertering, herunder indtastning af de manuelle data. Dette omfatter naturligvis også kontrol. Det, der gør konverteringsopgaven vanskelig, er, at der er stor forskel på det eksisterende systems datamodel og det nye systems datamodel. I analysefasen skal det defineres hvilke data, der ønskes konverteret. Der skelnes mellem konvertering af stamdata og transaktionsdata. Til forskel fra stamdata er transaktionsdata karakteriseret ved, at der er sammenhænge mellem data i de forskellige tabeller, og disse sammenhænge er ofte ikke de samme, når det eksisterende system sammenlignes med det nye system. Stamdata er karakteriseret ved at være default information, der hentes i forbindelse med registrering af transaktioner. Overtagelsesprøven er den juridiske handling, hvor man som virksomhed overtager løsningen, og garantiperioden påbegyndes. Ved overtagelsesprøven konstateres, om den aftalte funktionalitet er til stede i løsningen. I praksis vil der ofte være en mangelliste, som skal udbedres, inden endelig overtagelse finder sted. Typisk tilrettelægges overtagelsesprøven af leverandøren. Det er imidlertid væsentligt, at man som kunde gennemgår og forholder sig kritisk til indholdet af overtagelsesprøven. Således sikrer man, at alt relevant er medtaget fx forretningskritisk funktionalitet, integration til andre systemet, dokumentation, vejledninger mv. Overtagelsesprøven anses som accepteret, hvis der ikke konstateres en eller flere væsentlige mangler. Definitionen af en væsentlig mangel skal tydelig fremgå af kontrakten. Ofte defineres det som, at der mangler funktionalitet, så systemet må anses for at være ude af drift. Det kan dog nemt blive et diskussionspunkt mellem virksomhed og leverandør om, hvorvidt en fejl er væsentlig eller ikke. Mindre fejl fx stavefejl i udskrifter og rapporter kan ikke opfattes som væsentlig, men viser rapporten forkerte oplysninger, må det betragtes som en væsentlig fejl. Såfremt leverandøren umiddelbart kan anvise en simpel måde til at omgå en fejl, og hvor fejlen snarest rettes ved en generel opdatering af systemet, kan den heller ikke betragtes som væsentlig. Stamdata er ofte den letteste type data at konvertere. Man undgår dog ikke udfordringen med at skulle parre datafelter fra det eksisterende system op imod datafelter i det nye. Til denne opgave er der behov for adgang til en medarbejder, der har indsigt i, hvad de forskellige felter i det eksisterende system repræsenterer og anvendes til. Denne viden er som regel ikke placeret på en enkelt medarbejder. Alternativet til at gennemføre en datakonvertering af stamdata er at indtaste stamdata manuelt eller i hvert fald dele af stamdata. Dette er ofte værd at overveje, idet der udover at få stamdata i det ny system endvidere opnås værdifuld træning i brugen af det nye system. Desuden giver manuel indtastning af stamdata mulighed for at rydde op i data, eksempelvis fjerne dubletter og tilføje manglende oplysninger. Automatisk konvertering af transaktionsdata er som regel kompliceret, idet datastruktur ofte er forskellig fra det gamle til det nye system. Som hovedregel bør mængden af transaktionsdata, der søges konverteret, derfor begrænses til det absolut nødvendige. Manuel indtastning af åbne ordrer kan være et godt alternativ til automatisk konvertering. Et alternativ til en omfattende datakonvertering er at bevare den eksisterende database samt en klientadgang, så medarbejdere har mulighed for at hente historiske informationer. Opgaven omkring konvertering er hermed stærkt reduceret: Nemlig til stamdata, åbningssaldi og åbne ordrer. Vælges denne løsning, bør det for god ordens skyld afklares, at dette er i orden med leverandøren af det eksisterende system, dvs. at licensforhold er på plads. Ved gennemførelse af driftskonvertering bør man være opmærksom på, at det ikke er lovligt at tilføje ny information i det gamle ERP-system, når denne har fundet sted. Der bør være fokus på, at en datakonvertering ikke løser opgaven med at foretage parameteropsætning og kontrollere og færdiggøre stamdataopsætningen i det nye ERP-system. 26

27 Implementering 7.4 Driftsstart Driftsstarten er sandhedens øjeblik, hvor det nye ERP-system sættes i drift. Ofte ses et fald i præstationsniveauet ved driftsstart ( golive-tidspunkt ), se figur 19. På go-live-tidspunktet bliver det gamle ERP-system ofte opfattet af brugerne som meget bedre, end de tidligere har givet udtryk for: Med det kunne vi også..., Da fungerede... osv. De følgende spørgsmål omhandler faktorer, som bestemmer både dybden og varigheden af dette fald i præstationsniveau ved driftsstart. Det er derfor vigtigt, at de besvares entydigt positivt, før det nye ERP-system sættes i drift: Er overtagelsesprøven gennemført og fundet OK? Mere subjektivt: Er der generelt i organisationen tillid til systemet? Er systemstabiliteten testet og fundet OK, fx er svartider acceptable? Er konvertering gennemført og fundet OK, fx er stamdata og åbningsposter på plads? Mere subjektivt: Er der generelt i organisationen tillid til stamdata? Er uddannelse af slutbrugere gennemført og fundet OK? Er de kundevendte udskrifter på plads og viser det korrekte fx salgsordrer og fakturaer? Er eventuelle nye forretningsgange på plads? Er supportteam på plads både i hektisk overgangsperiode og mere permanent? Er produktionsmiljø med servere, netværk, bruger PC er mv. testet og fundet OK? Og lidt mere overordnede spørgsmål: Er ledelsen klar til at sætte skiftet i gang? Er kunder og leverandører blevet informeret om skiftet og evt. konsekvenser? En metode til at mindske risikoen i forbindelse med et skift er at have en periode, hvor både det nye og det gamle ERP-system anvendes parallelt. Det er imidlertid en meget ressourcekrævende opgave at holde to systemer ajour med dobbeltregistrering af alle ændringer i stamdata og transaktioner. Det gælder især i stressede perioder, hvor man samtidig af al magt forsøger at få et nyt ERP-system til at fungere. Det rigtige tidspunkt for driftsstart er ofte et diskussionsemne: Skal det være sammenfaldende med regnskabsår eller være et andet tidspunkt. Det efterfølgende skema søger at veje fordele og ulemper for de to muligheder. Tidspunkt Fordele Ulemper Driftsstart sammenfaldende med regnskabsår Driftsstart på andet tidspunkt Åbningssaldi findes og er afstemt i forvejen. Kan placeres på et tidspunkt, som passer ressourcemæssigt godt. Organisationen har (mindst) to store samtidige opgaver: Årsafslutning og et nyt ERPsystem. Er kun mulig ved Big Bangimplementeringsstrategi, idet de øvrige strategier har flere tidspunkter for idriftsættelse. Åbningssaldi skal findes og afstemmes separat. Perioderapporter for første regnskabsår kræver anvendelse af to systemer, hvor data måske ikke har helt samme struktur. Stor fokus Go Live tidspunkt Ringe fokus Præstationsniveau Tid Figur 19: Der ses ofte et fald i præstationsniveauet umiddelbart efter idriftsættelse af et nyt ERP-system. Varigheden og dybden af dette fald kan reduceres ved at have fokus på forandringsledelse og træning den grønne kurve i stedet for den blå kurve. 27

28 Efter driftsstart 8. Efter driftsstart 8.1 Supportorganisation Vi anbefaler, at superbrugerne ses som en vigtig del af supportorganisation i forbindelse med implementeringen. Superbrugerfunktionen skal så vidt muligt inddrages og præsenteres i undervisningen. Superbrugerfunktionen skal her forstås bredt, nemlig som tiltag, der på en eller anden måde understøtter udrulningen af ERP-systemet i organisation. Det gælder den praktiske og tekniske udrulning af systemet, men også organisatoriske og personalemæssige tiltag (information, forandringsledelse etc.). Her oplistes nogle eksempler på elementer i en supportorganisation: Superbrugerorganisation: Er en supportfunktion tæt på brugerne, med godt lokalkendskab. Det er en udbredt misforståelse, at det er muligt på forhånd eller udelukkende gennem uddannelse at etablere den nødvendige kompetence i en superbrugerorganisation. Kompetencen opnås i ligeså høj grad ved at involvere superbrugerne i implementeringen og i de relevante beslutningsprocesser. Superbrugerne er et naturligt mellemled mellem ledelse og brugere. Det er derfor vigtigt, at superbrugerorganisationen fra starten er synlig, og at ledelsen gennem ord og handling bakker superbrugerne op. Helpdesk: Er det fælles sted i organisationen, hvor brugerne kan få hjælp og information omkring anvendelsen af ERP-systemet fx aktuel driftsstatus. Helpdesken opsamler viden om, hvordan systemet fungerer og opfattes rundt om i organisationen. Intranet og/eller anden elektronisk kommunikation: Er velegnet som supportværktøj i den daglige drift. Nyheder, retningslinjer, vejledninger, dokumentation, procesbeskrivelser, FAQ s etc. er oplagte emner. Procesbeskrivelser: beskriver de centrale områder i virksomhedens drift, som ERP-systemet skal understøtte. Virksomheden bør formulere konkrete procesbeskrivelser for anvendelse af ERPsystemet. Procesbeskrivelserne vil danne en naturlig referenceramme for undervisningen, ligesom de vil være et godt støtteværktøj for brugerne efterfølgende. Ud over selve implementering af løsningen er det uhyre vigtigt, at løsningen efterfølgende supporteres og videreudvikles af leverandøren. Dette kan typisk omfatte følgende ydelser fra leverandøren: Løbende konsulentassistance fx for udvikling af ny funktionalitet til løsningen og rapporter. Opgraderinger. 28

29 Efter driftsstart 8.2 ERP er som en rejse Implementering og anvendelse af ERP beskrives ofte som en rejse, hvor første fase eller bølge er selve implementeringen, der efterfølges af en anden bølge, som forankrer og optimerer anvendelsen af ERP-systemet i virksomheden, se figur 20. Rejsen: Transformation af virksomheden Undersøgelsen ERP s Second Wave Maximizing the Value of Enterprise Applications and Processes, som er udarbejdet af Deloitte Consulting, har identificeret 12 best practices. Disse best practices hjælper med at få mere ud af ERP-systemet, dvs. med at få anden bølge i gang: 1. Fokusér på muligheder og effekter, ikke kun på at komme i drift. Driftsstarten er kun en enkeltstående aktivitet og skal opfattes som sådan. Der er mange flere muligheder og effekter, som skal høstes. Sat på spidsen: En succesfuld virksomhed kan tillade sig at udsætte driftsstart, men vil ikke acceptere tabet af en forventet effekt. Værktøjet ERP-systemet Første bølge Implementering Go live Anden bølge Optimering af proceser Målet Vækst Fleksibilitet Overskud 2. Etablér fælles opfattelse af målet. Alle medarbejdere skal forstå og acceptere, hvad målet er med det nye ERP-system. De skal være villige til at handle og agere således, at det opnås. Dette omfatter synlig og konsistent opbakning fra ledelsen vi vil det her, vedvarende kommunikation på mange niveauer, afstemning af forventninger, uddannelse og involvering. Figur 20: Implementering ERP-system og optimering af anvendelsen opfattet som en rejse. Mange effekter ved anvendelse af ERP-systemer opnås først gennem tilpasning af forretningsprocesserne, således at de bedre passer sammen med tankegangen i ERP-systemet. Dette er illustreret i figur 21 med et isbjerg. Der opnås ofte et bedre resultat ved at tilpasse virksomhedens arbejdsgange, således at de svarer til tankegang og standardfunktionalitet i ERP-systemet i stedet for at indføre tilretninger i ERP-systemet. Det kan derfor være et relevant alternativ at gå i drift med standardfunktionalitet og så løbende tilpasse arbejdsgange i stedet for at udvikle omfattende tilretninger af systemet for at tilpasse det til de bestående arbejdsgange. Dermed spiser man elefanten i små bidder: I stedet for at udføre ALLE ændringer og tilpasninger af forretningsgange og ALLE tiltretninger inden driftsstart, så begynder man at bruge systemet og får dermed praktisk erfaring med det. Denne fremgangsmåde kræver dog en meget aktiv kommunikation og forandringsledelse for at sikre accept og forståelse. Den naturlige holdning er: Sådan har vi altid gjort, og det skal vi blive ved med. Igen skal man være opmærksom på, at ting ikke er sorte/ hvide. Der er forretningsprocesser, som er så unikke og særlige, at der skal indføres tilretninger, såfremt de ikke kan håndteres af standardfunktionalitet. 3. Udfør ændringer, medarbejderopfattelser, processer og teknologi i relevante områder. Det er nødvendigt at se på hele virksomheden og foretage ændringer, hvor det er nødvendigt. 4. Anvend afprøvede metoder for planlægning og styring af forløbet. Et ERP-optimeringsforløb vil typisk omfatte flere delprojekter. For at kunne overskue og gennemføre disse, kræves afprøvede metoder og værktøjer. 5. Se ud over ERP-systemet. Der kan fortsat findes andre områder, som med fordel kan it-understøttes og som måske kan bindes sammen med ERP-systemet. 6. Lær organisationen at bruge de nye muligheder. Mange kender ikke mulighederne i deres ERP-system og bruger dem derfor ikke. Dette omfatter uddannelse og træning, men også opbygning af en forståelse for systemet: Når jeg udfører denne handling, så kan en række andre kolleger drage fordel af det. 7. Brug business casen som et ledelsesværktøj. Business casen omfatter forudsætninger, mål og effekter for ERP-systemet. Dette kan anvendes som pejlemærker på rejsen. 8. Transformér fra projekt til dagligdag. Ved driftsstart ændres situationen fra at være et projekt med det mål at få ERP-systemet i drift til at være daglig drift. Dette kræver en række holdningsmæssige ændringer. 9. Opbyg viden om forretningsprocesser. Kerneviden for alle virksomheder er deres processer: Hvordan de fungerer, hvordan de understøttes af it, og hvor de kan forbedres. Umiddelbare effekter Langsigtede målbare og ikke-målbare effekter Effekter fra selve implementeringen den første bølge Effekter som kan opnås ved optimering af processer, bedre brug af ERP-systemer mv. den anden bølge 10. Understøt fælles tilgang. I stedet for at alle opfinder deres egen måde at udføre aktiviteter på, så anvendes der fælles arbejdsgange, fælles værktøjer og fælles data i hele organisationen. 11. Tildel ejerskab af mål. Der skal være en person, som føler ejerskab for de definerede mål, og som derfor vil arbejde for, at de bliver opnået. 12. Opsæt målepunkter og styr efter dem. Det er nødvendigt at sætte mål for at have noget at styre efter. Figur 21: Mange effekter kommer først efter driftsstart. 29

30 Case 9. Case Casen skal illustrere, hvilke overvejelser virksomheder skal gøre sig, når de skal have implementeret et nyt it-system. Casen beskriver også, hvad der kan ske, såfremt køber ikke gør sig disse overvejelser. Der er tale om en fiktiv historie, der bygger på erfaringer fra lignende kunder. Denne case beskriver en bilforhandler PænØse A/S. PænØse er i de sidste år vokset samtidig med, at virksomheden har oplevet en øget konkurrence. PænØse bruger en del lagerplads på reservedele. De overvejer at gå ind på det voksende marked for leasing af biler til private kunder. For at kunne yde kunderne god service og samtidig være en lønsom virksomhed har PænØse brug for en bedre it-mæssig understøttelse af sine forretningsgange. De ønsker for eksempel at blive bedre til at kunne håndtere nye krav fra markedet og nye lovningsregler samt til bedre at kunne planlægge og styre likviditeten. PænØse har tidligere købt telefonsystem, computere, Microsoft Office mv. hos it-leverandøren IT til tiden ApS. PænØse har derfor taget kontakt til IT til tiden for at få dem til at hjælpe med at finde det rigtige it-system og efterfølgende implementere det. PænØse har følgende meget overordnede krav til systemet: Det skal kunne håndtere indkøb og salg af biler Det skal effektivt kunne klare økonomistyringen Det skal kunne håndtere de nye lovregler inden for autobranchen. IT til tiden, der har en stor erfaring indenfor implementering af systemer til tekstilbranchen, anbefaler et standardsystem og udarbejder en tilhørende løsningsbeskrivelse. PænØse får en meget teknisk beskrivelse af moduler og skærmbilleder i det valgte system. Beskrivelsen omfatter også hvilke opgaver i implementeringsforløbet, som PænØse skal udføre, og hvilke opgaver IT til tiden skal udføre. Der aftales en fast pris, som skal falde, når systemet er færdigt og taget i brug. IT til tiden går i gang med at opsætte og tilrette det nye it-system. Da PænØse skal til at bruge systemet i dagligdagen, går det op for dem, at systemet ikke kan de ting, som de mente, at de tydeligt havde forklaret til IT til tiden. Systemet kan ikke levere de tal, som de har brug for, og systemet svarer ikke til deres processer. Et længere tovtrækkeri begynder mellem IT til tiden og PænØse. Der kommer flere tilretninger til og yderligere strid, om disse er indeholdt i den oprindelige fastprisaftale. Og Pæn Øse er stadig ikke helt tilfreds med systemet. PænØse står nu med et system, som ikke kan de ting, som de har brug for og en ekstra regning, der skal betales samt en igangværende strid med leverandøren IT til tiden. Gennem deres revisor får de kontakt til en konsulent, som har stor erfaring med implementering af it-systemer. PænØse og konsulenten får sammen overblik over og indsigt i opgavens omfang og stade. De gennemgår de enkelte arbejdsprocesser, der er hos PænØse og som systemet skal understøtte. De afdækker de reelle fremtidige krav til systemet og får beskrevet de enkelte processer, som skal tilføjes de eksisterende arbejdsgange. Der bliver også ændret på nogle arbejdsgange for i højere grad at kunne anvende standardfunktionalitet. Sammen fastlægger PænØse og konsulenten følgende succeskriterier for det nye system: At få overblik over den samlede kundeportefølje At anvende mest mulig standardfunktionalitet, så omfanget af tilretninger minimeres At få et system, der kan lette de daglige administrative rutiner og samtidig give kunderne en oplevelse af en forbedret service At få det nye it-system forankret i driftsorganisationen, så den tager ejerskab for systemet At opnå procesdisciplin i forhold til de fastlagte forretningsgange og tilhørende it-understøttelse At kunne foretage opfølgning baseret på udtræk og rapporter fra systemet fx at kunne se hvilke mærker, der sælger bedst over en given periode At kunne håndtere leasing af biler. De enkelte krav gennemgås også af revisor for at være sikker på, at PænØse kan få de tal ud af systemet, som der er brug for, samt at lovgivning inden for autobranchen er overholdt. PænØse beslutter efter råd fra konsulenten at fortsætte samarbejdet med IT til tiden, da det vil kræve mange ekstra ressourcer fra en ny leverandør at sætte sig ind i systemet og PænØses forretning. Konsulenten assisterer PænØse i, sammen med IT til tiden at få lavet en realistisk tidsplan og få afsat de fornødne ressourcer, så det ikke kun er en mand hos PænØse, der sidder med projektet. De rigtige personer bliver tilknyttet projektet og der etableres en styregruppe. Styregruppen beslutter, at implementeringen skal forløbe faseopdelt for derved at kunne tage dele af systemet i brug hurtigere. Styregruppen beslutter også at gå videre med den standardløsning, man er gået i gang med at implementere og så betale for de få ekstra tilpasninger, der kræves. Efter at IT til tiden har tilrettet og opsat systemet, tester PænØse, om systemet kan de ting, som det skal kunne. Herefter bliver de løse ender rettet til. Der gennemføres træningskurser, så alle brugere lærer, hvordan de skal bruge systemet. Der udpeges superbrugere i systemet, som man kan gå til, hvis man har problemer med systemet. PænØse kan endelig tage systemet i brug og vide, at det er tilpasset de fremtidige krav. 30

31 Deloittes tilgang til it-implementeringsprojekter 10. Deloittes tilgang til it-implementeringsprojekter Deloitte har to projektmetoder, som vi bringer i anvendelse i forbindelse med it-systemimplementeringsprojekter. De to metoder betegnes: Express for Implementation TM Project Management Method TM (PMM) De to metoder forklares i det efterfølgende Express for Implementation TM Deloitte har naturligvis en model for gennemførelse af ERP-implementeringsprojekter med faser og aktiviteter, værktøjer, checklister, skemaer, opmærksomhedsområder, eksempler osv. Deloittes metode betegnes Express for Implementation TM, se figur 22. Metoden omfatter 5 faser (de lodrette kasser) i projektforløbet og 6 tværgående aktiviteter (de vandrette kasser), som er nødvendige gennem hele projektet for at sikre, at kvaliteten og fokus bevares i alle faser, samt at organisationen bliver klædt på til de forestående forandringer på forretningsprocesser, organisation, applikationer mv. De enkelte faser i Express for Implementation TM metoden omfatter: Afgrænsning og planlægning, som afdækker ønsker og forventninger til projektet. I denne fase etableres projektplan og projektorganisation. Vision og målsætning, som definerer de relevante forretningsprocesser og de systemmæssige krav. Dernæst identificeres i hvilket omfang det kommende ERP-system er i stand til at håndtere den ønskede funktionalitet. Design, som specificerer, hvorledes den ønskede funktionalitet opnås i ERP-systemet. Såvel standardfunktionalitet som eventuelle tilretninger defineres dog med vægten på tilretningerne. Konstruktion, som bl.a. omfatter opsætning af brugerrettigheder, bogføringsgrupper, kontoplan m.v. Ligeledes udføres programmering af tilretning med udgangspunkt i designdokumentationen. Når konfigurering, udvikling og prøvekonvertering er gennemført, udføres test af systemet. Implementering. Når testforløbet er gennemført tilfredsstillende for henholdsvis konvertering, integration, opsætning og udviklet funktionalitet, kan den endelige implementering påbegyndes. Implementeringen omfatter uddannelse af slutbrugere forud for driftsstart samt endelig konvertering fra det nuværende system. Efter en passende periode efter driftsstarten udføres overtagelsesprøven, der skal sikre, at systemet virker efter hensigten. Såfremt overtagelsesprøven forløber planmæssigt, kan projektet herefter formelt afsluttes. Afgrænsning og planlægning Projektledelse Projektorganisation, risikostyring, planlægning, overvågning, kommunikation, budgetter, bemanding og kvalitetssikring Procesdesign og implementering Procesdesign, testplanlægning, konfigurering, datadesign, konvertering, integration, accepttest, assistance ved implementering og driftsættelse Informationsteknologi Hardware og netværk: valg, indkøb, installation, drift, software-design, udvikling og installation Proces og systemintegritet Sikkerhed og revision Vision og målsætning Forandringsledelse Ledelsesopbakning, organissationsdesign og -ændring, organisationsparathed, politikker, procedurer og ydelsesmålinger Træning og dokumentation Behovsvurdering, udformning af materiale, gennemførelse og dokumentation Design Konstruktion Implementering Figur 22: Deloitte metode Express for Implementation TM. 31

32 Deloittes tilgang til it-implementeringsprojekter De tværgående aktiviteter omfatter: Projektledelse, som inkluderer planlægning, koordinering og opfølgning igennem hele projektforløbet. Desuden har projektledelsen til formål at sikre en effektiv kommunikation, en høj kvalitet af det udførte arbejde og en kvalificeret risikostyring. Procesdesign og implementering, som beskriver de forretningsprocesser, der involveres i implementeringen. Forretningsprocesser og applikationer er designet til at kunne håndtere såvel operationelle som organisatoriske ændringer i forbindelse med implementering af ERP-systemet med signifikante besparelser og forbedringer til følge. Informationsteknologi, som opbygger en it-infrastruktur til at understøtte implementeringen af ERP-systemet. Proces og systemintegritet, som omfatter forhold omkring adgangssikkerhed, revisionsspor og driftssikkerhed. Det har til formål allerede før implementering at identificere de risici, der kan opstå i forbindelse med implementeringen af et nyt ERPsystem samt naturligvis at finde metoderne til at fjerne disse risici. Forandringsledelse, som skal sikre, at medarbejderne forstår behovet for forandring og har de rette kompetencer og motivation til forandring. Når organisationer ændrer strategi, teknologi og processer, påtvinger man også medarbejderne en ændring i deres måde at arbejde på. Virkningen af implementeringen af nyt ERP-system går langt videre end de tekniske aspekter. For at opnå det maksimale udbytte af strategiske mål skal et projekt gennem effektiv forandringsledelse behandle følgende: 1) den måde virksomheden administreres og ledes; 2) eliminering af funktionsgrænser for at øge effektiviteten af virksomhedens processer; og 3) større synlighed mellem driftsenheder og kundebehov. Træning og dokumentation, som overfører viden til organisationen. Alle organisationens behov for undervisnings- og performancesupport er indeholdt i denne hovedaktivitet. Det indeholder bl.a. områder som forretningsmæssige og faglige færdigheder, bløde færdigheder (såsom facilitering og konfliktstyring) og tredjeparts softwarefunktionalitet. Vi anvender ofte projektmetoden til på vegne af virksomheden at trykprøve leverandørens tilgang til gennemførelse af implementeringsprojekt. Dvs. til at afdække, om der er yderligere områder, som bør inkluderes i projektet og til at undersøge, om forhold er fyldestgørende behandlet. 32

33 Deloittes tilgang til it-implementeringsprojekter 10.2 Project Management Method TM Deloitte anvender desuden det mere generelle projektledelsesværktøjet Project Management MethodTM (PMM). PMM er en leveranceorienteret og skalerbar metode til håndtering af projekter. Metoden giver med en struktureret angrebsvinkel til projektledelse en sikker strømlinet og effektiv gennemførelse af projekter. PMM anvendes til at styrke og underbygge aktiviteterne i Express-metoden. Metoden opdeler projektledelsesaktiviteterne i 5 trin, se figur 23. De enkelte trin er kort beskrevet i det følgende. Trin 4. Kontrollere projektfremdriften På dette trin overvåges fremdriften af projektet. Dette omfatter bl.a. korrigerende handlinger for at rette op på konstaterede problemer eller afvigelser, som kan betyde, at de definerede mål ikke opnås. Trin 5. Afslutte projektet På dette afsluttende trin føres de involverede projektressourcer tilbage til deres oprindelige opgaver og ansvarsområder. Desuden udføres aktiviteter for at afslutte projektet på passende vis. Trin 1. Initiere projektet På dette indledende trin bestemmes og godkendes den ledelsesmæssige opbygning af projektet, dvs. styregruppe og projektledelse. Desuden fastsættes og godkendes de overordnede projektmål og strategier for gennemførelse af projektet. Trin 2. Planlægge projektet På dette trin opbygges en konkret plan og procedurer for, hvordan projektet gennemføres, således at de fastlagte projektmål opnås. Det kan være eksempelvis tids- og aktivitetsplan, ressourcetræk, mødeplan, ændringsstyring og kommunikationsplan. Under selve projektforløbet ajourføres dette materiale i relevant omfang. Trin 3. Gennemføre projektet På dette trin udarbejdes og godkendes de leverancer, som kræves for at kunne opnå de fastlagte projektmål. Desuden foretages nødvendig og relevant rapportering af fremdrift. Initiate Project Plan Project Execute Project Control Project Close Project Organization Logistics Produce Organization Strategies Produce Organization Plan Produce Logistics Plan Acquire Staff Acquire Logistics Improve Staff Performance Implement Logistics Monitor Staff Performance Control Logistics Decommission Staff Decommission Logistics Communications Produce Project Communications Plan Communicate Project Information Monitor Project Communications Procurement Produce Client Produce Vendor Contract Plan Contract Plan Establish Vendor Contracts Administer Client Contrats Administer Vendor Contrats Close Vendor Contracts Close Client Contracts Workplan Produce Workplan Execute Workplan Control Workplan Financials Produce Budget Strategy Produce Financial Plan Perform Financial Transactions Maintenance Control Financials Close Financials Risk/ Issues Scope/ Change Produce Project Charter Produce Risk Plan Produce Scope Plan Produce Issues Plan Produce Change Plan Implement Risk Approach & Risk Responses Implement Change Requests Performance Issue Resolutions Monitor Risks & Risk Responses Control Change Requests Control Issue Resolutions Quality Produce Quality Plan Conduct Quality Assurance Monitor Quality Assurance Integration Produce Integration Strategies Produce Project Plan Execute Project Plan Monitor Project Complete Performance Phase Complete Project Figur 23: Deloitte metode Project Management Method TM (PMM). 33

34 Om IT Solutions 11. Om IT Solutions Deloitte IT Solutions er en funktion i Deloitte, som blandt andet tilbyder uafhængig it-rådgivning inden for fx: Udarbejdelse af it-strategi. Valg og anskaffelse af it-systemer fx virksomhedssystemer (ERP), systemer for fakturahåndtering, sags- og dokumentstyringssystemer, ledelsesrapporteringssystemer. Projektledelse/-assistance ved implementering af it-systemer. Analyse og optimering af forretningsprocesser ud fra leanprincipper. Strategisk it-planlægning er et middel til at opnå bedre udnyttelse af it-investeringer. Det er vores opfattelse, at forretningsorienterede it-strategiprojekter omfatter: Afdækning af det generelle forretningsmiljø, forudsætninger og betingelser. Afdækning af generelle it-trends og andre virksomheders anvendelse af it. Vurdering af den aktuelle virksomheds it-anvendelse, it-infrastruktur og it-organisation. Etablering af en vision for, hvordan den aktuelle virksomhed vil anvende it. Opstilling af business case for realisering af denne it-vision. Opbygning af en konkret handlingsplan for realisering. Udfordringen for virksomheden er derefter at identificere, vælge, anskaffe og indføre de it-systemer, som opfylder virksomhedens itstrategiske visioner, krav og behov og at gennemføre denne proces hurtigt og effektivt. Vi har en gennemarbejdet og i praksis anvendt metodik for valg og anskaffelse af it-systemer. Metodikken omfatter tre hovedspor, nemlig: Fra en række projekter har vi opbygget en meget stor erfaringsbase. Den danner grundlag for vores tilgang til gennemførelse af projekter. Vi lægger vægt på at være uformelle og enkle at arbejde sammen med og at tilpasse os vores kunders kultur. Ydelser fra Deloitte IT Solutions i forbindelse med gennemførelse af it-projekter kunne være at fungere som sparringspartner og ressource for virksomheden bl.a. i relation til at: Medvirke ved kontraktforhandlinger med den valgte leverandør Styre og lede projektet sikkert gennem forløbet Støtte virksomhedens medarbejdere undervejs i forløbet Varetage kommunikation med den valgte leverandør Medvirke ved design af nye forretningsprocesser Assistere ved opsætning af systemet Medvirke ved test og datakonvertering Håndtere forandringer, herunder intern og ekstern kommunikation. De tekniske og administrative aspekter af et projekt får typisk fuld opmærksomhed, men det er ofte de bløde aspekter, som afgør, om et it-projekt bliver en succes fx: Håndtering af forandringsledelse og kommunikation til organisationen om projektet og de tilhørende ændringer. Opbygning af samarbejdskultur og ansvar/ejerskabsfølelse internt i projektgruppen bestående af personer fra såvel virksomhed som leverandør. I erkendelse heraf har Deloitte IT Solutions også specialister med HRmæssige kompetencer. Formel, som er den traditionelle udbudsform (fx EU-udbud), hvor der udarbejdes en detaljeret og omfattende kravspecifikation, som udsendes til besvarelse hos et antal leverandører evt. efter en forudgående prækvalifikation. Derpå evalueres de modtagne svar og derudfra træffes valget. Unikke krav, hvor fokus er på at identificere de forretningskritiske krav til det fremtidige system, hvorefter 2-3 mulige leverandører på en stramt styret workshop viser, hvordan de vil opfylde disse essentielle krav. På baggrund af dette træffes valget. Fit-Gap-analyse, hvor virksomheden allerede har foretaget valg af et system og nu ønsker sikkerhed for, at valget er rigtigt. Dvs. at systemet virkeligt kan opfylde de opstillede krav. 34

35 Afrunding 12. Afrunding Det er vores håb, at læseren gennem denne publikation er blevet mere tryg og komfortabel med at gennemføre en ERP-implementering. Vi har søgt at beskrive et forløb, som vi ved fungerer. Samtidig har vi beskrevet mulige faldgruber undervejs, samt hvordan man kommer uden om dem. For yderligere information om vores ydelser inden for it-rådgivning kontakt: Erik Lennings Senior Manager Tlf. direkte: Mobil: Troels Ladefoged Manager Tlf. direkte: Mobil: Birkerød Kongevej 25C, 3460 Birkerød Tlf.:

36 Deloitte i Danmark Kundernes tillid i over 100 år har gjort Deloitte til Danmarks førende revisions- og rådgivningsfirma. Vi servicerer vores kunder fra 21 lokale kontorer landet over de 4 i Grønland. Vores dybe brancheindsigt og viden om lovgivnings- og forretningsmæssige forhold bringer os i stand til at rådgive på mange niveauer. Vi er førende inden for vores felt, og vores godt medarbejdere hører til de dygtigste i branchen. De nyder udfordringer og er opdateret med den seneste viden. Med en professionel indstilling til etik og ansvarlighed løfter de engageret deres opgaver. Vi er lokalt forankret, har national indsigt og global udsigt. Om Deloitte Deloitte leverer ydelser inden for Revision, Skat, Consulting og Financial Advisory til både offentlige og private kunder i en lang række brancher. Vores globale netværk med medlemsfirmaer i 140 lande sikrer, at vi kan trække på stærke kompetencer foruden en dybtgående lokal indsigt, når vi skal hjælpe vores kunder overalt i verden. Deloittes medarbejdere arbejder målrettet efter at sætte den højeste standard. Deloittes medarbejdere understøttes af en virksomhedskultur, der fremmer integritet og merværdi til kunderne, en forpligtelse over for hinanden og en styrke gennem forskellighed. De arbejder i et miljø præget af konstant udvikling, udfordrende oplevelser og berigende karrieremuligheder. Deloittes medarbejdere arbejder målrettet på at styrke ansvarlighed, opbygge tillid og sikre positiv indflydelse i deres lokalsamfund. Deloitte Touche Tohmatsu Deloitte er en betegnelse for Deloitte Touche Tohmatsu, der er en schweizisk organisation (Verein), og dets netværk af medlemsfirmaer. Hvert medlemsfirma udgør en separat og uafhængig juridisk enhed. Vi henviser til about for en udførlig beskrivelse af den juridiske struktur i Deloitte Touche Tohmatsu og dets medlemsfirmaer. Deloitte Statsautoriseret Revisionsaktieselskab 2008 Medlem af Deloitte Touche Tohmatsu