Deloitte IT Solutions Marts Nyt it-system Succes eller fiasko?

Transkript

1 Deloitte IT Solutions Marts 2013 Nyt it-system Succes eller fiasko?

2 Indholdsfortegnelse Forord 2. Generelt om it-projekter 3. Business case 4. Fremgangsmåde for valg og anskaffelse af it-systemer 5. Kontraktforhandling med leverandør 6. Etablering af implementeringsprojektet 7. Specifikation og design 8. Udvikling, opsætning og test 9. Idriftsætning 10. Efter driftsstart 11. Oversigt over it-systemer 12. Om Deloitte IT Solutions 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 Revisionspartnerselskab. Der tages forbehold for eventuelle fejl og misforståelser vedrørende oplysninger i publikationen. 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. 2

3 1. Forord Med denne publikation er det vores ønske at viderebringe Deloitte IT Solutions praktiske erfaringer med gennemførelse af valg og implementering af it-systemer. Vi har samlet vores erfaringer fra en række danske virksomheder og offentlige institutioner. Vi oplever, at mange virksomheder løber panden mod muren ved såvel valg som implementering af nye itsystemer. Typisk undervurderes omfanget og indholdet af de opgaver, som projektet består af, og derudover opstår der altid en række problemer og konflikter undervejs, som virksomheder er uforberedte på. Desuden har langt de fleste virksomheder ikke tilstrækkelige interne ressourcer til at gennemføre implementering af nye it-systemer, da det daglige arbejde fortsat skal passes. Ofte bliver sådanne opgaver bare lagt oven på de daglige opgaver i virksomheden det klarer du lige. Konsekvensen er, at opgaver knyttet til it-syste - met nedprioriteres til fordel for de daglige opgaver. Virksomheder er også ofte uforberedte og mangler forudsætninger for at håndtere projektet, da projektets aktiviteter og begreber er nye og ukendte. Det er også muligt, at selve projektbegrebet er ukendt. Ovenstående resulterer i en ond cirkel med forsinkel - ser, gensidige beskyldninger mellem virksomhed og leverandør om at være årsag til problemerne, tab af tillid mellem virksomhed og leverandør, manglende opfyldelse af mål med det nye it-system osv. Denne cirkel kan i yderste konsekvens betyde 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 itprojekter, så man som virksomhed får et velfungerende it-system, der understøtter forretningen og opfattes positivt af brugerne. Det er vores håb, at læseren gennem denne publikation vil blive mere tryg og komfortabel med at gen nemføre den svære proces med valg, anskaffelse og implementering af et it-system. Vi vil beskrive et forløb, som vi ved fungerer. Samtidig vil vi beskrive mulige faldgruber undervejs, og hvordan man kommer uden om dem. God læselyst. Med denne publikation er det vores ønske at viderebringe Deloitte IT Solutions praktiske erfaringer med gennemførelse af valg og implementering af it-systemer. Nyt it-system Succes eller fiasko? 3

4 2. Generelt om it-projekter Implementeringsprojektet udgør en væsentlig del af den samlede investering i forbindelse med anskaffelse af et nyt it-system. En simpel tommelfingerregel vedrørende implementering af it-systemer siger, at omkostninger til implementering er licensprisen ganget med en faktor 2-3, se figur 1. Hertil kommer også de interne ressourcer, som virksomheden selv anvender, og mistet indtjening for personer, der ikke kan udføre deres sædvanlige arbejdsopgaver % 65-75% 31% 53% 16% 21% 42% 37% Projekter bliver aldrig fuldført og opfattes som en fiasko Projekter gennemføres delvist og opfattes ikke som vellykket Projekter gennemføres og opfattes som en klar succes Kilde: Standish Group CHAOS report 2010 Interne omkostninger IT licenser udgør 25-35% af de eksterne omkostninger IT tilretning og implementering udgør 65-75% af de eksterne omkostninger Figur 1 En tommelfingerregel siger, at omkostninger til implementering er licensprisen ganget med en faktor 2-3. Man skal som virksomhed som oftest anvende og leve med it-systemet i lang tid efter implementeringen. Det er derfor meget vigtigt, at it-systemet bliver opfattet som en succes, og at det bliver implementeret på en måde, som understøtter ens forretning. Gennemførelsen af it-projekter er ofte præget af problemer. I CHAOS-undersøgelsen har Standish Group set på over it-projekter, se figur 2. De har påvist, at ud af påbegyndte it-projekter bliver kun omkring en tredjedel (i 2010) gennemført med succes, og 21% bliver aldrig fuldført. De resterende projekter bliver 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 Figur 2 Undersøgelse foretaget af Standish Group omkring gennemførelse af it-projekter. Som det fremgår af ovenstående er det ikke så let at opnå et succesfuldt it-implementeringsprojekt. To væsentlige faktorer for at opnå et succesfuldt projekt er en velafprøvet metode og et kompetent projektteam, 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 såsom kommunikation, som afgør, om it-projekter bliver opfattet som en succes. Erfaringen har vist, at man får det bedste resultat, hvis man har gjort et godt forarbejde. Hvis man fra start har haft klare mål for projektet, så er der også størst sandsynlighed for, at man får det, man har efterspurgt. De fleste systemer kan langt hen ad vejen løse behovene hos de fleste virksomheder. Dér hvor der kan opstå store forskelle er, hvis man efterspørger deciderede branchesystemer, eller hvis man har en lang række specifikke ønsker, som ligger langt fra den gængse standardfunktionalitet. Her er det specielt vigtigt, at man har været rigtig god til at definere kravene til det nye system. Man bør også forsøge at fokusere mere på valget af leverandør end på valget af system. Det er langt vigtigere at have en god leverandør, som man har tillid til, frem for et godt system, som leverandøren ikke kan supportere. 4

