Intégration en temps réel avec Exact : quand le temps réel est-il vraiment nécessaire ?

Commande passée avant 23 h 59, livraison le lendemain. Cela ressemble à une simple promesse commerciale. Mais derrière cette simple phrase se cache en réalité un processus logistique complexe.

Une commande reçue à 23 h 58 doit parfois être disponible dans d'autres systèmes en quelques secondes. Le stock doit correspondre. L'entrepôt doit savoir qu'une commande est prête. La commande doit être validée pour traitement et, enfin, le colis doit parvenir à temps au transporteur.

Une minute peut alors vraiment faire la différence.

Pour une telle organisation, l'échange de données en temps réel peut s'avérer essentiel.

Mais nous avons ensuite discuté avec une autre organisation où un tableau de bord BI est mis à jour une fois par nuit.

Et là aussi, on entend :

“ Nous voulons du temps réel. ”

Mais pourquoi, au juste ?

 

Le « en temps réel » sonne toujours mieux

Dans le cadre des projets d'intégration, le temps réel est souvent cité comme un principe de base allant de soi.

Si les informations peuvent être disponibles immédiatement, pourquoi attendre ?

D'un point de vue technique, il semble difficile de contester cela.

Mais l'intégration ne doit pas être une course à la vitesse.

La question pertinente n'est pas :

À quelle vitesse pouvons-nous échanger ces données ?

Mais :

Dans quel délai ces données doivent-elles être disponibles pour assurer le bon fonctionnement du processus métier ?

Cela peut prendre quelques secondes.

Mais ça peut tout aussi bien être cinq minutes, un quart d'heure, toutes les heures ou une fois par nuit.

 

Prenez cette boutique en ligne de 23 h 58

Cette boutique en ligne bleue à succès qui promet “ commandé avant 23 h 59, livré demain ” dispose probablement d'un processus logistique différent de celui d'un grossiste qui regroupe les commandes et effectue les livraisons tous les matins à 8 h.

Dans cette première entreprise, on peut supposer que ce n'est pas seulement la boutique en ligne qui doit être rapide.

Les processus sous-jacents doivent l'être également.

Le traitement des commandes, la gestion des stocks, la gestion des entrepôts, la préparation des commandes, l'emballage et la remise au transporteur doivent être parfaitement coordonnés.

Dans ce cas, il peut être pertinent qu'une commande soit disponible dans le système suivant pratiquement immédiatement après avoir cliqué sur le bouton de commande.

En effet, si les commandes ne sont échangées qu'une fois par heure, par exemple, une commande passée à 23 h 58 ne pourra être traitée que bien après minuit.

La fréquence de l'intégration fait ainsi soudainement partie intégrante de la promesse commerciale faite au client.

Le temps réel n'est pas un luxe technique dans ce contexte. Il soutient le modèle économique.

 

Mais toutes les procédures ne concernent pas forcément une boutique en ligne à 23 h 58.

Prenons l'exemple d'un tableau de bord de gestion.

Chaque matin, la direction souhaite connaître le chiffre d'affaires, la marge et le carnet de commandes.

Faut-il alors mettre à jour toutes les données sous-jacentes toutes les secondes ?

Probablement pas.

Un traitement nocturne peut suffire pour ce processus.

Ou peut-être qu'un responsable opérationnel souhaite disposer d'informations tout au long de la journée et qu'une mise à jour toutes les quinze minutes est souhaitable.

Ça me va aussi.

Le temps réel pourrait être techniquement possible, mais n'apporte pas automatiquement une valeur ajoutée à l'entreprise dans une telle situation.

Il en va de même, par exemple, pour certaines données de base.

Si la description d'un article est modifiée, est-ce que cela a de l'importance que cette modification soit répercutée dans un autre système dans les 200 millisecondes, dans les cinq minutes ou cette nuit ?

Cela dépend entièrement de ce que cet autre système fait de ces informations.

 

Il n'y a donc pas une seule vitesse idéale

Dans le cadre des intégrations, les données peuvent être traitées de différentes manières.

En temps réel ou piloté par les événements cela signifie qu'un événement entraîne presque immédiatement une réaction.

Une commande arrive et son traitement commence.

Tu peux également effectuer un traitement périodique.

Par exemple, toutes les minutes, toutes les cinq minutes, toutes les quinze minutes ou toutes les heures.

Et il y a traitement par lots, ce qui implique le traitement de volumes importants d'informations à des moments fixes. Par exemple, chaque nuit.

