Moderne ERP-systemer: Forretningsværdi og -fordele

Tiden før skyen 

Hvad var egentlig typisk for virksomhedsapplikationer i tiden før skyen?

Microsoft gik ind på markedet for virksomhedsløsninger i 2002 med opkøbet af løsningerne Navision og Axapta. Navision, der nu kendes som Dynamics 365 Business Central, henvendte sig på det tidspunkt allerede til små virksomheder, mens Axapta, der i dag kendes som Dynamics 365 for Finance and Operations, primært henvendte sig til større virksomheder. På trods af forskellene mellem de to løsninger er der også en del fællestræk, der faktisk er typiske for de fleste traditionelle virksomhedsløsninger:

• Implementering på egen infrastruktur (eller på datacenterinfrastruktur).
• Måden at foretage tilpasninger på – tilpasninger er en integreret del af enhver implementering, idet der ofte er tilfælde, hvor standardfunktionerne ikke opfylder alle klientens behov. Med traditionelle løsninger betød tilpasningerne som regel en direkte ændring af leverandørens standardprogramkode (i vores tilfælde Microsoft).
• Der blev anvendt en metodisk tilgang til implementeringen – som regel sekventiel gennemførelse af individuelle faser (i de fleste tilfælde den såkaldte vandfaldsmetode) – hvor faserne fulgte på hinanden: analyse, design, udvikling, afprøvning, træning, overgang til produktion.
• Der blev leveret ændringsstyring – opdateringer af standardløsninger (i form af hotfixes, forbedringer etc.) – i en specifik versions fulde supportlivscyklus, men den var ofte temmelig kompleks at implementere i miljøer med mange tilpasninger. 
• Opgraderinger og hele applikationens livscyklus – typisk blev en ny version introduceret over en periode på et eller to år – der medførte store forandringer, både i forhold til datastruktur og teknologi. Jo mere systemet blev tilpasset, jo sværere var det at foretage omstillingen til den nye version.

Dynamics 365-virksomhedsapplikationer

I dag tilbyder Microsoft Dynamics 365 Business Central og Dynamics 365 Finance and Supply Chain inden for virksomhedsapplikationer samt mange andre Dynamics 365 apps. Begge løsninger er udviklet med udgangspunkt i tanken om moderne løsninger i skyen, og de forsøger at respondere fuldt ud på alle de udfordringer, der er forbundet med implementeringen af traditionelle virksomhedsløsninger. Svarene medfører også vigtige konsekvenser for implementeringsmetoden, dvs. for den, der implementerer, samt for klienten. Men hvad er det så for konsekvenser? 

Infrastruktur

Lad os begynde med infrastruktur – måske det mest åbenlyst berørte område.

Med løsninger i skyen behøver vi ikke længere tænke over krav til hardware og software, der sikrer smidig drift. Vi behøver ikke tænke over system- og applikationssoftwareopdateringer. Vi behøver ikke bekymre os om scenarier, der omfatter sikring af høj systemtilgængelighed, sikkerhedskopier og den slags... Med udgangspunkt i telemetri kan vi få masser af information, der fortæller os om den tilstand, vores system er i. 

Cloud-infrastruktur gør det let at oprette supplerende miljøer til forskellige formål, f.eks. udvikling, afprøvning, performancetests etc., hvilket er en stor fordel i forhold til lokal implementering (supplerende miljøer i cloud-infrastrukturen er naturligvis forbundet med merudgifter).

Det er vigtigt at understrege, at Dynamics 365 ERP-løsninger også kan installeres på lokal infrastruktur, hvilket naturligvis øger kompleksiteten markant. Hvis det er tilfældet, skal den implementeringsansvarlige udarbejde en detaljeret plan for kravene til hardware, system og applikationssoftware. Der skal også etableres vedligeholdelses- og opdateringsmekanismer. 

Tilpasninger

En af de vigtige ting, som leverandørerne af traditionelle ERP-løsninger fandt ud af, var, at det kunne være svært for kunderne at afgøre, om de skulle opgradere til nyere versioner af deres løsning. Deres tvivl og frygt skyldtes hovedsageligt bekymringer over det potentielt høje antal tilpasninger, det ville medføre. Jo mere tilpasset løsningen var, jo større indsats ville opgraderingen kræve. 

Derfor stødte vi ofte på det faktum, at vi ikke længere kun talte om opgradering, men også om genimplementering. 

En af de primære funktioner i alle cloud-tjenester er den konstante opdatering og tilføjelse af nye egenskaber – der er stort set opdateringer hver eneste måned. For at kunderne relativt let kunne implementere nye versioner af deres løsning, var det nødvendigt med en grundlæggende ændring af måden at foretage tilpasninger på. Tidligere var det muligt at ændre den grundlæggende standardkode, som leverandøren leverede, men det er ikke længere tilfældet med cloud-løsninger. Derfor blev der indført en ny model, hvor den implementeringsansvarlige ikke længere har mulighed for at ændre standardkoden, men i stedet kan skrive sin egen kode – en såkaldt udvidelse – forudbestemte steder i programkoden (såkaldte udvidelsespunkter). Når producenten udskifter sin standardkode og ikke foretager store ændringer (f.eks. ved at fjerne visse datastrukturer, softwareartefakter etc.), fungerer de eksisterende udvidelser med den nye opdatering på samme måde som før opdateringen (f.eks. for lettere præsentation – når en bærbar computer udskiftes, fungerer alle USB-enheder som før, og en ændring af standarden ville naturligvis være en stor ændring). Som følge heraf bliver det mere kompliceret af foretage tilpasninger.

