SAP IS-U Konnektor: API, CLI und MCP für Churn 2026

Constantin Budin, Lead Consultant Data & AI bei Pexon Consulting | 8 Min. Lesezeit | 02.10.2026

TL;DR: Wozu ein SAP IS-U-Konnektor?

Ein SAP IS-U-Konnektor macht Vertrags- und Abrechnungsdaten über API, CLI und MCP für Analytics verfügbar. Pexon Consulting baut die Leseschicht so, dass Churn Prediction auf SAP IS-U laufen kann, ohne das Abrechnungssystem zu verändern. Ergebnis: Der Vertrieb sieht Kündigungsrisiken vor der nächsten Preisrunde.

Das Problem: Ohne Datenabzug bleibt Churn Theorie

Churn Prediction braucht Verträge, Abrechnungen, Servicekontakte und historische Wechsel. Die liegen in SAP IS-U bzw. S/4HANA Utilities. Ohne einen klaren, wiederholbaren Zugang bleiben Modelle in Excel-Exporten stecken und zerbrechen nach dem nächsten Release.

Genau hier setzt der Konnektor an. Er ist die Leseschicht zwischen Abrechnung und Analyse. Darauf bauen Score, Uplift und Rückgewinnung auf, wie wir es unter Churn Management für Stadtwerke beschreiben.

Lage 2026: SAP IS-U im Markt

Weiterhin das am weitesten verbreitete Abrechnungssystem bei mittleren Stadtwerken. Oft betrieben über Dienstleister wie rku.it. Die Wartung für klassisches IS-U endet spätestens 2030, deshalb steht bei vielen Werken die Migration auf S/4HANA Utilities oder einen Wechsel noch aus.

Die Migrationswelle ist 2026 sichtbar: Stadtwerke Rosenheim haben SAP IS-U zugunsten von Schleupen.CS abgelöst (Schleupen-Pressemitteilung, 07.07.2026), mit rund 90.000 Verträgen. Wer auf IS-U bleibt, braucht trotzdem einen stabilen Datenabzug für Analytics, unabhängig von der späteren Zielplattform.

Was API, CLI und MCP jeweils leisten

Drei Zugänge, eine Datenlage. So setzen wir den SAP IS-U-Konnektor um:

1. API: OData- oder RFC-basierte Leseschnittstellen auf CDS-Views bzw. BW-Objekte, gekapselt hinter einer eigenen API-Schicht, die nur freigegebene Felder ausliefert.
2. CLI: Ein CLI-Befehl synchronisiert nächtlich Verträge, Belege und Wechsel der letzten Tage in die Analyse-Schicht. Für Ad-hoc-Prüfungen gibt es Debug-Kommandos mit Zeilenlimit.
3. MCP: Ein MCP-Server stellt Tools wie list_contracts, get_invoice, list_switches bereit. Agenten und Analysten fragen damit gezielt, ohne SQL auf dem Produktivsystem.

Die drei Wege teilen Auth, Feldkatalog und Audit-Log. Wer heute per CLI synchronisiert, kann morgen denselben Katalog per MCP einem Agenten geben. Das spart Doppelarbeit und hält §6a EnWG und Datenschutz an einer Stelle.

Welche Objekte der Konnektor für Churn liefert

Netzseitige Daten bleiben draußen. Nach §6a EnWG darf der Vertrieb keine wirtschaftlich sensiblen Netzinformationen nutzen. Details zur sauberen Trennung stehen unter KI im Stadtwerk unter §6a EnWG.

BW, CDS und Datasphere: welcher Pfad passt

Bei SAP-Landschaften gibt es selten nur einen Weg. Wir prüfen im Scoping drei Varianten und wählen die mit dem geringsten Eingriff.

Wichtig ist die Reihenfolge: Zuerst die Fachobjekte festlegen, dann den technischen Pfad. Wer mit der Technik startet, landet bei schönen Schnittstellen ohne die Merkmale, die das Modell braucht.

Viele Stadtwerke betreiben IS-U über einen Dienstleister. Dann gehört dessen Freigabe in den Projektplan. Der Konnektor läuft trotzdem in Ihrer Verantwortung: Feldkatalog, Löschkonzept und Zweckbindung dokumentieren wir auf Ihrer Seite.

Migrationsfestigkeit bis 2030

Solange die IS-U-Wartung läuft, lohnt sich der Konnektor doppelt. Er liefert sofort Daten für Churn und erzwingt gleichzeitig ein sauberes Mapping, das Sie bei S/4 oder einem Systemwechsel wiederverwenden. Die Analyse-Schicht hängt nicht am GUI des Abrechnungssystems, sondern an stabilen Schlüsseln wie Vertragskonto und Geschäftspartner.

Vom Konnektor zur Kündigungsanalyse

Sobald die Leseschicht steht, folgt dieselbe Auswertung wie im Beitrag Churn Prediction Stadtwerke:

1. Historische Kündigungen der letzten zwei bis drei Jahre als Label.
2. Merkmale aus Vertrag, Abrechnung und Service.
3. Modell und Score vor der nächsten Preisanpassung.
4. Ansprache mit Kontrollgruppe.
5. Nachtrainieren nach dem Jahreswechsel.

