Glöm finjusteringar: Orkestrera din ERP AI

Ha ett samtal med tillverkningschefer om AI, så hör du ett välbekant mål: ”Vi behöver träna en anpassad modell på all vår historiska ERP-data så att den lär sig vår unika verksamhet.”

Tro mig eller ej, men jag hör detta oftare än någonsin nuförtiden. Ledare tror att genom att lägga ner tjugo år av anpassade tabeller, äldre kod och unika arbetsflöden i en stor språkmodell, kommer AI:n magiskt att absorbera deras hemliga ingrediens oavsett vad.

Låt mig vara helt tydlig: detta visar hur dålig den faktiska kunskapen om hur modern artificiell intelligens fungerar är. Ännu viktigare är att det är det snabbaste sättet att bränna massor av pengar på ett fastnat IT-projekt.

Sluta försöka träna GenAI på era äldre ERP-data. Det fungerar inte, och ärligt talat, det är inte nödvändigt.

Låt mig förklara exakt varför finjusteringsfällan kommer att ruinera företagens AI-initiativ, och hur jag råder alla att faktiskt få autonoma agenter att utföra mycket anpassad affärslogik utan att förstöra deras budgetar.

Finjusteringsfällan

När IT-chefer pratar om att lära en AI sina specifika affärsregler, använder de vanligtvis en process som kallas finjustering. Detta innebär att man tar en förtränad modell och aggressivt justerar dess interna vikter (de matematiska kopplingar som avgör hur AI:n tänker och värderar information) genom att mata den med ditt företags mycket anpassade historiska data.

Ur ett arkitekturperspektiv finns det tre kritiska problem med att finjustera en AI på ett äldre ERP-system:

1. Semantisk lucka

AI-modeller är förtränade för att förstå global, standardiserad affärssemantik. De vet hur ett standardiserat order-till-kassaflöde ser ut inom branschen. Om din konkurrensfördel är begravd i en anpassad databastabell som heter t_z_special_discount_v3, kan AI:n läsa texten, men den saknar helt den kontextuella förståelsen för vad tabellen faktiskt gör. Du ber i huvudsak en briljant men generaliserad hjärna att läsa ett språk som bara en pensionerad utvecklare i ditt företag talar.

2. Extrem styvhet

Finjustering innebär i huvudsak att tvinga AI:n att memorera stela mönster. Om din prissättningslogik ändras nästa månad för att anpassa sig till ett nytt marknadsskifte, är din finjusterade modell omedelbart föråldrad. Du tvingas börja om den dyra, tidskrävande träningscykeln igen.

3. Hallucinationsrisken

Jurister är fantastiska på språk, men de är usla på stel matematik och komplexa flödesscheman. Om man försöker tvinga en probabilistisk modell att memorera en 50-stegs proprietär leveranskedjelogik, kan jag garantera att den så småningom kommer att hallucinera och självsäkert utföra fel process i ljusets hastighet.

Om vi ​​inte finjusterar AI:n, hur ska vi få den att förstå och utnyttja vår unika konkurrensfördel?

I en modern företagsarkitektur tränar AI:n på våra affärsregler. Vi kontextualiserar den och ger den verktyg. Vi uppnår detta genom två paradigmer: RAG och funktionsanrop.

RAG (Retrieval-Augmented Generation)

Istället för att tvinga AI:n att memorera era komplexa företagspolicyer, leverantörsavtal eller unika lagerregler använder ni RAG.

Tänk på RAG som att ge AI:n ett examensprov med öppen bok.

Istället för att förändra AI:ns interna hjärna tar du all dokumentation från din hemliga ingrediens (dina standardförfaranden, dina policymanualer, ...) och indexerar den i en säker vektordatabas.

När en planerare frågar AI:n: ”Hur hanterar vi en försenad leverans från leverantör X för just den här produktlinjen?”, gissar inte AI:n baserat på sin förinlärning. Först söker den i din vektordatabas. Den hämtar din exakta, proprietära regel för det specifika scenariot, läser den och formulerar ett svar som kombinerar sin flytande intelligens med dina stela, faktiska regler.