5 Er et nyt it-system svaret på alle problemer? Det er vigtigt at have i tankerne, at et nyt itsystem ikke nødvendigvis er svaret på udfordringerne i virksomheden. Fx kan et nyt itsystem ikke forbedre en i forvejen mangelfuld forretningsmodel eller effektivisere arbejdsgange, hvor de underliggende processer som udgangspunkt er ineffektive. I projektet indgår flere elementer. Naturligvis er der selve opgaven, men også målet med den og det endelige resultat. Dette resultat er af interesse for en række interessenter, og de har mulighed for at påvirke projektet undervejs. For at opnå det ønskede resultat skal der anvendes en række ressourcer, blandt andre især menneskelige ressourcer. Endelig indgår projekt planen som et element, altså hvordan man har tænkt sig at gribe opgaven an. Et nyt it-system kan som udgangspunkt heller ikke løse ledelses- eller personalemæssige problematikker. Fx kan det nye it-system ikke i sig selv fremme accepten af forandringer i organisationen. Forandringsaccept påvirkes af en lang række forhold som organisationskultur, ledelsesstil, tidligere erfaringer i organisationen mv. Det er desuden ikke op til det nye it-system at sikre, at man har de rigtige medarbejdere til arbejdsopgaverne. Et nyt it-system medfører ikke nødvendigvis en bedre datakvalitet Man kan ikke få bedre data ud, end dem der kommer ind! Det er derudover ikke en selvfølge, at systemet er lettere at anvende. Flere muligheder kan sagtens give større kompleksitet. De fleste virksomheder bliver overraskede 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. En simpel tommelregel siger, at det virksomhedens interne ressourcebehov til projektet er omtrent det dobbelte af leverandørens ressourcebehov. Dette afhænger naturligvis af kompleksitet, omfang og fordelingen af opgaver mellem leverandør og virksomhed. Typisk vil det interne ressourcebehov i virksomheden variere meget gennem projektforløbet, se et eksempel i nedenstående figur Projekttankegang Men hvad er egentlig et projekt? Lidt akademisk defineres et projekt ofte som det at løse en specifik op - gave (fx at implementere et nyt it-system) inden for en tidsmæssig afgrænset periode med fastlagt startog sluttidspunkt (fx klar til driftsstart d. 1. januar 2014) 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, hvor man ikke har den nødvendige viden fra starten af. Projekter adskiller sig fra de daglige opgaver netop ved, at det er noget helt andet, der skal udføres. Specifikation og design Udvikling og opsætning samt test Figur 3 Ressourcebehovet i implementeringsprojektet varierer meget i løbet af projektperioden. Implementering Udrulning Træning af slutbrugere Datakonvertering Overtagelsesprøve Driftsstart Nyt it-system Succes eller fiasko? 5

6 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: Høj Etablering. Denne periode optræder, når gruppen sammensættes som et overgangsforløb fra individualisme til gruppemedlemskab. Deltagerne afprøver lederens styring både formelt og uformelt. Motivation Præstationsniveau Oprør. Dette er den hårdeste periode, hvor deltagerne begynder at forstå, at opgaven er anderledes og mere vanskelig, end de forestillede sig. Stemningen bliver trykket, opfarende og frustrerende. Varighed og omfang af oprørsperioden kan mindskes gennem etablering af team spirit og klar kommunikation om forventede mål og øvrige forventninger. Gennemførelse. Deltagerne forener loyalitet, ansvar og opgaver og accepterer gruppen, gruppens regler og de individuelle forskelle hos deltagerne. Dette er den produktive periode. Afslutning. Projektet er succesfuldt afsluttet, og forankringen af resultaterne påbegyndes. Deltagerne skilles og vender tilbage til deres dagligdag. Lav Etablering Oprør Gennemførsel Afslutning Figur 4 Typisk forløb for projektgruppens motivation og præsta tionsniveau gennem projektforløbet. 2.2 Faser for etablering af nyt it-system: Fra ide til drift Valg, anskaffelse og implementering af et nyt it-system vil typisk omfatte faserne illustreret i figur 5, hvor betegnelser og indhold kan variere lidt i de forskellige projektmodeller og metoder. Hver enkelt fase vil blive behandlet i denne publikations øvrige kapitler, som det er anført i figuren. 6

7 Forberedelse Business case (Kapitel 3) Anskaffelsesprojekt Valg af it-system (Kapitel 4) Implementeringsprojekt Projektetablering (Kapitel 6) Forhandling med leverandør (Kapitel 5) Specifikation og design (Kapitel 7) Udvikling, opsætning og test (Kapitel 8) Idriftsætning (Kapitel 9) 2.3 Faldgruber undervejs Der findes en lang række faldgruber, som kan føre til mislykkede it-projekter. For det første kan der opstå gnidninger i samarbejdet mellem virksomhed og leverandør. Der kan fx forekomme en forståelseskløft, hvor leverandør og virksomhed anvender terminologi forskelligt, har forskellig baggrundviden om it, eller hvor leverandøren måske har et mangelfuldt branchekendskab. Det er desuden ikke ualmindeligt, at virksomheden har urealistiske forventninger til systemet. Dernæst kan uklare mål, urealistisk tidsplan og utilstrækkelige eller upræcise krav til systemet være fatale for implementeringen. Der kan selvfølgelig også opstå problemer, hvis samarbejdet i projektgruppen ganske enkelt ikke fungerer. Drift Efter driftsstart (Kapitel 10) Figur 5 Faser for etablering af nyt it-system: fra ide til drift Desuden er der en række aktiviteter, som udføres i alle faser, blandt andet kommunikation, håndtering af forandringsprocesser, kvalitetsstyring og projektledelse, herunder ændrings- og projekthindringshåndtering 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. 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. Simple forhold som forskellig anvendelse af begreber og sprogbrug er årsag til mange konflikter. For det andet kan implementeringen mislykkes på grund af interne forhold i virksomheden. Her tænkes blandet andet på mangelfuld eller utilstrækkelig ledelsesopbakning, manglende fokus på forandringsledelse og modstand i organisationen. Det er desuden vigtigt, at der bliver taget hånd om de projekthindringer, der opstår undervejs i projektet. Et sådant problem kan fx være, hvis virksomheden ikke kan stille de interne ressourcer til rådighed, som implementeringen kræver, og leverandøren dermed får utilstrækkeligt brugerinput og deltagerinvolvering. For det tredje kan eksterne faktorer påvirke implementeringens succesrate, som fx anvendelse af ny og umoden teknologi. Listen over mulige faldgruber er lang, men heldigvis er der også en række måder at undgå faldgruberne på. I denne publikations kapitel 3-10 vil det blive gennemgået, hvordan ovennævnte faldgruber kan undgås i it-implementeringsprojektets forskellige faser. Nyt it-system Succes eller fiasko? 7

