Denne klumme er et debatindlæg og er alene udtryk for forfatternes synspunkter.
At ERP projekter ofte ikke helt går som forventet er noget, som de fleste vil nikke genkendende til.
ERP projekter er ofte langstrakte komplekse projekter med mange deltagere fra forretning, it og eksterne samarbejdspartnere.
På trods af allokering af de bedste folk og den vedvarende fokus, er der alligevel stor risiko for ikke at lykkes.
Spørgsmålet er, hvordan man som forretning undgår at bruge et enormt ressourcetræk på noget, som ikke lykkedes?
Først og fremmest er kursen afgørende.
Den første tid i projektet, fra udarbejdelse af den indledende analyse til det egentlige udviklingsprojekt, vil tegne banen for, hvor godt projektet formår at kunne lykkedes.
Og det er ikke ligetil. Der er enormt mange parametre, der skal tages i betragtning, før man kan vide sig sikker på, at man kommer godt fra land.
Store beslutninger skal træffes på et oplyst grundlag
I forarbejdet op til et projekt, vil der nærmest altid være pågået en analyse med henblik på at afklare hvilken funktionalitet, der er behov for.
I denne analyse vil specialister fra forretningen sammen med systemkonsulenter, gennemgå hvilke procesområder, der skal afdækkes, samt hvilken ændringer disse processer vil medføre til et standard ERP system.
Analysen vil også skulle omfatte omkringliggende systemer og integrationer.
På baggrund af dette vil der kunne udarbejdes et løsningsoplæg samt etableres både en projektplan og et budget.
Der vil samtidig også præsenteres en projektmodel, der skal tilsikre, at udviklingerne sker i henhold til det aftalte, hvor partnernes forskellige roller vil være defineret.
Men her går det galt
Tilfældet er dog, at oplægget i nærmest alle tilfælde vil være for snævert defineret, og det vil ikke afspejle alle de scenarier, der skal kunne håndteres i et fremadrettet system.
Konsekvensen vil være, at et projekt opstartes med et forfejlet budget og en forfejlet tidsplan.
Man kan spørge sig selv, hvorledes det kan være, at yderst professionelle folk gang på gang kan ende i samme situation.
Der er mange grunde, der vil føre en ned af denne vel. Generelt er tilfældet, at en virksomhed sjældent vil have tilstrækkelig systemforståelse til at få udfordret en implementeringspartner.
Konsulenthuset derimod vil have svært ved at danne sig et komplet billede af den nødvendige systemunderstøttelse, så analysen tænkes ud fra det repræsenterede system.
Hermed er grundlaget skabt for en kommunikation præget af manglende viden, forståelse og kvalitet.
Skibet er sejlet
Kort tid efter opstart vil projektet blive ramt af ændringsanmodninger.
Dialogen om, hvorledes det kan være, at man ikke kan holde budgettet og udviklingerne, vil begynde.
Implementeringspartneren fra det valgte systemhus vil påberåbe sig, at der efterspørges ændringer, der ikke har været nævnt tidligere.
Forretningen vil plædere for, at de i god tro havde en forventning om, at analyse og implementeringsmodellen ville have taget højde for en tilstrækkelig analyse af behovet.
Men skibet er sejlet. Man skal i mål, hvorfor man oftest blot fortsætter og nødtvunget accepterer, at udgangspunktet har ændret sig.
Projektet blev ikke opstartet på et tilstrækkeligt oplyst grundlag, men det er for sent at hive i bremsen.
Når ovenstående sker, må virksomheder i de fleste tilfælde affinde sig i at leve med betydelige begrænsninger eller allokere yderligere budget til uhensigtsmæssige tilpasninger.
Det kan ligeledes afføde medarbejdere til at finde supplerende løsninger til at lukke huller imellem proces- og systemlandskabet.
I yderste konsekvens kan det efter nogle år ende med en re-implementering af den valgte ERP løsning eller en implementering af en ny ERP løsning.
Spørgsmålet er, hvorledes opnår man et oplyst grundlag?
1. Foranalyse
Udgangspunktet må være, at man på struktureret vis får etableret et billede af forretningsmodel og processer. Dokumentationen heraf skal som minimum indikere, hvilke processer og scenarier der håndteres i dag, så disse vil blive tænkt ind i scope for en fremadrettet løsning.
Et andet ben af analysen vil bestå af en gennemgang af, hvorledes vedligeholdelse og ændringer af stamdata orkestreres. Et fremtidigt skifte af ERP system vil ubetinget medføre, at stamdata skal renses, beriges og ændres for at kunne integreres på fornuftig vis.
Det er også i foranalysen, at der foretages en evaluering af mulige projektressourcer og fremadrettet forventning til eksekvering af projektet.
Afhængigt af det rette match af projektorganisation og -model, vil det være muligt at tilgodese, hvorledes den resterende del af virksomheden bør inkluderes i projektet, for at sikre en samhørighed mellem hvad der operationelt sker i virksomheden, samt hvad fremtiden vil bringe.
Disse tiltag bør i stor udstrækning foretages, før en eventuel implementeringspartner fra et systemhus bringes i spil. Dette for at sikre, at virksomheden er afstemt og afklaret, inden man bevæger sig for hurtigt ind i den endelige afklaring omkring, hvorledes systemet bør ændres.
2. Valg af system og partner
Det kan være nærliggende at fortsætte med en eksisterende samarbejdspartner. Der vil ofte være opbygget en relation indeholdende god forståelse for hinandens kompetencer og forretning.
I mange tilfælde vil det kunne ende ud med et valg om, at den eksisterende partner fortsætter samarbejdet.
Når et ERP system skal udskiftes, bør man benytte muligheden for at sikre, at det stadig er den korrekte konstellation, man arbejder ud fra.
I forsøget på at belyse hvilken løsning der er den bedste, vil det derfor være en fordel, at få bragt forskellige muligheder i spil, der herved vil kunne fange eventuelle mangler herimellem.
Den generelle anbefaling vil ligeledes være, at man inden en endelig evaluering af samarbejdspartner får adresseret, hvilke kompetencer og egenskaber, der ønskes prioriteret.
I nogle tilfælde kan det være en fordel at finde en partner med tilstrækkeligt branchekendskab. Andre gange vil det være mere relevant, at der er en overvægt af kompetencer indenfor et specifikt funktionsområde eller teknologi.
3. Solution Modelling
Det næste logiske skridt vil være en løsningsmodellering, hvor man sammen med den udvalgte partner, beskriver, hvorledes processer skal modelleres, samt hvilke ændringer dette medfører til et givent system.
Dette muliggør etablering af et overblik over fremtidige processer, samt hvorledes disse skal systemunderstøttes.
Samtidig vil der være en evaluering af hvilken systemunderstøttelse, som kræver udvikling.
Hermed er det også det naturlige tidspunkt for at afklare det endelige budget for projektet samt foretage den sidste forhandling med en samarbejdspartner, inden udviklingen i projektet opstartes.
Det handler i høj grad om at få skabt et fælles billede af, hvad løsningen er, samt at være i stand til at gøre denne tilpas eksplicit til, at andre medarbejdere i virksomheden kan få et tilfredsstillende billede af, hvad målet er.
Efter denne fase er retningen for projektet mere eller mindre sat, og eventuelt ændringer hertil bliver markant vanskeligere.
4. Hold momentum, når projektet skal skifte gear
Slutteligt er det værd at bemærke, at tempoet kan dale i et projekt, uden at det umiddelbart observeres.
Alle projektdeltagere arbejder egentligt dedikeret, men de opgaver, der var tiltænkt løst, bliver ikke løst.
Denne udfordring opstår ofte ved fase-skift i et projekt. Når et projekt afslutter en solution modelling-fase og overgår til build, vil opgavetyperne ændre sig.
De processer som har været abstrakte tanker, skal nu omgøres til reelle eksekverbare løsninger i et system.
Som projektleder skal man tænke langsigtet, og det skal man også mellem de forskellige faser. Projektdeltagere skal forberedes på kommende opgaver i god tid, og de skal hjælpes til at kunne lykkedes med deres opgaver.
Kort sagt
At sikre en succesfuld ERP-rejse starter med en grundig forberedelse, og nedenstående investeringer betaler sig meget hurtigt tilbage.
- Få bragt de rigtige kompetencer ombord, allerede inden projektet egentligt startes.
- Tegn, før du bygger.
- Få skabt overblik over processer som skal modelleres og systemer, der skal tilpasses, inden kontrakten med implementeringspartneren indgås, og implementering opstartes.”
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.