Fire veje til det samme mål
Beslutningen er truffet: Slut med at flytte ordrer manuelt mellem systemerne. Og her begynder det næste problem, som der tales mindre om. Én leverandør foreslår integration via API. En anden mener, at en natlig eksport af CSV-filer er nok. En branchekollega roser RPA-robotter, der klikker rundt på skærmen i stedet for et menneske, og da en del af dokumenterne alligevel kommer som PDF, frister OCR også. Hver af disse veje kan være god. Ingen af dem er god alle steder.
Hvad selve den manuelle indtastning koster, og hvordan man opgør omfanget, har vi beskrevet i artiklen om, hvor mange timer om ugen teamet mister på at flytte data. Her går vi ud fra, at regnestykket allerede ligger klar. Nu skal forbindelsesmetoden vælges.
API: den direkte forbindelse
Systemerne taler sammen programmatisk: En ordre gemt i ERP-systemet ligger et øjeblik senere i CRM, uden at et menneske rører den. Det er den mest holdbare form for integration, fordi systemproducenten behandler API'et som en officiel aftale. Ændringer varsles, dokumenteres og holdes bagudkompatible.
Et ærligt interval for en enkelt integration er som regel 2-6 uger, og prisen afhænger først og fremmest af antallet af dataflows og dokumentationens kvalitet på begge sider. Vi indrømmer det gerne: API koster mere i starten end et fildump, fordi det kræver udviklingsarbejde og test. Til gengæld er vedligeholdelsen bagefter den billigste af alle fire veje.
Fileksport: enkelhed med fast køreplan
Det ene system skriver hver nat en CSV- eller XML-fil, det andet indlæser den om morgenen. Det lyder gammeldags, men er ofte det mest fornuftige valg: Implementeringen tager fra få dage til to uger og koster mindst. Prisen for enkelheden er forsinkelse. Data flyder én gang i døgnet og som regel kun i én retning. Til at sende fakturaer til bogholderiet rækker det; til lagerbeholdninger i en webshop gør det ikke.
OCR: når data kommer som billeder
Fakturaer fra hundredvis af leverandører, scannede protokoller, papir. OCR med et AI-lag trækker felterne ud af dokumentet og gemmer dem i systemet. Denne vej giver mening, når der ikke er noget at integrere med i den anden ende, fordi afsenderne tælles i snesevis, og man ikke kan påtvinge dem et format. Træfsikkerheden er aldrig 100 %, så en obligatorisk del af implementeringen er en proces, hvor et menneske verificerer undtagelserne. Realistisk tidsramme: 3-8 uger afhængigt af dokumenternes variation.
RPA: robotten, der klikker som et menneske
Et script logger ind i applikationen og udfører de samme bevægelser i brugerfladen, som medarbejderen før udførte. Fordelen er indlysende: Der kræves hverken API eller producentens samtykke, og en fungerende demo står klar på få dage. Det gør ulempen også: Robotten er naglet fast til skærmens udseende. En systemopdatering flytter en knap 20 pixels, og flowet går i stå, ofte helt lydløst. Efter vores opfattelse bør RPA være den sidste mulighed, ikke den første, for den lave startomkostning betaler virksomheden tilbage måned for måned i vedligeholdelse og i nerver efter hver opdatering.
Sammenligningstabel
| Kriterium | API | Fileksport | OCR | RPA |
|---|---|---|---|---|
| Hvornår giver det mening | begge systemer har et API | data behøves én gang i døgnet | dokumenter fra mange afsendere | lukket system uden API |
| Implementeringstid | 2-6 uger | dage til 2 uger | 3-8 uger | dage (demo), uger (produktion) |
| Startomkostning | middel | lav | middel til høj | lav |
| Vedligeholdelsesomkostning | lav | lav, men kræver en ejer | middel (verifikation af undtagelser) | høj |
| Skrøbelighed | lav | lav | middel | høj |
| Dataaktualitet | sekunder | et døgn | minutter til timer | minutter |
Tre faldgruber, vi oftest ser
Den første: RPA oven på en brugerflade, der ændrer sig. Hvis systemleverandøren udsender opdateringer hvert kvartal, går robotten i stykker hvert kvartal. Budgettet til at holde øje med den kan overstige prisen på en ordentlig API-integration.
Den anden: CSV-eksport uden ejer. Filen holder op med at blive genereret, ingen får en alarm, og i to uger arbejder virksomheden på gamle data. En fileksport skal have en navngiven ansvarlig og en automatisk alarm, når filen udebliver.
Den tredje: OCR på dokumenter, der kunne komme digitalt. Hvis samhandelspartneren udsteder fakturaer i et system med API eller via KSeF, er maskinlæsning af deres PDF'er betaling for et kunstigt problem. Det er billigere at aftale et udvekslingsformat.
Beslutningstræ i fire trin
- Har begge systemer et dokumenteret API? Vælg API. Den højere startomkostning tjener sig hjem i vedligeholdelsen.
- Intet API, men data behøves kun én gang i døgnet? Fileksport, med ejer og alarm.
- Kommer data som dokumenter fra mange eksterne afsendere? OCR med en proces til verifikation af undtagelser.
- Lukket system, leverandøren samarbejder ikke, og data skal bruges løbende? Først nu RPA, med budget til vedligeholdelse og en plan for at skifte til API, så snart det findes.
I praksis blander større implementeringer vejene: API mellem ERP og CRM, OCR til leverandørfakturaer, fileksport til datavarehuset. Det er helt normalt. Det vigtige er, at hvert dataflow får et værktøj, der passer til dets karakteristik, og ikke leverandørens ene yndlingsværktøj.
Sådan gør vi det i ESKOM AI
Hos ESKOM AI er valget af integrationsvej en del af analysen, ikke en forudsætning på forhånd. Vi undersøger jeres systemers grænseflader, derefter udfører et team af specialiserede AI-agenter størstedelen af ingeniørarbejdet med at bygge integrationen, og det hele gennemgår den fulde testpakke: unit-, integrations-, E2E-, brugerflade-, sikkerheds- og performancetest. Takket være den automatiserede udviklingsproces taler vi om uger, ikke kvartaler. Hvordan sådan et projekt forløber trin for trin, har vi beskrevet i artiklen om, hvordan man forbinder ERP, CRM og egen applikation på uger.
Står I over for valget mellem de fire veje, så book en gratis konsultation via formularen på eskom.ai/pl/kontakt. Skriv, hvilke systemer I vil forbinde, og hvor hurtigt data skal flyde — så vender vi tilbage med en anbefaling af en konkret vej og et ærligt prisoverslag.