Agents IA SAP et données ERP : qualité des données et gouvernance

Auteur : Laura Parri Royo, Directrice Marketing chez TJC Group

Cet article fait partie de la série SAP AI and ERP Data. Abonnez-vous pour lire le prochain numéro.

Les agents IA SAP peuvent récupérer des informations, recommander des actions et automatiser certaines parties d’un processus métier. Mais un agent ne peut travailler qu’avec les enregistrements, les autorisations, les règles et le contexte dont il dispose. Des dépendances manquantes, des enregistrements de base en double ou des informations de statut obsolètes peuvent amener un agent à recommander la mauvaise action, même lorsque le modèle fonctionne comme prévu. L’intelligence de l’IA dépend de la gouvernance des données et de la qualité des données, combinées à des limites claires sur ce qu’un agent peut récupérer, recommander et exécuter.

Introduction

Les workflows SAP traditionnels suivent généralement des règles prédéfinies. Un utilisateur effectue une action, le système vérifie l’autorisation pertinente et la transaction est enregistrée.

Les agents IA introduisent une couche plus dynamique. Ils peuvent collecter des informations depuis plusieurs applications, interpréter une situation, recommander l’étape suivante ou déclencher une action dans le cadre d’un workflow plus large.

Cela soulève de nouvelles questions : quelles autorisations l’agent utilise-t-il, quelles sources peut-il considérer comme fiables, quand une approbation humaine est-elle requise et quelles preuves doivent être conservées ensuite.

SAP décrit les Joule Agents comme utilisant le contexte des processus métier et des informations provenant d’applications connectées. Ce contexte est important, car les données métier, telles que le statut d’un fournisseur, un retard de livraison ou le solde d’un client, ont rarement du sens isolément.

Pourquoi la qualité des données ERP est importante pour les agents IA SAP

Un agent IA peut traiter l’information rapidement, mais il ne peut pas corriger automatiquement toutes les faiblesses du paysage ERP sous-jacent. L’agent peut fonctionner comme prévu tout en aboutissant à une mauvaise conclusion si les informations dont il dispose ne représentent pas la situation métier dans son ensemble.

Trois problèmes sont particulièrement importants : des informations de processus incomplètes, des enregistrements en double ou obsolètes, et des données qui ont perdu leur contexte métier.

Informations incomplètes et incohérentes

Les processus ERP s’étendent souvent sur plusieurs enregistrements et applications.

Une facture peut apparaître dans le système financier tandis que son bon de commande, la réception des marchandises, le contrat et la correspondance avec le fournisseur se trouvent ailleurs. Si l’agent ne voit qu’une partie de cette chaîne, il peut mal interpréter la cause d’une exception.

Une facture apparemment en retard, par exemple, peut résulter d’une réception de marchandises manquante plutôt que d’un problème de paiement. Un agent qui ne voit que le statut de la facture pourrait escalader le mauvais sujet.

L’incohérence crée un risque similaire. Les unités métier peuvent utiliser des définitions différentes pour un même statut, tandis que les systèmes régionaux peuvent enregistrer les devises, unités, dates ou structures organisationnelles différemment. Des champs SAP personnalisés peuvent également avoir des significations comprises localement mais non documentées de manière centralisée.

Avant qu’un agent n’utilise des informations provenant de plusieurs sources, le workflow doit traiter les questions suivantes :

Lorsque les systèmes ne sont pas d’accord, le workflow doit définir quelle source est prioritaire, si le conflit bloque l’automatisation et qui doit le résoudre.

L’information n’a pas nécessairement besoin d’être dans une seule base de données. Elle doit toutefois être rapprochée et adaptée à la tâche.

Enregistrements dupliqués ou obsolètes

Des données de base en double peuvent fournir à un agent des versions contradictoires d’une même entité métier.

