10 tips for å flytte ERP til skyen

1. Kravspesifikasjoner

En god kravspesifikasjon resulterer i et prosjekt som leveres til rett tid og innenfor budsjett.
Den sikrer en grundig gjennomgang av behovene. Samtidig bør den ikke være for detaljert, slik at prosjektet låses og muligheten til å ta inn nye erfaringer underveis, ny teknologi og bedre løsninger begrenses.

Tabellaes erfaring er at i prosjekter som går veldig bra, har det vært en dialog om hva som faktisk trengs. I prosjekter som har gått mindre bra, har mange hatt en svært detaljert kravspesifikasjon – men den har vært for rigid.

Vær åpen for endringer

Hele arbeidet med kravspesifikasjon er svært viktig å tenke nøye gjennom. Men hvis det er for mange krav, ser vi ofte at det fører til lite fleksible prosjekter. Hvis du heller ikke kjenner alle kravene dine fullt ut, bør du heller ikke låse kravspesifikasjonen. Du vil alltid lære mer underveis – spesielt gjennom dialog med eksperter som har gjort dette før.

ERP-konsulent Mette Ohmsen forklarer:

«Det er altfor mye fokus på funksjonelle krav og for lite fokus på alt det andre som også er viktig for prosjektopplevelsen og driften. Det er først når dere går live at det hele egentlig begynner. Derfor bør dere tidlig i prosjektet fokusere på drift, dokumenter og andre områder som IT-revisjon og sikkerhet. Og hvis dere skal jobbe med en kravspesifikasjon, må det gjøres på et så godt informert grunnlag som mulig – og det gjør dere ved å hente inn rådgivere som kan støtte dere i dette.»

2. Unngå 1:1-oppgraderinger

Noen ganger møter vi kunder som sier:
«Vi trenger bare det samme som sist – vi trenger det bare i skyen. Det må være slik, fordi vi vil at det skal være billig, raskt å implementere, og vi ønsker ingen overraskelser siden vi leverer kritiske varer.»

Ikke bestem løsningen på forhånd

Dette anbefaler ikke Tabellae. En 1:1-oppgradering er ofte en løsning man har bestemt seg for på forhånd. Den gir ingen reelle forretningsmessige gevinster og fører ofte til en (for) lav pris, som igjen kan resultere i feil løsning og feil leverandør for dine behov.

Velger du en 1:1-oppgradering, vil virksomheten ofte ikke være fornøyd med resultatet, fordi teknologien utvikler seg hele tiden. Hvis vi ser på Microsoft-plattformen, blir ny funksjonalitet kontinuerlig lagt til – og det er nesten synd å ikke ta den i bruk.

Husk hva du faktisk betaler for

ERP-konsulent Mette Ohmsen sier:

«Det ville være synd å tro at ingenting har skjedd med D365FO sammenlignet med AX2009. Det ville også være synd å tro at virksomheten deres ikke har endret seg radikalt i løpet av den tiden. Med en 1:1-oppgradering må man passe på at man ikke bygger noe som blir for stort og tungt, slik at ambisjonsnivået ikke blir for høyt fra starten. Så et minimum viable product – det forstår jeg godt. Men man må også forholde seg til at ledelsen vil spørre: ‘Hva er det egentlig vi har betalt 35 millioner kroner for, hvis vi ikke har fått noe nytt?’»

3. Sikkerhet

Mange spør fortsatt: «Er det trygt å gå til skyen?»
Det korte svaret er ja. Generelt sett er sikkerheten i skyen nå godt ivaretatt, og den er ofte mer sikker enn å ha egne servere lokalt. Likevel er sikkerhet fortsatt et stort tema når man går til skyen, og derfor får det mye oppmerksomhet. Mette Ohmsen utdyper:

«Når vi snakker om sikkerhet i Cloud versus On-Premise, må man være oppmerksom på hvilken tankegang IT-avdelingen deres har i dag, og hva de er vant til. Det krever nemlig en annen tankegang, fordi infrastrukturen i skyen er annerledes enn On-Premise.»

