Modifikasjon av ERP løsninger i skyen - hvordan håndteres dette med Microsoft Dynamics 365 Finance and Operations?
Å gjøre modifikasjoner av standardfunksjonalitet ved innføring av ERP-systemer er kostnadsdrivende og kan gjøre løsningen vanskeligere å administrere i etterkant. Uansett gjøres slike modifikasjoner i stort sett hvert eneste implementeringsprosjekt for å kunne dekke opp gap mellom brukerkrav og funksjonalitet i standardsystemet.
Nå som flere av ERP løsningene kommer som «skyløsninger» åpner dette at standardkoden vil bli oppdatert «automatisk» fra applikasjonsleverandøren med jevne mellomrom. Dette kan gjøre at de blir enda viktigere å redusere antall modifikasjoner i ERP løsningene da:
- Hver gang standardkoden oppdateres bør man teste modifikasjonene som kan ha blitt berørt av oppdateringen, for alle relaterte forretningsprosesser i samtlige selskaper. Dette kan være en formidabel jobb hvis man har mange modifikasjoner og selskaper i løsningen.
- Tidligere ville man naturlig ta en gjennomgang på alle forretningsprosesser mot ny funksjonalitet når man skulle oppgradere til ny versjon og fjerne de modifikasjoner som ikke lengre var aktuelle. Men siden disse oppdateringene vil komme oftere i en skyløsning, vil man vanskeligere ta en slik helhetsvurdering. Dermed kan du risikere at organisasjonen vil fortsette å bruke modifikasjonen og de gamle måtene å jobbe på, på tross av at det har kommet ny funksjonalitet og nye muligheter. Man kan derfor bli «fanget» i gamle modifikasjoner og forretningsprosesser i lang tid istedenfor å nytte ny teknologi og nye arbeidsmåter.
Minimer antall modifikasjoner med skymulighetene
Kort sagt så gjør inntreden av «skyløsninger» det viktigere enn før å unngå modifikasjoner av standardprogramkoden. Så hvordan kan vi bruke mulighetene i D365 (Dynamics 365) og ERP systemet D365FO (Microsoft Dynamics 365 Finance & Operations, Enterprise Edition) i skyen for å minimere antallet av modifikasjoner?
Det er gjort mye med D365FO for å unngå de negative effektene med modifikasjoner. For å oppsummere det viktigste av disse, lister jeg de aktivitetene jeg anbefaler å gjøre når man finner et gap mellom bedriftens funksjonskrav og funksjonalitet i D365FO (i prioritert rekkefølge):
- Dobbelt sjekk om kravet er reelt, eller om man kan jobbe på andre måter - Den letteste alltids å fjerne kravet helt og spørre seg om man kan unngå dette og/eller jobbe på en smartere måte. Ofte hender det at man er blir fokusert på å kunne jobbe som man gjør i dag, uten å ta hensyn til at ting kan løses på en annen måte.
- Finn en løsning i standard D365FO – D365FO kommer med svært mye funksjonalitet; mye mer enn i tidligere versjoner. Så du bør først teste om standardfunksjonene er gode nok og eventuelt søke alternative løsninger i D365FO. iStone bruker innføringsmetodikken iStep som er skreddersydd for å hjelpe bedrifter til å tilpasse seg standardsystemet, blant annet ved at vi først setter opp en prototype på standardfunksjonalitet og teste ut denne sammen før man går videre å vurdere «funksjonsgapene». Alternativ kan man utsette brukerkravet til senere faser hvor Microsoft har kommet løsninger i standardsoftwaren. Portalen Microsoft Dynamics 365 Roadmap viser hvilken funksjonalitet som kommer i D365, i tillegg til hva som er under arbeid og hva som er levert i den siste tiden.
- Finn en ferdig «App» i AppSource eller en annen «partnerapp» som dekker behovet - Microsoft har en egen «appstore» ("AppSource") for D365. Apps her inne vil bli vedlikehold sammen med standardkoden og kan derfor i stor grad betraktes som en del av standardprogramvaren i denne forbindelse.
- Lag en tilpasset «App» gjennom f.eks. PowerApps – en ekstern «app» vil være enklere å utvikle og vedlikeholde enn en modifikasjon i standardprogrammet. Enklere apper kan gjøres av bedriften selv gjennom verktøy som PowerApps og Flow, mens mer avanserte «apper» kan utvikles av implementeringspartneren eller andre som spesialiserer seg på dette.
- Bruk et tredjepartsprogram – å bruke en tredjeparts applikasjon er ofte en bedre løsning enn å omprogrammere ERP-systemet. Dette kan imidlertid kreve at integrasjoner må lages og vedlikeholdes.
- Modifiser D365FO-funksjonaliteten gjennom en såkalt «extension» – Finner man ingen løsning uten om å måtte endre standardkoden, kan modifikasjoner i D365FO programmeres som en «extension». Dette betyr at du hovedsakelig legger til funksjonalitet til eksisterende kode. Dette gjør endringen enklere å vedlikeholde og håndtere ved oppgradering av standardkoden, men gir noen begrensinger på hva som kan programmeres da dette i prinsippet kun er tillegg til standardkoden og ikke endringer av denne.
- Endre D365FO gjennom «overlaying» - dette er "den klassiske måten" for å modifisere et ERP-system. Her «overskrives» standardkoden med tilpasset kode, og man får det man tradisjonelt ofte har forstått med «en modifikasjon» (eller «en tilpasning») av ERP-løsningen.
I overskuelig framtid vil det alltid være ett visst behov for modifikasjoner når man innfører en ny ERP løsning, men ved å bruke listen over kan man kunne redusere dette ned til et håndterlig nivå, som ikke hindrer videreutvikling av løsningen. Man bytter da ut deler av skreddersømmen av ERP applikasjonen med tilknyttede applikasjoner som handler i relasjon med ERP systemet. Denne tankegangen relaterer også til det som blir kalt «postmodern ERP», som jeg du kan lese her.
