Vi ved vist alle at man kan købe et system til f.eks. økonomistyring til få hundrede kroner og i løbet af kort tid er den lille håndværker kørende og har styr på firmaets økonomi. På den anden side er der ERP programmer til globale koncerner der kræver års arbejde og et budget på ni cifre. Kompleksiteten i de to scenarier er åbenlyst forskellig og jeg vil her komme med et forslag til en simpel model der kan hjælpe til at strukturere vurderingen af kompleksiteten.

Når man taler om kompleksitet så taler man også om risiko. Høj kompleksitet giver typisk høj risiko for overskridelse af projektets plan og budget – i den yderste konsekvens kan risikoen være af en kaliber så man ikke bør binde an med projektet, eller projektet skal stoppes hvis man opdager det for sent. Men i alle tilfælde er det vigtigt at forholde sig til risikoen – vurdere og analysere kompleksiteten før projektet etableres og sættes i søen. Måske skal projektet skæres til på en anden måde for at opnå en fornuftig håndtering af risikoen. Når først projektet kører tæller taxametret for alvor og prisen for at stoppe og gen-planlægge bliver høj. Der er naturligvis andre faktorer der spiller ind ved projektetableringen – f.eks. projektets business case eller match til virksomhedens strategi – alle vigtige overvejelser der afgør hvordan et projekt skal skæres til.

Men hvis vi for et øjeblik fokusere på kompleksiteten så er min påstand, at der er tre faktorer der er afgørende for et ERP-projekts kompleksitet – og det er:

  • Procesbredde
  • Funktionel dybde
  • Lokationsvariation

Procesbredden dækker over, hvor meget af forretningen der bliver ”ramt” mere eller mindre samtidigt af implementeringen. Er det et snævert scope, hvor det f.eks. udelukkende finansprocesserne der skal understøttes, eller er det ”kun” et nyt CRM system. Disse scenarier giver mulighed for fokus, målet er klart og inden for rækkevidde.  I den anden ende af skalaen finder vi projekter der går efter at understøtte væg-til-væg processerne i virksomheden – lige fra økonomi, HR, løn, logistik, produktion, CRM m.v. I disse tilfælde stiger kompleksiteten mht. procesbredden naturligvis. Det bliver mere vanskeligt at gennemføre, idet projektet skal kunne håndtere en dialog med forretningen på ganske mange områder der interagerer på forskellige vis – hvis vi ændre et sted påvirkes et andet sted – måske opstår der et ”waiting game” fordi den ene beslutningstager er afhængig af beslutningerne andre steder i forretningen. Der opstår ressourcemæssige flaskehalse. Der åbnes også for en organisatorisk change management opgave som kan være ganske omfattende og udfordrende.

Den funktionelle dybde spænder over den kompleksitet du møder i forbindelse med de enkelte moduler eller procesområder af et ERP-system. Der kan være procesområder der kan understøttes af simple standardprocesser der kan etableres forholdsvis hurtigt. Men hvis du f.eks. skal implementere en produktkonfigurator kan dette være ganske komplekst, du skal naturligvis først have styr over de enkelte komponenter, dernæst gyldige kombinationer og sekvenser. Der er med andre ord et omfattende analysearbejde før dette modul kan konfigureres for ikke at snakke om al den masterdata der skal være på plads. Typisk påvirkes den funktionelle dybde også af tilretninger, udvidelser eller interfaces til andre systemer som giver kompleksiteten vokseværk. Et andet element der kan give hovedbrud her, er hvordan det nye system skal erstatte det gamle på et måde så der er kontinuitet i forretningen. Ofte er projektets fokus de nye processer og tilhørende løsning, men succesen er først hjemme når man også kan gennemføre transitionen fra det gamle til det nye.

Lokationsvariation er udtryk for den kompleksitet man møder i forbindelse med de lokationer, hvor ERP-systemet skal implementeres. Typisk er der tale forskellige selskaber på forskellige geografiske lokationer. Er det blot en lokation eller er det en global koncern hvor systemet skal implementeres i mange selskaber, i mange lande? Er der tale om ensartende lokationer der har karakter af samme organisatoriske og forretningsmæssige set up bare gentaget på f.eks. forskellige lande? Eller er virksomheden skabt gennem opkøb og står med forskellige processer der skal erstattes af nye fælles processer og system. Sidste nævnte scenarie høre til i den høje ende af kompleksitetsskalaen og giver anledning til overvejelser omkring, hvordan det skal gribes an – dvs. skal vi starte med en lokation og få det til at virke og så gå videre til den næste lokation, eller skal man etablere en global løsning med fælles processer først, for dernæst at gå i gang med udrulning i forretningen.

Hvis vi ser på disse faktorer i kombination tegner der sig et billede af, hvordan de hyper-komplekse projekter opstår. Vi tager væg-til-væg processerne, forsøger at implementere de nye processer og tilhørende system i en global organisation med fragmenterede selvstyrende enheder. Systemet skal erstatte et kludetæppe af gamle systemer og samtidigt skal der optimeres på nogle funktionelle områder som ligger i hjertet af virksomhedens produkter eller services. Som jeg nævnte ovenfor så drejer det sig om at analysere og vurdere kompleksiteten og aktivt benytte dette ved projektetableringen. Det er jo – som altid – lettest at styre når man har en idé om vejen forude.