Pour ma part, j’ai pu constater les risques en participant activement à une douzaine de démarrage sur SAP ECC (surtout autour de WM). J’ai commencé chez un grossiste alimentaire (Groupe POMONA), où la conception et le déploiement avaient été réalisés par des équipes mixtes entres internes et consultants d’un grand intégrateur. J’ai donc démarré à la Direction Supply Chain, avant de rejoindre ensuite le projet de déploiement SAP en tant que support fonctionnel métier, puis partie intégrante de l’équipe pendant près de 3 ans. Je suis passé de la rédaction des supports de formation pour le site pilote, au support terrain pendant les formations, et enfin en support en phase de Go-Live.

Mon intégration s’est faite dans ce projet au moment où le premier entrepôt pilote allait basculer sous SAP. J’ai ensuite pu suivre l’amélioration continue des méthodes de déploiement à travers 10 sites en France. Après ces 3-4 années d’expérience terrain en interne, l’enchaînement de 2 ans de conseil SAP m’a permis de comprendre les paramétrages critiques. Ceux qui doivent systématiquement et obligatoirement être présentés, échangés, construits et validés avec les opérationnels.

La réussite d’un démarrage SAP passe donc évidemment par un bon projet, impliquant obligatoirement les opérationnels (et leurs référents fonctionnels), avant toute décision importante sur la préparation du système. Mais une part essentielle de cette réussite est liée aussi à la préparation de l’organisation opérationnelle des sites et des équipes, pour ce changement. En effet, la complexité majeure de l’implémentation de SAP n’est pas d’adapter le système à son organisation, mais bien d’adapter son organisation aux contraintes du système.

• Tous les niveaux de management doivent participer (à leur niveau de responsabilité) aux décisions de conception sur le système.

• Tous les salariés doivent être informés et ceux travaillant avec l’ERP (même ceux pour lesquels les actions sont ponctuelles dans le système) doivent être formés à ce changement de système.

• Une séparation physique réelle doit se refléter dans le système par une identification claire des stocks que vous souhaitez différencier : contraintes comptables, catégorie de risque, fragilité, températures de conservation, etc. (SAP WM pourra vous aider à les distinguer dans le système sans avoir d’impact sur les autres services)

• Les mouvements de stocks doivent toujours être saisis avec les quantités réellement mouvementées (toute approximation de quantité bloquera les mouvements ultérieurs, cf. point suivant)

• Les inventaires doivent être indéniablement fiables (dans le WMS actuel) et correspondre strictement à la réalité physique (aucun stock négatif toléré dans SAP à Blocage des mouvements en cas de rupture)

• Pour les sites ayant des activités de production : privilégier dès que possible la consommation et la déclaration de quantités au réel (les solutions de post-consommation ou de déclaration de production en auto sont généralement non recommandées, car elles génèrent des erreurs de stock)

• De même, les BOM (Nomenclatures) de production sont à formaliser, vérifier et ajuster pour correspondre au plus près de la réalité des opérations de transformation.

• Concernant tout mouvement physique autre, il est indispensable de le reporter immédiatement et en temps réel (au plus près) dans le système. Tout décalage dans le temps, ou autre cause de décalage entre les stocks informatique et physique, nuira à vos stocks et génèrera des blocages à très très court terme.

• Vérifier ou créer la procédure de gestion des retours : aucune remise en stock physique ne doit être acceptée si elle n’a pas été enregistrée en même temps ou au préalable dans le système.

Du côté des relations interservices, celles-ci doivent être parfaites. Faute de quoi, on se retrouve, par exemple, (déjà vu) un jour de démarrage avec des stocks (réceptions) dépassant largement la capacité de l’entrepôt, par peur de rupture côté achats. La coordination avec les ventes (bien plus que d’habitude) sera le seul sésame pour livrer vos clients à l’heure, et rattraper les retards liés à ce changement fondamental (de système informatique), très perturbant pour vos équipes, même si bien préparé.

Un des points clés, et rarement compris, concerne la réservation des stocks pour les clients. SAP est un ERP. Vos stocks (entrepôts) seront donc visibles par tous les services de l’entreprise qui en ont besoin. Cela ne signifie pas pour autant que celui-ci sera réservé dès la prise de commande.

En effet, lors de la création de commande ou ordre de production dans SAP, le contrôle de disponibilité se base sur le stock projeté, en date de prélèvement (calculée pour une livraison à la date souhaitée par le client). Ce qui signifie que l’ordre de commande (ORDERS), tout comme l’ordre de fabrication (OF) n’est pas ferme à sa création (même sauvegardé). Comme l’ordre de fabrication (OF) devient ferme à son lancement, une commande de vente ne devient donc ferme qu’à la création de la livraison sortante (pendant de la commande ferme, côté logistique). C’est donc uniquement à partir de ce moment-là que le stock physiquement disponible devient bloqué et réservé (en quantité uniquement) pour cette commande.

L’ensemble des commandes transformées ainsi (en livraison) réserve donc du stock. Cette opération est donc à retarder le plus possible (en accord avec le service commercial) sauf exception. Les risques logistiques sont que ce stock ne peut dès lors plus être utilisé pour d’autres opérations logistiques. Côté commercial, une transformation trop tôt sera elle à l’origine de commandes bloquées en rupture, alors que le stock aurait pu être disponible (plus tard) à temps pour livrer le client.