8 3. Business case Som figur 5 illustrer, er udarbejdelse af en business case den første fase ved etablering af et nyt it-system Udarbejdelse af business casen er en meget vigtig aktivitet, da business casen indeholder formål og mål med implementeringen og den efterfølgende anvendelse af det nye it-system. Med andre ord viser business casen, om det nye system kan retfærdigøres eller ej. Den definerer, hvad der skal gøres, hvorfor, hvad tidsrammen er og hvilke forventede omkostninger, implementeringen indebærer. Den indeholder også forventede risikoelementer forbundet med implementeringen, samt estimater for gevinster med både de direkte kvantificerbare og efterfølgende målbare effekter og de mere uhåndgribelige effekter såsom forbedret ledelsesinformation. Business casen er dermed styregrundlaget for anskaffelse, implementering og anvendelsen af det nye it-system. Når tidsplanen og budgettet for projektet fastlægges i business casen skal virksomheden være klar over, at 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 er vigtigt, at tidsplanen afspejler de aktuelle forhold fx efter det nødvendige omfang af forandringsledelse og systemtilpasninger. Det må forventes, at den tidsmæssige udstrækning er på 9-12 måneder fra udarbejdelse af business casen til idriftsætning. 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 den nødvendige træning af slutbrugere og test af systemet ikke finder sted inden driftsstart. En for lang projektperiode kan medføre træthed i organisationen med holdninger som det bliver aldrig til noget. Man må se i øjnene, at budgettet for et it-projekt 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. Generelt er det vigtigt at have mål man kan planlægge og styre efter. Man skal kende målet for at kunne planlægge og styre. I modsat fald bliver situationen som for Alice i bogen Alice i Eventyrland af Lewis Carroll, hvor hun på sin vej møder Filurkatten og spørger Vil du ikke nok fortælle mig, hvilken vej jeg skal gå for at komme herfra?. Det afhænger jo en hel del af, hvor du vil hen, svarer Filurkatten. Det er mig temmelig ligegyldigt, siger Alice. Så kan det jo også være det samme, hvilken vej du går, svarer Filurkatten. Som optakt til business casen er der en række forhold, som virksomheder bør overveje og afklare, inden de kaster sig ud i et forløb med at vælge, anskaffe og implementere et nyt it-system. Disse forhold vil blive forklaret i afsnit 3.1, mens udarbejdelse og anvendelse af business casen beskrives i afsnit Forarbejde til business casen Det er en god ide at træffe langsigtede beslutninger omkring, hvordan man ønsker at anvende it i sin organisation, da det kan hjælpe med at styre virksomhedens brug af og investeringer i informationsteknologi. Dette kaldes formelt for en it-strategi. Hvis man som virksomhed har en sådan, vil det være naturligt, at den ligger til grund for udarbejdelsen af business casen. Uanset om man som virksomhed har en it-strategi eller ej, er der en række forhold, som er relevante at adressere inden business casen udarbejdes. Det bør fx afklares: Hvilken leverandørmodel man foretrækker direkte eller indirekte. Hvordan man ønsker at tilgå og anvende sine it-systemer. Hvilken implementeringsstrategi man ønsker at benytte sig af. Hvilken projekttilgang man foretrækker. Disse områder er forklaret nærmere i de efterfølgende afsnit. 8

9 3.1.1 Leverandørmodeller direkte eller indirekte Markedsføring, salg og implementering af it-systemer kan principielt ske efter to forretningsmodeller. Den ene kan betegnes som en direkte model, hvor den virksomhed, som udvikler, dokumenterer og generelt vedligeholder systemet, også selv markedsfører, sælger og implementerer og efterfølgende vedligeholder systemet hos kunderne. Den anden kan betegnes son en indirekte (eller partnerbaseret) model, hvor udvikling, dokumentation og generel vedligeholdelse af systemet udføres af en virksomhed. Denne virksomhed har tilknyttet en række andre virksomheder (ofte betegnet som partnere), som markedsfører, sælger og implementerer og efterfølgende vedligeholder systemet hos kunderne. De to modeller har hver deres fordele og ulemper. Dette er forsøgt skitseret i skemaet nedenfor. Der er også mellemformer af de to modeller, fx hvor virksomheden, der udvikler systemet, også selv leverer og implementerer systemet hos meget store og komplekse brugere af systemet eller inden for bestemte brancher. Fordele Ulemper Den direkte model Leverandøren har udviklet systemet og har derfor meget detaljeret viden om muligheder og begrænsninger i systemet. Dette giver gode muligheder for kreativ opsætning og anvendelse af systemet Bedre mulighed for at få særlige funktionalitet (gælder primært for de mindre leverandører) Stor afhængighed af leverandøren Mindre leverandører kan have svært ved både at have ressourcer til at udvikle det generelle system og til at implementere løsninger hos kunder. Der er dermed risiko for at implementeringer nedprioriteres i perioder Der kan være modsætningsforhold mellem systemet og forretningen, da systemet oprindeligt er orienteret mod en bestemt branche eller anvendelse (gælder primært for de mindre leverandører) Den indirekte (eller partnerbaserede) model Der er flere leverandører af det samme system. Dermed er det muligt at skifte leverandør i tilfælde af samarbejdsvanskeligheder Mange leverandører at vælge blandt, fx ud fra størrelse, branchekendskab, relevante referencer og geografisk placering Stor forskel på viden, erfaring, størrelse mv. hos de forskellige leverandører Mellemmand mellem bruger og udvikler af det generelle system Nyt it-system Succes eller fiasko? 9

