Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
It-projekter er svære og komplicerede.
Især kompleksiteten tager til, når man ser på for eksempel nyere ERP-systemer, hvor mange moduler og funktioner er indbygget i motoren.
En cloud-verden, hvor vi arbejder i en webbrowser samt tvungne opdateringer, gør, at vi internt skal tænke på en helt anden måde end for bare fem år siden, når vi skal implementere it-projekter.
Derfor har jeg sammensat nogle ingredienser, der kan give inspiration og hjælpe med, at opskriften også bliver til et ”spiseligt it-projekt."
Ressourceallokering
Hvis man tager et ERP-projekt, og ERP-leverandøren estimerer for eksempel 1.000 udviklingstimer, så er tendensen, at man internt skal køre med 1:1, altså 1.000 timer internt.
Mange virksomheder synes allerede, at det lyder voldsomt – men man skal nærmere gange med 1,5 på grund af følgende:
- At vænne sig til nye systemer (skærmbilleder, andre feltnavne og det at arbejde i en webbrowser) er store forandringer, selv for rutinerede it-brugere.
- Opbygge egne dashboards og skærmbilleder. Det lyder både smart og er smart – men kan den enkelte bruger gennemskue, hvilke lister og menupunkter der er behov for?
- Når man arbejder i cloud-systemer, er fleksibiliteten til at kode ændringer mindre, og dermed bliver en række arbejdsprocesser anderledes. Den manglende fleksibilitet kan skabe en masse interne diskussioner, fordi tingene ikke ligner ”plejer”.
Disse faktorer gør, at det ikke er nok bare at lave en overlevering til en bruger og så regne med, at de selv kan teste den i mål og godkende.
Belært af erfaring, skal man nærmere gange med 1,5, da det er meget sværere at komme midt i et projekt og bede om flere ressourcer hos nøglepersoner.
Typer af folk vi skal bruge
Normalt siger man, at man skal have nogle procesejere og superbrugere i sin projektgruppe – men jeg vil gerne introducere et par nye begreber.
1) Procesfolk, der kan gå på tværs mellem processer og afdelinger
Mange processer i en produktionsvirksomhed går på tværs af afdelinger, og ofte ender vi i silotankegangen, at jeg passer min del af butikken, og hvad der sker bagefter i processen interesserer mig ikke.
I udviklingen af et nyt it-system skal man have nysgerrige interne procesfolk. Kendetegnene for disse folk er:
- De kender hele en given proces, for eksempel vareoprettelse, og har forståelse for, at for eksempel vægt, intrastat-koder eller andet er vigtige at få udfyldt, inden man frigiver et produkt.
De kan gennemskue de interne processer, især hvis man vil lave en proces om-
2) Personer, der kan deltage i abstraktionstest
Vi hører ofte, at vi vil køre standard – men for at gennemskue, om man kan det, har man brug for personer, der kan deltage i abstraktionstest.
En abstraktionstest er en test, hvor ERP-leverandøren for eksempel viser, hvordan en salgsordre oprettes i det nye system. Der er ikke udviklet noget endnu (knapper, felter).
I en abstraktionstest skal disse typer hurtigt kunne gennemskue, om man kan leve med standard, eller om man skal bygge tilpasninger på.
Ofte bruger man en masse tid på et whiteboard – men min erfaring er, at det giver meget mere at komme ind og se systemer, inden man beslutter, om man vil overføre sine nuværende processer 1:1 eller kan leve med standard.
Disse interne folk med evner til abstraktionstest er vitale, hvis man vil holde sig mere til standard end det system, man har for nuværende, ”der måske er kodet ihjel”.
3) 'Blå' personer
I nyere systemer findes task recorder og simple optagelser med en mobiltelefon, og upload af en instruktion på et Teams-site fungerer også.
Så det at dokumentere test og lave instruktioner er blevet lettere – MEN:
At udføre grundige tests kræver, at man har en overvægt af ”blå personer” i DISC-profil i sin projektgruppe.
Blå personer er detaljeorienterede og strukturerede og tester gerne mange gange for at sikre, at alle funktioner virker.
De har det simpelthen ikke godt med kun at teste et delelement og sige: ”Jeg tror, det virker.”
Derfor skal man, når man skal i gang med at teste, have en stor del af ”blå personer”, ellers vil man efter go-live rende ind i en masse tilbageløb, fordi man glemte at teste nogle arbejdsprocesser.
Udarbejdelse af testcases er kedeligt for mange – men gode testcases inden test og dialog med superbrugeren om, hvorvidt det dækker deres hverdag og de processer, de arbejder med digitalt, er en grundsten.
Tag for eksempel de seneste 10 salgsordrer fra det gamle system, tast dem ind i det nye system og se, om det virker, eller opret en vare og se, om du både kan producere den, lægge den på lager, sælge den og lave en forsendelse.
Gode råd:
- Vær opmærksom på din egen estimering af interne ressourcer og vær hellere konservativ end for optimistisk.
- Kortlæg, om du både har nok interne procesfolk og folk, der kan deltage i abstraktionstest.
- Afklar, om vi har blå personer nok til test.
- Overvej, hvordan vi smartest laver testdokumentationen, så den også efter go-live er opdateret.
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.