Un fournisseur peut apparaître sous plusieurs numéros de fournisseur après une acquisition, un déploiement régional ou un nettoyage incomplet. Un enregistrement peut contenir des incidents qualité récents, tandis qu’un autre contient le contrat en vigueur et les informations de paiement.

Si l’agent les traite comme des fournisseurs distincts, il peut sous-estimer le risque ou recommander une action sur le mauvais enregistrement.

Les informations obsolètes créent un problème connexe. Un contrat expiré, un client inactif, un code société clôturé, un ancien employé ou un compte bancaire obsolète peuvent rester techniquement accessibles alors qu’ils ne devraient plus influencer une décision opérationnelle.

Ces enregistrements ne peuvent pas toujours être supprimés immédiatement. Ils peuvent rester liés à des transactions historiques ou être soumis à des exigences de conservation. Selon la situation, ils peuvent devoir être harmonisés, bloqués, marqués comme inactifs ou exclus du workflow.

C’est pourquoi l’archivage des données SAP et le nettoyage des données ne doivent pas être considérés comme la même activité.

L’archivage contrôle le volume de données terminées éligibles dans les tables SAP actives. Le nettoyage et la gouvernance des données de base traitent la duplication, l’exactitude, la cohérence et la responsabilité. Une base fiable peut nécessiter les deux.

Données sans contexte métier suffisant

Les données ERP sont façonnées par le processus qui les a créées.

Une facture en retard peut indiquer un problème de paiement. Elle peut aussi résulter d’un litige, d’une erreur de prix, d’une preuve de livraison manquante, d’un code taxe incorrect ou d’un retard d’approbation interne.

Les informations historiques créent un défi supplémentaire. Les structures organisationnelles, les correspondances de comptes, les taux de change, les règles d’approbation et la logique personnalisée peuvent évoluer au fil du temps.

Un modèle comparant plusieurs années de transactions ne peut pas supposer que chaque valeur a été produite selon les mêmes définitions et règles.

Le contexte nécessaire peut inclure les relations entre transactions et données de base, la signification des statuts de processus, l’unité organisationnelle responsable, la configuration en vigueur à l’époque, ainsi que les documents ou approbations de support.

SAP Knowledge Graph peut fournir des relations sémantiques et un contexte métier pour l’IA. Les organisations doivent néanmoins traiter leurs propres personnalisations non documentées, identités en double, terminologie locale et exceptions historiques.

Comment fonctionne, en pratique, un workflow d’agent IA SAP gouverné

Considérez un agent examinant un fournisseur après une série de livraisons retardées.

Tout d’abord, le workflow vérifie les droits du demandeur et confirme que l’identité technique utilisée par l’agent est autorisée à récupérer les enregistrements requis et à effectuer l’action permise.

Il récupère ensuite les informations approuvées nécessaires à la tâche. Cela peut inclure les bons de commande en cours, l’historique des livraisons, les incidents qualité, le statut du contrat, les informations de paiement et les données de base du fournisseur.

Le workflow identifie que le fournisseur apparaît sous deux numéros de fournisseur. Il applique une règle approuvée de rapprochement d’entités. Si le résultat reste incertain, les enregistrements restent séparés et l’écart est escaladé pour examen.

L’agent trouve également des informations de statut contradictoires. S/4HANA indique que le fournisseur est actif, tandis que le référentiel de contrats indique que l’accord en vigueur a expiré.

Le workflow a été configuré pour ne pas résoudre automatiquement ce type de conflit. Il signale l’écart et limite la sortie à une recommandation.

Un responsable achats examine les preuves et approuve, rejette ou modifie l’action proposée. Tout changement résultant dans SAP est enregistré avec le demandeur, l’approbateur, les enregistrements sources, l’identité technique et la version du workflow.

L’extraction, la recommandation, l’approbation et la transaction finale suivent ensuite les règles de conservation et d’audit applicables.