Aucun de ces modèles n'est meilleur par définition.

Ils font partie de différents processus.

 

C'est le stock qui rend l'offre intéressante

Les stocks en sont un bon exemple.

Imaginons qu'une boutique en ligne indique qu'il ne reste plus qu'un seul exemplaire disponible.

Deux clients tentent de commander ce produit presque simultanément.

Dans ce cas, disposer d'informations actualisées sur les stocks peut s'avérer très important.

Mais même dans ce domaine, nous devons voir plus loin que la simple intégration.

Quel système détermine en fait le niveau des stocks ?

Est-ce Exact ?

Le WMS ?

La boutique en ligne ?

Et quand faut-il constituer des stocks ?

Lors de l'ajout au panier ? Lors de la passation de la commande ? Après le paiement ? Ou seulement lorsque l'entrepôt traite la commande ?

Tout à coup, la question se pose “ Pouvez-vous synchroniser les stocks en temps réel ? ” il s'agit avant tout d'une question de procédure.

La technique viendra ensuite.

 

Le temps réel a aussi un coût

Une vitesse accrue implique généralement aussi des exigences plus élevées en matière d'architecture.

Davantage de transactions.

Augmentation du trafic API.

D'autres événements à traiter.

Accorder davantage d'attention à la gestion des erreurs.

Et un besoin accru de pouvoir bien voir ce qui se passe lorsqu'un des systèmes concernés est temporairement indisponible.

Sur certaines plateformes, des limites peuvent en outre s'appliquer au nombre d'appels API.

C'est pourquoi “ dès que possible ” ce qui ne signifie pas nécessairement que “ du mieux possible ”.

Si un processus fonctionne parfaitement avec une synchronisation toutes les quinze minutes, il n'y a guère d'intérêt à le compliquer pour que les informations soient disponibles en quelques secondes.

 

Ne commencez donc pas par la technique

Chez Sense-Cloud, nous préférons commencer par une autre question.

À ne pas faire :

“ Voulez-vous établir une connexion en temps réel ? ”

Mais :

“ Que se passerait-il si ces informations n'étaient disponibles que cinq minutes plus tard ? ”

La réponse est-elle :

Dans ce cas, nous dépasserons l'heure limite et la commande ne pourra plus être expédiée par le transporteur.

Nous avons donc une bonne raison de nous intéresser au traitement en temps réel.

La réponse est-elle :

En fait, rien.

Dans ce cas, nous avons nous aussi appris quelque chose.

Peut-être que cette intégration n'a pas besoin d'être en temps réel.

 

Les différents processus peuvent avoir des vitesses différentes

Au sein d'une même organisation, il est d'ailleurs tout à fait possible de combiner ces deux approches.

Une commande passée sur une boutique en ligne peut être traitée presque immédiatement.

Le stock peut être mis à jour à chaque minute.

Des informations sur les articles, peut-être toutes les quinze minutes.

Les données financières peuvent être traitées à certains moments.

Les informations de gestion peuvent être préparées pendant la nuit pour le lendemain.

Ce n'est pas une architecture incohérente.

Il s'agit d'une architecture qui s'adapte aux processus métier.

Avec Clickker® | L'API dédiée à Exact nous pouvons rendre Exact accessible aux applications externes et, grâce à Clickker Automation Suite Nous pouvons ensuite mettre en place des flux adaptés à ces processus.

La fréquence souhaitée en fait partie.

Tous les processus ne doivent pas nécessairement passer par le même moule technique.

 

Le temps réel n'est pas un objectif

Au final, l'intégration la plus intéressante n'est pas celle qui permet de transférer le plus de données en un minimum de temps.

C'est celui qui correspond exactement aux besoins de l'organisation.

Pour une boutique en ligne qui accepte encore une commande à 23 h 58 en promettant de la livrer le lendemain, chaque seconde peut compter.

Pour le tableau de bord qui sera mis en ligne demain matin à 8 h, probablement pas.

Alors, avant de dire :

“ Nous voulons du temps réel. ”

Il y a en fait une question à laquelle il faut d'abord répondre :

“ Quelles seraient les conséquences sur nos processus opérationnels si ces informations n'étaient disponibles qu'une minute, un quart d'heure ou une heure plus tard ? ”

La réponse à cette question détermine la vitesse réelle que doit avoir l'accouplement.

Ce n'est pas une question de technique.

Sense-Cloud