Category: Insights

Articles on SAP S/4HANA Utilities, SAP BTP, integration and AI in SAP.

  • LLMs in SAP customer service: lessons from a productive project

    Energy suppliers receive thousands of customer requests every month – by e-mail and on the hotline. Many of them are standard cases: payment plans, payment extensions, invoice copies, moves. Large language models (LLMs) can take over a large part of this work, but only if they are connected to SAP securely and reliably. These are the lessons from a productive project.

    Start with clear, high-volume business cases

    “Use AI in customer service” is not a use case. The following are – and together they cover a large share of the daily workload:

    • Payment plans: recognise the request, check the conditions and set up the installment plan in SAP S/4HANA Utilities.
    • Payment extensions: grant a deferral of the due date within defined rules.
    • Invoice copies: identify the customer and the invoice and send the copy automatically.
    • Moves: capture move-in and move-out data and trigger the move process in SAP.

    AI e-mail triage

    Every incoming e-mail is classified by the LLM: which business case is it, which contract account, which data is missing? Clear cases are processed automatically, all others are routed to the right team in SAP Customer Engagement – with a pre-filled summary and a suggested answer.

    Connecting the hotline: Cognigy and SAP

    The same business cases are also available on the phone. A voice bot based on Cognigy answers calls, identifies the customer and executes the request directly in SAP – for example sending an invoice copy or registering a payment extension – without waiting in the queue.

    Architecture: Azure, Databricks and SAP BTP

    • Azure OpenAI provides the language model, hosted in a region that meets data protection requirements.
    • Databricks is used for data preparation, analytics and the AI pipelines around the model.
    • SAP BTP Integration Suite is the integration layer: it validates the model output, enriches it with master data, calls the right SAP APIs and handles errors.
    • SAP S/4HANA Utilities and SAP Customer Engagement remain the leading systems for all business transactions.

    Important: the LLM never talks to the SAP back end directly. The integration layer keeps SAP consistent even when the model is wrong.

    Keep a human in the loop

    Uncertain cases go to an agent, with the AI’s suggestion attached. The share of fully automated cases grows step by step – based on evidence, not hope.

    Data protection and authorizations

    • Define where the model runs and which data it may see.
    • Use technical users with minimal authorizations for every system call.
    • Log decisions so that they can be traced and audited.

    Plan operations from the start

    An AI solution is never “done”. Prompts, models and SAP releases change. Monitoring, a release process via ChaRM or Cloud ALM and a clear owner are essential. Also keep an eye on SAP’s own offerings such as SAP AI Core, Joule and the Model Context Protocol (MCP).

    Conclusion

    AI in SAP customer service works – when it is treated as an integration and governance project, not only as a model question. Read more about our AI in SAP services or get in touch.

  • Swiss energy law (Mantelerlass, LEG, vZEV) in SAP S/4HANA Utilities

    The Swiss electricity market is undergoing its biggest change in years. With the Federal Act on a Secure Electricity Supply from Renewable Energy Sources (known as the “Mantelerlass”), approved by Swiss voters in June 2024, energy suppliers and grid operators have to support new market models – and they have to do it in SAP IS-U or SAP S/4HANA Utilities.

    What changes for utilities

    • Local electricity communities (LEG): consumers and producers within a municipality can share locally produced electricity using the public grid, with reduced grid tariffs.
    • Virtual self-consumption communities (vZEV): extended options for joint self-consumption behind the connection point.
    • Dynamic and new tariff models and additional requirements for metering and data exchange.

    What this means in SAP

    In SAP S/4HANA Utilities these requirements affect the device and installation structure, billing and tariff design, energy data management (EDM), market communication and the customer front end. On top of the functional changes come the technical ones: new Fiori apps, new roles and authorizations, adjusted interfaces and a clean transport and go-live process.

    Lessons from practice

    • Authorizations are on the critical path. New transactions and Fiori apps need roles, and missing authorizations are among the most common go-live issues. Trace early and test with realistic users.
    • Use standard functionality first. SAP and industry partners deliver more and more of the regulatory content – check it before building custom code.
    • Plan transports and ChaRM carefully. Several regulatory projects often run in parallel on the same system; conflicts are inevitable without coordination.
    • Involve the operating partner early for roles, transports and system copies.

    How we can help

    We have implemented LEG and Mantelerlass requirements in S/4HANA Utilities, including authorization concepts, Fiori roles, transports and go-live support. Learn more about our S/4HANA Utilities services or contact us.

  • SAP PI/PO to Integration Suite: a practical migration guide

    SAP Process Orchestration (PI/PO) still carries business-critical interfaces in many SAP landscapes. With mainstream maintenance for SAP PO 7.5 ending at the end of 2027 and extended maintenance offered until 2030, now is the time to plan the move to SAP Integration Suite. Here is how we approach such a migration in practice.

    1. Start with a complete inventory

    Before anything is migrated, list every integration scenario: sender and receiver, adapter types, mappings, message volumes, error rates and business owner. In most landscapes a surprising share of interfaces is no longer used or can be replaced by standard APIs. Every interface you retire is one you do not have to migrate.

    2. Decide: lift, re-design or replace

    • Lift: simple, stable scenarios can often be moved with SAP’s migration tooling and minor adjustments.
    • Re-design: complex mappings or BPM processes are usually better rebuilt as clean iFlows with Groovy scripts and reusable components.
    • Replace: where SAP or the partner system offers a modern API, use it instead of a file or IDoc interface.

    3. Get security and connectivity right early

    Most delays are not caused by mappings but by connectivity: SAP Cloud Connector configuration, certificates, OAuth clients, technical users, firewall openings and SFTP keys. Plan these topics with your BASIS team and hosting partner from day one – especially in RISE with SAP, where responsibilities are split between you, SAP and your operator.

    4. Establish BTP governance

    Integration Suite is part of SAP BTP. Define the account and subaccount model, naming conventions, transport path (e.g. with SAP Cloud ALM or the Transport Management Service), monitoring and alerting, and who may deploy what. Without these rules the new platform quickly becomes as unstructured as the old one.

    5. Migrate in waves and run in parallel

    Group interfaces into waves by business process and risk. Test end-to-end with the business, switch over wave by wave and keep the PI/PO system available as a fallback until the last wave is stable.

    Conclusion

    A PI/PO migration is a chance to clean up your integration landscape, not just a technical obligation. If you would like support with the inventory, architecture or implementation, get in touch – or read more about our SAP BTP & Integration Suite services.