Hvad ændrer sig i det daglige arbejde?
Det får teamet ud af det
En tydelig kilde til oplysningerne
Vi aftaler, hvilket system der har ansvaret for hver værdi. Så cirkulerer en ændring af kundens adresse eller en ordres status ikke endeløst mellem programmerne.
Forudsigelig dataudveksling
Data kontrolleres og tilpasses modtagerens format. Vi aftaler opdateringshyppighed og måden, gentagne hændelser genkendes på.
Fejl bliver synlige for den rette person
Et utilgængeligt API eller en afvist post sendes til håndtering. Synkroniseringshistorikken hjælper med at skelne en forsinkelse fra et problem, der kræver en beslutning.
En forbindelse begynder med dataenes betydning.
Det samme felt kan betyde forskellige ting i to programmer. En “leveringsdato” kan være planlagt, faktisk eller lovet kunden. Før vi forbinder systemerne, aftaler vi begreber, identifikatorer og opdateringsregler. Ellers risikerer automatiseringen blot at sprede misforståelser hurtigere.
Vi undersøger også, hvor oplysningerne opstår, og hvem der må ændre dem. Kunde-, ordre- eller partinummeret skal gøre det muligt at forbinde poster entydigt. Når data er ufuldstændige, har integrationen brug for en regel: afvis posten, markér den til supplering, eller send den videre med en aftalt begrænsning. Erfaring med kontor-, produktions- og lagerprocesser hjælper os med at opdage forskelle, som den tekniske dokumentation alene ikke viser.
- Overførsel af henvendelser og ordrer til driftssystemet.
- Visning af statusser og dokumenter i kundeportalen.
- Rapporter med data fra forskellige værktøjer.
- Import og eksport mellem filer, API’er og databaser.
API, fil eller database? Vi vælger ud fra de reelle muligheder.
Først undersøger vi dokumentation og adgang hos leverandøren. Et API kan kræve et bestemt abonnement, have begrænsninger eller kun give adgang til en del af dataene. Hændelser fra systemet gør det muligt at reagere hurtigt, mens en planlagt filimport kan være tilstrækkelig til en rapport, der udarbejdes én gang om dagen.
Direkte adgang til databasen kræver særlig omtanke og aftale med systemets ejer. Vi foretrækker understøttede måder at udveksle data på. Vi lover ikke integration med et vilkårligt program, før vi har undersøgt dets grænseflader, adgangsbetingelser og testmiljø.
Synkroniseringen skal kunne komme sikkert tilbage efter en afbrydelse.
Netværket kan afbryde forbindelsen, efter at data er gemt, men før bekræftelsen er modtaget. Et nyt forsøg må ikke oprette endnu en ordre. Vi planlægger identifikation af hændelser, dubletkontrol og en måde at afgøre, hvilke oplysninger der er nået frem til modtageren.
Vi aftaler regler for nye forsøg, begrænsninger og behandlingsrækkefølge. Hvis svarformatet ændres eller adgangsrettighederne udløber, skal der være en tydelig besked og en ansvarlig for problemet. Det er også vigtigt at kunne sammenligne begge systemers tilstand efter et længere nedbrud frem for alene at stole på enkelte beskeder.
Begynd med én retning og én type data.
At udveksle alt i begge retninger er ofte et unødigt bredt udgangspunkt. Første etape kan sende en godkendt ordre videre til udførelse og hente dens status tilbage. Det gør det muligt at afprøve identifikatorer, rettigheder og fejlhåndtering, før dokumenter, rettelser og flere systemer kommer til.
- Oplys programmernes navne og de tilgængelige versioner eller abonnementer.
- Angiv, hvilke data der skal overføres, og i hvilken retning.
- Fastlæg den acceptable forsinkelse i opdateringer.
- Find den person, der administrerer hvert af systemerne.
Fra den første samtale til idriftsættelsen
Kontrol af adgang
Vi undersøger grænseflader, leverandørbegrænsninger og eksempeldata. Vi aftaler, hvilket system der har ansvaret for hver oplysning, der synkroniseres.
Datakortlægning og afprøvning
Vi bygger den første datastrøm i et aftalt miljø. Vi tester gentagelser, manglende værdier, afbrydelser og afvisninger.
Idriftsættelse og tilsyn
Vi aktiverer dataudveksling, hændelseshistorik og fejlhåndtering. Vi aftaler, hvordan ændringer hos eksterne leverandører håndteres.
Spørgsmål, der er værd at stille
Bliver data synkroniseret i realtid?
Det afhænger af systemernes muligheder og processens behov. Nogle integrationer reagerer på hændelser, mens andre henter data med faste intervaller. Vi aftaler acceptabel forsinkelse og håndtering, når datakilden er utilgængelig.
Kan integrationen fungere i begge retninger?
Ja, hvis grænsefladerne understøtter det, og vi aftaler, hvordan ændringer skal afgøres. Det skal være klart, hvem der ejer dataene, og hvad der sker, hvis to personer ændrer samme oplysning i forskellige systemer.
Hvad sker der, hvis leverandøren ændrer sit API?
Integrationen kan kræve en opdatering. Vedligeholdelsen bør derfor omfatte overvågning af fejl, dokumentation af forbindelsen og ansvar for tilpasning til leverandørens ændringer.
Skal vi udveksle alle vores data?
Som regel ikke. Det er bedre at overføre de oplysninger, en konkret opgave har brug for. Et mindre og tydeligt beskrevet omfang gør rettighedskontrol, fejlanalyse og senere videreudvikling lettere.