Exact Globe Next en Globe+ ontsluiten met Orbis of via een API: wat is het verschil?

Een order komt binnen in een extern systeem. De gegevens moeten naar Exact. Klant controleren. Artikel opzoeken. Verkooporder aanmaken. Misschien nog iets terugmelden naar het oorspronkelijke systeem.

Dat proces kun je op verschillende manieren automatiseren.

Organisaties die al langer met Exact Globe werken, hebben daarvoor bijvoorbeeld processen ingericht met Orbis Software.

Een andere mogelijkheid is om Exact Globe Next of Exact Globe+ rechtstreeks beschikbaar te maken via een API.

Aan de buitenkant kan het resultaat hetzelfde lijken: gegevens gaan automatisch van applicatie A naar Exact.

Technisch zijn het echter twee behoorlijk verschillende uitgangspunten. En dat verschil wordt vooral interessant wanneer er steeds meer applicaties rondom Exact komen te staan.

 

Orbis automatiseert een proces

Orbis Software wordt al jarenlang gebruikt om processen rondom Exact te automatiseren.

Daarbij wordt een proces ingericht waarin verschillende stappen achter elkaar worden uitgevoerd.

Bijvoorbeeld:

bestand ontvangen → gegevens uitlezen → controleren → bewerken → verwerken in Exact → vervolgactie uitvoeren

Daar kan behoorlijk uitgebreide logica in zitten.

En wanneer zo’n proces goed is ingericht, kan het jarenlang een belangrijk bedrijfsproces automatiseren.

De kracht zit dus vooral in het proces.

Er wordt vastgelegd welke stappen moeten worden uitgevoerd om van situatie A naar resultaat B te komen.

 

Een API begint ergens anders

Bij een API is het uitgangspunt anders.

Een API maakt functionaliteit en gegevens van een applicatie rechtstreeks beschikbaar voor andere software.

Een extern systeem kan dan bijvoorbeeld vragen:

“Geef mij deze debiteur.”

“Wat is de actuele informatie van dit artikel?”

of:

“Maak deze verkooporder aan.”

Daarvoor hoeft niet eerst een compleet automatiseringsproces rondom die specifieke vraag te worden gebouwd.

De functionaliteit van Exact wordt als het ware beschikbaar gesteld aan andere applicaties.

Dat is een fundamenteel verschil.

Orbis automatiseert een proces rondom Exact. Een API ontsluit Exact zodat andere applicaties ermee kunnen communiceren.

 

Het verschil wordt duidelijk bij de tweede applicatie

Stel dat een organisatie één extern systeem met Exact wil verbinden.

Daarvoor wordt een Orbis-proces ingericht.

Het werkt.

Vervolgens komt er een webshop bij.

Daarna een WMS.

Later een CRM.

En vervolgens wil ook een BI-oplossing informatie uit Exact gebruiken.

Dan ontstaat een interessante architectuurvraag.

Ga je voor iedere nieuwe behoefte opnieuw een proces bouwen waarmee informatie uit Exact wordt gehaald en verwerkt?

Of maak je Exact één keer op een gestandaardiseerde manier toegankelijk en laat je verschillende applicaties die functionaliteit gebruiken?

Dat laatste is precies het uitgangspunt van een API.

 

Van proces naar beschikbare functionaliteit

Neem het ophalen van een debiteur.

In een traditionele procesgerichte aanpak kan dat onderdeel zijn van een grotere flow.

Er gebeurt iets.

Een proces start.

Het klantnummer wordt opgezocht.

De gegevens worden uit Exact gehaald.

Vervolgens gaat het proces verder.

Via een API wordt het ophalen van die debiteur een zelfstandig beschikbare functie.

Een applicatie kan die functie gebruiken wanneer dat nodig is.

En niet alleen die applicatie.

Een andere applicatie kan hetzelfde endpoint eveneens gebruiken.

Daarmee verandert iets belangrijks: de toegang tot Exact wordt losgekoppeld van één specifiek bedrijfsproces.

 

Dat wordt belangrijk bij best-of-breed

Steeds meer organisaties gebruiken niet één applicatie voor alles.

Exact vormt bijvoorbeeld het financiële of ERP-hart, terwijl daaromheen gespecialiseerde software wordt gebruikt voor:

CRM, e-commerce, warehousemanagement, planning, HRM, BI of branchespecifieke processen.

Dat noemen we vaak een best-of-breedstrategie.

Iedere applicatie doet waar hij goed in is.

Maar dan moeten die applicaties wel gegevens kunnen uitwisselen.

In zo’n landschap wordt het steeds interessanter om Exact niet voor ieder proces opnieuw technisch te ontsluiten.

Je wilt een herkenbare toegang tot Exact waarop meerdere integraties kunnen voortbouwen.

 

Dat is waar Clickker een andere rol speelt

Clickker is geen vervanger van een bestaande Orbis-flow in de betekenis van:

“haal Orbis weg en zet Clickker ervoor terug.”

Het zijn verschillende concepten.

Met Clickker® | De dedicated API voor Exact bieden we API-toegang tot Exact Online, Exact Globe, Globe+ en Exact Financials.

Een externe applicatie kan daarmee via REST-endpoints met Exact communiceren.

Conceptueel:

Applicatie ↔ Clickker ↔ Exact

Daarmee maken we de toegang tot Exact herbruikbaar.

De vraag wat er vervolgens met die informatie moet gebeuren, staat daar los van.

 