Ce scénario montre que le comportement fiable d’un agent dépend de contrôles connectés. La qualité des données seule ne suffit pas. Le workflow a également besoin d’autorisations spécifiques à la tâche, de règles de source faisant autorité, de limites d’autonomie, d’une intervention humaine et de preuves traçables.

Découvrez-en plus sur le potentiel IA de SAP S/4HANA en regardant le replay de ce webinaire avec Andreas Welsch, ancien dirigeant SAP AI, animé par TJC Americas.

Pourquoi les contrôles d’accès doivent s’appliquer aux workflows pilotés par l’IA

Un agent ne doit jamais étendre l’accès autorisé du demandeur ni utiliser des informations au-delà du périmètre approuvé du workflow.

Le même principe s’applique lorsque l’agent exécute une action plutôt que de se limiter à récupérer des données.

Si un agent peut créer une demande d’achat, modifier un blocage de paiement, mettre à jour des données de base ou déclencher un workflow d’approbation, son autorité doit être clairement définie.

Les organisations doivent gouverner à la fois l’utilisateur qui demande la tâche et l’identité technique qui l’exécute. L’agent ne doit pas devenir un moyen de contourner les contrôles qui s’appliqueraient à la même action dans SAP.

Autorisations utilisateur et informations sensibles

L’accès de l’agent doit refléter le périmètre autorisé du demandeur et le minimum de données requis pour la tâche.

Un utilisateur peut avoir accès à une transaction sans être autorisé à voir chaque champ, entité juridique, groupe d’employés ou document de support qui y est lié.

Les informations ERP sensibles peuvent inclure des données de paie, des coordonnées bancaires, des identifiants fiscaux, des accords tarifaires et des conditions commerciales confidentielles.

La question devient plus complexe lorsqu’un workflow combine des informations provenant de plusieurs systèmes. L’autorisation de consulter des données dans une application ne permet pas automatiquement leur réutilisation dans un autre processus.

Une conception gouvernée doit définir :

Ces contrôles doivent être conçus avant que l’agent n’entre dans un processus en production.

Accès aux données ERP basé sur la finalité

L’accès technique ne permet pas d’utiliser l’information pour toutes les finalités.

Les données client collectées pour exécuter une commande peuvent ne pas convenir à un cas d’usage IA sans lien. Les informations des employés utilisées pour la paie peuvent nécessiter une approbation supplémentaire avant de soutenir une analyse des effectifs. Les transactions historiques conservées à des fins fiscales ne doivent pas devenir automatiquement des données d’entraînement.

Chaque workflow doit donc avoir un objectif métier défini, des sources de données approuvées, des utilisateurs visés et des actions autorisées. Il doit également préciser si l’information peut être utilisée pour l’entraînement ou l’amélioration du modèle.

La minimisation des données s’applique également. Un agent enquêtant sur une exception de facture peut avoir besoin de la facture, du bon de commande, de la réception des marchandises et du statut d’approbation. Il est peu probable qu’il ait besoin de l’historique complet du client.

Limiter le workflow aux informations requises pour la tâche réduit l’exposition et rend le résultat plus facile à expliquer.

Responsabilité des actions automatisées

Toutes les actions d’un agent ne présentent pas le même niveau de risque.

Fournir un résumé des factures en retard est différent de modifier les coordonnées bancaires d’un fournisseur. Recommander un blocage de paiement est différent de l’appliquer automatiquement.

Une approche utile consiste à diviser l’autorité de l’agent en trois niveaux :

Les exigences d’approbation doivent refléter la valeur financière, la réversibilité, l’utilisation d’informations sensibles, l’impact sur les clients, fournisseurs ou employés, les conséquences juridiques ou fiscales, les modifications des données de base et les conflits entre enregistrements sources.

Les actions à fort impact ou irréversibles peuvent nécessiter une approbation humaine même lorsque l’agent peut préparer la transaction.