10 3.1.2 Tilgang til og anvendelse af it-systemer Grundlæggende er der to metoder, som en virksomhed kan tilgå og anvende sine it-systemer på. Den ene metode er som egen applikation (engelsk betegnelse: On-premise), der enten driftes af en intern it-afdeling eller af en ekstern hosting partner. Ved den anden metode kan man tilgå og anvende sine it-systermer som serviceydelse (engelsk betegnelse: Software-as-a-Service: SaaS), der udbydes af en ekstern partner og tilgås via internettet. Den eksterne partner drifter systemet. Det efterfølgende skema opsummerer karakteristika for de to metoder. Som egen applikation (on-premise) Som serviceydelse (SaaS) Systemarkitektur Hver virksomhed anvender sin egen applikation. Flere virksomheder anvender den samme applikation på samme tid. Kræver en meget sikker adskillelse af opsætning og data. Betalingsmodel Hardware: Servere Fleksibilitet/ mulighed for tilpasning Implementering/ udrulning Opgradering af systemet Infrastruktur omkostninger Miljøer Geografiske begrænsninger Skalerbarhed Licens, som typisk er baseret på antal brugere og anvendt funktionalitet. Licensen betales ved indgåelse af aftale. Årlig vedligeholdelsesafgift (maintenance fee). Virksomheden har selv den nødvendige serverinstallation eller har den hos en ekstern hosting samarbejdspartner. Nærmest ubegrænsede muligheder for individuel tilpasning af systemet. Typisk en omfattende handling i form af et implementerings- og udrulningsprojekt med en række faser. Der skal typisk også installeres nyt serverhardware. Dette besluttes af virksomheden og udføres typisk i samarbejde med virksomhedens it-leverandør. Forholdsvis store, da der skal installeres servere, netværk, bruger-pc er og software (database, applikation mv.) Antal og anvendelse af miljøer er helt op til virksomheden, fx Produktion, Test, Træning og Udvikling. Virksomheden er selv ansvarlig for definition og vedligeholdelse af miljøer. Fjernadgang kræver VPN eller adgang til internt netværk (intranet). Forholdsvist vanskeligt og kostbart, da dette ofte vil kræve både supplerende licenser og serverhardware. Månedlig afgift, som typisk er baseret på antal brugere, anvendt funktionalitet og antal transaktioner. Den nødvendige serverinstallation er hos udbyderen. Der er kun netværk og bruger-pc er i virksomheden. Der er alene de tilpasningsmuligheder, som systemets opsætning giver mulighed for (stærkt begrænsede muligheder). Typisk en forholdsvis begrænset handling med specifikation og opsætning inden for de muligheder, som findes samt test. Der er ingen installation af nyt serverhardware. Dette besluttes og udføres af udbyderen, og som virksomhed må man acceptere og følge med. Næsten ingen, da der alene skal være netværk og bruger-pc er. Antallet af miljøer fastsættes suverænt af udbyder og er typisk forholdsvis begrænset, fx Produktion og Test (ofte benævnt Sandkasse). Kan tilgås overalt via internettet, hvor der er tilstrækkelig båndbredde. Meget simpelt, da nødvendig serverhardware stilles til rådighed af udbyder. 10

11 3.1.3 Valg af implementeringsstrategi Implementeringsstrategien bestemmer, hvornår det nye it-system kommer til at påvirke forretningen, kunder og medarbejdere. Den bestemmer også i høj grad tidsplan og ressourcebehov for projektet. Principielt kan der anvendes tre forskellige implementeringsstrategier. I en Big Bang-strategi planlægges, konfigureres, tilrettes og implementeres it-systemet og de tilhørende forretningsprocesser i hele virksomheden i en samlet idriftsættelse. Ved en Faseopdelt strategi deles it-systemet og de tilhørende forretningsprocesser op i mindre, gradvise idriftsættelser fx ved implementering af et ERP-system: Økonomi -> Lager -> Indkøb -> Salg. Der findes også en Kombineret strategi, som er en Big Bangtilgang der gradvis idriftsættes i virksomhedens datterselskaber, divisioner, afdelinger mv. fx Datterselskab B -> Datterselskab A -> Hovedkontor. En Big Bang-strategi egner sig som udgangspunkt 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 hovedsageligt bedst til virksomheder med komplekse delprocesser og forholdsvist ensartede forretningsområder. En kombineret strategi egner sig til virksomheder med uensartede forretningsområder. Big bang Fordele Omfatter en mere intens og afgrænset periode end en faseopdelt strategi Ressourcebehov kan lettere estimeres Eksisterende systemer kan hurtigere elimineres og dermed forhindres, at skyggeløsninger lever videre Ulemper Risikofyldt, da 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 Faseopdelt strategi Kombineret strategi 1 2 Giver mulighed for at planlægge, tilpasse og kvalitetssikre forretningsgangen og systemets funktionalitet inden for hver enkel arbejdsproces Sikrer en mere smidig overgang til det nye miljø og lettere koordinering med den daglige forretning Har fordele fra en Big Bang-strategi inden for det område, hvor løsningen rulles ud, men med lavere risiko og bedre mulighed for at tilpasse implementeringsforløbet lokalt 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 Kræver midlertidige grænseflader til og paralleldrift af eksisterende systemer Har som ved faseopdelt strategi en tendens til at trække ud i tid En vis grad af midlertidige grænseflader og paralleldrift kan ikke undgås 3 4 Nyt it-system Succes eller fiasko? 11

