Microsoft Dynamics 365 et flux de données OEE
Microsoft Dynamics 365 Finance and Supply Chain Management (D365 F&SCM) est le choix ERP de nombreux fabricants de taille moyenne et de grandes entreprises déjà investis dans l'écosystème technologique Microsoft. Le module Contrôle de production de D365 F&SCM gère les ordres de production, les itinéraires de fabrication et la planification des ressources ; le module Gestion des actifs prend en charge les ordres de travail de maintenance des équipements et les demandes de service. Le logiciel OEE s'intègre aux deux modules pour fournir les données de performance de l'atelier dont les fonctions de planification et de maintenance de D365 ont besoin pour fonctionner avec précision. Les principaux flux de données de l'OEE vers D365 comprennent : les quantités réelles produites consignées sur les ordres de production dans le module Contrôle de production de D365, les événements d'arrêt qui créent des demandes d'intervention ou des notifications de localisation fonctionnelle dans D365 Gestion des actifs, et les décomptes de rejets qualité qui mettent à jour les rapports de rebut des ordres de production. En retour, D365 envoie des informations sur les ordres de production, les quantités planifiées et les données de capacité des machines à la plateforme OEE afin de fournir un contexte de planification pour les calculs de performance. La plateforme d'intégration de Microsoft pour D365 est Azure Integration Services — plus précisément Azure Logic Apps, Azure API Management et Azure Service Bus. Les fabricants utilisant la plateforme Microsoft Azure bénéficient d'une connectivité native entre D365 et les plateformes OEE qui prennent en charge l'intégration Azure, avec des connecteurs préconfigurés disponibles via la place de marché Microsoft AppSource pour plusieurs des principaux éditeurs OEE. Cette voie d'intégration native Microsoft est généralement plus simple à mettre en œuvre et à maintenir que les approches middleware inter-plateformes pour les organisations qui utilisent déjà Azure.
Intégration de la gestion des actifs D365 et de la maintenance TRS (OEE)
D365 Asset Management (anciennement connu sous le nom d'Enterprise Asset Management) est le module de maintenance qui se connecte le plus directement au logiciel OEE. L'intégration crée un lien bidirectionnel entre les données de performance des équipements OEE et les ordres de travail de maintenance dans D365 : l'OEE détecte les événements d'arrêt et les anomalies des équipements, crée des demandes de maintenance dans D365, et les travaux de maintenance effectués ainsi que la consommation de pièces de rechange sont enregistrés dans D365 Asset Management avec un lien vers l'événement OEE d'origine. Pour les fabricants utilisant le planning de maintenance et les déclencheurs de maintenance basés sur des compteurs de D365 Asset Management, les données OEE fournissent les heures de fonctionnement et les comptages de cycles qui alimentent les plannings de maintenance préventive basés sur des compteurs. Au lieu de saisir manuellement les heures machine dans D365 à la fin de chaque poste, le logiciel OEE met automatiquement à jour les compteurs de maintenance en fonction du temps de fonctionnement réel — ce qui permet de maintenir la précision des plannings de maintenance sans imposer de saisie supplémentaire aux équipes de production. La capacité d'intégration Power Platform de D365 (via Power Automate et Power BI) offre des options d'intégration supplémentaires pour les logiciels OEE. Les plateformes OEE qui exposent des données via une API peuvent se connecter à Power BI pour des rapports financiers combinés OEE et D365, et Power Automate peut orchestrer des flux de travail qui déclenchent des actions dans D365 en fonction d'événements OEE — par exemple, créer automatiquement une demande d'achat dans D365 pour une pièce de rechange lorsque les données OEE montrent qu'un mode de défaillance spécifique dépasse un seuil de fréquence. Ces intégrations Microsoft Power Platform permettent aux fabricants de construire des flux de travail personnalisés sans code en utilisant les mêmes outils que leurs utilisateurs métiers connaissent déjà.
Mise en œuvre et gouvernance de l’intégration OEE pour D365
Les intégrations D365 F&SCM pour les logiciels OEE tirent parti de l'investissement de Microsoft dans des modèles d'intégration standardisés. Les API OData de D365 et le cadre des événements métier fournissent des points d'intégration propres pour l'achèvement des ordres de production, les notifications de gestion des actifs et les transactions d'inventaire, réduisant la quantité de développement personnalisé requise par rapport aux intégrations plus anciennes de Microsoft Dynamics AX. La décision de conception d'intégration la plus importante pour les intégrations OEE avec D365 est la granularité de la confirmation des ordres de production. D365 Production Control prend en charge à la fois les clôtures au niveau des opérations (opération par opération) et au niveau de l'ordre — et l'intégration OEE doit s'aligner sur le modèle de confirmation utilisé par le fabricant. Pour les fabricants ayant des processus de production simples à opération unique, la confirmation au niveau de l'ordre est directe. Pour les fabricants discrets dont les gammes comportent plusieurs opérations, les données OEE au niveau des opérations doivent être mappées sur des opérations de gamme spécifiques dans D365, ce qui exige un alignement plus soigné des données maîtres lors de la mise en œuvre. Pour les fabricants prévoyant une migration de Dynamics AX (2009, 2012) vers D365 F&SCM, la bascule de l'intégration OEE doit être planifiée dans le cadre du projet de migration ERP. D365 F&SCM dispose d'un modèle de données d'ordre de production sensiblement différent de celui d'AX 2012, et tenter de réutiliser le code d'intégration AX pour D365 crée généralement plus de problèmes qu'une réimplémentation propre. La migration est une opportunité d'aligner l'intégration OEE sur les cadres améliorés de D365 pour la confirmation de production et la gestion des actifs, et de nettoyer la taxonomie des temps d'arrêt et la cartographie des centres de travail qui ont probablement accumulé des incohérences au fil des années d'exploitation sous AX.