Accéder à Exact Globe Next et Globe+ avec Orbis ou via une API : quelle est la différence ?

Une commande arrive dans un système externe. Les données doivent être transférées vers Exact. Vérifier le client. Rechercher l'article. Créer une commande client. Éventuellement renvoyer une information au système d'origine.

Il existe plusieurs façons d'automatiser ce processus.

Les organisations qui utilisent Exact Globe depuis un certain temps ont, par exemple, mis en place des processus à cet effet avec Orbis Software.

Une autre possibilité consiste à rendre Exact Globe Next ou Exact Globe+ directement accessibles via une API.

À première vue, le résultat peut sembler identique : les données sont transférées automatiquement de l'application A vers Exact.

D'un point de vue technique, il s'agit toutefois de deux approches assez différentes. Et cette différence devient particulièrement intéressante à mesure que de plus en plus d'applications s'articulent autour d'Exact.

 

Orbis automatise un processus

Orbis Software est utilisé depuis de nombreuses années pour automatiser les processus liés à Exact.

À cette fin, on met en place un processus dans lequel différentes étapes sont exécutées les unes après les autres.

Par exemple :

réception du fichier → lecture des données → vérification → modification → traitement dans Exact → exécution de l'action suivante

Cela peut impliquer une logique assez complexe.

Et lorsqu'un tel processus est bien conçu, il peut automatiser un processus métier important pendant des années.

La force réside donc avant tout dans le processus.

On définit les étapes à suivre pour passer de la situation A au résultat B.

 

Une API commence ailleurs

Avec une API, le principe de base est différent.

Une API permet à d'autres logiciels d'accéder directement aux fonctionnalités et aux données d'une application.

Un système externe peut alors, par exemple, demander :

“ Donne-moi ce débiteur. ”

“ Quelles sont les informations actuelles contenues dans cet article ? ”

ou :

“ Créez cette commande client. ”

Pour cela, il n'est pas nécessaire de mettre d'abord en place un processus d'automatisation complet autour de cette demande spécifique.

Les fonctionnalités d'Exact sont, pour ainsi dire, mises à la disposition d'autres applications.

C'est une différence fondamentale.

Orbis automatise un processus lié à Exact. Une API permet d'accéder à Exact afin que d'autres applications puissent communiquer avec ce dernier.

 

La différence apparaît clairement lors de la deuxième application

Supposons qu'une organisation souhaite connecter un système externe à Exact.

À cette fin, un processus Orbis sera mis en place.

Ça marche.

Une boutique en ligne sera ensuite mise en place.

Ensuite, un WMS.

Plus tard, un CRM.

Par ailleurs, une solution BI souhaite également exploiter les informations provenant d'Exact.

Cela soulève alors une question architecturale intéressante.

Allez-vous créer à chaque nouveau besoin un nouveau processus permettant d'extraire et de traiter les informations provenant d'Exact ?

Ou bien rendez-vous Exact accessible une seule fois de manière standardisée et laissez-vous différentes applications utiliser cette fonctionnalité ?

C'est précisément là le principe de base d'une API.

 

Du processus à la fonctionnalité disponible

Prenons l'exemple du recouvrement d'une créance.

Dans une approche traditionnelle axée sur les processus, cela peut s'inscrire dans un flux plus large.

Il se passe quelque chose.

Un procès commence.

Le numéro de client est recherché.

Les données sont extraites de Exact.

Le processus se poursuit ensuite.

Grâce à une API, la récupération des données de ce débiteur devient une fonctionnalité accessible de manière autonome.

Une application peut utiliser cette fonction lorsque cela est nécessaire.

Et pas seulement cette application.

Une autre application peut également utiliser ce même point de terminaison.

Cela entraîne un changement important : L'accès à Exact est dissocié d'un processus métier spécifique.

 

C'est un aspect important dans le cadre d'une approche « best-of-breed »

De plus en plus d'organisations n'utilisent plus une seule application pour tout.

Exact constitue par exemple le cœur du système financier ou ERP, tandis que des logiciels spécialisés sont utilisés en complément pour :

CRM, e-commerce, gestion des entrepôts, planification, gestion des ressources humaines, BI ou processus spécifiques à un secteur d'activité.

C'est ce qu'on appelle souvent une stratégie « best-of-broad ».

Chaque application fait ce qu'elle sait faire le mieux.

Mais pour cela, ces applications doivent pouvoir échanger des données.

Dans un tel contexte, il devient de plus en plus intéressant de ne pas avoir à mettre en place une nouvelle intégration technique d’Exact pour chaque processus.

Vous souhaitez disposer d'un accès unique à Exact sur lequel plusieurs intégrations puissent s'appuyer.

 

C'est là que Clickker joue un rôle différent

Clickker ne remplace pas un flux Orbis existant au sens où :

“ Supprimez Orbis et remettez Clickker à la place. ”

Ce sont des concepts différents.

Avec Clickker® | L'API dédiée à Exact Nous proposons un accès via API à Exact Online, Exact Globe, Globe+ et Exact Financials.

Une application externe peut ainsi communiquer avec Exact via des points de terminaison REST.

Sur le plan conceptuel :

Application ↔ Clickker ↔ Exact

Nous rendons ainsi l'accès à Exact réutilisable.

La question de savoir ce qu'il faut faire ensuite de ces informations n'a rien à voir avec cela.

 

Car une API ne constitue pas encore un processus

Cette distinction est importante.

Imaginons qu'une boutique en ligne reçoive une nouvelle commande.

