Moderne ERP-systemer: Forretningsverdi og fordeler

Tiden før skyen

Hva var typisk for forretningsprogrammer før skyen gjorde sitt inntog?

Microsoft startet sin virksomhet innen forretningsløsninger i 2002 med oppkjøpet av løsningene Navision og Axapta. Navision, som nå heter Dynamics 365 Business Central, var utviklet primært for små bedrifter, mens Axapta, som nå heter Dynamics 365 for Finance and Operations, var utviklet primært for større bedrifter. Selv om de to løsningene er forskjellige, deler de flere funksjoner, noe som også gjelder de fleste tradisjonelle forretningsløsningene:

• Utrulling på egen infrastruktur (eller på datasenterinfrastruktur).
• Måten løsningene kan tilpasses på – tilpasninger er en viktig del av enhver implementering, siden det ofte oppstår situasjoner der standardfunksjonene ikke oppfyller kundens behov. I tradisjonelle løsninger innebar tilpasningene vanligvis at leverandøren (i dette tilfellet Microsoft) endret programmets kode.
• En metodisk tilnærming til implementering – i de fleste tilfeller ble det brukt en tilnærming med sekvensiell gjennomføring av enkeltfaser (vanligvis i tråd med den såkalte fossefallmetoden), der fasene fulgte etter hverandre: analyse, design, utvikling, testing, opplæring og overgang til drift.
• Endringsadministrasjon – oppdateringer av standardløsninger (i form av hurtigreparasjoner, forbedringer og lignende) ble levert gjennom hele støtteperioden for den aktuelle versjonen, men de var ofte relativt komplekse å implementere i miljøer som var preget av stor grad av tilpasning.
• Oppgraderinger og hele appens levetid – vanligvis kom det en ny versjon hvert år eller annethvert år. Den nye versjonen hadde store endringer både når det gjaldt datastruktur og teknologi. Jo mer tilpasset systemet var, desto vanskeligere var overgangen til den nye versjonen.

Forretningsprogrammene Dynamics 365

I dag tilbyr Microsoft løsningene Dynamics 365 Business Central og Dynamics 365 Finance and Supply Chain som forretningsprogrammer, sammen med mange andre Dynamics 365-apper. Begge løsningene er utviklet som moderne skyløsninger, og de har som mål å løse alle utfordringene som er knyttet til implementeringen av tradisjonelle forretningsløsninger. Løsningene påvirker også hvordan de implementeres, med andre ord den som implementerer dem, samt kunden. Hva består påvirkningene av?

Infrastruktur

La oss begynne med infrastrukturen, som kanskje er det mest naturlige området som påvirkes.

Med skyløsninger slipper vi å tenke på krav til maskinvare og programvare for at løsningen skal fungere problemfritt. Vi slipper å tenke på oppdateringer av system og programvare. Vi slipper å bekymre oss for å sikre god systemtilgjengelighet, sikkerhetskopier og lignende. Vi får mye informasjon basert på telemetri, slik at vi ser hvordan systemet fungerer.

Med infrastruktur i skyen blir det enkelt å sette opp ekstra miljøer for forskjellige formål, for eksempel utvikling, testing, testing av ytelse og så videre. Det er en stor fordel sammenlignet med lokal utrulling (flere miljøer i skyen fører naturligvis til ekstra kostnader).

Det er viktig å understreke at Dynamics 365 ERP-løsninger også kan installeres på lokal infrastruktur, noe som naturligvis gjør dem mye mer komplekse. Da må den som implementerer løsningen, lage en detaljert plan over nødvendig maskinvare, system og programvare. Det oppstår også behov for rutiner for vedlikehold og oppdateringer.

Tilpasninger

Noe av det viktigste leverandører av tradisjonelle ERP-løsninger fant ut, var at det kan være vanskelig for kunder å bestemme seg for å oppdatere til nyere versjoner av løsningen. Tvil og frykt hang vanligvis sammen med den potensielt store mengden tilpasninger som må gjennomføres. Jo mer tilpasset løsningen er, desto mer innsats kreves for å oppgradere den.

Derfor havnet vi ofte i situasjoner der det ikke lenger var snakk om en oppgradering, men om en ny implementering.

En av skytjenestenes viktigste fordeler er kontinuerlig oppdatering og implementering av nye funksjoner. Oppdateringer kan gjennomføres hver måned ved behov. For at brukere relativt enkelt skal kunne begynne å bruke nye versjoner av løsningene sine, måtte vi endre hvordan løsningene tilpasses. Tidligere kunne leverandøren endre standardkoden, men med skytjenester er ikke det lenger et alternativ. Derfor ble det innført en ny modell der den som implementerer løsningen, ikke lenger kan endre standardkoden, men isteden skriver sin egen kode – en såkalt utvidelse – som inkluderes på konkrete steder i programmets kode (såkalte utvidelsespunkter). Når produsenten bytter ut standardkoden og ikke gjennomfører større endringer (for eksempel fjerner datastrukturer, programvareartefakter eller lignende), vil eksisterende utvidelser fungere med den nye oppdateringen på samme måte som i den eldre versjonen (for presentasjoner vil for eksempel alle USB-enheter fungere som tidligere, med mindre standarden endres). Det fører til at det blir mer komplekst å lage tilpasninger.

