Interfaces entre votre système d'information et les PDA de saisie mobiles ?

Stratégies d’évolutions

Vous avez un système d’information de gestion de production (ERP / PGI), ou logistique (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 ce système d’information de gestion ?

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 (PDA) : 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 visons à 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, quelles sont les interfaces possibles ?

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 :

• soit en architecture « 3 tiers »: (exemple d’AX de Microsoft) 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.

• soit en architecture Web : (beaucoup en Opensource, comme Dolibarr) la logique applicative est écrite 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 avantages des terminaux durcis à scanner

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:

1. 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 et écrans ne sont pas prévus pour rapidement accepter des données en rafale avec un scanner, on est donc ramené au cas suivant.
2. en architecture « 3 tiers » : on emploie le mode Offline : voir OFFLINE 1st sur app 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 existe 3 modes d’échanges des données avec les systèmes centralisés de gestion / ERP et une quatrième solution

1. 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 email des fichiers csv modèles et testés d’import et d’export. Ce mode est sous la responsabilité des clients, nous avons toujours un mode d’export et d’import de csv sur nos app, par contre ce mode est fastidieux en exploitation.

2. 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. On ne l’utilise plus pour des questions techniques (mode ancien), de sécurité et de responsabilités.

   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.

3. 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. C’est celui-là qui est favorable aux normes de sécurité et d’exploitation long terme.

   A ce niveau on dispose d’une automatisation complète, propre et simple. Par exemple, voir apps mobiles autour de 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.

4. la quatrième solution sans interface: (ici si nous ne vendons pas de logiciels ne ne vendrons pas de terminaux, ceci est juste une astuce pour vous) si aucune solution n’est prévue dans votre système d’information pour faire des échanges semi-temps réel avec d’autres systèmes code-barres, la seule solution qui reste est de mettre un écran mobile avec scan et une main de libre:

• soit la tablette professionnelle avec un imageur inclus dessous (le plus généralement sous Windows, vérifier et tester avant, et dans le cas d’une architecture web, on peut prendre de l’Android).
• soit une tablette sans imageur inclus et ajouter une bague de scan au doigt, voir types de terminaux mobiles code-barre

Les performances élevées des fonctionnalités que nous installerons avec l’API 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 suivante : ces nouvelles données saisies par le processus mobile doivent-elles et peuvent-elles ê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 de tables pour les stocker, ce n’est pas nécessaire, on peut les mettre dans une base qui sera lue qu’en cas de rappel de produits, soit le plus rarement possible.

Quatre cas s’offrent à vous pour les remontées de données mobiles :

1. ces données sont prévues dans l’ERP : donc pas de soucis, demande le mode d’emploi de l’API
2. 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 pour les 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 / système d’information l’investissement a été lourd ou le changement est impossible : documentez-vous auprès de votre éditeur sur ce qui existe en standard au niveau interfaces de sorties, de possibilité d’accès en lecture directe à la base au moins 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 sont faits dans cet ERP et des catalogues fournisseurs y sont inclus (par exemple dans l’automobile, dans les stores, etc) : pas question de la changer. Alors vous gardez l’outil, vous imprimez vos commandes client et le reste (comme la gestion de stock, la production) peut être realisé en terminal mobile par lecture OCR des références du bon de commande ou BL: nous avons réalisé cette app et sa base de données en ligne : Solution de gestion de stock mobile développée

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