Ohne Schritt eins und zwei bleibt jeder Score Schätzung. Der Konnektor ist deshalb kein Nebenprodukt, sondern die Voraussetzung.

So starten wir in fünf Schritten

1. Scoping: Systemstand, Betriebsmodell, vorhandene Schnittstellen.
2. Feldkatalog: nur Lieferanten- und Vertriebsdaten, Netz ausnehmen.
3. Adapter bauen: API zuerst, CLI für den Betrieb, MCP für Analysten und Agenten.
4. Qualitätscheck: Abgleich gegen Stichproben aus der Fachlichkeit.
5. Churn-Pilot: eine Sparte, Kontrollgruppe, Festpreis nach Scoping.

Pexon Consulting ist Microsoft Partner und arbeitet mit 30 Azure-Spezialisten an Datenplattformen. Die Analyse-Schicht kann auf Fabric oder einer offenen Plattform liegen, siehe auch Fabric für Smart-Meter-Daten.

Abgrenzung zu klassischen iPaaS-Konnektoren

Ein generischer Integrationsbus kopiert oft zu viele Objekte und zu wenig Semantik. Unser Konnektor ist absichtlich schmal: nur die Objekte für Kundenbindung und Churn, mit dokumentiertem Zweck. iPaaS kann darunter liegen, ersetzt aber weder Feldkatalog noch MCP-Rechte noch die Anbindung an den Churn-Pilot.

Wer bereits SAP-MCP oder andere Agent-Anbindungen nutzt, etwa aus dem Umfeld von Copilot Studio, kann Teile wiederverwenden. Für IS-U und die anderen Billing-Systeme bleibt der energiewirtschaftliche Objektzuschnitt entscheidend, nicht nur die technische Protokollwahl.

Typische Stolpersteine und wie wir sie vermeiden

In den Gesprächen mit Versorgern wiederholen sich dieselben Punkte. Wir adressieren sie bewusst vor dem Bau, nicht danach.

1. Feld ohne Owner: Jedes Merkmal braucht eine Fachrolle. Sonst stirbt der Katalog nach dem ersten Release.
2. Zu breiter Zugriff: Lieber zehn stabile Felder als hundert ungeprüfte. Das Modell startet schlank.
3. Einmal-Export: Ohne Delta-Sync veraltet der Score in Wochen. CLI und Scheduler gehören zum Lieferumfang.
4. MCP ohne Rechtekonzept: Tools nur für freigegebene Rollen, mit Audit welche Abfrage wann lief.
5. Churn ohne Kontrollgruppe: Der Konnektor allein hält keinen Kunden. Die Auswertung gegen eine Kontrollgruppe bleibt Pflicht.

Wer diese fünf Punkte im Scoping klärt, spart die teure Nacharbeit im Betrieb. Der Konnektor ist dann nicht nur angebunden, sondern führbar.

Für IS-U-Landschaften mit starkem Customizing gilt: Standard-Views zuerst, Z-Felder nur mit Begründung. Jedes Kundenerweiterungfeld erhöht den Testaufwand nach Support Packages. Der Konnektor bleibt wartbar, wenn er schmal und standardnah geschnitten ist.

Häufig gestellte Fragen

Was ist ein SAP IS-U-Konnektor?

Eine Leseschicht, die Vertrags- und Abrechnungsdaten aus SAP IS-U über API, CLI und MCP bereitstellt. Das Abrechnungssystem bleibt unverändert. Die Daten fließen in eine Analyse-Umgebung für Churn und verwandte Use Cases.

Warum API, CLI und MCP parallel?

Die API bedient Anwendungen, das CLI den Betrieb und Sync-Jobs, MCP die Arbeit mit Agenten und Analysten. Ein Katalog, drei Oberflächen.

Funktioniert der Konnektor auch während der S/4-Migration?

Ja. Wir binden die Leseschicht so an, dass sie nach dem Wechsel auf S/4HANA Utilities weiterläuft. Während der Migration lesen wir aus dem jeweils aktiven System und dokumentieren Feld-Mappings.

Was kostet der Konnektor?

Festpreis nach Scoping. Der Umfang hängt vom Betriebsmodell und von den freigegebenen Schnittstellen ab. Den Churn-Pilot für eine Sparte kalkulieren wir getrennt oder als Paket.

Wie hängt der Konnektor mit Churn Management zusammen?

Der Konnektor liefert die Daten. Churn Management nutzt sie für Score, Ansprache und Erfolgsmessung. Beides ist unter Churn Management für Stadtwerke beschrieben. Externe Einordnung zum Systemumfeld: SAP Help Portal zu Utilities.

Nächster Schritt

Wenn Sie SAP IS-U für Analytics öffnen und vor der Preisrunde 2027 Kündigungsrisiken sehen wollen, besprechen wir Konnektor und Pilot gern mit Ihnen. Überblick: Energie und Stadtwerke.

Verwandte Themen