12 3.1.4 Valg af projekttilgang Man kan opdele projekttilgange i strukturerede tilgange og iterative tilgange. Ved en typisk struktureret tilgang færdiggøres én del af udviklingsforløbet, før den næste påbegyndes, og hele processen er planlagt på forhånd. En iterativ tilgang kan derimod karakteriseres som en evolutionær proces, hvor man løbende finder frem til krav og løsninger ved at gennemgå det komplette udviklingsforløb for en lille del af projektet ad gangen. I den nedenstående tabel er en oversigt over fordele og ulemper ved at anvende de to projekttilgange i et implementeringsprojekt: Struktureret tilgang Fordele Kan med fordel anvendes, når kravene er velkendte, og udviklingsmiljøet er stabilt Kan anvendes til projekter af alle størrelser og kompleksitetsgrader Ulemper Omfattende planlægning er nødvendig Kan opfattes som en bureaukratisk tilgang Ufleksibel hvis der forekommer ændringer i krav eller omgivelser Iterativ tilgang Kan med fordel anvendes, når kravene er vanskelige at specificere Fleksibel hvis der forekommer ændringer i krav eller omgivelser Kan hurtigt levere resultater/delleverancer Ændringer i krav kan have følger for allerede leverede delleverancer fejl må accepteres til en vis grad Egner sig bedst til mindre implementeringer, hvor antallet af interessenter er lavt Vanskeligere for projektlederen at kontrollere, da strukturen i processen er begrænset, og beslutningsansvaret i høj grad ligger hos de enkelte udviklingsteams 12

13 Af eksempler på iterative tilgange kan nævnes SCRUM, spiralmodellen og DSDM (Dynamics Systems Development Method). Af strukturerede tilgange kan nævnes vandfaldsmodellen og varianter heraf såsom V-modellen og den trinvise model. 3.2 Udarbejdelse og anvendelse af business case På baggrund af ovenstående forhold, samt evt. en it-strategi, kan en business case for anskaffelse og implementering af et nyt it-system udarbejdes. Det omfatter følgende: Business case Identificere evalueringskriterier Udføre implementeringen Tjek business case 1. Beskrivelse af problemet eller muligheden. Gøres kort og præcist. Evaluere gevinster 2. Opstilling af succeskriterier for det kommende projekt. Hvad vil virksomheden opnå gennem projektet? Hvad er forudsætningerne for at opnå disse mål? Man bør opstille både direkte kvantificerbare effekter af it-projektet og mere uhåndgribelige og bløde effekter. 3. Identificere risikoelementer og barrierer for projektet, og hvordan disse skal håndteres. 4. Vurdere omkostninger ved at gennemføre projektet. 5. Vurdere de direkte kvantificerbare gevinster af projektet. 6. Vurdere de uhåndgribelige og bløde gevinster af projektet, og forsøge at angive et økonomisk omfang af disse. 7. Foretage periodisering af omkostninger og gevinster. Dette udføres for at vurdere, hvor lang tid der går, før investeringen er tjent hjem igen. Business casen anvendes løbende til at holde projektet på rette spor, og kan også anvendes som et udgangspunkt for løbende evalueringer af, hvorvidt de planlagte gevinster opnås. Dette er illustreret i figur 6. Gevinst realiseringsrapport Figur 6 Anvendelse af business case Løbende evaluering af implementeringsprojektet tager udgangspunkt i kriterier fastlagt ud fra mål og forventede gevinster specificeret i business casen. Den løbende evaluering har til formål at sikre, at fokus på forretningsmålene fastholdes og overskridelse af budgetter og deadlines forhindres. Det er ikke blot projektlederen, der løbende skal evaluere implementeringen. Andre interessenter vil også overvåge og kontrollere implementeringen for at vurdere, om den bliver en succes eller ej. Projektlederen vil have meget stor indflydelse på, hvorvidt mål og forventede gevinster kan realiseres. Det er derfor vigtigt, at projektlederen har en stor indsigt i business casen og føler ejerskab for den, uanset om projektlederen har været med til at udarbejde den eller ej. Nyt it-system Succes eller fiasko? 13