Want een API is nog geen proces

Dat onderscheid is belangrijk.

Stel dat een webshop een nieuwe order ontvangt.

Clickker kan de benodigde functionaliteit van Exact beschikbaar maken.

Maar daarmee is nog niet bepaald:

• wanneer de order verwerkt mag worden;
• of de klant eerst gecontroleerd moet worden;
• welke gegevens verplicht zijn;
• hoe artikelen worden gemapt;
• wat er moet gebeuren bij een fout;
• welke informatie uiteindelijk terug moet naar de webshop.

Dat is proceslogica.

En daarvoor gebruiken we binnen Sense-Cloud CAS.

Daarmee ontstaat een scheiding tussen:

Clickker → toegang tot Exact

en

CAS → wat moet er met die toegang gebeuren?

Die scheiding is belangrijk voor hergebruik.

 

Waarom zou je die twee uit elkaar halen?

Omdat dezelfde functionaliteit van Exact in verschillende processen gebruikt kan worden.

Het endpoint waarmee een debiteur wordt opgehaald, hoeft niet speciaal gebouwd te zijn voor één webshopflow.

Het kan ook gebruikt worden door een CRM-integratie.

Of door een WMS.

Of door een andere flow binnen dezelfde organisatie.

Hetzelfde geldt voor artikelen, orders en andere functionaliteit.

Je bouwt daarmee niet alleen een oplossing voor één proces.

Je bouwt een technische basis waarop meerdere processen kunnen draaien.

 

En bestaande Orbis-processen dan?

Daar moeten we vooral praktisch naar kijken.

Als een bestaande Orbis-flow iedere dag probleemloos zijn werk doet, is er niet automatisch een reden om hem morgen te vervangen omdat een API architectonisch moderner is.

Techniek vervangen alleen omdat er nieuwere techniek bestaat, levert geen bedrijfswaarde op.

Interessanter wordt het wanneer een organisatie bijvoorbeeld:

• naar Globe+ migreert;
• nieuwe applicaties wil aansluiten;
• bestaande processen moeilijk kan aanpassen;
• afhankelijk is geworden van specifieke kennis;
• onvoldoende inzicht heeft in bestaande flows;
• of het integratielandschap opnieuw wil structureren.

Dan ontstaat een logisch moment om te kijken:

Willen we bestaande automatisering één-op-één opnieuw bouwen, of willen we Exact voortaan anders ontsluiten?

Dat zijn twee verschillende vragen.

 

Documentatie wordt daarbij belangrijk

Bij oudere integratielandschappen zien we regelmatig nog een praktisch probleem.

Een proces kan jarenlang zijn uitgebreid.

Er is een stap toegevoegd.

Later nog een trigger.

Een uitzondering.

Een extra controle.

Een workaround.

En nog een vervolgproces.

Wanneer dat allemaal goed is gedocumenteerd, kan een volgende specialist relatief snel begrijpen wat er gebeurt.

Maar wanneer die documentatie ontbreekt, wordt migreren lastig.

Dan weten we misschien dat een Orbis-flow een verkooporder verwerkt, maar nog niet hoeveel triggers, controles, uitzonderingen en vervolgstappen daar daadwerkelijk achter zitten.

Je kunt dan niet simpelweg zeggen:

“We bouwen dezelfde flow opnieuw.”

Je moet eerst weten wat die flow werkelijk doet.

Dat is overigens geen probleem dat uniek is voor Orbis.

Het is een risico van iedere lang bestaande automatisering waarvan de proceskennis onvoldoende is vastgelegd.

 

Een migratie is daarom ook een kans

Zeker bij organisaties die van Exact Globe Next naar Globe+ gaan, kan dit een interessant moment zijn.

Je kunt proberen het bestaande landschap zo letterlijk mogelijk mee te nemen.

Maar je kunt ook opnieuw naar de architectuur kijken.

Welke processen bestaan er?

Welke daarvan zijn nog relevant?

Welke functionaliteit van Exact wordt steeds opnieuw gebruikt?

Welke processen kunnen worden vereenvoudigd?

En welke functionaliteit kunnen we voortaan generiek via een API beschikbaar maken?

Dan wordt een migratie meer dan het vervangen van techniek.

Het wordt een kans om technische historie op te ruimen.

 

Orbis of API is dus niet helemaal de juiste vraag

Orbis en een API doen namelijk niet precies hetzelfde.

Orbis is sterk gericht op het automatiseren van processen.

Een API is gericht op het beschikbaar maken van gegevens en functionaliteit aan andere software.

Voor moderne integratielandschappen combineren we die twee verantwoordelijkheden liever bewust:

• Clickker ontsluit Exact.
• CAS bepaalt de flow en proceslogica.
• Watcher bewaakt vervolgens of die integraties en flows functioneren zoals bedoeld.

Daarmee hoeven toegang tot Exact, proceslogica en monitoring niet meer in één specifieke automatisering verweven te raken.

En misschien is dat uiteindelijk wel het belangrijkste verschil.

De vraag is niet alleen:

“Hoe krijgen we deze gegevens vandaag van A naar Exact?”

Maar ook:

“Hoe zorgen we dat Exact morgen eenvoudig met applicatie B, C en D kan communiceren zonder iedere keer opnieuw te beginnen?”

Dat is het verschil tussen een proces automatiseren en een applicatie daadwerkelijk ontsluiten.

Sense-Cloud