Exemple de scénario de chaîne d’approvisionnement
L’un des processus les plus fondamentaux de la chaîne logistique de haute technologie est l’échange de messages de demande de bon de commande et de réponse. Un acheteur émet un bon de commande, et un fournisseur reconnaît, au niveau de la ligne, s’il accepte ou rejette la commande, ou si la commande est en attente.
Cette rubrique décrit un exemple de scénario où deux partenaires commerciaux échangent des messages de bon de commande et montre comment l’intégration et l’automatisation améliorent le processus.
Les joueurs
Dans cet exemple de scénario, l’acheteur est un grand fabricant d’équipements de haute technologie. Ils utilisent actuellement un système EDI pour l’échange automatisé de données. Avec les fournisseurs qui n’utilisent pas EDI, ils s’appuient sur le téléphone, la télécopie, la messagerie électronique avec des feuilles de calcul et des applications Web. Même avec les fournisseurs qui utilisent EDI, ils ont une capacité limitée à intégrer les communications de leurs partenaires commerciaux à leur système ERP back-end. Une fois qu’ils ont reçu des commandes et des informations via EDI, ils doivent les rescrire manuellement dans leur système ERP. Ils veulent améliorer leurs processus de chaîne d’approvisionnement existants en automatisant la demande, l’inventaire, les achats et la création de rapports avec leurs partenaires commerciaux. Ils ont besoin d’un système pour communiquer avec leurs fournisseurs et leurs clients par le biais d’Internet, qui s’intégrera également directement à leurs applications métier existantes.
Le vendeur est un fournisseur de taille moyenne de circuits intégrés (ICs) hautes performances. Ils communiquent actuellement avec leurs partenaires commerciaux par téléphone, télécopie, courrier électronique avec des feuilles de calcul Microsoft Excel, FTP et des applications web jointes. Ils n’utilisent pas EDI. Leurs interactions avec chaque partenaire commercial sont différentes, en fonction des besoins du client et de leurs propres technologies. Ils veulent rendre leurs processus métier plus efficaces afin de réduire les coûts de transaction, d’améliorer la satisfaction des clients et d’obtenir un avantage concurrentiel.
Processus métier actuel
Sans solution intégrée, le processus de bon de commande pour le fabricant et le fournisseur fonctionne comme suit :
Un client du fabricant d’équipement de haute technologie envoie une commande au fabricant par le biais d’un site Web.
En réponse à la commande d’origine, un employé du fabricant crée une demande de bon de commande dans son application LOB ERP pour le fournisseur IC.
La demande de bon de commande traverse les différentes parties de l’entreprise de fabrication qui doivent enregistrer, traiter, examiner et autoriser la demande de bon de commande. Ce traitement et ce routage sont une combinaison de processus automatisés pour les utilisateurs du système ERP et de processus manuels, tels que le courrier électronique avec une feuille de calcul Excel jointe.
Un employé crée une demande de bon de commande dans un e-mail et l’envoie au fournisseur. Un certain nombre d’autres employés qui communiquent par courrier électronique, télécopie ou EDI à d’autres fournisseurs répètent ce processus. Différents services utilisent des processus différents. Avec les fournisseurs qui utilisent EDI, un employé du fabricant doit toujours créer un message manuellement à partir du système ERP.
Un employé du fournisseur reçoit le message, puis le touche manuellement dans son système ERP, ce qui modifie le format des données. Par e-mail, l’employé informe les autres employés de la demande.
Les autres employés analysent la demande. Si nécessaire, ils informent leurs propres fournisseurs de pièces de la nécessité de pièces. Selon le fournisseur, ils utilisent le téléphone, la télécopie, la messagerie électronique ou FTP pour informer leurs fournisseurs.
Après avoir remis à ses services et fournisseurs, chaque employé accepte ou rejette chaque article de la ligne de produits de la commande d’achat, puis confirme ou rejette le bon de commande et indique qu’il est en attente. Ils effectuent ces tâches dans le système ERP.
Un employé du fournisseur crée une réponse de bon de commande dans un e-mail, confirmant ou rejetant chaque élément de ligne de la demande, ou créant un message indiquant que le bon de commande est en attente. L’employé du fournisseur envoie le message de réponse au fabricant. Si un élément de ligne est en attente, ils créeront ultérieurement un autre message indiquant si l’élément en attente est accepté ou rejeté.
Un employé du fabricant reçoit la réponse au bon de commande. Ils entrent de nouveau l’ordre dans leur système ERP back-end.
Un autre employé analyse la confirmation de bon de commande, puis crée une réponse au client d’origine, confirmant la commande. Ils envoient cette réponse par e-mail.
La solution RosettaNet
Microsoft BizTalk Server et BizTalk Accelerator pour RosettaNet (BTARN) automatisent et normalisent le processus de demande de bon de commande et de réponse. L’utilisation d’un système intégré réduit la quantité d’intervention manuelle, la quantité de manipulation du papier et l’utilisation des téléphones et des télécopieurs. La plupart des processus sont des transactions automatisées entre des ordinateurs serveurs intégrés. Lorsque les employés doivent effectuer manuellement une opération, ils le font généralement sur les systèmes ERP back-end. La figure suivante montre le système intégré.
Dans ce scénario, un système intégré modifie les processus suivants :
Une connexion RNIF (RosettaNet Implementation Framework) remplace les interactions manuelles de routine entre le fabricant et le fournisseur IC. Le système envoie et reçoit automatiquement des messages, achemine les données vers les systèmes principaux, et accepte et répond aux messages. Le fabricant et le fournisseur utilisent BTARN pour implémenter la connexion RNIF.
Une connexion RNIF remplace la connexion EDI entre le fabricant, le fournisseur IC et d’autres partenaires commerciaux. Cela permet au système d’intégration de router automatiquement les données vers les systèmes principaux des partenaires commerciaux. Certains partenaires commerciaux utilisent BTARN pour implémenter la connexion RNIF ; d’autres utilisent une autre solution conforme à RosettaNet.
Pour les petits partenaires qui n’ont pas de solution conforme à RosettaNet, le fabricant et le fournisseur ic créent des services Web auxquels le partenaire peut accéder avec un navigateur Web. Le service Web utilise une connexion RNIF standard pour communiquer avec le système BTARN chez le fabricant ou le fournisseur ic.
Les messages échangés par les fabricants et les fournisseurs suivent des schémas conformes aux processus d’interface partenaires (PIP) RosettaNet standard. Ces schémas remplacent les formats utilisés dans EDI et FTP. Tous les partenaires commerciaux utilisent les mêmes schémas ; ils n’ont pas besoin de mapper des données entre les messages.
BTARN valide automatiquement tous les messages par rapport aux schémas, ce qui réduit le risque d’erreurs de données.
Les administrateurs peuvent intervenir sur les serveurs BTARN à l’aide d’outils logiciels d’administration. Les décideurs métier sur les ordinateurs clients peuvent utiliser des outils de supervision d’entreprise hébergés dans des applications ou des outils Microsoft Office. Il s’agit de deux processus efficaces qui permettent au système de fonctionner efficacement et offrent plus de visibilité sur la façon dont le système et l’entreprise s’exécute.
Flux de messages
Le processus métier comprend désormais les étapes suivantes :
Un client du fabricant d’équipement de haute technologie envoie une commande au fabricant par le biais d’un site Web.
En réponse à la commande d’origine, un employé du fabricant génère une demande de commande d’achat sur le système de gestion des commandes et des stocks de l’entreprise. Cette application métier est un système ERP avec une interface utilisateur web.
Le système envoie la demande de bon de commande, toujours au format natif du système ERP, à BTARN.
BTARN génère automatiquement un message de demande de commande conforme au PIP 3A4 défini par le organization RosettaNet. Cette demande de bon de commande est au format XML. Le PIP définit le contenu du message.
Notes
Le PIP 3A4 garantit que toutes les demandes et réponses de bon de commande sont identiques dans le formulaire. Ce PIP fait partie d’une collection de PIP définis par RosettaNet qui forment un système de messagerie complet et interconnecté. Par exemple, avant d’envoyer le message 3A4, l’acheteur peut rechercher le prix et la disponibilité (PIP 3A2), demander un devis (PIP 3A1) ou transférer son panier d’achat (PIP 3A3). Après avoir envoyé la demande de bon de commande, l’acheteur peut modifier le bon de commande (PIP 3A8), annuler le bon de commande (PIP 3A9), interroger les status de bon de commande (PIP 3A5) ou distribuer le status de bon de commande (PIP 3A6). Le organization RosettaNet a standardisé tous ces messages.
BTARN encapsule le message de demande (nommé contenu du service) avec des en-têtes RNIF qui permettent à BTARN de transmettre le message via Internet à un autre ordinateur BTARN sur le site du fournisseur. RNIF définit la façon dont les partenaires échangent des messages sur Internet.
Le système BTARN du fabricant envoie la demande de bon de commande au système BTARN du fournisseur IC.
Le système BTARN N du fournisseur reçoit la demande de bon de commande. S’il s’agissait d’une demande à action unique (sans réponse correspondante), le système BTARN du fournisseur retournerait un message signal qui accuse réception du message. Toutefois, étant donné qu’il s’agit d’un message à double action, le système BTARN du fournisseur retourne un message d’accusé de réception suivi d’un message de réponse.
Le système BTARN du fournisseur supprime les en-têtes RNIF du message de demande de commande, traite le contenu du service du message, puis achemine la demande vers le système ERP du fournisseur.
Les employés du fournisseur travaillent dans le système ERP pour traiter la commande. S’ils doivent envoyer des messages à leurs propres fournisseurs de pièces, ils le font à l’aide du même système BizTalk et BTARN. Le service informatique peut personnaliser le système pour répondre automatiquement au fabricant.
Un employé utilise le système ERP du fournisseur pour générer un message de réponse de bon de commande, puis achemine le message de réponse vers le système BTARN du fournisseur.
Le système BTARN du fournisseur génère un message de réponse de commande PIP 3A4, encapsule le contenu de service du message de réponse dans des en-têtes RNIF, puis envoie la réponse de bon de commande au système BTARN du fabricant.
Le système BTARN du fabricant reçoit la réponse au bon de commande, puis envoie un accusé de réception au BTARN du fournisseur. Le système BTARN du fournisseur achemine l’accusé de réception vers le système ERP du fournisseur.
Le BTARN du fabricant supprime les en-têtes RNIF du message de réponse, traite le contenu du service, puis achemine la réponse de bon de commande vers l’application ERP du fabricant.
Un employé du fabricant analyse tous les messages de confirmation de bon de commande, puis crée une réponse au client d’origine, confirmant la commande. L’employé envoie ensuite cette réponse par courrier électronique.
Avantages de la solution BTARN
BizTalk Server et BTARN automatisent la plupart des facettes du processus de demande de bon de commande et de réponse. Ils le font non seulement pour le fabricant et le fournisseur IC, mais aussi pour tous les autres partenaires commerciaux qui ont adopté des solutions conformes à RosettaNet dans le cadre de la gestion de la chaîne d’approvisionnement.
Un système d’intégration réduit la quantité d’intervention manuelle et la quantité de traitement du papier. La plupart des processus impliquent des interactions automatisées entre des ordinateurs serveurs intégrés. Le fabricant et le fournisseur ic ont un haut degré de contrôle et de visibilité sur leurs processus. Ils reçoivent automatiquement des accusés de réception et peuvent conserver une preuve de non-répudiation.
Le système automatisé utilisant BTARN permet au fabricant et au fournisseur d’effectuer les opérations suivantes :
Réduire les temps de cycle pour l’exécution des commandes
Réduire les incertitudes dans le processus et augmenter la fiabilité du processus
Réduire les temps de traitement et les temps de réponse des devis
Réduire le temps passé à retravailler manuellement les informations, à obtenir des informations manquantes ou à corriger les erreurs
Fournir une visibilité et activer la surveillance du processus et du suivi des messages
Voir aussi
Comment BizTalk Server répond aux besoins de l’entreprise
Nécessité de l’intégration des partenaires commerciaux
Le défi de la chaîne d’approvisionnement
La solution de chaîne d’approvisionnement
Exemple de scénario basé sur un hub