Du tränade aldrig AI:n. Du gav den helt enkelt exakt det dokument den behövde, precis när den behövde det. Om din policy ändras imorgon uppdaterar du bara dokumentet i databasen. Ingen omträning krävs.

Funktionsanrop: Agenten som orkestrator

Även om RAG är fantastiskt för text och företagspolicyer, hur är det med transaktionell affärslogik? Tänk om din hemliga ingrediens är en mycket komplex algoritm som beräknar anpassade fraktkostnader baserat på realtidsbegränsningar med flera variabler?

Du vill absolut inte att en juristexamen ska försöka göra den matematiken. Istället använder du funktionsanrop (Agentic API:er). Det är precis här konceptet med Cloud ERP Extensibility verkligen lyser.

I en modern molnbaserad ERP-miljö som Infor LN är din anpassade affärslogik inte längre begravd i kärndatabasen, utan snarare byggd i systemets utkant som en förlängning, åtkomlig via säkra API:er.

Med Function Callingexponerar du existensen och syftet med din fraktalgoritm direkt för AI:n.

Du förser AI:n med en digital verktygslåda. Du säger till den: ”När en användare ber om att få beräkna anpassade fraktkostnader, försök inte göra matten själv. Anropa detta specifika API, ange destination och vikt och ge sedan användaren tillbaka det exakta numret som returneras.”

AI:n omvandlas till en orkestrator. Den fungerar som en intelligent brygga mellan den mänskliga användaren och din hårdkodade hemliga ingrediens. AI:n hanterar det naturliga språkets avsikt, men din felfria, specialbyggda API-tillägg gör det faktiska grovjobbet.

Avvägningar

För att vara intellektuellt ärliga måste vi erkänna att det inte är en mirakelkur att gå ifrån finjustering och helt förlita sig på RAG och funktionsanrop, och oundvikligen måste vi förr eller senare ta itu med smärtpunkterna. Denna arkitektur kommer med sin egen uppsättning av avvägningar:

• Latens och tokenkostnader: eftersom RAG kräver att AI:n hämtar och läser dina dokument varje gång en fråga ställs, lägger det till millisekunder (eller sekunder) till svarstiden. Dessutom kommer det att förbruka fler tokens om man upprepade gånger skickar stora mängder hämtad kontext till ett LLM API, vilket ökar dina driftskostnader över tid.
• Hämtningsberoende: ett RAG-system är bara så smart som sin sökmotor. Om din vektordatabas hämtar fel företagspolicy kommer AI:n med säkerhet att ge användaren fel svar baserat på det felaktiga sammanhanget.
• Moderniseringsförutsättning: funktionsanrop förutsätter att din ERP-arkitektur är tillräckligt modern för att exponera dina äldre anpassningar som rena, förbrukningsbara API:er. Om din hemliga lösning är hopplöst trasslad i monolitisk äldre kod måste du investera kraftigt i att frikoppla och modernisera den logiken innan en AI-agent någonsin kan orkestrera den.

Mitt slutgiltiga perspektiv

Krisen som äldre ERP-användare står inför under det kommande decenniet handlar inte om att molnsystem kommer att förstöra deras immateriella rättigheter. Den bistra verkligheten är att deras immateriella rättigheter för närvarande är fångade i ett format som artificiell intelligens faktiskt inte kan använda.

Om du vill uppnå en massiv ROI på företags-AI är den arkitektoniska strategin tydlig:

1. Sluta anpassa kärnan i ditt ERP-system. Det betyder inte att du slutar anpassa systemet för att passa dina affärsbehov. Det betyder att du håller grundkoden strikt standardiserad så att AI:n kan läsa den direkt.
2. Sluta försöka finjustera AI-modeller på smutsig äldre data.
3. Tänk om din anpassade kod och bygg om den som externa API:er med moderna tekniker.
4. Ge dina AI-agenter tillgång till dessa API: via funktionsanrop och förankra deras kunskaper med hjälp av RAG.

Er proprietära logik är den mest värdefulla tillgången ert företag äger. Sluta försöka lära ut den till en probabilistisk algoritm. Förvandla den till ett verktyg, ge den till den autonoma agenten och låt intelligensen göra det den gör bäst: orkestrera.

Skriven av Andrea Guaccio 

14 april 2026