Dokumentsikkerhet er et oversett område

Tabellae opplever at dokumentsikkerhet ofte ikke blir vurdert fra starten av, og det kan bli kostbart hvis det ikke er på plass. Generering og distribusjon av dokumenter – samt rollene som håndterer dem – må styres nøye. To eksempler fra virkeligheten:

En virksomhet sender en faktura med et svært høyt beløp til en mottaker for betaling. Hvis kontonummeret endres i PDF-en, blir betalingen sendt til feil konto. Vi har dessverre opplevd dette flere ganger fordi dokumentsikkerhet ikke har vært en del av ERP-prosjektet fra starten. Hvis det skjer flere ganger, kan det bli svært kostbart.
Et annet eksempel er Britta. Alle kjenner en «Britta». Hun var personen som endret kontonummeret slik at pengene havnet på hennes egen konto. Hun hadde alle de riktige rollene i systemet, og hvis hun fikk Dynamics 365, ville hun sannsynligvis også få en rolle som kunne gjøre alt. Dette kan forebygges med ulike sikkerhetstiltak, for eksempel flere former for autentisering.

Flere aspekter må tas i betraktning

Mette Ohmsen legger til sitt perspektiv på sikkerhet i skyen:

«Det finnes to sikkerhetsaspekter:

infrastruktursikkerhet, der Cloud versus servere i kjelleren er relevant, og

det jeg kaller ‘compliance’, altså sikkerhet knyttet til roller, ansvar og GDPR.
Jeg mener det er nyttig å skille mellom disse to områdene – og man må ha begge i tankene.»

Hun fortsetter:

«Roller og rettigheter er min kjepphest. Det må rett og slett være en del av analysen, selv om det er svært vanskelig å forholde seg til. Det handler ofte mer om prosesser enn om IT – hvem som skal få lov til å gjøre hva, og når. I tillegg forstår jeg ikke hvorfor så mange implementeringspartnere ikke tar hensyn til at det finnes noe som heter IT-revisjon. Som virksomhet må dere kunne redegjøre for dette og vise hvordan dere håndterer ‘segregation of duties’. Det er veldig viktig – og også krevende.»

4. Pris

Hvor mye koster det å flytte til skyen?
Dette er ofte spørsmålet som ingen kan – eller vil – svare på, og det kan heller ikke vi. Kostnadene avhenger blant annet av transaksjoner, antall virtuelle servere og lagringsplass.

Det finnes konsulentselskaper som kan gi råd om dette og om lisenser. Men det er komplekst, og det er vanskelig å lage et solid business case, fordi ingen kan forutsi fullt ut hvordan systemet faktisk vil bli brukt.

Et annet spørsmål er bemanning og hva det koster. Hvor mange ansatte trenger dere for å implementere løsningen? Og hvor mange vil dere trenge for å vedlikeholde den etterpå?

Evergreen og compliance-kostnader

En annen ting som endrer seg når man går til skyen er at «man implementerer ikke et ERP-system og så går alle hjem». I skyen implementerer man et ERP-system i et Evergreen-miljø. Det betyr at behovet for ressurser er annerledes enn tidligere, da systemene ofte sto på egne servere lokalt.

For eksempel trenger man ressurser til testing, fordi Microsoft oppdaterer systemet flere ganger i året. Dette krever beredskap og bør inkluderes i driftsbudsjettet, siden det er en nødvendighet i et skybasert system.

ERP-konsulent Mette Ohmsen forklarer:

«Det er noen ting man kanskje ikke helt tør å innse. Man kan lett tenke at det nå vil komme nye muligheter, og at det ikke vil koste mer å drive applikasjonsforvaltning på D365FO sammenlignet med vårt gamle AX. Men det gjør det.»

Tabellaes beste råd er derfor å snakke med noen som faktisk har vært gjennom prosessen og har praktisk erfaring med å implementere og ta et ERP-system i skyen i bruk (se også punkt 10).

5. Systemytelse i skyen