Clickker peut mettre à disposition les fonctionnalités nécessaires d'Exact.

Mais cela ne suffit pas à déterminer :

• quand la commande peut être traitée ;
• si le client doit d'abord faire l'objet d'un contrôle ;
• quelles sont les données obligatoires ;
• comment les articles sont classés ;
• ce qu'il faut faire en cas d'erreur ;
• quelles informations doivent finalement être renvoyées à la boutique en ligne.

C'est la logique du processus.

Et pour cela, nous utilisons, au sein de Sense-Cloud CAS.

Il en résulte une distinction entre :

Clickker → accès à Exact

et

CAS → que faut-il faire de cet accès ?

Cette séparation est importante pour le recyclage.

 

Pourquoi voudrais-tu les séparer ?

En effet, la même fonctionnalité d'Exact peut être utilisée dans différents processus.

L'endpoint permettant de récupérer les informations d'un débiteur n'a pas besoin d'être spécialement conçu pour un flux de boutique en ligne en particulier.

Il peut également être utilisé via une intégration CRM.

Ou via un système de gestion d'entrepôt (WMS).

Ou par un autre processus au sein de la même organisation.

Il en va de même pour les articles, les commandes et les autres fonctionnalités.

Cela ne vous permet pas seulement de mettre en place une solution pour un seul processus.

Vous mettez en place une infrastructure technique sur laquelle plusieurs processus peuvent fonctionner.

 

Et qu'en est-il des processus Orbis existants ?

Il faut surtout aborder cette question d'un point de vue pratique.

Si un flux Orbis existant fonctionne sans problème au quotidien, il n'y a pas forcément de raison de le remplacer demain simplement parce qu'une API est plus moderne sur le plan architectural.

Remplacer une technologie simplement parce qu'il en existe une plus récente n'apporte aucune valeur ajoutée à l'entreprise.

Cela devient plus intéressant lorsqu'une organisation, par exemple :

• migrer vers Globe+ ;
• souhaite connecter de nouvelles applications ;
• peut avoir des difficultés à adapter les processus existants ;
• est devenu dépendant de connaissances spécifiques ;
• n'a pas une connaissance suffisante des flux existants ;
• ou s'il souhaite restructurer le paysage de l'intégration.

C'est alors le moment idéal pour se demander :

Souhaitons-nous recréer à l'identique l'automatisation existante, ou souhaitons-nous désormais exploiter Exact d'une autre manière ?

Ce sont deux questions différentes.

 

La documentation joue ici un rôle important

Dans les anciens environnements d'intégration, on rencontre encore régulièrement un problème pratique.

Un procès peut s'étendre sur plusieurs années.

Une étape a été ajoutée.

Un autre déclencheur plus tard.

Une exception.

Une vérification supplémentaire.

Une solution de contournement.

Et encore un nouveau procès.

Si tout cela est bien documenté, un autre spécialiste pourra comprendre assez rapidement ce qui se passe.

Mais lorsque cette documentation fait défaut, la migration devient difficile.

Nous savons peut-être qu'un flux Orbis traite un ordre de vente, mais nous ne savons pas encore combien de déclencheurs, de contrôles, d'exceptions et d'étapes suivantes il comporte réellement.

On ne peut pas se contenter de dire :

“ Nous reconstruisons le même flux. ”

Il faut d'abord comprendre ce que ce flux fait réellement.

Ce n'est d'ailleurs pas un problème propre à Orbis.

C'est un risque inhérent à tout système d'automatisation en place depuis longtemps dont la connaissance des processus n'est pas suffisamment documentée.

 

Une migration est donc aussi une opportunité

Cela peut constituer une opportunité intéressante, en particulier pour les organisations qui passent d'Exact Globe Next à Globe+.

Tu peux essayer de reproduire le paysage existant de la manière la plus fidèle possible.

Mais on peut aussi porter un regard neuf sur l'architecture.

Quels sont les processus existants ?

Lesquels sont encore d'actualité ?

Quelle fonctionnalité d'Exact est utilisée de manière récurrente ?

Quels processus peuvent être simplifiés ?

Et quelles fonctionnalités pourrons-nous désormais rendre accessibles de manière générique via une API ?

Dans ce cas, une migration ne se limite plus à un simple remplacement technique.

Ce sera l'occasion de faire le tri dans l'histoire de la technologie.

 

La question « Orbis ou API ? » n'est donc pas tout à fait pertinente.

En effet, Orbis et une API ne font pas exactement la même chose.

Orbis met fortement l'accent sur l'automatisation des processus.

Une API a pour objectif de mettre des données et des fonctionnalités à la disposition d'autres logiciels.

Dans le cadre des environnements d'intégration modernes, nous préférons combiner délibérément ces deux responsabilités :

• Clickker accède à Exact.
• CAS détermine le flux et la logique du processus.
• Watcher vérifie ensuite si ces intégrations et ces flux fonctionnent comme prévu.

Ainsi, l'accès à Exact, la logique de processus et la surveillance n'ont plus besoin d'être intégrés dans un seul et même système d'automatisation.

Et c'est peut-être là, en fin de compte, la différence la plus importante.

La question n'est pas seulement :

“ Comment pouvons-nous aujourd’hui transférer ces données de A vers Exact ? ”

Mais aussi :

“ Comment faire en sorte que Exact puisse communiquer facilement demain avec les applications B, C et D sans devoir tout recommencer à zéro à chaque fois ? ”

C'est là toute la différence entre l'automatisation d'un processus et la mise à disposition effective d'une application.

Sense-Cloud