La responsabilité doit également rester clairement attribuée. L’organisation a besoin d’un responsable de processus qui définit le workflow, d’un propriétaire des données qui approuve l’information utilisée, d’un responsable des contrôles qui surveille la conformité, et d’une voie d’escalade lorsque le workflow ne peut pas se poursuivre en toute sécurité.

Comment les règles de cycle de vie et de conformité s’appliquent aux workflows IA

Les informations ERP ne deviennent pas exemptes des règles de conservation, de confidentialité ou de gel juridique lorsqu’elles entrent dans un workflow IA.

Les workflows IA peuvent créer des extractions, des index, des historiques de prompts, des enregistrements mis en cache, des recommandations, des jeux de données analytiques et des journaux de transactions. Si ces copies ne sont pas incluses dans la gestion du cycle de vie, une organisation peut supprimer des informations de SAP tout en laissant les mêmes données ailleurs.

Conservation, gels juridiques et gestion du cycle de vie sur les copies dérivées

La conception du workflow doit intégrer le statut de cycle de vie et les règles d’usage autorisé attachés aux informations sources.

Elle doit prendre en compte si un enregistrement se trouve encore dans sa période de conservation approuvée, si des champs personnels doivent être masqués et si un gel juridique empêche sa suppression.

Les mêmes règles peuvent devoir couvrir les copies dérivées. Lorsqu’un enregistrement client devient éligible à la suppression selon la politique de conservation applicable, les extractions associées, index, données mises en cache ou historiques de prompts peuvent également devoir être traités.

Le traitement peut varier selon la copie. Une extraction temporaire peut être supprimée à la fin de la tâche, tandis qu’un enregistrement d’audit peut devoir être conservé plus longtemps.

L’organisation doit savoir où chaque copie est stockée, quelle règle s’y applique, si l’action de cycle de vie doit se propager et quelles preuves confirment que le processus a été mené à bien.

Un gel juridique exige une attention particulière. Il peut suspendre le traitement normal du cycle de vie pour des enregistrements liés à un litige, une enquête ou une autre affaire juridique. Si des informations sous gel apparaissent dans une extraction ou une recommandation générée par l’IA, l’organisation doit pouvoir identifier et préserver cette copie.

La conservation n’autorise pas une réutilisation sans restriction. Les informations conservées pour un litige peuvent néanmoins devoir être exclues de l’entraînement du modèle ou d’une automatisation sans lien.

RGPD, limitation des finalités et exigences fiscales

Les exigences de confidentialité affectent la manière dont l’information est traitée tout au long du workflow.

Les données personnelles doivent être utilisées pour une finalité définie, limitées à ce qui est nécessaire, protégées contre les accès non autorisés et non conservées plus longtemps que justifié.

Un workflow IA peut donc nécessiter l’exclusion de champs, le masquage, une récupération restreinte ou des durées de stockage plus courtes pour les extractions temporaires et les prompts.

Les travaux de TJC Group autour de SAP ILM et du RGPD portent sur la conservation, le blocage et le traitement contrôlé de fin de vie au sein des environnements SAP.

Les exigences fiscales créent une obligation différente. Les factures, enregistrements comptables et preuves à l’appui peuvent devoir rester lisibles, complets et traçables pendant des périodes définies.

Une copie analytique peut être transformée pour un modèle particulier, mais la source gouvernée requise pour l’audit ou les preuves fiscales doit rester intacte.

Les recommandations de TJC Group sur l’archivage des données SAP et la conformité juridique expliquent pourquoi l’accessibilité, la conservation et la protection doivent fonctionner ensemble.

Les enregistrements associés peuvent également avoir des dates de fin de conservation différentes. Une facture, un enregistrement client, un journal d’approbation et une correspondance jointe peuvent ne pas devenir éligibles au traitement du cycle de vie au même moment.

Les recommandations de TJC Group sur la gestion de différentes durées de conservation dans SAP ILM traitent de ces dépendances.

Comment SAP ILM prend en charge l’application du cycle de vie

