Comment prévoir les interfaces entre ERP et terminaux de saisie mobiles ? Stratégies d’évolutions

Vous avez un ERP (PGI), un WMS et vous voulez faire des saisies intelligentes mobiles par code-barre / Rfid de vos entrées de commandes, expéditions et sorties de stock, traçabilité et voir rapidement le résultat dans cet ERP ou WMS ?

Vous avez vérifié avec votre éditeur qu’il n’a rien à vous proposer par lui-même et vous comptez ajouter cette fonction avec nos logiciels et terminaux : voici alors les demandes à faire et questions à poser d’abord à votre éditeur avant de nous appeler car la question fondamentale à ce stade n’est PAS : « comment il faut le faire ? » MAIS « comment on échange les données ? » et « jusqu’à quel niveau d’automatisation je veux arriver ? »

Présentation des enjeux :

Nous visions à réduire significativement les dépenses d’intégration de nos applications mobiles de traçabilité dans un projet ERP par leur standardisation. Vous êtes ainsi en peu de temps et avec peu de coûts, capable d’optimiser nos services. Mais au-delà des dépenses, il y a la question à répondre avant : est-ce possible d’intégrer avec mon ERP ?

Beaucoup de facteurs d’intégration de solutions de traçabilité mobile dépendent de votre éditeur et de vos choix. Voici donc les éléments qui vous permettent de faire vos demandes à votre éditeur et faire vos choix pour le futur : principes d’échanges, demandes et stratégies.

Principes et types d’échanges des applications mobiles avec les ERP, demandes à faire à votre éditeur en fonction

Les ERP sont en architecture « 3 tiers » (exemple d’AX de Microsoft) :

  1. la base de données : SQL Server,
  2. la logique applicative, en techno standard Microsoft + un langage de développement propriétaire appelé X++,
  3. la couche présentation, dit aussi le "client", installée sur votre PC. Le client standard existe, le client "léger" pour navigateur existe aussi, il permet un peu moins de fonctions.

Ou en architecture Web : (beaucoup en Opensource, comme Dolibarr)

  1. la base de données
  2. la logique applicative en PHP ou Python : mise à disposition d’écrans accessibles par le navigateur « client »

Qu’est-ce qu’un terminal mobile avec scanner intégré ?
Voir paragraphes de : Fiabilisez, tracez vos flux d’exploitation avec des apps mobiles agiles
Nous employons sur ces terminaux leur propre processeur, leur système de bases embarquées et NON leur navigateur.

Impacts sur les échanges des terminaux mobiles avec l’ERP
Ces conseils ou demandes sont plus faciles à faire ou obtenir avant d’acheter un ERP, qu’après : y penser alors au moment du choix de l’ERP.

Notre liaison mobile avec les ERP dépend de leur architecture  :

  • en architecture Web : on est en ligne et on peut accéder aux écrans prévus, s’ils sont « responsives », directement par le navigateur du terminal (et vous n’avez pas besoin de nous). Mais en général leur ergonomie n’est pas prévue pour aller rapidement en rafales avec un scanner, on est donc ramené au cas suivant.
  • en architecture « 3 tiers » : on emploie le mode Offline : voir Les avantages et économies du mode OFFLINE en applications mobiles : on lit ou intègre une partie de la base de ERP concernée par le processus visé, on travaille dessus avec la base locale mobile et on reverse les données en fin de processus.

