Realtime koppelen met Exact: wanneer is realtime écht nodig?

Voor 23:59 uur besteld, morgen in huis. Het klinkt als een simpele commerciële belofte. Achter die ene zin gaat alleen een behoorlijk logistiek proces schuil.

Een bestelling die om 23:58 uur binnenkomt, moet misschien binnen enkele seconden beschikbaar zijn in andere systemen. De voorraad moet kloppen. Het warehouse moet weten dat er een order klaarstaat. De order moet worden vrijgegeven voor verwerking en uiteindelijk moet het pakket op tijd bij de vervoerder terechtkomen.

Eén minuut kan dan daadwerkelijk verschil maken.

Voor zo’n organisatie kan realtime gegevensuitwisseling essentieel zijn.

Maar vervolgens spreken we een andere organisatie waar één keer per nacht een BI-dashboard wordt bijgewerkt.

En ook daar horen we:

“Wij willen realtime.”

Waarom eigenlijk?

 

Realtime klinkt altijd beter

Bij integratieprojecten wordt realtime regelmatig als vanzelfsprekend uitgangspunt genoemd.

Als informatie direct beschikbaar kán zijn, waarom zou je dan wachten?

Technisch klinkt daar weinig tegenin te brengen.

Maar een integratie moet geen snelheidswedstrijd zijn.

De relevante vraag is niet:

Hoe snel kunnen we deze data uitwisselen?

Maar:

Hoe snel moet deze data beschikbaar zijn om het bedrijfsproces goed te laten functioneren?

Dat kan een paar seconden zijn.

Maar net zo goed vijf minuten, een kwartier, ieder uur of één keer per nacht.

 

Neem die webshop van 23:58 uur

Die ene blauwe succesvolle webshop die belooft “voor 23:59 uur besteld, morgen in huis” heeft waarschijnlijk een ander logistiek proces dan een groothandel die orders verzamelt en iedere ochtend om 08:00 uur uitlevert.

Bij die eerste organisatie mag je aannemen dat niet alleen de webshop snel moet zijn.

De processen erachter moeten dat ook zijn.

Orderverwerking, voorraad, warehousemanagement, picking, packing en overdracht aan de vervoerder moeten nauw op elkaar aansluiten.

Dan kan het relevant zijn dat een order vrijwel direct na het indrukken van de bestelknop beschikbaar komt in het volgende systeem.

Want als orders bijvoorbeeld maar eens per uur worden uitgewisseld, kan een bestelling van 23:58 uur pas ver na middernacht in het vervolgproces terechtkomen.

Daarmee wordt de frequentie van de integratie ineens onderdeel van de commerciële belofte aan de klant.

Realtime is daar geen technische luxe. Het ondersteunt het bedrijfsmodel.

 

Maar niet ieder proces is een webshop om 23:58 uur

Neem een managementdashboard.

Het management wil iedere ochtend weten wat de omzet, marge en orderportefeuille zijn.

Moeten alle onderliggende gegevens dan iedere seconde worden bijgewerkt?

Waarschijnlijk niet.

Een verwerking ’s nachts kan voor dat proces voldoende zijn.

Of misschien wil een operationeel manager gedurende de dag inzicht en is een update iedere vijftien minuten gewenst.

Ook prima.

Realtime zou technisch mogelijk kunnen zijn, maar levert in zo’n situatie niet automatisch extra bedrijfswaarde op.

Hetzelfde geldt bijvoorbeeld voor bepaalde stamgegevens.

Als een artikelomschrijving wordt aangepast, maakt het dan uit of die wijziging binnen 200 milliseconden, binnen vijf minuten of vannacht in een ander systeem staat?

Dat hangt volledig af van wat dat andere systeem met die informatie doet.

 

Er bestaat dus niet één juiste snelheid

Bij integraties kunnen gegevens op verschillende manieren worden verwerkt.

Realtime of event-driven betekent dat een gebeurtenis vrijwel direct tot actie leidt.

Er komt een order binnen en de verwerking begint.

Daarnaast kun je periodiek verwerken.

Bijvoorbeeld iedere minuut, vijf minuten, vijftien minuten of ieder uur.

En er is batchverwerking, waarbij grotere hoeveelheden informatie op vaste momenten worden verwerkt. Bijvoorbeeld iedere nacht.