SAP Information Lifecycle Management fournit des contrôles de conservation, de blocage, de gels juridiques et de traitement de fin de vie au sein des environnements SAP.

Pour la gouvernance de l’IA, le workflow doit utiliser le statut de cycle de vie et les règles d’usage autorisé associées aux informations sources pour décider si les données peuvent être récupérées, réutilisées, restreintes ou traitées davantage.

Les copies liées à l’IA ne doivent pas fonctionner selon une politique de cycle de vie déconnectée.

Pourquoi les décisions pilotées par l’IA doivent rester traçables et auditables

Une organisation doit être en mesure de reconstituer une action significative pilotée par l’IA.

Si un agent recommande de mettre un fournisseur en attente, les examinateurs peuvent avoir besoin de savoir quels enregistrements fournisseur, échecs de livraison, contrats, incidents et règles métier ont influencé le résultat.

« L’IA a décidé » n’est pas une preuve suffisante.

Selon le risque, la piste d’audit peut devoir enregistrer :

La traçabilité devient plus difficile lorsque l’information circule entre SAP, SAP BTP, des applications externes et d’autres plateformes de données ou d’orchestration.

Chaque transfert peut créer une lacune si les identifiants sources, horodatages, lignage et journaux d’actions ne sont pas préservés. L’auditabilité doit donc couvrir l’ensemble du workflow plutôt que la seule transaction SAP finale.

La gestion du changement fait également partie de la traçabilité. Un agent peut se comporter différemment après des modifications de son modèle, de ses prompts, de ses sources de récupération, de ses règles métier, de ses autorisations, de ses transformations ou de ses outils connectés.

Les changements matériels d’un workflow à fort impact doivent déclencher des tests, une revue et une approbation avant que la nouvelle version ne retourne en production. L’organisation doit également pouvoir identifier quelle version a produit une recommandation passée.

Les contrôles doivent rester proportionnés. Un résumé à faible risque n’a pas besoin du même dossier de preuves qu’une transaction affectant l’argent, des données personnelles, l’emploi, la fiscalité ou des données de base.

Les principes de l’IA responsable de SAP incluent la transparence, la responsabilité, la confidentialité, la sécurité et la supervision humaine. Les organisations doivent néanmoins traduire ces principes en contrôles adaptés à leurs propres processus SAP et niveaux de risque.

Pourquoi des données gouvernées sont nécessaires mais insuffisantes

Une base de données SAP gouvernée améliore les conditions dans lesquelles un agent opère. Elle ne garantit pas que chaque recommandation ou action sera correcte.

Même avec des informations exactes et correctement contrôlées, un agent peut mal interpréter des instructions, sélectionner une action inadaptée, répondre avec une confiance excessive ou échouer lorsqu’un système connecté est indisponible.

Les organisations ont donc besoin de contrôles à la fois sur l’information et sur l’agent.

Cela inclut le test du comportement de l’agent, la définition de limites d’action, le suivi des résultats, la fixation de seuils d’exception et la mise en place de solutions de repli lorsque le workflow ne peut pas se terminer en toute sécurité.

Une intervention humaine doit rester possible lorsque les preuves sont contradictoires, qu’un système requis est indisponible ou que l’impact potentiel dépasse le niveau d’autonomie approuvé.

Le rôle de TJC Group se situe principalement dans la base de données gouvernée. L’archivage des données, l’ILM, l’accès historique et les contrôles de cycle de vie soutiennent une automatisation fiable, mais ils ne constituent qu’une partie d’un programme plus large de gouvernance des agents.

Comment TJC Group peut soutenir une base de données SAP gouvernée

TJC Group peut aider les organisations à renforcer la base d’information utilisée par les agents IA SAP.

Son rôle peut être résumé en trois résultats connectés :

Grâce à ses services de gestion des données S/4HANA, TJC Group peut évaluer les volumes de données SAP, les objets d’archivage, les exigences de conservation et les besoins d’accès historique.