Il y existe 3 modes d’échanges des données avec les ERP 

  • mode ancien et manuel par « import – export » de fichiers en général au format « csv » (lisibles par Excel) : le terminal mobile va donc lire en automatique lui les fichiers mis à disposition par l’opérateur de l’ERP et écrire en automatique les fichiers à intégrer par l’ERP sur exécution manuelle ou parfois automatisée (demande à faire). Les processus couverts sont donc listés par l’ERP et il suffit de nous faire parvenir par processus des fichiers csv modèles et testés d’import et d’export.
  • mode d’échanges directs par la base de données : les droits sont concédés par l’éditeur par table, par base, par mode : lecture ou écriture. Le mode de connexion OLE DB ou ODBC selon le moteur de base, est alors installé pour les échanges.
    Pour la lecture des données ERP vers les terminaux, cela ne pose pas beaucoup de problèmes de droits et de responsabilités, à condition de demander à l’éditeur l’autorisation de lecture de la base et son "dictionnaire des données".
    En revanche, ni l’éditeur ni nous, ne prenons la responsabilité d’écriture ou de modification directe des données dans la base sous peine de perdre tous les contrôles de cohérence assurés. Il faut donc demander (à l’éditeur), si ce n’est pas prévu, et par processus, de créer une table que l’on dit « pivot » qui permet au terminal d’y déverser ses données et à l’ERP de les intégrer proprement dans sa base par le processus de l’éditeur (développement en général en plus, fait par l’éditeur) qui vide cette table. Une sorte de mode batch aussi, qui n’est pas forcément perçu par l’utilisateur car sa fréquence peut être élevée.
  • le mode d’échanges directs par API : les échanges en écriture et lectures sont intégralement contrôlés en termes de possibilités et de droits par des programmes d’interfaces (« API ») mis à disposition par l’éditeur : là encore la documentation est à demander à l’éditeur.
    A ce niveau on dispose d’une automatisation complète, propre et simple. Par exemple, l’ERP Open Source Dolibarr depuis sa version 10, a un nombre important d’API (inventaire, entrée de marchandise, maintenance sur site et échange de pièces sur machines, picking, sorties de marchandise, mise à jour de type d’emplacements, saisie des temps passés, etc... ) . Dans notre cas, on importe dans la base de données du mobile une table des articles avec ses descriptions, valeurs, photos produits par des commandes propres et on écrit en retour les valeurs saisies par scan, comme un inventaire. L’ERP par ses API, se charge de la cohérence de sa base.

Les performances élevées des fonctionnalités que nous installerons seront un avantage, grâce des liaisons qui n’ont pas besoin d’être synchronisées en temps réel : le mode off-line est très utile dans des zones sans réseau, ou à l’inverse les endroits qui sont rudement sollicités en mode quasi temps réel on-line comme les lignes de picking.

Parallèlement à ces modes, il faut se poser la question de savoir si ces (nouvelles ?) données à saisir du processus peuvent être intégrées dans l’ERP

Exemple : saisir des DLUO (Dates Limites d’Utilisation Optimales) ou DLC, N° de série, etc si l’ERP n’a pas de champs ni te tables pour les stocker.

Quatre cas s’offrent à vous :

  • ces données sont prévues dans l’ERP : donc pas de soucis,
  • ces données ne sont pas prévues dans l’ERP : vous avez donc le choix entre :
    • faire intégrer cette fonction par l’éditeur,
    • changer d’ERP,
    • nous faire ajouter une base de données distincte : la liaison des analyses entre les tables et bases sera à prévoir ensuite.

Stratégies de changements d’ERP en fonction des cas

  • Vous avez acquis récemment un ERP , l’investissement a été lourd ou le changement est impossible : documentez-vous auprès de votre éditeur sur ce qui existe en standard et en fonction des réponses et de votre niveau d’automatisation souhaité, négociez des ajouts : voir les points et questions plus haut, revenez ensuite vers nous.
  • Vous avez un outil qui relève plus d’une gestion commerciale « métier » : des calculs y sont faits et des catalogues fournisseurs y sont inclus (par exemple dans l’automobile, dans les stores, etc) : pas question de la changer. Alors vous la gardez, vous imprimez vos commandes client et le reste (comme la gestion de stock, la production) peut être fait en terminal mobile lié à Dolibarr par lecture OCR des références du bon de commande : vous testez par téléchargement direct sur votre PC, nous réalisons l’hébergement et sauvegardes sur un serveur, le paramétrage et les applications mobiles de scan adaptés si elles ne sont pas en standard.
  • Vous pouvez changer d’ERP alors vous revenez au cas ci-dessus avec la gestion commerciale incluse dans Dolibarr.

Nous pouvons répondre à vos questions particulières.