Sådan afgrænser AI-konsulenter en intern SaaS-erstatning

Enhver konsulent med respekt for sin dagsrate afgrænser en intern SaaS-erstatning på samme måde: opdel hvert værktøj i de dele, du kan se, og de dele, der skal være korrekte hver gang. SaaS (software, du lejer på månedsbasis) består for det meste af skærmbilleder, arbejdsgange og rapporter, der ligger oven på en mindre kerne af dataregistrering. AI har gjort den første halvdel billig at genopbygge. Den anden halvdel er dér, hvor erstatningsprojekter dør, og en god afgrænsning har til formål at måle, hvor meget af din abonnementsregning der reelt hører til dér.

Her er, hvordan afgrænsningen af en intern SaaS-erstatning udformes trin for trin, og det ene spørgsmål, der afgør det meste. (Leverandørnavne og undersøgelsestal nedenfor var korrekte ved udgivelsen; betragt de specifikke oplysninger som et øjebliksbillede.)

Hvad indeholder afgrænsningen af en SaaS-erstatning egentlig?

En fortegnelse over opgaver, ikke en funktionsliste. Konsulenten opstiller enhver opgave, værktøjet udfører, hvem der berører hver enkelt, og hvad der sker, når resultatet er forkert. Godkendelsesflow, dashboards og formularer placeres i én kolonne. Pengeoverførsler, lageroptællinger, skat og medarbejderregistreringer placeres i en anden. Det færdige resultat er dette kort, en risikovurdering pr. opgave og en liste over alle de systemer, værktøjet i det skjulte er forbundet med.

Spørgsmålet om risikovurdering er selve kernen: Hvis dette resultat var forkert, hvordan ville du så opdage det, og hvad ville det koste? Et forældet dashboard opdages med et enkelt blik og koster ingenting. En forkert udbetalingssum opdages ved skattetid og koster rigtige penge.

Hvorfor opdele produktet i to lag?

Fordi AI har nedbragt omkostningerne ved det ene lag dramatisk, men ladet det andet være urørt. Grænsefladelaget (formularer, dashboards, interne værktøjer, godkendelsesflow) er nu hurtigt at genopbygge; nuværende modeller genererer fungerende webapps på få timer, hvilket var præcis det, vi opdagede, da vi undersøgte om GPT-5.6 kunne bygge et fungerende POS. Infrastrukturlaget er anderledes: betalingsbehandling, PCI-overholdelse (de kortsikkerhedsregler, indløsere håndhæver), lagerstyring ved samtidighed (to kasser, der sælger den samme sidste enhed) og rapporter, der stemmer (totaler, der matcher dit bankindskud). Det lag er ikke svært, fordi koden er lang. Det er svært, fordi 'næsten rigtigt' er intet værd dér, og det koster mere at bevise korrektheden end at generere koden.

Bedre modeller fjerner heller ikke den begrænsning. Flaskehalsen er verifikation og ansvar, ikke kodegenerering, så en ærlig afgrænsning prissætter verifikationen. Generering er demoen. Verifikation er regningen.

Hvad beviste Klarnas SaaS-erstatning egentlig?

Den mest omtalte historie om 'vi udskiftede vores SaaS med AI' er i virkeligheden en lektion i afgrænsning. I slutningen af 2024 meddelte Klarnas administrerende direktør, at virksomheden droppede Salesforce og Workday som led i en AI-omstilling, og overskrifterne rapporterede, at AI erstattede SaaS fuldstændigt. Opfølgende dækning viste noget mere afgrænset: Klarna flyttede HR til en anden leverandør og dækkede sine CRM-behov med en blanding af alternative værktøjer og intern integration med AI placeret ovenpå¹. En bank med licens, som driver et af de mest aggressive AI-programmer inden for fintech, beholdt stadig sine autoritative datakilder (system of record – den endelige udgave af dine virksomhedsdata) på gennemprøvede platforme og genopbyggede kun i periferien.

Det var ikke et svigt i modet. Det var afgrænsningen, der fungerede.

Hvilke tal retfærdiggør et erstatningsprojekt?

Reducer spild først, byg bagefter. Zylos SaaS Management Index for 2026, baseret på mere end 40 millioner administrerede licenser, sætter de mediane SaaS-udgifter til $9.455 pr. medarbejder om året, viser at i gennemsnit 36 % af licenserne står ubrugte hen, og afslører at forretningsenheder styrer 81 % af SaaS-forbruget, mens IT direkte administrerer 15 %². En konsulent sammenligner din teknologistak med disse tal, før der foreslås noget som helst: annuller de ubrugte licenser, konsolider de overlappende værktøjer, og udvælg først derefter kandidater til genopbygning.

De værktøjer, der slipper igennem nåleøjet, deler samme profil: høje løbende omkostninger, opgaver der primært ligger i grænsefladelaget, og en lille konsekvensradius, hvis noget går i stykker. Projektet bliver godkendt, når abonnementsudgiften vokser hurtigere end omkostningerne ved at bygge og vedligeholde, og enhver opgave, der skal være 100 % korrekt, kan forblive på en infrastruktur, som en anden allerede driver.

Hvor placerer et POS sig i denne afgrænsning?

I den helt nådesløse ende af spektret. Et point of sale ligner et grænsefladeprojekt – et gitter af knapper og en indkøbskurv – så ejere antager, at afgrænsningen svarer til et dashboard. Størrelsesforholdet er imidlertid omvendt. Betalingsskærmen er blot en lille del af produktet; resten er betalinger, certificeret hardware til fysiske kortbetalinger, lagerstyring der fungerer, selvom to kasser sælger samtidig, skatteregler og dagsopgørelser, der stemmer. Når et POS tager fejl, tager det fejl med penge, hver eneste dag.

Derfor afgrænser konsulenter en genopbygning af et POS på samme måde, som Klarna afgrænsede sit hovedbogssystem: tilpasset grænseflade, gennemprøvet infrastruktur. Den opdeling krævede tidligere et udviklerteam. Nu er det en produktkategori: Final's Build forvandler en skriftlig instruktion i almindeligt sprog til et betalingsflow, du kan forhåndsvise og ibrugtage, og du kan tilslutte din egen AI via MCP for at bygge op mod den samme handelsinfrastruktur. Betalingerne, lagerstyringen, rapporteringen og hardwaren forbliver på det lag, der allerede er verificeret.

Så hvordan bør du afgrænse en intern SaaS-erstatning?

Opdel ethvert værktøj i dets to lag, vurder hver opgave ud fra omkostningen ved et uopdaget forkert resultat, og prissæt verifikationen frem for koden. Genopbyg grænseflader og arbejdsgange frit; lad de autoritative datakilder (systems of record) forblive på en infrastruktur, som en anden sørger for er korrekt. Før du genopbygger et værktøj internt, skal du spørge: Hvis resultatet var forkert, hvor hurtigt ville jeg så opdage det? Hvis svaret er "ikke hurtigt", skal den opgave forblive på gennemprøvede skinner.

Og hvis handelsdelen af din teknologistak er den del, du ønsker at genopbygge, så start med et ærligt kig på, hvad nutidens modeller kan og ikke kan bygge på egen hånd: Claude vs ChatGPT vs Gemini i opbygningen af et reelt POS eller de to no-code-muligheder i sådan bruger du Gemini 3.6 Flash til at bygge et tilpasset POS.