Daten und Prozesse Hand in Hand: das Beispiel Wärmeplanung

„Wo lohnt es sich, Fernwärme zu verdichten?” klingt nach einer Frage. In Wahrheit sind es fünf: Wo stehen welche Gebäude, wie viel Wärme brauchen sie, wo liegt das Netz, wer wohnt dort und hat welchen Vertrag, und wer im Haus darf was davon sehen.

Fragen dieser Art gibt es bei Energieversorgern viele. Solide beantworten lassen sie sich nur, wenn Daten und Prozesse zusammenspielen: Interne und externe Quellen müssen angeschlossen, miteinander verknüpft, aufbereitet und dann so bereitgestellt werden, dass jede Rolle das Richtige sieht. Fehlt einer dieser Schritte, bleibt es bei Einzelauswertungen, die niemand pflegt, oder bei einer Excel, die nur eine Person versteht.

Wie das konkret aussieht, zeigen wir am Beispiel der Wärmeplanung.

Die Fragen: je Rolle andere

Die kommunale Wärmeplanung setzt den Rahmen. Für ein Stadtwerk folgen daraus sehr praktische Fragen, und jede Rolle stellt sie anders:

• Vertrieb: Wo lohnt es sich hinzugehen? Wen sprechen wir an, und wann - etwa weil ein Gasvertrag in anderthalb Jahren ausläuft?
• Netzplanung: Wo verdichten wir am bestehenden Netz, wo bauen wir aus, und was berichtet der Vertrieb von der Straße zurück?
• Wärmeplanung: Wie entwickelt sich der Bedarf bis 2045, wenn saniert wird? Welche Gebiete sind für Wärmenetze vorgesehen?
• Beratung: Was kann das einzelne Gebäude selbst beitragen - Photovoltaik auf dem Dach, eine Wärmepumpe, Erdwärme?

Alle vier Fragen betreffen dieselben Straßen und dieselben Häuser. Beantwortet werden sie heute oft getrennt.

Die Daten: verteilt, öffentlich und intern

Ein großer Teil der nötigen Daten ist öffentlich - und erstaunlich gut. Nordrhein-Westfalen stellt für jede Gemeinde bereit:

• das Wärmebedarfsmodell mit jedem Gebäude, seinem Wärmebedarf und Sanierungsszenarien bis 2045,
• die Gebäudehöhen aus dem 3D-Gebäudemodell,
• das Solarkataster mit dem Dachpotenzial je Gebäude,
• Angaben zur Eignung für Wärmepumpen und Erdwärme.

Dazu kommt, wo veröffentlicht, die kommunale Wärmeplanung selbst, und als Grundlage für die Karte OpenStreetMap.

Der andere Teil liegt im Haus und ist über mehrere Systeme verteilt: Kunden und Verträge, Netz und Hausanschlüsse, der Kontaktverlauf und die Besuchsplanung des Vertriebs. Und es gibt eine Regel, die mitgedacht werden muss: Vertrieb und Netzbetrieb dürfen nicht alles voneinander sehen (Entflechtung nach § 6a EnWG).

Abbildung 1: Verteilte Quellen werden angeschlossen, aufbereitet und je Rolle bereitgestellt.

So lösen wir das: myFlow•OS und myFlow•Kit greifen ineinander

Wir lösen solche Aufgaben mit zwei Teilen, die zusammenspielen.

Das myFlow•OS ist unser Vorgehen. Bevor gebaut wird, wird der Prozess einmal ganz durchdacht: vom Anwendungsfall über die Spezifikation und die Gestaltung bis zu festen Abnahmekriterien. Jede Stufe hat einen Prüfpunkt. Das klingt nach Aufwand, spart aber welchen: Lücken fallen auf, bevor sie im Code stecken - etwa die Frage, welche Rolle die Besuchsnotizen des Vertriebs nicht sehen darf.

Das myFlow•Kit ist das, womit wir bauen. Kuratierte, wiederverwendbare Bausteine aus offenen Komponenten, für die drei Schritte, auf die es ankommt:

• Anschließen: die Landesdaten einer Gemeinde holen und entpacken, später auch die internen Quellen.
• Aufbereiten: Koordinaten umrechnen, Gebäude mit Straßen, Netz und Dachflächen verknüpfen, Kennzahlen ableiten.
• Bereitstellen: eine Karte direkt im Browser, Listen, Steckbriefe und Rollen.

Zum Kit gehört auch ein Generator für Testdaten: erfundene Personen, Verträge und Kontakte, mit Rufnummern, die für Medienproduktionen reserviert sind, und einer Sperrliste, die verhindert, dass zufällig Namen bekannter Personen entstehen. So lässt sich ein Prozess durchspielen, bevor ein einziger echter Kundendatensatz im Spiel ist.

