Catégorie : Uncategorized

Les fournisseurs d’énergie reçoivent chaque mois des milliers de demandes clients – par e-mail et par téléphone. Beaucoup sont des cas standard : plans de paiement, reports d’échéance, copies de factures, déménagements. Les grands modèles de langage (LLM) peuvent prendre en charge une grande partie de ce travail, mais seulement s’ils sont connectés à SAP de manière sûre et fiable. Voici les enseignements d’un projet en production.

Commencer par des cas métier clairs et à fort volume

« Utiliser l’IA dans le service client » n’est pas un cas d’usage. Les suivants le sont – et ensemble, ils couvrent une grande partie de la charge quotidienne :

• Plans de paiement : reconnaître la demande, vérifier les conditions et créer le plan de paiement échelonné dans SAP S/4HANA Utilities.
• Reports d’échéance : accorder un report de la date d’échéance selon des règles définies.
• Copies de factures : identifier le client et la facture et envoyer la copie automatiquement.
• Déménagements : saisir les données d’emménagement et de déménagement et déclencher le processus dans SAP.

Tri des e-mails par IA

Chaque e-mail entrant est classé par le LLM : de quel cas métier s’agit-il, quel compte contrat, quelles données manquent ? Les cas clairs sont traités automatiquement, tous les autres sont routés vers la bonne équipe dans SAP Customer Engagement – avec un résumé pré-rempli et une proposition de réponse.

Connecter la hotline : Cognigy et SAP

Les mêmes cas métier sont disponibles par téléphone. Un voicebot basé sur Cognigy répond aux appels, identifie le client et exécute la demande directement dans SAP – par exemple l’envoi d’une copie de facture ou l’enregistrement d’un report d’échéance – sans file d’attente.

Architecture : Azure, Databricks et SAP BTP

• Azure OpenAI fournit le modèle de langage, hébergé dans une région conforme aux exigences de protection des données.
• Databricks sert à la préparation des données, à l’analyse et aux pipelines d’IA autour du modèle.
• SAP BTP Integration Suite est la couche d’intégration : elle valide la sortie du modèle, l’enrichit avec les données de base, appelle les bonnes API SAP et gère les erreurs.
• SAP S/4HANA Utilities et SAP Customer Engagement restent les systèmes de référence pour toutes les transactions métier.

Important : le LLM ne communique jamais directement avec le back-end SAP. La couche d’intégration garde SAP cohérent, même lorsque le modèle se trompe.

Garder l’humain dans la boucle

Les cas incertains sont transmis à un conseiller, avec la suggestion de l’IA jointe. La part des cas entièrement automatisés augmente pas à pas – sur la base de preuves, pas d’espoirs.

Protection des données et autorisations

• Définissez où le modèle s’exécute et quelles données il peut voir.
• Utilisez des utilisateurs techniques avec des autorisations minimales pour chaque appel système.
• Journalisez les décisions afin qu’elles puissent être tracées et auditées.

Planifier l’exploitation dès le départ

Une solution d’IA n’est jamais « terminée ». Prompts, modèles et releases SAP évoluent. Supervision, processus de release via ChaRM ou Cloud ALM et un responsable clairement désigné sont indispensables. Gardez aussi un œil sur les offres de SAP comme SAP AI Core, Joule et le Model Context Protocol (MCP).

Conclusion

L’IA dans le service client SAP fonctionne – lorsqu’elle est traitée comme un projet d’intégration et de gouvernance, et pas seulement comme une question de modèle. Découvrez nos services IA dans SAP ou contactez-nous.

Le marché suisse de l’électricité vit son plus grand changement depuis des années. Avec la loi fédérale relative à un approvisionnement en électricité sûr reposant sur des énergies renouvelables (le « Mantelerlass »), acceptée par le peuple suisse en juin 2024, fournisseurs d’énergie et gestionnaires de réseau doivent prendre en charge de nouveaux modèles de marché – et ce dans SAP IS-U ou SAP S/4HANA Utilities.

Ce qui change pour les fournisseurs

• Communautés électriques locales (CEL/LEG) : consommateurs et producteurs d’une même commune peuvent partager l’électricité produite localement via le réseau public, avec des tarifs d’utilisation du réseau réduits.
• Regroupements virtuels dans le cadre de la consommation propre (RCPv/vZEV) : possibilités élargies de consommation propre commune derrière le point de raccordement.
• Modèles tarifaires dynamiques et nouveaux, ainsi que des exigences supplémentaires en matière de comptage et d’échange de données.

