Waarom uw systemen uit de pas gaan lopen en wat u eraan doet

Een bestelling staat in de webshop op betaald, maar blijft in het ERP openstaan. Een klant wijzigt zijn adres in het portaal en krijgt het pakket alsnog op het oude adres bezorgd. Zulke verschillen kosten zelden alleen even herstelwerk. Er gaat een verkeerde mail uit, iemand neemt een beslissing op cijfers die niet kloppen, en het vertrouwen in de eigen systemen brokkelt af.

Wat ons bij dit soort meldingen opvalt: de koppeling zelf is meestal niet kapot. Bedrijven draaien op een stapel systemen met elk hun eigen logica, veldnamen en tempo. Webshop, CRM, boekhouding, voorraadbeheer, planningstool, app, klantportaal. Zolang het rustig is valt daar niets van op. Pas bij een piek, een update of een order die net even anders loopt blijkt of de afspraken tussen die systemen ergens zijn vastgelegd of alleen in iemands hoofd zaten.

Waar het meestal misgaat

Synchroniseren is meer dan een record van A naar B duwen. Er moet vastliggen welk systeem gelijk heeft bij twijfel, wanneer een wijziging wordt verwerkt, wat er gebeurt als dat niet lukt en hoe u omgaat met dubbele of botsende gegevens. Ontbreekt een van die vier, dan lopen uw systemen uit elkaar. Niet meteen, maar wel onvermijdelijk.

Niemand heeft bepaald welk systeem gelijk heeft

Dit komen we het vaakst tegen. Een klant kan zijn telefoonnummer aanpassen in het CRM en in het portaal. Schrijven beide kanten terug zonder vaste regel, dan wint niet de nieuwste wijziging maar degene die toevallig als laatste langskomt. Zo verdwijnt een correctie zonder dat iemand het merkt, tot een collega belt met een nummer dat al maanden niet meer in gebruik is.

Wijs daarom per soort gegeven een eigenaar aan. Het CRM voor klantgegevens, het ERP voor facturen en voorraad, de webshop voor bestellingen. Die verdeling hoeft niet heilig te zijn, maar hij moet wel ergens opgeschreven staan. Zonder eigenaar is een conflict tussen twee systemen geen incident, maar een kwestie van tijd.

API's hebben ook slechte dagen

Een API is geen belofte dat elk verzoek meteen en onbeperkt wordt uitgevoerd. Er gelden limieten op het aantal aanvragen, er is onderhoud, en soms blijft een verzoek gewoon hangen. Vervelend detail bij een time-out: u weet niet of de andere kant niets heeft gedaan of de wijziging half heeft verwerkt.

Een koppeling die na de eerste foutmelding opgeeft, is daar niet tegen bestand. Een goede integratie probeert het opnieuw met oplopende tussenpozen, houdt per bericht bij hoe het is afgelopen en zorgt dat dezelfde order niet vijf keer wordt aangemaakt. Dat laatste heet idempotentie: hetzelfde verzoek twee keer versturen levert precies een mutatie op. Het klinkt als een detail voor ontwikkelaars, maar het is het verschil tussen een storing en een dubbele levering.

De wijziging wordt niet opgemerkt

Veel koppelingen vragen elk kwartier op wat er sinds de vorige ronde is veranderd. Dat werkt prima, totdat twee systemen in een andere tijdzone staan, een wijzigingsdatum alleen tot op de minuut wordt bijgehouden of een record pas later definitief wordt opgeslagen. Een mutatie die precies op de grens van twee rondes valt, glipt er dan tussendoor. Zoiets vindt u niet terug in de logging, want er is niets misgegaan. Er is alleen niets gebeurd.

Webhooks helpen, omdat het bronsysteem meteen een seintje geeft. Alleen kan zo'n seintje ook verdwijnen, dubbel binnenkomen of in de verkeerde volgorde arriveren. In de praktijk werkt een combinatie het best: webhooks voor alles wat snel moet, plus een controleronde die periodiek naast elkaar legt wat beide systemen denken en de verschillen rechttrekt.

Hetzelfde veld, een andere betekenis

Een veld dat status heet zegt op zichzelf niets. In het ene systeem betekent het dat er betaald is, in het andere dat het pakket de deur uit is. Hetzelfde geldt voor valuta, btw-tarieven, productvarianten en klanttypen. De data kan technisch perfect aankomen terwijl de betekenis onderweg is gesneuveld, en dat merkt u pas als de omzetrapportage niet meer aansluit.

Een mapping van veld A naar veld B is daarvoor te weinig. Leg ook vast welke waarden zijn toegestaan, hoe uitzonderingen worden vertaald en wat het ontvangende systeem doet met een waarde die het niet kent. Stil negeren is bijna altijd de verkeerde keuze, apart zetten en melden bijna altijd de goede. Bij internationale verkoop of samengestelde producten is die vertaallaag geen bijzaak maar het halve werk.

Een update haalt een stille aanname onderuit

Leveranciers wijzigen API-versies, maken velden verplicht en vervangen authenticatiemethoden. Een plugin-update of een release van uw eigen backend kan hetzelfde effect hebben. Draait de koppeling op aannames die nergens staan opgeschreven, dan hoort u het pas als er orders blijven hangen. Meestal op vrijdagmiddag.