14 4. Fremgangsmåde for valg og anskaffelse af it-systemer 2. Udarbejde og udsende udbudsmateriale 4. Afholde leverandør workshops 1. Kortlægning af forretningsprocesser og de unikke itsystemkrav 6. Evaluering og indstilling af leverandør 3. Udarbejde vurderingsskema til brug ved leverandør workshops 5. Udfylde vurderingsskema på leverandør workshops Figur 7 Fremgangsmåde for valg og anskaffelse af nyt it-system. Som illustreret i figur 5 behandler vi i Deloitte fasen for valg og anskaffelse af it-systemer som et separat projekt. Til dette anvendes en projektmodel, som i et faseopdelt forløb fastlægger aktiviteter og tilhørende dokumentation. Figur 7 viser vores tilgang til valg og anskaffelse af et nyt it-system. Vi har anvendt denne tilgang hos mange kunder og for flere typer af it-systemer, og har gode erfaringer med den. De bedste resultater er opnået i de situationer, hvor kunden forinden har udarbejdet en business case, hvilket vi derfor anbefaler, at man gør. Grundtanken i denne fremgangsmåde er, at der fokuseres på at afdække og dokumentere krav til det nye it-system omkring de for virksomheden unikke og essentielle områder. Dette gøres ved at kortlægge virksomhedens forretningsprocesser på overordnet niveau for at sikre, at alle relevante områder behandles og medtages. Når de unikke krav er fastlagt, identificeres og udvælges et begrænset antal it-systemer med tilhørende leverandører (typisk 3-4), der inviteres til at udarbejde et løsningsforslag inkl. prisestimat, som de præsenterer på workshops hos virksomheden. Det er lettere og bedre at vurdere systemer ved at se dem end ved at læse om dem. I forhold til en mere traditionel fremgangsmåde som indeholder en meget detaljeret kravspecifikation, prækvalifikation, udbudsforløb, evaluering og forhandling, er det vores erfaring, at der ved anvendelse af denne fremgangsmåde opnås følgende fordele: Tids- og ressourcebesparelse såvel hos virksomheden som hos de involverede leverandører. Fokus på de virksomhedsspecifikke arbejdsgange giver større sikkerhed for at anskaffe et system, der effektivt understøtter forretningsgange. Den tidsmæssige udstrækning af dette forløb afhænger naturligvis af kompleksitet og omfang af den aktuelle it-anskaffelse. En typisk tidsmæssig udstrækning for trin 1-6 er ca. 10 uger, se figur 8. Den tidsmæssige udstrækning af den forudgående business case kan variere meget bl.a. ud fra virksomhedens aktuelle it-niveau, ønsket omfang og ønsket detaljeringsgrad af business casen. Ligeledes vil den tidsmæssige udstrækning af kontraktforhandlingen kunne variere meget. 14

15 Business case Trin 1: Forretningsprocesser, visioner og krav Trin 2 & 3: Udbudsmateriale og internt evalueringsskema Leverandører forbereder sig Trin 4 & 5: Leverandør workshops og udfylde evalueringsskemaer Trin 6: Evaluering og indstilling Afklaringsfase og kontraktforhandling Figur 8 Eksempel på typisk tidsplan for valg af nyt it-system. Uge Trin 1-6 for valg og anskaffelse af et nyt it-system er beskrevet mere detaljeret i de efterfølgende afsnit Efter en leverandør er udvalgt, kan virksomheden med fordel indgå en afklaringsfase med leverandøren, hvor man bliver enige om de nærmere rammer for projektet, se nærmere i afsnit 4.5. Herefter er parterne klædt på til at indgå i kontraktforhandlinger, som vil blive gennemgået i det efterfølgende kapitel 5. Det skal bemærkes, at den beskrevne fremgangsmåde ikke kan anvendes ved EU-udbud, da forløbet for EUudbud er lovmæssigt reguleret med hensyn til annoncering, tidsfrister mv. og vil kræve en mere omfattende og detaljeret kravspecifikation, end modellen foreskriver. 4.1 Trin 1: Forretningsprocesser, visioner og krav Det primære i dette trin er at etablere en kravspecifikation, der omfatter det væsentlige for virksomheden. Det er nemt nok at udarbejde en stor og omfattende kravspecifikation med en række banaliteter fx omkring korrekt bogføring, bestemte felter osv., alt sammen forhold, som man kan gå ud fra, at systemerne kan. Kunsten er derimod at få afdækket de essentielle og de unikke krav. Det er de krav, som er forretningskritiske, og som gennem effektiv håndtering giver virksomheden en konkurrencemæssig fordel. Et centralt element i afdækning af de unikke krav er at kortlægge virksomhedens forretningsprocesser. Populært sagt fungerer procesmodellen som et juletræ, hvor kravene hænges op. Deloitte baserer procesmodelleringen på et selvudviklet værktøj IndustryPrint, som omfatter generelle procesmodeller for en række virksomhedstyper, fx handel/grossist, detailhandel, produktion, service og projektorienteret og offentlige virksomheder. Fordelen ved at tage udgangspunkt i en generel procesmodel er, at man derved sikrer, at der ikke glemmes processer. Analysen af forretningsprocesser sikrer, at kravene til et nyt it-system kommer til at afspejle de forretningsmæssige behov og ikke bliver styret af fra de teknologiske muligheder. Igennem procesmodellering er det samtidig muligt at fastlægge, hvilke forretningsprocesser som skal understøttes af it-systemet. Når disse forretningsprocesser er identificerede, er det muligt at identificere de unikke krav og behov, som it-systemet skal opfylde. Ved unikke krav forstås forhold, som det vurderes, at et standard it-system ikke omfatter, og som er forretningskritiske for virksomheden. Det er en vigtig fase i projektforløbet, hvor grundlaget for det kommende it-system opbygges. Derfor bør virksomheden involvere såvel medarbejdere med viden om forretningsgange og processammenhænge som de kommende brugere af systemet. Nyt it-system Succes eller fiasko? 15

