Modernisation ERP et sortie de SAP ECC : l'ingénierie autour de la migration que personne n'a chiffrée

Toute migration d'ERP contient deux projets. Il y a celui qui figure au plan (le nouveau système, la refonte des processus, l'intégrateur), et celui qui remonte à la surface au quatrième mois, quand quelqu'un compte les interfaces.

Ce second projet est le nôtre. Les quatre-vingts intégrations spécifiques, les états dont la finance dépend et que personne ne revendique, les terminaux d'entrepôt qui interrogent une vue de base de données, le portail client qui lit directement dans les anciennes tables, et les vingt ans de données qui doivent arriver dans le nouveau système sous une forme qu'il acceptera. C'est rarement dans le périmètre initial, et c'est fréquemment ce qui détermine la date.

Pourquoi le sujet est à l'ordre du jour

La maintenance standard de SAP ECC 6.0 prend fin le 31 décembre 2027. La maintenance étendue peut porter une entreprise jusqu'à fin 2030, moyennant un surcoût et un périmètre réduit. Une large part du parc installé n'a pas commencé, les migrations demandent couramment dix-huit à trente-six mois, et les partenaires comme les capacités des hyperscalers se réservent dès maintenant.

La même pression existe en dehors de SAP. Les clients Oracle EBS font face à leur propre horizon de support, les installations Dynamics AX et NAV sont poussées vers Business Central et Dynamics 365, et une longue traîne d'entreprises exploite un ERP fortement personnalisé il y a dix ans par des gens qui sont partis depuis.

Quelle que soit la destination, la forme du problème est la même : l'ERP n'est pas une île, et ce qui s'y rattache est le plus souvent non documenté.

Ce que nous faisons

Découverte et inventaire des interfaces

Avant de planifier quoi que ce soit, il faut établir ce qui parle réellement à l'ERP. Nous le faisons de façon empirique (lecture des journaux de base de données, du trafic réseau, des travaux planifiés, de la configuration du middleware d'intégration et du code source), plutôt qu'en faisant circuler un questionnaire en espérant des réponses.

Le livrable est un inventaire de chaque interface avec son sens, son protocole, sa fréquence, son volume de données, son propriétaire métier lorsqu'on parvient à l'identifier, et un avis sur son sort : à reconstruire, à retirer ou à adapter. Nos clients découvrent régulièrement deux à cinq fois plus d'interfaces qu'ils n'en attendaient, et un nombre non négligeable ne sert plus rien du tout.

Reconstruction de la couche d'intégration

Nous reconstruisons les interfaces qui doivent survivre, et nous préférons les reconstruire contre une abstraction plutôt que de les pointer directement sur le nouveau système. Une couche d'intégration entre vos applications satellites et l'ERP signifie que la prochaine migration (et il y en aura une) n'imposera pas de refaire cet exercice. Elle permet aussi de faire basculer les applications par vagues au lieu d'un unique week-end de bascule.

Le travail couvre ici les interfaces IDoc et BAPI, les services OData, les points d'accès SOAP d'une époque antérieure, les échanges de fichiers plats et SFTP qui font encore tourner la moitié du B2B européen, les files de messages, et les API REST modernes du côté du nouveau système.

Ingénierie de la migration des données

Extraction, nettoyage, transformation, chargement et (la partie habituellement sous-estimée) réconciliation. Nous construisons la migration comme du code réexécutable, non comme un script à usage unique, afin de la rejouer des dizaines de fois sur des données de plus en plus propres, avec comparaison automatique des résultats à chaque passage.

C'est dans la réconciliation que se joue la crédibilité. La finance ne validera pas une migration parce que le chargement a réussi ; elle valide parce que les soldes concordent, que les comptages concordent, et que les écarts restants sont expliqués et acceptés par écrit.

Les applications spécifiques qui survivent à l'ERP

La plupart des entreprises ont bâti autour de l'ancien ERP des applications qui encodent ce que l'ERP ne savait pas faire : un configurateur, un outil de tarification, un terminal d'atelier, un portail client, un tableur de planification devenu porteur. Certaines doivent disparaître au profit des fonctions standard du nouveau système. D'autres constituent un véritable avantage concurrentiel et méritent d'être reconstruites correctement, comme des applications à part entière, non plus soudées à un schéma de base de données sur le point de changer.

Nous vous aidons à distinguer les deux, puis nous construisons celles qui valent d'être gardées.

Le reporting et le patrimoine de données parallèle

Tout ERP durable fait pousser autour de lui une couche d'états, d'extractions et de tableurs. Ces objets cassent bruyamment à la bascule et ne figurent presque jamais au plan. Nous les inventorions, identifions ceux dont l'activité dépend réellement, et les reconstruisons sur le nouveau modèle de données ou sur une couche de restitution qui les en isole.

Décommissionnement et conservation des données

L'ancien système détient des enregistrements que vous êtes légalement tenu de conserver des années après son extinction. Maintenir ECC en lecture seule pendant une décennie est une manière coûteuse de satisfaire une règle de conservation. Nous construisons l'extraction vers une archive accessible, dotée des capacités de recherche et d'export que réclament effectivement les auditeurs et l'administration fiscale, afin que l'ancien système puisse être éteint.

Ce que nous ne sommes pas

Nous ne sommes pas un cabinet de conseil fonctionnel SAP. Nous ne paramétrons pas FI/CO, nous ne concevons pas vos modèles de processus, et nous ne sommes pas le partenaire qui pilote le programme S/4HANA. Ce sont des rôles de spécialistes, et vous devez engager un spécialiste pour les tenir.