Ce que cela signifie dans SAP

Dans SAP S/4HANA Utilities, ces exigences touchent la structure des appareils et des installations, la facturation et la conception tarifaire, la gestion des données énergétiques (EDM), la communication de marché et le front-end client. Aux changements fonctionnels s’ajoutent les changements techniques : nouvelles applications Fiori, nouveaux rôles et autorisations, interfaces adaptées et un processus de transport et de mise en production rigoureux.

Enseignements de la pratique

• Les autorisations sont sur le chemin critique. Les nouvelles transactions et applications Fiori nécessitent des rôles, et les autorisations manquantes figurent parmi les problèmes de mise en production les plus fréquents. Tracez tôt et testez avec des utilisateurs réalistes.
• Privilégier d’abord le standard. SAP et les partenaires du secteur livrent de plus en plus de contenus réglementaires – vérifiez-les avant de développer du spécifique.
• Planifier soigneusement transports et ChaRM. Plusieurs projets réglementaires tournent souvent en parallèle sur le même système ; sans coordination, les conflits sont inévitables.
• Impliquer tôt le partenaire d’exploitation pour les rôles, les transports et les copies de systèmes.

Comment nous pouvons aider

Nous avons mis en œuvre les exigences LEG et Mantelerlass dans S/4HANA Utilities, y compris les concepts d’autorisation, les rôles Fiori, les transports et l’accompagnement de la mise en production. Découvrez nos services S/4HANA Utilities ou contactez-nous.

SAP Process Orchestration (PI/PO) porte encore des interfaces critiques dans de nombreux paysages SAP. La maintenance standard de SAP PO 7.5 se terminant fin 2027, avec une maintenance étendue proposée jusqu’en 2030, c’est le moment de planifier le passage à SAP Integration Suite. Voici comment nous abordons une telle migration en pratique.

1. Commencer par un inventaire complet

Avant toute migration, recensez chaque scénario d’intégration : émetteur et récepteur, types d’adaptateurs, mappings, volumes de messages, taux d’erreur et responsable métier. Dans la plupart des paysages, une part étonnante des interfaces n’est plus utilisée ou peut être remplacée par des API standard. Chaque interface supprimée est une interface de moins à migrer.

2. Décider : reprendre, repenser ou remplacer

• Reprendre : les scénarios simples et stables peuvent souvent être déplacés avec les outils de migration de SAP et de légers ajustements.
• Repenser : les mappings complexes ou les processus BPM gagnent généralement à être reconstruits sous forme d’iFlows propres avec des scripts Groovy et des composants réutilisables.
• Remplacer : lorsque SAP ou le système partenaire propose une API moderne, utilisez-la plutôt qu’une interface fichier ou IDoc.

3. Traiter tôt la sécurité et la connectivité

La plupart des retards ne viennent pas des mappings mais de la connectivité : configuration du SAP Cloud Connector, certificats, clients OAuth, utilisateurs techniques, ouvertures de pare-feu et clés SFTP. Planifiez ces sujets dès le premier jour avec votre équipe BASIS et votre hébergeur – surtout avec RISE with SAP, où les responsabilités sont réparties entre vous, SAP et votre exploitant.

4. Mettre en place la gouvernance BTP

Integration Suite fait partie de SAP BTP. Définissez le modèle de comptes et sous-comptes, les conventions de nommage, le chemin de transport (p. ex. avec SAP Cloud ALM ou le Transport Management Service), la supervision et les alertes, ainsi que qui peut déployer quoi. Sans ces règles, la nouvelle plateforme devient vite aussi désordonnée que l’ancienne.

5. Migrer par vagues et en parallèle

Regroupez les interfaces en vagues selon le processus métier et le risque. Testez de bout en bout avec les métiers, basculez vague par vague et gardez le système PI/PO disponible comme solution de repli jusqu’à ce que la dernière vague soit stable.

Conclusion

Une migration PI/PO est l’occasion d’assainir votre paysage d’intégration, pas seulement une obligation technique. Si vous souhaitez un soutien pour l’inventaire, l’architecture ou la réalisation, contactez-nous – ou découvrez nos services SAP BTP & Integration Suite.