Hvorfor bliver dit ERP tungere for hvert år?

Forestil dig et hus med bærende vægge.

De bærende vægge er der af en grund. De holder huset oppe, de er dimensioneret af nogen, der ved, hvad de laver, og de er tænkt sammen med resten af konstruktionen. Man kan sagtens indrette sig, som man vil: flytte møbler, sætte lette skillevægge op, bygge en carport. Men hver gang man hugger hul i en bærende væg, fordi der lige manglede en dør, betaler man for det. Ikke nødvendigvis i dag. Men den dag huset skal renoveres, står man med en konstruktion, hvor ingen længere helt tør sige, hvad der bærer, og hvad der bare hænger fast.

Sådan har mange virksomheder det med deres ERP.

Jeg skrev for nylig om, hvad kunden egentlig har købt, når de køber en Dynamics 365-applikation. Pointen var, at kunden har købt et SaaS-produkt med et roadmap, ikke en partnerafhængig genopbygning af produktet. Det indlæg handlede om CRM. Men spørgsmålet bliver faktisk endnu vigtigere, når vi flytter det over på ERP-siden, for i D365 Finance & Operations og Supply Chain er konsekvensen af at bygge i kernen større, og den kommer altid tilbage: ved hver eneste opgradering.

Og lad mig være ærlig om mit udgangspunkt, inden vi går videre: Jeg er ikke ERP-arkitekt. Jeg er CRM-arkitekt med hjemmebane i Dynamics 365 Customer Engagement og Power Platform. Alligevel bruger jeg i dag en stor del af min tid i ERP-projekter og ERP-aktiviteter. Det er ikke et tilfælde, og det er heller ikke, fordi jeg er ved at skifte spor. Det er, fordi det lag, der holder et ERP rent, er mit domæne. Den, der skal holde kernen ren, er nemlig sjældent den, der bygger kernen. ERP-arkitektens opgave er at få kerneprocesserne til at stå stærkt. Min opgave er at stå ved siden af med spørgsmålet: skal det her overhovedet ind i kernen? De to perspektiver er ikke i konkurrence. De er hinandens forudsætning.

Kundetilpasninger er lån, ikke køb

Hver gang der bygges kundespecifik logik ind i ERP-kernen, føles det som et køb. Man betaler én gang, og så virker det.

Men det er ikke et køb. Det er et lån.

Renterne betales ved hver release: analyse, regression, rework. De betales, når den nye funktionalitet fra Microsoft skal vurderes op mod alt det, der er bygget udenom. Og de betales i mennesker, for den logik, der ligger som custom kode i kernen, er ofte forstået af ganske få, og den viden står ikke i noget dokument.

Det snigende ved customization-gæld er, at hver enkelt tilpasning virker billig. "Det er bare en lille prisregel." "Det er bare et godkendelsesflow." "Det er bare en rapport." Ingen af dem vælter noget. Men sammen definerer de, hvad næste opgradering koster, og hvor hurtigt forretningen kan få den næste ændring.

Og imens vokser der noget udenfor systemet. For når en ændring skal vente på et release-vindue målt i måneder, venter forretningen ikke. Den bygger sin egen løsning: et Excel-ark, en mailproces, et lille sidesystem. Så nu har man både gæld inde i kernen og skygge-IT udenfor den.

Resultatet er et ERP, der bliver tungere for hvert år, i et marked hvor det burde blive lettere.

Det stærke ved Power Platform er det, du ikke behøver bygge på forhånd

Løsningen er ikke et produktkatalog af færdigbyggede apps, man kan købe ved siden af sit ERP. Løsningen er en disciplin.

Styrken ved Power Platform som extension-lag omkring ERP er netop, at intet behøver være klart på forhånd. Vi skal ikke gætte i dag, hvilke apps din forretning får brug for om to år. Vi skal bare være enige om ét princip: Den logik, der gør ERP tungt at vedligeholde, altså det kundespecifikke, det der ændrer sig ofte, og det der er dit og ikke alles, bygges ikke ind i kernen. Den flyttes ud i et styret lag udenom, efterhånden som den opstår.

Ude i extension-laget lever den logik på helt andre vilkår. En ændring tager dage eller uger, ikke måneder. Den regressionstester ikke hele dit økonomisystem. Og når Microsoft opgraderer kernen, står din forretningslogik ikke i vejen. Den står ved siden af og kigger på.

Med husmetaforen: Power Platform er de lette skillevægge og indretningen. Man kan flytte dem, bygge om, prøve noget af og fortryde, uden at røre de bærende vægge. Og hver gang noget flyttes fra kernen ud i laget, bliver huset lidt lettere at renovere.

Deraf princippet, der efterhånden er blevet mit begreb for hele tilgangen: Clean ERP.

Kommer du fra SAP-verdenen, nikker du sikkert genkendende. SAP har gjort "clean core" til en formel strategi for S/4HANA: Hold kernen så tæt på standard som muligt, og byg extensions side-by-side på Business Technology Platform i stedet for at modificere kernen. SAP har endda et modenhedsniveau for, hvor ren din kerne er. Når jeg alligevel kalder det Clean ERP og ikke clean core, er det fordi ambitionen er bredere end kernen: Et rent ERP-setup omfatter også laget udenom og alt det, der i dag gemmer sig i Excel, mail og sidesystemer. En ren kerne med rod omkring sig er ikke ren. Pointen her er ikke Microsoft mod SAP. Begge økosystemer er landet samme sted: standardkerne i midten, et styret lag udenom til alt det, der er dit. Hos Microsoft hedder laget Power Platform. Hos SAP hedder det BTP. Navnene er forskellige, løsningen er det samme.