16 4.2 Trin 2 & 3: Udbudsmateriale og internt vurderingsskema Identifikation af mulige systemer og leverandører Det er vores anbefaling, at virksomheden identificerer og udvælger et begrænset antal systemer og tilhørende leverandører (typisk 3-4 leverandører), da det i praksis ikke er muligt at håndtere et større antal leverandører. Desuden vil den enkelte leverandør sandsynligvis opfatte muligheden for at vinde opgaven som værende meget lille, hvis et større antal leverandører er i spil. Leverandøren kan derfor være tilbøjelig til ikke at lægge tilstrækkeligt arbejde i at udarbejde et virksomhedsrettet løsningsforslag. Vurderingskriterier Der er mange forhold og parametre, som man kan og bør tage i betragtning, når man skal vælge nyt it-system og sandsynligvis også ny leverandør. Hvilke parametre, der er de vigtigste, og som derfor bør vægtes mest, når man skal foretage det endelige valg, er meget afhængig af den enkelte virksomheds situation. Nedenfor gennemgås typisk anvendte vurderingsparametre opdelt i grupper: Selve it-systemet, fx opfyldelse af krav dels generelt, dels gennem standardfunktionalitet, brugergrænseflade, rapporteringsmuligheder og tilhørende fleksibilitet, samt sikkerhed, kontrol og revision Virksomheden bør fokusere på et udvalg af disse områder, som vurderes relevante i den aktuelle situation. Man skal sikre sig, at de vurderingskriterier, som man vælger at benytte, hænger sammen med de informationer, som man beder leverandørerne om at komme med i deres løsningsforslag/tilbud og ved workshops med leverandørerne. Udbudspakke De udvalgte leverandører skal have et grundlag for at kunne udarbejde et løsningsforlag eller tilbud. Dette materiale udbudspakken omfatter typisk formelle juridiske betingelser, program for workshop, hvor leverandøren præsenterer sit løsningsforslag, kravspecifikation og et kontraktudkast. Ud fra dette materiale kan leverandørerne udforme løsningsforslag/tilbud og planlægge og tilrettelægge deres præsentation af løsningsforslaget. Vurderingsskema Ud over udbudspakken skal virksomheden udarbejde et vurderingsskema, som skal anvendes ved de kommende workshops med leverandøren. Disse vurderingsskemaer gør vurderingsprocessen langt mere struktureret, og det er et anvendeligt redskab til at kunne sammenholde vurderingerne af de enkelte leverandører. Vurderingerne kan dermed opsamles ensartet og konsistent fra deltagerne i workshopperne. Den anvendte teknologi i it-systemet, fx systemarkitektur og -design og fremtidige muligheder og udvikling i systemet Leverandøren af it-systemet, fx leverandørens forståelse for virksomheden, stabilitet af produkt og leverandør, personkemi og referencer Leverandørens forslag til implementeringsprojekt, fx aktivitets- og tidsplan, implementeringsmetode, internt ressourceforbrug, konvertering af data, samt itsystemets kapacitet og performance Økonomiforhold ved såvel implementering som drift 16

17 4.3 Trin 4 & 5: Leverandør workshops Når de udvalgte leverandører har udarbejdet og afleveret deres løsningsforslag/tilbud, gennemføres workshops, hvor de præsenterer deres løsningsforslag. Der er tre primære formål med at anvende disse workshops ud over et skriftligt forslag. For det første er det lettere at vurdere systemer ved at se dem end ved at læse om dem. Der kan også være en vis tilbøjelighed hos leverandører til at svare bekræftende på krav. Så er det bedre at lade dem demonstrere, hvordan de vil løse en given arbejdsopgave. Det er vigtigt at understrege, at leverandørerne skal tilrettelægge præsentationen efter et fastlagt program, så det er nemmere for virksomheden at vurdere systemerne og leverandørerne på en sammenlignelig måde. For det andet giver det virksomheden en mulighed for at tale med de personer, som efterfølgende skal gennemføre implementeringen. Derved kan man vurdere deres kompetencer, forståelse for virksomhedens processer, og personkemi. For det tredje giver det de kommende brugere mulighed for at få en fornemmelse af, hvordan mulige it-systemer ser ud og kan anvendes. Det er en fordel, at de medarbejdere, som udviklede de unikke krav og programmet for workshoppen, er repræsenteret, og at et væsentligt antal deltagere er gennemgående ved alle workshops, så de får et helhedsbillede Ud over det relativt objektive vurderingsskema anser Deloitte det som relevant, at deltagerne også foretager mere subjektive vurderinger af de enkelte leverandørworkshops. Efter workshopforløbet kan det være en fordel, at leverandørerne evt. får mulighed for at revidere deres løsningsforslag/tilbud. Der vil ofte være fremkommet oplysninger, som berettiger dette. Fx kan det undervejs i workshopforløbet være blevet klarlagt, at standardfunktionalitet kan løse et givet krav i stedet for en omfattende tilretning, som leverandøren havde beskrevet og inkluderet i sit løsningsforslag/tilbud. 4.4 Trin 6: Evaluering og indstilling På baggrund af de forudgående trin er det nu muligt at evaluere systemerne og leverandørerne ud fra de objektive vurderingsskemaer og subjektive indtryk fra de enkelte workshops i henhold til de opstillede evalueringskriterier. Dette kan gøres på mange forskellige måder. Fx med vægtning af de enkelte områder i form af en prioritet fra 1 til 10. På den måde kan man tillægge de væsentlige områder større vægt i den samlede sum, dels kan man minimere udfaldet af, at en workshopdeltager favoriserer en bestemt leverandør. De subjektive indtryk, vurderinger, personkemi, mavefornemmelser m.v. skal absolut også tages i betragtning. Nyt it-system Succes eller fiasko? 17