Versiebeheer, een acceptatieomgeving en fatsoenlijke monitoring vangen dit af. Niet elke wijziging hoeft een project te worden. Maar alles wat een kritieke datastroom raakt verdient een test op een omgeving waar niemand er last van heeft, voordat het naar productie gaat.

Merk het voordat uw klant het merkt

Een geslaagde API-call betekent niet dat de gegevens kloppen. Technische logging vertelt u dat een bericht is aangekomen, niet dat het juiste bedrag is geboekt. Meet daarom ook op bedrijfsniveau. Sluit het aantal betaalde orders in de webshop aan op wat het ERP verwerkt? Wijkt de voorraad in het magazijn structureel af van wat online staat?

Maak daarbij onderscheid tussen een incident en een patroon. Twee minuten vertraging is prima. Een order die er na een uur nog niet doorheen is, vraagt om iemand die kijkt. Voorraad die een keer per nacht wordt bijgewerkt kan bij een groothandel uitstekend werken en tegelijk onbruikbaar zijn voor een webshop die daardoor uitverkochte artikelen blijft verkopen.

Zet die grenzen in gewone taal op papier. Welke gegevens moeten vrijwel direct kloppen, wat mag later volgen, en wie kijkt naar de uitzonderingen? Anders krijgt u het gesprek waarin IT zegt dat de koppeling het doet terwijl de klantenservice blijft bellen. Allebei waar, en dat is precies het probleem.

Wat een koppeling wel betrouwbaar maakt

Een nieuw integratieplatform is lang niet altijd het antwoord. Vaak is een bestaande koppeling prima te redden met betere foutafhandeling en wat meer inzicht. Soms is maatwerk nodig, omdat de standaardplugin nooit is gebouwd voor een orderproces als het uwe. Wat verstandig is hangt af van de hoeveelheid data, de schade bij een fout en hoe snel het proces echt moet zijn.

Begin met een eerlijke inventarisatie. Niet alleen van de systemen, maar van de werkelijke datastromen: wat gaat waarheen, langs welke route, hoe vaak en met welke bedrijfsregel? Let vooral op de Excel-import die iemand elke maandag doet, het mailadres waar bestellijsten binnenkomen en het scriptje dat ooit tijdelijk was. Dat zijn ook integraties, alleen staan ze op niemands tekening.

In elke opzet die het houdt zitten minstens vier onderdelen:

• Een eigenaar per soort gegeven, met een vaste regel voor conflicten.
• Een wachtrij, zodat een systeem dat even plat ligt geen mutaties kost.
• Herhaalpogingen plus een plek waar berichten belanden die echt handwerk nodig hebben.
• Monitoring op techniek en op cijfers: aantallen, bedragen, voorraadverschillen.

En test daarna vooral de uitzonderingen. Wat gebeurt er als een klant twee keer betaalt? Als een product uit de catalogus verdwijnt terwijl er nog orders openstaan? Als een retour binnenkomt voordat de order is verwerkt? Als een externe API een uur niets doet? Wie die scenario's vooraf heeft doorlopen, heeft bij een storing een procedure in plaats van een crisis.

Realtime of op vaste momenten

Realtime hoort bij gegevens die een klant direct ziet of die geld raken: voorraad, betalingen, toegangsrechten. Daar is het de moeite waard, ook al vraagt het meer van uw infrastructuur en foutafhandeling. Rapportages, historische gegevens en mutaties zonder directe gevolgen kunnen prima in een periodieke ronde mee.

De valkuil is realtime als kwaliteitsstempel voor alles. Een verwerking die binnen vijf minuten rond is, met een zichtbare status en automatisch herstel, is voor de meeste processen meer waard dan een directe koppeling die het bij piekdrukte laat afweten. Snelheid die alleen op rustige dagen wordt gehaald is geen snelheid.

Handmatig herstel is een meetwaarde

Dat een medewerker af en toe iets rechtzet is geen ramp. Maar zodra er dagelijks orders worden opgezocht, klantgegevens vergeleken en voorraden bijgesteld, betaalt u een technisch probleem af in uren. Met een bijkomend risico: na een tijdje is er nog maar een iemand die weet welke afwijkingen normaal zijn. Gaat die persoon op vakantie, dan gaat het inzicht mee.

Gebruik dat handwerk als aanwijzing. Welke fout komt elke week terug? Waar ontbreekt een status waardoor niemand kan zien hoe ver een order is? Welk systeem geeft te weinig informatie om een probleem snel op te lossen? Vaak is een klein intern overzicht, een duidelijkere foutmelding of een gerichte aanpassing aan de koppeling al genoeg om uren per week terug te winnen.

Bij LJPc kijken we daarom niet alleen naar de verbinding tussen twee systemen, maar naar het proces dat erop draait. Ontwikkeling, hosting en beheer horen wat ons betreft bij elkaar. Als een koppeling onder druk hapert, moet iemand in de applicatie, de database, de wachtrij en de infrastructuur kunnen kijken zonder dat drie partijen eerst naar elkaar wijzen.

Een koppeling die goed staat valt niet op. Uw mensen zien kloppende informatie, klanten krijgen de juiste status en de uitzonderingen komen terecht bij iemand die er iets mee kan. Dat is geen geluk en ook geen luxe. Het is het resultaat van een paar duidelijke keuzes, controles die u kunt nalezen en iemand die problemen oplost voordat ze zich opstapelen.