Kazam WMS · plateforme d'entrepôt
SAP gouverne l'entreprise ; l'entrepôt, lui, a besoin d'une couche opérationnelle qui parle aux scanners, aux opérateurs et à l'automatisation. L'erreur classique consiste à demander à l'ERP de faire aussi le travail de terrain — ou au WMS de se substituer à la gestion. Une intégration bien faite rend à chacun son rôle : SAP reste le système de référence, Kazam exécute et restitue les faits.
Comment fonctionne l'intégration
Kazam s'intègre à SAP par un échange de données bidirectionnel : interfaces API et formats d'échange convenus lors de l'analyse, adaptés à la version et à la configuration SAP du client (les modalités précises sont définies dans le projet d'intégration). Le principe, lui, ne change pas :
- De SAP vers Kazam : fiches articles, commandes d'achat et de vente, ordres de fabrication à servir depuis l'entrepôt.
- De Kazam vers SAP : confirmations de réception, mouvements et ajustements de stock, confirmations de prélèvement et d'expédition, données de traçabilité (lots, numéros de série, dates de péremption).
Les stocks restent alignés en temps quasi réel : SAP n'a pas à savoir dans quelle allée se trouve la palette, Kazam n'a pas à émettre de factures. À chacun son métier.
Ce qui change dans l'entrepôt
Avec Kazam devant SAP, les opérateurs travaillent sur des terminaux Android avec des missions guidées (réception, mise en stock, préparation, inventaire) plutôt que sur des transactions ERP ; le WES ordonne les priorités en temps réel ; et s'il y a de l'automatisation — navettes, trieurs, AGV — le WCS la pilote directement en OPC-UA, Modbus, FINS ou VDA 5050, ce qu'un ERP ne fait pas. La différence entre les trois niveaux est expliquée dans le guide WMS, WES et WCS.
L'inverse vaut aussi : Kazam ne fait ni comptabilité, ni prévision de la demande, ni gestion des fournisseurs, et il n'essaie pas. Si l'entrepôt est déjà bien tenu par le module de l'ERP et qu'il n'y a aucune automatisation à piloter, ajouter une couche supplémentaire serait un coût sans bénéfice correspondant.
Ce qui transite, concrètement
SAP et l'entrepôt ne se parlent pas directement. Entre les deux se trouve une zone d'échange : une base de données distincte de la base opérationnelle. L'ERP y écrit quand il a quelque chose à communiquer, Kazam la relit à intervalles configurables — de l'ordre de quelques secondes — et y renvoie les faits. Aucun des deux ne reste suspendu à l'autre : si l'entrepôt est à l'arrêt pour maintenance, SAP continue d'écrire et retrouve tout en file d'attente à la reprise.
Les familles de données sont au nombre de cinq : fiches des références, clients, adresses de livraison, documents de travail avec leurs lignes, et unités de charge avec leur composition.
Chaque ligne déposée porte un état : à lire, importée, ou écartée parce que dépassée. Cela sert à deux choses. La première, c'est que chaque importation est rejouable. Si le service s'interrompt en cours de route, il ne reprend à la relance que ce qu'il n'avait pas encore traité, sans rien dupliquer. La seconde concerne les mises à jour rapprochées. Si SAP réécrit trois fois la même fiche avant que Kazam ne la lise, c'est la dernière version qui entre ; les précédentes restent marquées comme dépassées, avec la date et le motif. Il n'y a aucune file à remettre en ordre à la main.
Comment vérifier que les comptes sont justes
Chaque document d'entrepôt conserve la référence au document SAP qui l'a généré, en en-tête et sur chaque ligne. Ce n'est pas un détail d'implémentation : c'est ce qui rend l'intégration vérifiable sans garder deux écrans ouverts et les comparer à l'œil.
Les API de Kazam s'interrogent avec la clé de SAP, pas avec une numérotation interne. On demande l'état d'un document en citant le numéro que l'ERP connaît déjà, et on obtient ce qui a été fait dans l'entrepôt. De la même manière, on lit où se trouve une référence ou une unité de charge. L'accès est authentifié par jeton.
C'est cela que l'on contrôle en recette. On prend un échantillon de documents et on compare ce que SAP a envoyé avec ce que l'entrepôt a exécuté. Tant que les deux côtés ne coïncident pas, on ne passe pas en production — et entre-temps l'entrepôt continue de travailler comme avant.
Questions fréquentes
Faut-il modifier SAP pour utiliser Kazam ?
Non : l'intégration passe par des interfaces, sans modification du cœur de SAP. La configuration des formats d'échange est définie avec l'équipe informatique du client pendant l'analyse.
Qui reste le « propriétaire » des stocks ?
SAP reste le système comptable de référence ; Kazam gère le stock opérationnel par emplacement et le réconcilie vers l'ERP avec les mouvements confirmés.
Cela fonctionne-t-il avec n'importe quelle version de SAP ?
L'approche par interfaces s'adapte aux différentes versions et configurations ; la faisabilité précise s'évalue lors de la première analyse technique (gratuite — parlez à un ingénieur).
Et si l'automatisation arrive demain ?
Rien à refaire : le WES et le WCS sont des modules de la même plateforme. L'intégration SAP reste identique ; on active le pilotage des machines le jour où il faut.
Kazam est la plateforme source-available qui couvre WMS et WES et s’intègre avec Sun Tech WCS. Parlez à un ingénieur pour une évaluation de l'intégration avec votre SAP.