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