Schleupen.CS 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 Schleupen.CS-Konnektor?

Ein Schleupen.CS-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 Schleupen.CS 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 Schleupen.CS. 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: Schleupen.CS im Markt

Schleupen.CS gewinnt aktiv SAP-Wechsler und läuft als SaaS in der Schleupen.Cloud. 2026 haben unter anderem die Stadtwerke Rosenheim (rund 90.000 Verträge), Ellwangen und Giengen sowie Lemgo (rund 65.000 Verträge in der Lieferantenrolle) den Wechsel angekündigt oder umgesetzt.

Am 07.07.2026 hat Schleupen den Zuschlag der Stadtwerke Rosenheim öffentlich gemacht: Ablösung von SAP IS-U, SaaS in der Schleupen.Cloud, Abschluss geplant für das erste Quartal 2028 (Schleupen). Lemgo hat die Entscheidung am 20.05.2026 bekanntgegeben.

Was API, CLI und MCP jeweils leisten

Drei Zugänge, eine Datenlage. So setzen wir den Schleupen.CS-Konnektor um:

1. API: REST- oder Export-API hinter einem Adapter. Der Adapter normalisiert Schleupen-Felder auf dasselbe Schema wie bei SAP oder Wilken, damit das Churn-Modell systemübergreifend bleibt.
2. CLI: CLI für Voll- und Delta-Sync aus der Cloud, inkl. Mandantenfilter. Läuft als geplanter Job oder manuell im Scoping.
3. MCP: MCP-Tools spiegeln die gleichen Ressourcen. So kann ein Analyst im Chat nach Verträgen mit Nachzahlung fragen, ohne die Schleupen-Oberfläche zu öffnen.

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.

SaaS in der Schleupen.Cloud: was das für den Konnektor heißt

Im Gegensatz zu On-Prem-IS-U liegt die Plattform beim Hersteller. Sie bekommen keinen klassischen Datenbankzugriff, sondern vereinbarte Schnittstellen und Exporte. Das ist kein Nachteil, wenn der Katalog klar ist. Es bedeutet nur: Freigaben und Rate-Limits gehören ins Scoping.

Für Rosenheim, Ellwangen, Giengen und Lemgo gilt dieselbe Logik unterschiedlich ausgeprägt. Rosenheim plant den Abschluss der Migration für das erste Quartal 2028 und rechnet rund 90.000 Verträge. Lemgo startet in der Lieferantenrolle mit Continuous Billing und Anbindung an das SAP-Hauptbuch. Der Konnektor muss Mandanten, Marktrollen und ggf. Hybrid-Landschaften (Schleupen plus SAP-FiBu) abbilden.

Wann der Konnektor parallel zur Migration startet

Wer gerade von IS-U auf Schleupen.CS wechselt, sollte die Leseschicht nicht erst nach dem Go-Live planen. Historische Kündigungen brauchen Sie aus dem Altsystem, aktuelle Verträge bald aus Schleupen. Wir schneiden den Adapter so, dass beide Quellen nacheinander bedienen und das Churn-Schema gleich bleibt.

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.

Schleupen.CS in der Cloud verändert auch die Betriebsverantwortung: Monitoring der Sync-Jobs liegt bei Ihnen, die Plattformverfügbarkeit beim Hersteller. Wir dokumentieren beide Seiten im Betriebshandbuch, inklusive Eskalationsweg, wenn ein Delta ausbleibt. Ohne diesen Schnitt landet jeder Fehler zuerst beim falschen Team.

Häufig gestellte Fragen

Was ist ein Schleupen.CS-Konnektor?

Eine Leseschicht, die Vertrags- und Abrechnungsdaten aus Schleupen.CS ü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.

Geht das auch bei Multi-Mandanten und Drittabrechnung?

Ja. Der Konnektor filtert nach Mandant und Marktrolle. Für Churn nutzen wir nur die Lieferantenrolle und die freigegebenen Kundendaten.

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: Schleupen.CS Produktseite.

Nächster Schritt

Wenn Sie Schleupen.CS 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