Ovenstående kommentar møder jeg tit når jeg diskuterer kundens egen bemanding af et ERP implementeringsprojekt. Og mit svar er på bedste konsulent vis ”It depends”. Der findes ikke en bestemt sandhed, men gennem mange forskellige ERP projekter fra simple implementeringer af en standard regnskabsløsning til fuldt dækkende løsninger, så er der en ting jeg har lært. Hvis involveringen undervurderes ender kunden op med en løsning, som den valgte leverandør har tænkt var passende for kunden.

Uanset om kunden og leverandøren mener løsningen er velbeskrevet i kontrakten og dens bilag – så er der meget der er åben for fortolkning – og er du som kunde ikke engageret i denne fortolkning   – så bliver det leverandørens fortolkning der bliver gældende. Det skaber ikke altid tilfredshed med løsningen.

Jeg arbejder ofte som kundens projektleder – så jeg synes jo helt klar at det er en meget vigtig opgave i projektet at sikre at sikre kunden forstår hvad leverandøren mener når de forklarer, hvad en leverance indeholder. I min rolle bringer jeg ofte noget erfaring ind hos kunden, som kunden ikke besidder selv. Medmindre kunden er en så stor en virksomhed, at der stort set altid er gang i flere IT-system implementeringer.

Kundens projektleder er med til at sikre at leverandøren lever op til sine forpligtigelser, men så sandelig også at kunden lever op til sine forpligtigelser.

 


For nogle uger siden skrev jeg også et blog indlæg vedrørende ressourcer i projektet. Her behandlede jeg bemanding af projektet i forbindelse med kontraktindgåelse.

I det indlæg kan du også læse om, hvordan der skal være opmærksomhed på om tilbuddene faktisk har medtaget en korrekt bemanding for kunden samt om den bemanding der er medtaget virker undervurderet.

Indlægget kan stadig læses på ERP.DK

 


 

Udover projektledelse er følgende områder punkter kunden skal være opmærksomme på at bemande:

  • Funktionel anvendelse – Beslutninger omkring konfiguration
  • Proces – Design af processer og arbejdsgange der skal matche det nye system
  • Forandringsledelse – Klargøring af organisationen til at tage i mod alle forandringerne
  • Migrering af data – Hvilke data, udtræk, vask og afstemning af data konvertering
  • Test – Udførelse af test omkring det nye system (evt. overtagelsesprøve)
  • Uddannelse – Uddannelse af medarbejderne i det nye system så de er klar ved idriftsættelse
  • Teknik og infrastruktur – Afvikling af den nye løsning

Forskellige implementeringer kræver forskellig indsats fra kunden. Så kunde A skal ikke nødvendigvis bruge samme kombination af ressourcer, som kunde B.

 

Er ansættelse af nye medarbejdere ikke bare løsningen

Bemandingen af projektet kan ikke på alle områder løses ved at ansætte nye medarbejdere. På nogle punkter skal projektdeltagerne have stor indsigt i den nuværende forretning og forstå hvad virksomheden gerne vil opnå med projektet. Hvilke fordele (benefits) skal projektet/løsningen give. Det er sjældent at man bare skifter for at skifte. På samme måde kræver det god indsigt i datastrukturen i det gamle system (eller systemer) for at kunne udtrække data og vaske data. Man kan måske købe den kompetencen om at kode udtræk, men ikke viden om at man anvender et bestemt felt på en bestemt måde i det system der står foran en udskiftning.

Så noget kan løses gennem ansættelse eller konsulentbistand, men ikke det hele.

 

Planlæg ressourcetrækket

Det bliver nemmere at overskue de ressourcer der skal frigøres fra basis organisationen når men ser frem i tiden. Som en tidlig øvelse er det min anbefaling man får set på det ressourcer/kompetencer der skal indgå i projektet. Få sat navne på og hvornår og hvor meget den enkelte skal bidrage med.

Det er meget nemmere at frigøre en medarbejder, hvis det er planlagt måneder i forvejen fremfor, hvis man skal trække en medarbejder væk fra sit daglige arbejde med kort varsel.

Så har lederne mulighed for at fordele eller tilrettelægge arbejdet omkring medarbejderens deltagelse i projektet på en god og ordentlig måde.

 

Alle vil gerne være involveret – men skal de det

Implementering af et nyt ERP-system er ofte en ændring der påvirker store dele af virksomheden. Jeg oplever ofte at mange gerne vil være med på det nye system og gøre deres del. De fleste medarbejdere er jo spændte på hvordan det nye bliver. Typisk vil alle ikke blive involveret. Rigtig mange vil være tilbage i basis-organisationen og arbejder måske ekstra for at løse opgaver for kollegaerne, der er med i projektet. Det er vigtigt at holde hele organisationen orienteret omkring, hvor man er på vej hen. Det kan gøres gennem forskellige former for kommunikation fra projektet. Er det muligt så op på ølkassen og fortæl om, hvad der sker på firma-møder, afdelingsmøder osv. Sørg også for information på intranet og nyhedsbreve – så er alle jo lidt involveret.

 

Idriftsættelse og hvad så?

Op til idriftsættelsen syder organisationen. Mange er involveret i at lukke gamle systemer ned, gennemførelse af overtagelses prøve, uddannelse af medarbejdere, afstemning af migrerede data bare lige for at nævne nogle af de aktiviteter der er lige op til idriftsættelsen. Er der tale om en big bang implementering sker skiftet pludseligt og så kan projektet jo lukke ned og alle går hjem og lever lykkeligt med deres nye system.  Det er vel sådan de fleste tænker. Men nej sådan går det sjældent. Den første tid efter idriftsættelsen vil der ofte være ekstra mange opgaver, hvor man bliver overrasket over noget ikke helt fungerer som man troede eller ligefrem er fejlbehæftet. Denne periode skal bemandes. Efter nogen tid, og det kan variere, begynder dagligdagen efter projektet.

Virksomheden skal så have styr på, hvordan man ønsker at vedligeholde den implementerede løsning. Skal man selv eller skal man købe ude i byen. Mon ikke der også der kunne skrives lille klumme omkring hvordan bemanding og rammen kunne være for at vedligeholde sine systemer – og jo man kan jo bare sige på bedste konsulent vis ”it depends”.