L’Archiving Sessions Cockpit prend en charge l’exécution récurrente et le suivi de l’archivage des données SAP et des processus ILM pris en charge. Il aide à transformer une politique approuvée en un processus opérationnel continu plutôt qu’en un exercice manuel irrégulier.

ELSA prend en charge un accès gouverné aux données et documents issus de systèmes SAP et non-SAP décommissionnés. Lorsqu’un futur workflow IA ou analytique a besoin d’informations historiques, des données sélectionnées peuvent être fournies via un processus contrôlé sans maintenir l’application d’origine en fonctionnement.

Ensemble, ces capacités aident les organisations à gérer le volume, le cycle de vie et la disponibilité des informations SAP. Elles fournissent une partie de la base gouvernée requise pour une automatisation fiable, tandis que le comportement du modèle, les décisions métier et l’autorité de l’agent restent dans le cadre plus large de la gouvernance IA de l’organisation.

Conclusion

Les agents IA SAP offrent un potentiel significatif pour accélérer et améliorer les processus métier, mais leur efficacité dépend directement de la qualité, de la gouvernance et de la gestion du cycle de vie des données ERP sous-jacentes. Les organisations qui investissent dans une base de données SAP gouvernée seront mieux positionnées pour déployer des agents IA de manière fiable et responsable.

Les points clés à retenir de cet article sont :

1. Prioriser la qualité et la cohérence des données. Des enregistrements incomplets, dupliqués ou obsolètes compromettront les recommandations des agents IA, quelle que soit la performance du modèle. Traitez le nettoyage des données et la gouvernance des données de base en parallèle de l’archivage des données SAP.
2. Appliquer des contrôles d’accès à chaque workflow IA. Un agent ne doit jamais étendre l’accès autorisé d’un utilisateur. Définissez l’identité du demandeur, les droits d’accès aux données, le périmètre de la tâche, l’autorité d’action et les règles d’approbation avant qu’un agent n’entre dans un processus en production.
3. Appliquer les règles de cycle de vie et de conformité sur toutes les copies. Les workflows IA créent des extractions, des enregistrements mis en cache et des journaux qui doivent suivre les mêmes règles de conservation et de confidentialité que les données sources. SAP ILM peut soutenir cette application au sein des environnements SAP.
4. Assurer la traçabilité de chaque action significative. Les organisations doivent être en mesure de reconstituer comment une décision pilotée par l’IA a été prise, y compris les enregistrements sources, la version du workflow et la supervision humaine impliquée.
5. Reconnaître que des données gouvernées sont nécessaires mais insuffisantes. La qualité des données et la gestion du cycle de vie constituent la base, mais les organisations ont également besoin de contrôles sur le comportement de l’agent, les limites d’autonomie et la gestion des exceptions.

TJC Group, avec plus de 25 ans d’expertise en gestion des volumes de données SAP, aide les organisations à construire la base de données gouvernée dont une automatisation IA fiable a besoin. Contactez-nous dès aujourd’hui pour découvrir comment nous pouvons soutenir votre stratégie de gouvernance des données SAP.

Sources d’information

Cet article est une publication fondée sur la recherche, basée sur les pages produits officielles de SAP, les ressources SAP Learning, les apports techniques de Thierry Julien et la propre analyse de TJC Group sur SAP Joule for Consultants.

SAP Joule Agents
https://www.sap.com/products/artificial-intelligence/ai-agents.html

SAP Joule Studio
https://www.sap.com/products/artificial-intelligence/joule-studio.html

SAP Knowledge Graph
https://www.sap.com/products/artificial-intelligence/knowledge-graph.html

Principes de l’IA responsable de SAP
https://www.sap.com/products/artificial-intelligence/ai-ethics.html

L’analyse de TJC Group sur SAP Joule for Consultants
https://www.tjc-group.com/blogs/is-sap-joule-for-consultants-a-great-assistant-our-opinion/