.svg)
Pourquoi la modernisation de la production est rarement un projet de remplacement complet
La tentation dans l'informatique industrielle est de planifier la modernisation comme un projet unique de migration ERP. Choisir le nouveau système, fixer la date de bascule, transférer les données, former les équipes, décommissionner l'ancien. Ce modèle fonctionne dans les présentations mais échoue dans les usines. Les opérations de production modernes tolèrent rarement le type de risque d'interruption que crée un remplacement complet d'ERP. L'écosystème environnant d'applications cloud, de portails clients et d'outils d'analyse a également besoin de données ERP fiables bien avant qu'une migration ne soit terminée.
C'est pourquoi la plupart des fabricants optent finalement pour une approche différente. Ils maintiennent leur ERP existant en fonctionnement tout en connectant des applications cloud autour de celui-ci via une couche d'intégration. La modernisation s'opère progressivement, la couche d'intégration absorbant la complexité qui, autrement, résiderait dans des projets de migration risqués.
Les ERP existants contiennent la logique métier que les fabricants ne peuvent pas se permettre de compromettre
La raison pour laquelle les ERP existants persistent n'est pas seulement la nostalgie ou les contraintes budgétaires. C'est la logique métier accumulée qui y réside. Un ERP de production typique contient des décennies de règles de tarification spécifiques aux clients, de séquences de production, de conditions fournisseurs, de flux EDI et de dépendances opérationnelles construites autour du système au fil du temps. La majeure partie de cette logique n'a jamais été correctement documentée au départ.
Cela rend le remplacement risqué d'une manière difficile à quantifier à l'avance. Un plan de bascule clair peut lister chaque module, chaque interface, chaque rapport. Il ne peut pas lister chaque solution de contournement non documentée qu'un planificateur de production a créée il y a six ans pour gérer un problème fournisseur spécifique. Ces solutions de contournement sont importantes, car elles sont devenues des dépendances opérationnelles dont l'entreprise ignore l'existence.
Le résultat est que les projets de remplacement d'ERP ont tendance à découvrir leur véritable portée en cours de migration, à quel moment le projet est déjà en cours et le coût de sa mise en pause augmente de semaine en semaine.
Qu'est-ce qu'une plateforme d'intégration hybride ?
Une plateforme d'intégration hybride est une catégorie de logiciels qui connecte les systèmes sur site aux applications cloud via une couche d'intégration gérée. Le mot « hybride » décrit l'architecture qu'elle prend en charge, où les systèmes existants fonctionnant dans des centres de données privés ou sur du matériel dédié coexistent avec des applications cloud fonctionnant dans des environnements partagés.
Pour la production, cela est important car la pile opérationnelle est rarement centralisée. L'ERP fonctionne souvent sur site sur AS/400, IBM i, ou des infrastructures Windows ou Unix plus anciennes. En revanche, la plateforme de commerce, le CRM et l'environnement d'analyse sont généralement natifs du cloud, chacun avec sa propre méthode de connexion, son modèle de sécurité et son format de données.
Une plateforme d'intégration hybride gère les mécanismes de connexion pour tous ces éléments, y compris les appels API, les transferts de fichiers, les messages EDI, les requêtes de base de données et les flux événementiels. Elle gère également la transformation, la validation et la surveillance des données lorsqu'elles circulent entre les systèmes, afin que les applications cloud reçoivent les données ERP dans des formats qu'elles peuvent réellement utiliser.
Connecter AS/400, IBM i et SAP ECC aux applications cloud via une seule couche d'intégration
Le défi technique de l'intégration d'ERP existants est rarement lié à un seul protocole. La connectivité mainframe, l'intégration AS/400 et l'intégration SAP ECC ont chacune leurs propres conventions. Les environnements AS/400 exposent généralement les données via des requêtes DB2, des transferts de fichiers ou des interfaces plus anciennes basées sur des messages. SAP ECC prend généralement en charge les BAPI, les IDoc et les appels RFC. D'autres systèmes s'appuient encore sur MQ Series, des échanges basés sur FTP ou des protocoles propriétaires.
Une plateforme d'intégration en tant que service (iPaaS) à usage général gère tous ces éléments via une seule couche de configuration plutôt que de nécessiter un code personnalisé pour chacun. L'iPaaS Alumio prend en charge la connectivité directe aux bases de données (MySQL, PostgreSQL, MSSQL), les échanges basés sur des fichiers via FTP et SFTP, les normes EDI (X12, EDIFACT), les API REST et SOAP, ainsi que les plugins API spécifiques à SAP qui exposent les points d'accès ECC et R/3. Cette étendue est importante car la plupart des fabricants ont plusieurs systèmes existants à intégrer, chacun avec des besoins de connexion différents.
Pelican Products, un fabricant américain d'équipements de protection pour le voyage avec 1 400 employés répartis dans 27 pays, a intégré son ERP SAP ECC R/3 sur site avec Adobe Commerce via l'iPaaS Alumio. Le système SAP continue de fonctionner comme le registre opérationnel pour la finance, les stocks et le traitement des commandes, tandis qu'Adobe Commerce gère la vitrine client. Les deux systèmes échangent des données en temps réel via la couche d'intégration, ce qui a résolu les erreurs financières et d'inventaire que la configuration autonome précédente générait. Ce modèle, où l'ERP existant reste en place et la couche cloud se connecte via l'intégration, s'applique à la plupart des scénarios de modernisation de la production.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