Få oversikt over ytelsen, spesielt når det gjelder dokumenter. Ytelsen i skyen har blitt bedre, og i dag finnes det flere måter å optimalisere den ytterligere på, blant annet ved å skalere opp via Azure.

Ytelse i skyen kan overraske mange

Det er mulig å skalere både opp og ned, men ytelsen i skyen kan likevel komme som en overraskelse for mange. Tabellae anbefaler derfor at dere involverer en arkitekt som har erfaring med dette fra før. Det kan være frustrerende hvis en bruker er vant til å få svar på 2 sekunder, og svaret plutselig kommer etter 28 sekunder. Samtidig kan det bli dyrt å løse ytelsesproblemer på feil måte.

Mette Ohmsen utdyper:

«Jeg er egentlig ikke så stor tilhenger av å skrive alle mulige avtaler med leverandører, men det er en god idé å insistere på at leverandøren kommenterer og tar stilling til ytelse i designet de lager.»

6. Test, test, test

Hver gang dere oppgraderer, må dere teste. Heldigvis kan mye automatiseres – det handler først og fremst om prioritering.

En enkel sjekkliste for testing kan være:

Hvem skal teste? Ofte er det de beste folkene i virksomheten, fordi de kjenner prosessene best – noe mange blir overrasket over. Problemet er at disse personene ofte også er opptatt med mange andre oppgaver.
Hvor mye tid bør vi sette av til testing?
Hva er formålet med testingen?
Hvilken funksjonalitet må vi teste?

Testing er svært viktig

Mette Ohmsen er også tydelig på at testing er helt avgjørende:

«Utnytt mulighetene for testautomatisering og bruk det allerede i implementeringsprosessen – da slipper dere å skrive testcaser i Word. I tillegg har jeg to råd:

Start tidlig med prosesstesting, altså flyttesting og end-to-end-testing på tvers av flere områder.

Sørg for å teste med riktige roller. Mange leverandører er imot dette, fordi hvis det blir veldig vanskelig, kan man ikke validere funksjonaliteten. Hvis leverandøren sier dette, bør dere insistere på først å teste funksjonaliteten slik at alle kan gå gjennom den – og deretter MÅ dere teste med de riktige rollene. Det er da dere virkelig ser hvordan det fungerer.»

7. Best of Suite / Microsoft “standard”

Standard er ikke alltid standard

Dette er en evig diskusjon – nesten som en religion – og i ERP-verdenen finnes det flere «retninger»:

Best of Suite: Alt skal ligge i én samlet løsning
Best of Breed: Man velger de beste løsningene på markedet (ISV-er)

Dette er ikke en diskusjon man nødvendigvis kan vinne, fordi det finnes mange nyanser. Hvis noen sier at noe er standard fordi det er SAP eller Microsoft, kan det godt være riktig. Men hvis man må skrive mye kode for å få standarden til å fungere, er det egentlig ikke standard lenger. Da ender man opp med et standardprodukt som er kraftig tilpasset med kode – og det kan bli vanskelig, dyrt og tidkrevende å vedlikeholde.

Derfor bør man lytte til flere «retninger» før man tar en beslutning.

Benytt rådgivning

Om du bør velge Best of Breed eller Best of Suite, avhenger av virksomhetens behov. Hos Tabellae hjelper vi med å velge riktig løsning fra starten av ved å analysere kravene dine. Når dette er gjort, kan vi vurdere om behovene best kan dekkes av en standardløsning eller av en tredjepartsløsning utenfor ERP-systemet.

8. Koding og tilpasninger

Koding og tilpasninger er noe mange virksomheter er vant til. En av grunnene til at man ønsker å redusere det, er at koding er kostbart.

Koding er ikke uten risiko

Jo mer dere koder, desto mer må dere teste. For eksempel krever 100 timer med koding i Dynamics ifølge flere ERP-leverandører opptil 700 timer med etterfølgende testing. Et ERP-system med mye kode er også mer utsatt for feil ved oppgraderinger. Derfor kan det ofte være bedre å konfigurere systemet og bruke ISV-løsninger der det gir mening.

Mette Ohmsen understreker likevel at koding i praksis noen ganger kan være nødvendig:

«Men virksomheten må fungere. Noen ganger må man kode hvis funksjonaliteten ikke finnes i standardløsningen eller i tredjepartsløsninger.»

9. Valg av partner er viktigere enn valg av programvare

Finn en partner du har god kjemi med, som forstår virksomheten din og behovene dine. Dette er ti ganger viktigere enn å velge en spesifikk løsning. Det krever selvfølgelig også erfaring, men hvis dere har samme tilnærming og sitter på samme side av bordet, trenger dere kanskje ikke å se så mye på kontrakten – og det er heller ikke spesielt spennende.

«Å måtte se på kontrakten er noe man helst vil unngå. Det dyreste er ikke gjennomføringen – det er konfliktene. Unngå dem med et godt kontraktsgrunnlag som er balansert mellom kunde og leverandør, og med god kjemi», sier ERP-konsulent Mette Ohmsen.

En god kontrakt hjelper på regnværsdager

Det finnes knapt et ERP-prosjekt som ikke har både solskinnsdager og regnværsdager. På de dagene det regner, er det godt å ha et solid kontraktsgrunnlag slik at man kan snakke sammen som partnere og bli enige om hvor mye det regner i dag – og hvem som skal fikse paraplyen.

En enkel sjekkliste for å vurdere en god partner:

Har de erfaring?
Har de bransjekunnskap?
Passer dere godt sammen? (både mentalt og når det gjelder prosjektmodell)
Har de de nødvendige ressursene?
Har de riktig kompetanse?
Har dere felles suksesskriterier?

10. Bruk ERFA – og få verdifull innsikt

Hvor ofte implementerer man egentlig et ERP-system i løpet av livet? Kanskje tre ganger. ERP-partneren kan ha 4–6 prosjekter i året, noe som heller ikke er veldig mye i global sammenheng. Derfor kan det være vanskelig å opparbeide seg mye erfaring med ERP-implementering. Hos Tabellae anbefaler vi derfor kundene våre å bruke ERFA-grupper.

Gratis, uavhengig rådgiver

ERFA-grupper fungerer som en uavhengig «rådgiver» – og deltakerne har ofte gjort dette før. Her kan du få råd og sparring om ERP-prosjektet både før, under og etter implementeringen.

Se etter ERFA-grupper som bruker det samme ERP-systemet som dere, og få inspirasjon som kan være svært verdifull og hjelpe dere med å unngå unødvendige endringsforespørsler.

Ta inn eksterne eksperter

Mette Ohmsen understreker også hvor viktig det er å involvere eksterne ressurser i et ERP-prosjekt:

«Dessverre har mange virksomheter en tilnærming der det føles utrygt å hente inn eksterne personer og dele denne ganske sårbare avklaringsprosessen. Og ja, den er sårbar. Men det er verdt det. Det er litt som å si: ‘Jeg må gå ned 10 kilo før jeg får meg en personlig trener.’ Det kan godt hende at vektnedgangen går raskere hvis du bare kaster deg ut i det – selv om det kanskje ikke er så gøy.»

11. Det grunnleggende: Husk å forankre det i ledelsen

Det siste rådet er ikke spesielt nytt eller spektakulært – faktisk er det ganske gammelt – men det er solid og gjelder fortsatt: forankring i ledelsen.

Se på ERP-oppgraderingen som en virksomhetstransformasjon og ikke bare som et IT-prosjekt. På den måten blir prosjektet forankret i ledelsen, og hele virksomheten tar eierskap til prosjektet. Det er vanskelig å lykkes uten støtte fra ledelsen, og mangel på dette kan koste prosjektet både tid og fremdrift. Sørg derfor for at det finnes engasjement, vilje og beredskap til å lære.

Enklere å gjennomføre

Mette Ohmsen avslutter med:

«Bare en sint CEO kan i etterkant stille spørsmål ved et prosjekt som ellers kunne vært en suksess. Derfor må ledelsen delta i prosjektet eller i styringsgruppen, fordi det har stor betydning for gjennomføringsevnen.»