Nous sommes l'équipe d'ingénierie qui travaille aux côtés de ce partenaire sur tout ce que l'ERP touche mais que le programme ERP ne couvre pas. En pratique, nous intervenons soit directement pour le client, afin de protéger son côté du programme, soit en sous-traitance de l'intégrateur qui le mène.

Si vous cherchez quelqu'un pour porter l'intégralité de la conversion S/4HANA, nous vous dirons que ce n'est pas nous, et nous préférons le dire à la première conversation plutôt qu'à la troisième.

Nos terrains d'intervention

Aux côtés d'un programme S/4HANA : reconstruction des intégrations, ingénierie de la migration des données, travaux sur les applications satellites et décommissionnement du parc historique.

Les migrations hors de SAP : vers Odoo, Dynamics 365 Business Central, ERPNext, NetSuite ou un système sectoriel, cas fréquent chez les entreprises de taille intermédiaire pour lesquelles S/4HANA est disproportionné. L'intégration et les données y représentent l'essentiel du projet.

Les parcs Oracle, Dynamics AX/NAV et Infor, soumis à la même pression de cycle de vie avec moins d'attention portée sur eux.

Les entreprises qui ne migrent pas, qui ont décidé de rester en place pour l'instant et qui doivent moderniser les systèmes environnants, rendre les interfaces maintenables et réduire le risque pendant l'attente.

Déroulement des missions

Découverte, trois à six semaines. Inventaire des interfaces, évaluation de la qualité des données, revue des applications satellites, et un rapport écrit sur ce à quoi ressemble réellement le parc environnant. Cette phase est délibérément disponible en mission autonome : plusieurs clients s'en sont servis pour renégocier le périmètre et le prix de la proposition d'un intégrateur, ce qui l'a plus que remboursée.

Réalisation, en parallèle du programme principal : couche d'intégration, chaîne de migration, reconstruction d'applications, à votre rythme et sur votre date de bascule.

Accompagnement de la bascule, répétitions comprises, avec les passages de réconciliation et la période d'hypercare où les interfaces jamais vraiment sollicitées en test le sont enfin.

Décommissionnement, une fois le nouveau système stabilisé et l'archive validée.

Technologies

Java, .NET, Python, Node.js et PHP côté applicatif ; les technologies d'interface SAP dont IDoc, BAPI, RFC et OData ; les middlewares MuleSoft, Apache Camel, Kafka et Azure Integration Services ; SQL Server, Oracle, DB2, HANA et PostgreSQL ; AWS et Azure. Lorsque le parc existant repose sur plus ancien (Delphi, VB6, PowerBuilder, du COBOL adjacent à l'ERP) c'est pour nous un terrain familier, pas une surprise.

Questions fréquentes

Quand la maintenance de SAP ECC prend-elle fin exactement ?

La maintenance standard de SAP ECC 6.0 prend fin le 31 décembre 2027. La maintenance étendue est disponible jusqu'à fin 2030, moyennant un coût supplémentaire et un périmètre réduit. Vérifiez les conditions applicables à votre enhancement pack et à votre contrat directement auprès de SAP, car elles varient.

Nous avons déjà retenu un intégrateur. Où vous situez-vous ?

À côté de lui. L'intégrateur porte la conversion de l'ERP ; nous portons le parc qui l'entoure : interfaces, ingénierie des données, applications satellites, reporting et décommissionnement. Cette répartition est courante, elle laisse l'intégrateur concentré sur le système dont il est spécialiste, et elle fait en sorte que quelqu'un soit responsable des parties qui tombent d'ordinaire entre deux contrats.

Est-il réaliste de quitter SAP complètement ?

Pour certaines entreprises, oui. Cela dépend de la part de votre activité qui est standard, de la part qui réside dans les spécifiques, et de la capacité d'une plateforme plus légère à absorber votre volume et vos exigences réglementaires. C'est une option sérieuse pour les industriels et distributeurs de taille intermédiaire, et une mauvaise option pour les groupes multinationaux complexes. La phase de découverte vous donne des éléments pour décider, plutôt qu'un argumentaire.

Combien de temps prend l'inventaire des interfaces ?

Trois à six semaines pour la plupart des parcs de taille intermédiaire. La durée est essentiellement bornée par les accès : la rapidité avec laquelle nous atteignons les journaux, le code source, la configuration du middleware et les personnes qui se souviennent pourquoi telle chose existe.

Pouvez-vous garder l'ancien système consultable pour l'audit après son extinction ?

Oui. Nous construisons l'extraction vers une archive interrogeable, avec la durée de conservation, la recherche et les capacités d'export que vos auditeurs et l'administration fiscale exigent. C'est en général bien moins coûteux que de maintenir un ERP sous licence en lecture seule pendant dix ans.

Et si nous décidons de ne pas migrer tout de suite ?

C'est une décision légitime, en particulier avec une maintenance étendue disponible jusqu'en 2030. Le travail consiste alors à réduire le risque dans l'intervalle : documenter et stabiliser les interfaces, retirer ce que plus rien n'utilise, et moderniser les applications autour de l'ERP pour que, le jour où vous bougerez, le parc environnant ne soit pas l'obstacle.

Commencer

Dites-nous ce que vous exploitez, où vous en êtes dans la décision, et si un intégrateur est déjà retenu. Nous vous dirons ce que le parc environnant risque de vous coûter et par où nous commencerions.

Contactez-nous pour cadrer une découverte des interfaces et des données.

Services associés

• Maintenance systèmes legacy : pour les systèmes qui restent en place
• Intégration de la facturation électronique : l'obligation qui tombe fréquemment au milieu d'une migration
• Renforcement d'Équipe et Outsourcing : des ingénieurs intégrés pour la durée du programme