Geen van deze modellen is per definitie beter.

Ze horen bij verschillende processen.

 

Voorraad maakt het interessant

Voorraad is een goed voorbeeld.

Stel dat een webshop aangeeft dat er nog één exemplaar beschikbaar is.

Twee klanten proberen dat product vrijwel tegelijkertijd te bestellen.

Dan kan actuele voorraadinformatie behoorlijk belangrijk worden.

Maar zelfs daar moeten we verder kijken dan alleen de integratie.

Welk systeem bepaalt eigenlijk de voorraad?

Is dat Exact?

Het WMS?

De webshop?

En wanneer reserveren we voorraad?

Bij het toevoegen aan het winkelmandje? Bij het plaatsen van de bestelling? Na betaling? Of pas wanneer het warehouse de order verwerkt?

Ineens blijkt de vraag “kunnen jullie de voorraad realtime koppelen?” vooral een procesvraag te zijn.

De techniek komt daarna.

 

Realtime heeft ook een prijs

Meer snelheid betekent meestal ook dat er meer van de architectuur wordt gevraagd.

Meer transacties.

Meer API-verkeer.

Meer gebeurtenissen die moeten worden verwerkt.

Meer aandacht voor foutafhandeling.

En een grotere noodzaak om goed te kunnen zien wat er gebeurt wanneer één van de betrokken systemen tijdelijk niet beschikbaar is.

Bij sommige platformen kunnen bovendien limieten gelden voor het aantal API-aanroepen.

Daarom is “zo snel mogelijk” niet automatisch hetzelfde als “zo goed mogelijk”.

Als een proces prima functioneert met een synchronisatie iedere vijftien minuten, is het weinig zinvol om complexiteit toe te voegen om informatie binnen enkele seconden beschikbaar te krijgen.

 

Begin daarom niet bij de techniek

Bij Sense-Cloud beginnen we liever met een andere vraag.

Niet:

“Willen jullie realtime koppelen?”

Maar:

“Wat gebeurt er als deze informatie vijf minuten later beschikbaar is?”

Is het antwoord:

Dan missen we onze cut-offtijd en kan de bestelling niet meer mee met de vervoerder.

Dan hebben we een goede reden om naar realtime verwerking te kijken.

Is het antwoord:

Eigenlijk niets.

Dan hebben we óók iets geleerd.

Misschien hoeft die integratie helemaal niet realtime te zijn.

 

Verschillende processen mogen verschillende snelheden hebben

Binnen één organisatie kan bovendien prima een combinatie bestaan.

Een webshoporder kan vrijwel direct worden verwerkt.

Voorraad kan iedere minuut worden bijgewerkt.

Artikelinformatie misschien ieder kwartier.

Financiële gegevens kunnen op bepaalde momenten worden verwerkt.

En managementinformatie kan ’s nachts worden klaargezet voor de volgende werkdag.

Dat is geen inconsistente architectuur.

Dat is een architectuur die aansluit op de bedrijfsprocessen.

Met Clickker® | De dedicated API voor Exact kunnen we Exact beschikbaar maken voor externe applicaties en met Clickker Automation Suite kunnen we vervolgens flows inrichten die passen bij die processen.

De gewenste frequentie is daar onderdeel van.

Niet ieder proces hoeft door dezelfde technische mal.

 

Realtime is geen doel

De interessantste integratie is uiteindelijk niet degene die de meeste gegevens in de kortste tijd kan verplaatsen.

Het is degene die precies aansluit op wat de organisatie nodig heeft.

Voor de webshop die om 23:58 uur nog een bestelling accepteert met de belofte dat deze morgen wordt geleverd, kunnen seconden tellen.

Voor het dashboard dat morgenochtend om 08:00 uur wordt geopend, waarschijnlijk niet.

Dus voordat je zegt:

“Wij willen realtime.”

is er eigenlijk één vraag die eerst beantwoord moet worden:

“Wat gebeurt er met ons bedrijfsproces als deze informatie een minuut, een kwartier of een uur later beschikbaar is?”

Het antwoord daarop bepaalt hoe snel de koppeling werkelijk moet zijn.

Niet de techniek.

Sense-Cloud