Artikel top billede

Derfor skal du spise dit it-projekt i små bidder

Klumme: Mange it-projekter bliver forsinkede, fordyrede og for meget. Her har du en række punkter til et nyt fokus, som vil hæve succesraten for it-projekterne markant.

Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.

Ofte hører vi om it-projekter, der er blevet forsinket, dyrere og ikke den løsning, som man egentlig havde tænkt sig. Men hvad går galt?

Vil kunden for meget eller er leverandøren ikke god nok til at forstå jeres forretning eller er det en kombination?

Der er mange årsager, men her er nogle punkter, som jeg vil anbefale, at I arbejder videre med for at minimere risikoen, så it-projektet kan spises i små bidder.

Tegn processen op først

Agile processer- og projektmodeller er fint – men pas nu på med at komme i gang for tidligt med at programmere.

Det lyder omstændigt, at alle processer skal tegnes op først med de nuværende processer, fremtidig processer samt opstille ønskede KPI for hvert flow.

Vi kender jo vores processer hører man ofte. Ja - men er processerne tænkt ind med nye digitaliseringsmuligheder? Hvordan er vi stillet, hvis vi køber en anden virksomhed, der skal på samme it-platform?

Her kræver det også mod fra ERP-leverandøren at sige til virksomheden, at I mangler at afklare det område, før vi starter programmeringsmaskinen op. Tro mig: Et godt dokumenteret forarbejde sparer masser af tid bagefter, når vi for alvor skal i gang.

Hvad er mest tidskrævende i jeres it-projekt?

Man er selvfølgelig nødt til at have dialog med it-leverandørerne omkring deres forventede tidsforbrug og hvornår, de kan gå i gang.

Men ofte undervurderer vi vores egne ressourcer: At dokumentere, designe, afklare og opnå enighed kræver mange ressourcer.

De mest komplekse processer, der involverer leveringstiden ud til slutkunden, vil typisk tage lang tid, fordi diskussioner opstår om, hvor meget skal ligge på lager kontra hvor hurtigt vi ønsker levering til slutkunden. Det er en naturlig konflikt.

Hvad er kritisk vej og afhængigheder

Et ERP-projekt består måske af 50 flows, der skal flettes sammen.

Man er nødt til at begynde med at liste de flows, der er mest kritiske. Det kunne være produktionsflowet eller salgsflowet.

Når man har fået prioriteret disse flows, får man det første overblik. Nu ved vi, hvor vi skal begynde.

Det næste, der skal gøres, er at tegne afhængigheder. Det vil sige: Er der nogle flows, som vi ikke kan sætte i gang, før andre er designet og dokumenteret.

Eksempelvis kan vi ikke lave alle dokumenter (faktura, følgeseddel, plukliste), før flowet er på plads og vi ved hvilke felter, vi skal have vist. Et andet eksempel er, at indkøbsprocesserne typisk venter på produktionsflowet, så vi ved, hvornår vil vi producere kontra købe ind.

Hvilke ressourcer trækker I på?

Tordenskjolds soldater hører vi ofte og selvfølgelig har vi personer, der ved en masse om vores forretning.

Men måske er en ERP-implementering chancen for at bryde det mønster. Måske har vi folk, der har procesforståelse og tør tænke forandringer og som ser mulighederne. Tordenskjolds soldater kan jo være groet fast i den gamle løsning og måske oplever de, at noget af deres magt forsvinder ved en ny løsning?

Og når vi skal i gang med det omfattende testarbejde hvem er så de rette ressourcer, da en god procesmand nødvendigvis ikke er detaljeret nok i sit mind-set til at teste alle scenarier.

Hvem træffer de endelige beslutninger?

Der er mange projektmodeller, når man implementerer eksempelvis ERP.

Enten har man en projektleder med eksperter for hver flow inden for indkøb, salg og produktion. Hver person ved en masse om sin egen proces, men er ikke nødvendigvis ekspert i et samlet indkøbsflow.

Alternativet er, at man nedsætter en samlet projektgruppe på for eksempel seks-otte personer, der gennemgår alle processer. De er nødvendigvis ikke eksperter i salg, men kan så sparre med sælgere og salgsassistenter,

Erfaringerne viser, at kan man og tør man nedsætte en samlet projektgruppe, så vil man opleve en langt hurtigere implementering og få en løsning, der har fokus på det samlede flow.

Vi skal ville folk, der tør sætte fingrene på kogepladen og tør tage det ansvar, der følger med.

Derfor husk:

- At tegne og dokumentere processen før og at sikre, at alle mand er med, inden I går i gang med programmeringen.

- At vurdere, hvad der er mest tidskrævende i projektet - især processer ud mod slutkunden kræver ekstra fokus.

- At kritisk vej og afhængigheder er nøglen til at få brudt projektet ned i spiselige klumper.

- Hvem sætter hånden på kogepladen og står til mål for løsningen?

- Sammensæt din projektgruppe efter det, der er bedst for din virksomhed og ikke efter Tordenskjolds soldater.

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.