18 Der er imidlertid vigtigt at understrege, at valg af itsystemer ikke kan foretages alene ved ren matematik ud fra en opnået pointsum. De subjektive indtryk, vurderinger, personkemi, mavefornemmelser m.v. skal absolut også tages i betragtning. På baggrund af denne evaluering er det en fordel at udvælge to leverandører en foretrukken og en alternativ som virksomheden indgår i en afklaringsfase med. Man bør ikke straks kun fokusere på én leverandør, men af taktiske grunde holde forbindelsen varm til to leverandører. 4.5 Afklaringsfase Inden der indgås aftale mellem virksomhed og leverandør om det samlede implementeringsprojekt kan det være en fordel at gennemføre en afklaringsfase, hvor leverandør og virksomhed sammen gennemgår virksomhedskrav/behov og leverandørens løsningsforslag. Med en sådan afklaringsfase opnås et fælles mere præcist og korrekt grundlag for aftalen, fx om der skal anvendes fast pris eller efter timesats. Afklaringsfasen omfatter uddybning af de krav, som virksomheden har beskrevet i udbudsmaterialet, og det tilbud/løsningsbeskrivelse, som leverandøren har udarbejdet, med efterfølgende afstemning af krav med muligheder og begrænsninger i det valgte it-system. Det er også væsentligt i fællesskab at beskrive, afstemme og planlægge den efterfølgende implementeringsproces, med alt hvad den indeholder. Det er en god ide at dokumentere denne afklaringsfase med opdaterede løsningsbeskrivelse med bl.a. systemskitse(r), herunder væsentlige opsætningsmæssige beslutninger, væsentlige tilretninger i form af designspecifikation og håndtering af integration til andre systemer i form af designspecifikation. Det kan også anbefales at dokumentere datakonvertering og dataetablering, krav til it-infrastruktur, detaljeret tids-/aktivitetsplan, leverancer undervejs i forløbet, projektorganisation med roller og ansvar, projektprocedurer, fx statusrapportering, ændringshåndtering, projektmøder, og opdateret økonomisk overblik frem til driftsstart inkl. støtte til driftsstart (projektbudget). 18

19 5. Kontraktforhandling 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 it-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 kan man med fordel 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å kontraktoplægget i udbudsmaterialet bliver udformet mest hensigtsmæssigt ud fra de konkrete, individuelle forhold, hvad enten den udarbejdes helt fra grunden eller baseres på en allerede udarbejdet standardkontrakt, fx 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. Kontraktforhandlingen afslutter anskaffelsesprojektet som illustreret i figur 5. De efterfølgende kapitler 6-9 vil dermed omhandle implementeringsprojektet. Kontrakten er det juridiske grundlag og fundament for projektet, som kan anvendes til at afgøre tvister og bilægge uenighed. Nyt it-system Succes eller fiasko? 19

20 6. Etablering af implementeringsprojektet Dette kapitel vil omhandle det første trin i den egentlige implementering af det nye it-system. Ved etablering af implementeringsprojektet er der en lang række faktorer, som har indflydelse på, om implementeringen bliver en succes eller ej. Dette kapitel handler om en række af de faktorer, som vi i Deloitte har oplevet som kritiske faktorer for at opnå et vellykket implementeringsprojekt. De efterfølgende kapitler, 7-10, behandler specifikke forhold i selve implementeringsprojektet, fx specifikation, design, udvikling, opsætning, test, konvertering, driftsstart, og perioden efter driftsstart. 6.1 Opnå opbakning Man får ikke en succesfuld implementering, hvis der ikke er opbakning til projektet og det nye system i organisationen. Det er derfor vigtigt, at man fra projektets start sørge for at informere organisationen om de kommende forandringer. Desuden er det essentielt, at ledelsen på en synlig måde involverer sig i og bakker op om det nye it-system. En effektiv måde at sikre opbakning i organisationen på er at involvere medarbejderne i det forestående projekt. Det giver en følelse af ejerskab og medindflydelse, som kan forebygge den ellers naturlige mistro og skepsis over for forandringer. Denne involvering bør begynde allerede ved valg og anskaffelse af det nye it-system. 6.2 Fastlægge succeskriterier Det er en fordel at have målbare succeskriterier for det kommende it-implementeringsprojekt, som kan anvendes undervejs i projektet for at vise, at man er på rette vej. Succeskriterierne bør på dette tidspunkt allerede være fastlagt i den udarbejdede business case. Det er vigtigt, at disse mål bliver kommunikeret ud til hele projektorganisationen og også gerne bredt til alle medarbejdere i virksomheden. 6.3 Sammensætte og sammentømre det rette projektteam Denne faktor har stor indflydelse på forløbet i implementeringsprojektet, da den kan være kilden til et hurtigt og effektivt projektforløb, hvis den håndteres hensigtsmæssigt. Det er af stor betydning, at man vælger de bedst kvalificerede til opgaven, da it-systemet sandsynligvis skal anvendes i virksomheden i flere år. Dermed er det så også vigtigt, at virksomheden sørger for at aflaste medarbejderne, så disse personer reelt får mulighed for at deltage i projektet. Kerneprojektgruppen skal være tæt på 100% allokeret til implementeringsprojektet. Kun på denne måde opnås den nødvendige kontinuitet i arbejdet med at designe systemet (designfasen). En anden måde at sikre kvalitet i implementeringen er at uddanne projekttemaet i det aktuelle it-system på et tidligt tidspunkt i implementeringsforløbet. På den måde får projektdeltagerne indsigt i, hvad systemet kan, hvordan det fungerer og hvilke muligheder der er i standardfunktionerne. Ofte viser det sig, at det reelle behov bag formulerede krav kan løses via standardfunktionalitet. God kommunikation kan forebygge og afhjælpe flere typer problemer, som forhindrer det hurtige og effektive projektforløb. Derfor kan man med fordel lave aktiviteter med det formål at sammentømre projektteamet og opbygge team spirit. For at få en høj grad af fællesskabsfølelse mellem virksomhed og leverandør kan man lade projektdeltagere fra leverandøren deltage i aktiviteterne. Der kan let opstå de og vi -holdninger i et implementeringsprojekt med udsagn og opfattelser som nu kan vi igen ikke komme videre, fordi de ikke har leveret, som de havde lovet 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 i samme lokale og med fælles input. Dette minimerer samtidigt den skriftelige kommunikation, som let kan skabe misforståelser mellem fysisk adskilte parter. 20