På den anden side er der en "low-code-udviklingsplatform", der går under navnet Power Platform, som omfatter PowerBI, PowerApps, PowerAutomate etc. Disse tjenester gør det muligt at udvikle hurtige løsninger på områder som "selvbetjenings-business intelligence", applikationsudvikling og automatisering. 

Metode

Den moderne Dynamics 365-familie af virksomhedsapplikationer opdateres så godt som hver eneste måned eller oftere. Der finder i øjeblikket store transformeringer sted i form af en nedbrydning af store monolitløsninger, som kommer til udtryk gennem eliminering af hele moduler, der erstattes af nye cloud-løsninger (blandt de nyere eksempler finder vi Dynamics 365 Human Resources, Dynamics 365 Finance Insights og Dynamics 365 AI), og i et sådant miljø er det umuligt at forestille sig at bruge rigide metoder til implementering af en kompleks virksomhedsløsning. Som en reaktion på det hurtigt skiftende 

miljø har Microsoft foreslået en metodetilgang ved navn CRP (Conference Room Pilot), der er en blanding af vandfaldstilgangen og den agile tilgang. 

I dette tilfælde omfatter implementeringen følgende trin:

• Agil forberedelse af den indledende opgavebeholdning (backlog items)
• Fastsættelse af milepæle i form af CRP-workshopper
• Iterativ implementering af CRP-faser (hver CRP-fase består af en kortfattet analyse, design, udvikling, afprøvning; fremskridt sker samtidig efter alle projektaktiviteter fra indstillinger, tilpasninger, integrationer, migrationer…)
• Træning
• Test
• Overgang til produktion

De vigtigste fordele ved en sådan tilgang er:

• Involvering af klienten fra projektets begyndelse til dets afslutning
• Løbende overvågning af fremskridt og om nødvendigt korrigerende tiltag
• Løbende feedback fra brugerne
• Tilpasning af behovene i henhold til trinvise leveringer (kravene ændres ofte i løbet af selve implementeringen), hvilket alt sammen resulterer i hurtigere implementering.

Applikationslivscyklus

I de traditionelle løsninger var vi ofte vant til komplet autonomi i forvaltningen af kode og installationen af programrettelser, men det er helt anderledes i forbindelse med cloud-løsninger. I forbindelse med Dynamics 365 Finance and Operations er forvaltning af applikationslivscyklussen kun mulig via samarbejdsportalen LCS (Lifecycle Services), der i relation til cloud-løsninger betyder, at opdatering af produktionsmiljøet udføres af Microsoft som del af deres regelmæssige tjenester. Både klienten og den implementeringsansvarlige har kun adgang til systemet via brugergrænsefladen. Hvor vi før havde let adgang til data, kunne installere programrettelser og udføre hurtige handlinger ad hoc, er disse muligheder nu helt fjernet. Der er nu en procedure, der præcist beskriver trinnene til installation af en ny pakke i produktion, f.eks. er test i et sandkassemiljø en forudsætning. 

Tests med opbakning fra automatiserede tests er nu vigtigere end nogensinde, idet vi ikke har råd til, at systemet fejler som følge af utilstrækkelig afprøvning. 

En stedsegrøn løsning

Opdateringerne omfatter løbende tilføjelse af egenskaber og funktioner. Til Dynamics 365 for Finance and Supply Chain har klienten 8 opdateringer om året og skal acceptere mindst to om året, hvilket i praksis betyder, at man kan springe over tre opdateringer i træk. Desuden er kritiske rettelser altid tilgængelige til den foregående frigivelse (dvs., at hvis den nuværende frigivelse er 10.0.6, er der adgang til kritiske rettelser til frigivelse 10.0.5). 

På denne måde har klienterne altid den seneste opdatering, der omfatter alle kendte kritiske rettelser og nye egenskaber og funktioner.

Det betyder naturligvis, at vi som implementeringsansvarlige er nødt til at kunne acceptere opdateringer flere gange om året og sikre, at alle udvidelserne fungerer korrekt. Igen – automatiserede tests spiller en vigtig rolle.

I tilfælde af en "cloud"-løsning må vi naturligvis ikke glemme, at vi taler om en alt inklusive-service, hvilket betyder opdatering af både systemet og applikationssoftwaren.

Der er forskel på implementering i skyen og på stedet – med en lokal implementering får klienten mere fleksibilitet (og de skal klare sig selv), men det er ikke muligt uden regelmæssige opdateringer.