På den andre siden finnes det en «utviklingsplattform med lav kode», kalt Power Platform. Den inkluderer blant annet PowerBI, PowerApps og PowerAutomate, tjenester som gjør at man raskt kan utvikle løsninger innen «selvbetjent forretningsintelligens», utvikle apper og sikre automatisering.

Metodikk

Den moderne Dynamics 365-familien av forretningsprogrammer oppdateres minst hver måned. Det gjennomføres for øyeblikket store endringer. Store, monolittiske løsninger brytes opp, for eksempel byttes hele moduler ut med nye skyløsninger (noen nylige eksempler inkluderer Dynamics 365 Human Resources, Dynamics 365 Finance Insights og Dynamics 365 AI). I slike miljøer kan man ikke lenger bruke fast implementeringsmetodikk for å implementere komplekse forretningsløsninger. I tråd med et miljø som er i rask endring,

har Microsoft foreslått en metodisk tilnærming som kalles CRP (Conference Room Pilot), og som er en kombinasjon av fossefallmodellen og en agil tilnærming.

I dette tilfellet består implementeringen av følgende trinn:

• Agile forberedelse av den første backloggen av oppgaver (backlog-elementer).
• Definere milepæler i form av CRP-workshops.
• Iterativ implementering av CRP-faser (hver CRP-fase består av en kort analyse, design, utvikling og testing, og fremdriften sikres parallelt etter alle prosjektaktiviteter fra blant annet innstillinger, tilpasninger, integreringer og migreringer).
• Opplæring.
• Testing.
• Overgang til produksjon.

De viktigste fordelene med en slik tilnærming inkluderer følgende:

• Kunden er involvert fra start til slutt i prosjektet.
• Fremdriften overvåkes kontinuerlig, slik at man kan iverksette korrigerende tiltak ved behov.
• Kontinuerlige tilbakemeldinger fra brukerne.
• Kravene tilpasses i henhold til inkrementelle leveranser (ofte endres kravene under selve implementeringen), noe som fører til raskere implementering.

Programmets livssyklus

I tradisjonelle løsninger var vi ofte vant til full autonomi i kodehåndteringen og installering av oppdateringer, men slik er det ikke med skyløsninger. For Dynamics 365 Finance and Operations er livssyklusstyring bare mulig ved hjelp av samarbeidsportalen LCS (Lifecycle services). For skytjenester betyr det at Microsoft oppdaterer produksjonsmiljøet som en del av de vanlige tjenestene. Kunden og den som implementerer løsningen, får bare tilgang til systemet via brukergrensesnittet. Tidligere fikk vi enkelt tilgang til data, til å installere oppdateringer og gjennomføre ad hoc-tiltak, men det er ikke lenger mulig. Nå finnes det en rutine som nøyaktig beskriver fremgangsmåten for å installere en ny pakke i produksjonen, for eksempel må den testes i en sandkasse først.

Automatisk testing har blitt viktigere enn noensinne, og vi har ikke råd til at systemet slutter å fungere på grunn av manglende testing.

Eviggrønn løsning

Oppdateringer inkluderer kontinuerlig utvidelse av funksjoner og funksjonalitet. For Dynamics 365 for Finance and Supply Chain får kunden åtte oppdateringer hvert år og må godta minst to av dem, noe som betyr at kunden kan hoppe over tre påfølgende oppdateringer. Kritiske feilrettinger er alltid tilgjengelig for den tidligere versjonen (hvis den nyeste versjonen er 10.0.6, tilbys det kritiske feilrettinger for versjon 10.0.5).

Det gjør at kundene alltid har den nyeste oppdateringen, inkludert alle kjente kritiske feilrettinger og ny funksjonalitet.

Dette betyr at når vi implementerer løsningen, må vi kunne godta oppdateringer flere ganger i året og sørge for at alle utvidelsene fungerer som de skal. Nok en gang spiller automatisk testing en viktig rolle.

Med en skyløsning må vi naturligvis ikke glemme at vi snakker om en løsning der alt er inkludert, noe som betyr oppdatering av både system og programvare.

Det er en forskjell mellom utrulling i skyen og utrulling lokalt. Ved lokal utrulling får kunden mer fleksibilitet (med andre ord må kunden gjennomføre det selv), men det er ikke mulig uten regelmessige oppdateringer.