Én beslutning, truffet hver gang, ikke én gang

Hvordan ser den disciplin så ud i praksis? Den er næsten pinligt simpel.

Den består af ét spørgsmål, stillet hver gang der skal bygges ny logik, og før den bliver bygget:

"ERP eller Power Platform?"

Det afgørende er ikke spørgsmålet. Det er, at det bliver stillet hver gang, og at det besvares med kriterier, ikke med vane. For vanen har et velkendt svar: "Vi løser det i ERP, det plejer vi." Ikke af ond vilje, men fordi det er dér, ERP-konsulenter er hjemme, og fordi ingen har givet dem et alternativ, de kan stole på.

Det er præcis dét, jeg bruger min tid på i ERP-projekterne. Ikke at bygge kerneprocesser, det gør folk, der er langt dygtigere til det end mig. Men at være den i rummet, der har hjemmebane i laget udenom, og som kan gøre "ERP eller Power Platform?" til et reelt valg i stedet for et retorisk. Min erfaring er, at spørgsmålet kun bliver stillet konsekvent, når der sidder en med ved bordet, som kan stå på mål for svaret.

Kriterierne er til gengæld ret håndfaste. Transaktionsvolumen. Datakonsistens. Compliance. Performance. Antal integrationspunkter. Logik med regnskabsmæssig konsekvens, tunge transaktionelle flows og alt det, der ér selve kerneprocessen, bliver i ERP, hvor det hører hjemme. Clean ERP betyder ikke tom kerne. Det betyder, at det, der ligger i kernen, ligger der af en grund, som nogen kan forklare.

Resten er kandidater til laget udenom: godkendelsesflows, reklamationsindtag, kvalitetstjek, portaler, statusvisninger, master data-anmodninger og de små arbejdsgange, der i dag bor i Excel og mail.

Uden governance har du bare flyttet problemet

En fair indvending: er et voksende Power Platform-lag ikke bare skygge-IT med et pænere navn?

Jo. Hvis det er ustyret, er det præcis, hvad det er. Så har man byttet customization-gæld i kernen ud med app-spredning udenom den, og det er ikke en handel, der er værd at lave.

Derfor er governance ikke et appendiks til disciplinen, men halvdelen af den. Environment-strategi, DLP, ALM, sikkerhed, og vigtigst af alt: et eksplicit ejerskab for hver eneste extension. Hvem ejer processen? Hvem supporterer den? Hvad sker der med den efter go-live: kører den under ERP-supportaftalen, hos partneren eller hos jeres eget Power Platform-team?

Det sidste er i øvrigt et helt legitimt valg. Nogle virksomheder vil selv bygge og drive deres extension-lag, og det kan være den rigtige model, hvis grænserne og governance er på plads. Det er ikke afgørende, hvem der bygger. Det afgørende er, at nogen har besluttet hvor tingene bygges, og at nogen ejer dem bagefter.

Spørgsmålene, der er værd at stille

Hvis du ejer eller køber et D365 FO/SC-miljø, behøver du ikke være arkitekt for at holde din kerne ren. Men du bør stille nogle spørgsmål, helst før næste projekt og senest før næste opgradering:

• Hvor meget kundespecifik logik ligger der i vores ERP-kerne i dag, og kan nogen forklare hvorfor for hver enkelt del?
• Hvad kostede vores seneste opgradering, og hvor stor en del af prisen var vores egne tilpasninger?
• Når forretningen beder om en ændring, hvor lang tid går der så, før den er i drift?
• Hvilke processer er endt i Excel, mail eller sidesystemer, fordi ERP-vejen var for lang?
• Stiller vores partner spørgsmålet "ERP eller Power Platform?", eller bygger de bare, hvor de plejer?
• Hvem ejer de extensions, vi allerede har, og ved vi, hvad der sker med dem efter go-live?

Det er ikke fjendtlige spørgsmål. Det er husets tilstandsrapport.

Lettere for hvert år

Der findes en simpel test af, om et ERP-setup er sundt: Bliver næste opgradering billigere eller dyrere end den forrige?

I de fleste organisationer er svaret dyrere, og det er blevet accepteret som naturlov. Det er det ikke! Det er summen af en lang række små beslutninger, hvor logik blev bygget ind i kernen, fordi det var det nemmeste den dag.

Hvis man vender den om, så man hver gang stiller sig spørgsmålet om hvor det skal bygges og hvad er konsekvensen af det valg, så vendes den kedelig trend. Kernen forbliver standard og følger Microsofts roadmap uden dyre opgraderinger eller udsatte opgraderinger. Forretningslogikken lever i et lag, hvor den kan ændres i det tempo, forretningen faktisk har brug for. Og de dygtige ERP-folk bruger deres tid på kerneprocesserne i stedet for på at vedligeholde fortidens undtagelser.

Dit ERP skal blive lettere med tiden, ikke tungere.