Weil Vorgehen und Bausteine wiederverwendbar sind, ging es schnell: Der Prototyp stand in unter einem Tag, entwickelt mit KI-Unterstützung im myFlow•OS. Für eine andere Gemeinde braucht es einen neuen Download, keinen neuen Prototyp - das dauert unter einer Minute.

Was dabei herauskommt

Für einen Termin mit einem Stadtwerk ist so ein Wärme-CRM entstanden. Die Bilder zeigen eine anonymisierte Fassung: Straßennamen sind erfunden, die Karte ist ohne Beschriftung, alle Personen und Verträge sind Testdaten. Wärmebedarf, Gebäude und Dachpotenzial stammen aus den Landesdaten, Netz und Anschlüsse sind daraus abgeleitet.

Clip: Rundgang durch den Prototyp, gut 30 Sekunden, ohne Ton.

Wo lohnt es sich hinzugehen? Jede Straße am bestehenden Netz bekommt eine Bewertung aus Wärmebedarf, Wärmedichte, Netznähe und dem Anteil noch nicht angeschlossener Gebäude. Daraus entsteht eine Rangliste, die sich nach drei Strategien sortieren lässt: am bestehenden Netz verdichten, neue Straßen erschließen oder Gas- und Ölheizungen gezielt ansprechen.

Abbildung 2: Die Rangliste zeigt, welche Straße zuerst - mit Wärmebedarf, Dichte und offenem Potenzial.

Wen ansprechen, und wann? Der Steckbrief eines Gebäudes zeigt die Kundensicht: Ansprechpartner, Verträge mit dem Stadtwerk, den bisherigen Kontaktverlauf - und ein Ansprachefenster, wenn ein Gasvertrag ausläuft.

Abbildung 3: Kundensicht mit Verträgen und Ansprachefenster (Testdaten).

Was kann das Gebäude selbst? Aus dem Solarkataster und dem Wärmebedarfsmodell kommen das Photovoltaik-Potenzial auf dem Dach, die zu erwartende Jahresarbeitszahl einer Wärmepumpe und der Anteil, den Erdwärme im Baublock decken könnte. Das ist ein Hinweis für die Beratung, keine Planung.

Abbildung 4: Energie vor Ort, aus den Landesdaten.

Andere Rolle, anderer Blick. Wer als Netzplanung arbeitet, sieht Fernwärme- und Gasnetz und die Rückmeldungen aus dem Vertrieb, aber keine Besuchsnotizen. Die Entflechtung ist von Anfang an Teil des Werkzeugs, nicht nachträglich angeflanscht.

Abbildung 5: Die Rolle Netzplanung sieht die Netze, nicht die Besuchsnotizen des Vertriebs.

Und bis 2045? Ein Schalter zeigt den Wärmebedarf in den Sanierungsszenarien der Landesdaten. Straßen, die heute attraktiv sind, sind es nicht unbedingt noch in zwanzig Jahren.

Abbildung 6: Wärmebedarf 2045 im Sanierungsszenario.

Vom Prototyp in den Betrieb

Ein Prototyp beantwortet nicht alle Fragen, aber er stellt die richtigen. Im Gespräch reden dann alle über dasselbe Bild: Was fehlt, was stimmt nicht, was braucht es wirklich?

Für den Betrieb kommt dazu, was ein Prototyp bewusst weglässt:

• Interne Quellen statt Testdaten: Kunden, Verträge, Netz und Hausanschlüsse werden angeschlossen - mit denselben Bausteinen, über Schnittstellen statt Downloads.
• Rechte und Datenschutz: Rollen werden echt, nicht nur angezeigt; was gespeichert wird, wo und wie lange, wird festgelegt.
• Betrieb: Aktualisierung der Daten, Sicherung, Zuständigkeiten.

Was es nicht ist: keine Wärmeplanung und kein fertiges Produkt. Es ist ein Werkzeug, das Daten und Prozess zusammenbringt - und ein Ausgangspunkt, um gemeinsam festzulegen, was davon wirklich gebraucht wird.

Zur Einordnung

Die Wärmeplanung ist nur ein Beispiel. Dasselbe Muster - verteilte Quellen anschließen, verknüpfen, je Rolle bereitstellen - steckt in vielen Fragen bei Energieversorgern: in der Bepreisung im Vertrieb, im Forderungsmanagement, in der Marktbeobachtung. Mit dem myFlow•OS als Vorgehen und dem myFlow•Kit als Baukasten wird daraus kein Großprojekt, sondern ein Werkzeug, das schnell steht und wächst.

Für jede Gemeinde in Nordrhein-Westfalen lässt sich das in kurzer Zeit zeigen - mit den eigenen Straßen. Sprechen wir darüber.

Datenquellen: Daten Kommunale Wärmeplanung NRW und Solarkataster NRW (LANUV, Datenlizenz Deutschland Zero 2.0), 3D-Gebäudemodell (Geobasis NRW), Kartengrundlage © OpenStreetMap-Mitwirkende.