TIWAG digital weiterdenken: von smarten Produkten zur erklärbaren Energieservice-Schicht
Das ist eine unabhängige TIWAG Opportunity Analysis, keine Case Study und kein Audit. Sie stellt eine konkrete Produktfrage: Welche Software-, Automatisierungs- und KI-Chancen wären angesichts der öffentlich sichtbaren digitalen Energieservices als Nächstes prüfenswert, wenn Wavect einen Energieversorger mit vergleichbaren Herausforderungen beraten würde?
Diese Seite beantwortet die TIWAG-spezifische Frage. Unser Leitfaden zur Smart-City-Architektur behandelt allgemeine Entscheidungen zu IoT und Datenplattformen. Der DACH-KI-Adoptionsbenchmark behandelt die Marktentwicklung. Keiner dieser Artikel behauptet, TIWAG zu analysieren.
Warum TIWAG für eine digitale Energieanalyse interessant ist
Der TIWAG-Geschäftsbericht 2024 beschreibt den Wandel vom Verbraucher zum Prosumer und nennt Dezentralisierung, Digitalisierung sowie die Integration neuer Technologien als prägende Kräfte im Energiesektor. Das ist eine historische Aussage des Unternehmens, keine Schlussfolgerung von uns. Siehe TIWAG-Geschäftsbericht 2024.
Die aktuelle Produktoberfläche ist konkreter. TIWAG veröffentlicht TIWAG-smart flex mit preisbasierter Steuerung für kompatible E-Autos, Wärmepumpen, Photovoltaikanlagen und Batteriespeicher sowie einem zentralen Dashboard. Die Seite zur TIWAG-Ökostrom-Community beschreibt Registrierung, EDA-Marktkommunikation, Teilnehmerverwaltung, Abrechnungsdaten und die Visualisierung von Energieflüssen. Ein veröffentlichtes Factsheet zum Kundenportal dokumentiert außerdem die digitale An- und Abmeldung von Strom.
Bei Energiegemeinschaften sind die zugrunde liegenden Daten operativ anspruchsvoll. Die österreichische Koordinationsstelle erklärt, dass die Aufteilung Viertelstundenwerte nutzt, während untermonatlich verfügbare Werte noch nicht für die Abrechnung validiert sein können. Ihre Hinweise zu Messung und Aufteilung unterscheiden laufende Messwerte vom späteren Clearing. Für Dashboards, Prognosen und Rechnungen ist diese Trennung wesentlich.
Was ist öffentlicher Fakt, Schlussfolgerung und Hypothese?
| Kategorie | Was wir sagen können | Was wir nicht sagen können |
|---|---|---|
| Verifizierter öffentlicher Fakt | TIWAG veröffentlicht ein Kundenportal, dynamische Produkte, smarte Gerätesteuerung und Services für Energiegemeinschaften. | Öffentliche Produktseiten zeigen die internen Systeme dahinter nicht. |
| Vertretbare Schlussfolgerung | Diese Services erzeugen Customer Journeys über Tarife, Geräte, Zählerdaten, Gemeinschaften und Support. | Wir können nicht folgern, dass diese Journeys fragmentiert, langsam oder teuer sind. |
| Hypothese | Eine gemeinsame Entscheidungs- und Operations-Schicht könnte manche Journeys leichter erklärbar und betreibbar machen. | Wir können weder behaupten, dass diese Schicht fehlt, noch dass sie wirtschaftlich gerechtfertigt ist. |
Die nützliche Chance lautet daher nicht „digital werden“ oder „KI hinzufügen“. Digitale Services sind bereits öffentlich sichtbar. Die wichtige Frage ist, ob eine kohärente Schicht über diese Angebote hinweg Entscheidungen, Erklärungen und Abläufe verbessern könnte, ohne bewährte energiewirtschaftliche Systeme zu ersetzen.
Fünf Chancen, die wir untersuchen würden
| Chance | Wirtschaftlicher Mechanismus | Erstes Validierungssignal |
|---|---|---|
| 1. Entscheidungs-Schicht für Kundenenergie | Haushalte oder Betriebe vergleichen Tarife, Geräte, Speicher und Energiegemeinschaften in einer geführten Journey. | Mehr Nutzer schließen einen informierten nächsten Schritt ohne zusätzliche Rückfrage ab. |
| 2. Erklärbare Gerätesteuerung | Zeigen, warum Auto, Speicher oder Wärmepumpe eingeplant wurden, welche Grenzen galten und welche Alternative bestand. | Nutzer verstehen die Automatisierung und lassen sie aktiv. |
| 3. Ausnahmeorientierte EEG-Operations | Saubere EDA- und Abrechnungsflüsse von fehlenden, späten oder widersprüchlichen Fällen trennen. | Operations-Teams verbringen mehr Zeit mit echten Ausnahmen. |
| 4. Quellengebundener Service-Copilot | Die passende freigegebene Regel, Produktunterlage oder Prozessanweisung finden und eine belegte Antwort entwerfen. | Schnellere, konsistentere Antworten ohne mehr Korrekturen. |
| 5. Ebene für Produktexperimente | Onboarding, Erklärungen und Benachrichtigungen mit klaren Kennzahlen und Guardrails testen. | Ein Team kann eine Hypothese mit beobachteter Evidenz annehmen oder verwerfen. |
1. Eine Entscheidungs-Schicht für Kundenenergie
Das Business-Problem ist eine Wahl unter zusammenhängenden Bedingungen. Ein Kunde kann Tarif, Photovoltaik, Speicher, E-Auto, Wärmepumpe und mögliche EEG-Teilnahme kombinieren. Der passende nächste Schritt hängt von Berechtigung, Gerätekompatibilität, Nutzung, Einwilligung und Konditionen ab.
Wir würden zuerst eine Journey abbilden, zum Beispiel: „Kann dieser Haushalt von einem dynamischen Produkt und gesteuertem Laden profitieren?“ Eine Rule Engine prüft Produkt- und Geräteberechtigung. Ein deterministischer Simulator vergleicht Szenarien mit offengelegten Annahmen. KI kann das Ergebnis verständlich formulieren oder fehlende Angaben dialogisch erfassen, darf aber keine Preise, Berechtigungen oder Ersparnisse erfinden.
- Benötigte Daten: Produktkatalog, Kompatibilitätsregeln, freigegebene Intervalldaten oder ein eingegebenes Lastprofil, Gerätebedingungen und Vertragskontext.
- Menschliche Rolle: Produkt- und Compliance-Verantwortliche geben Regeln und Formulierungen frei; der Service übernimmt unklare Fälle.
- Günstiger Test: klickbarer Prototyp und Szenario-Engine mit synthetischen Profilen, bevor ein Kundenkonto angebunden wird.
2. Erklärbare Gerätesteuerung
Optimierung ist nicht nur ein Planungsproblem, sondern auch eine Vertrauensfrage. Nutzer müssen verstehen, ob Abfahrtszeit, Komfort, Speicherreserve, PV-Prognose und Preisgrenzen eingehalten wurden. Der Optimierer kann Regeln, lineare Programmierung oder Model Predictive Control verwenden. Generative KI gehört nicht in den Regelkreis.
Eine mögliche Umsetzung speichert jeden Plan mit Inputs, Grenzen, gewählter Aktion und Gegenfaktum. Die Oberfläche könnte erklären: „Der Ladevorgang startete um 02:00 Uhr, weil das Auto bis 07:00 Uhr 32 kWh benötigte und dies das günstigste machbare Zeitfenster war.“ KI kann strukturierte Gründe in natürliche Sprache übersetzen. Die Erklärung selbst muss aus deterministischer Evidenz stammen.
- Benötigte Daten: Gerätestatus, Nutzerbedingungen, Preisreihe, freigegebene Erzeugungs- oder Lastprognosen und Ergebnisse von Befehlen.
- Menschliche Rolle: Kunden behalten Overrides; Operations sieht fehlgeschlagene Befehle und ungewöhnliche Zustände.
- Günstiger Test: Empfehlungen im Shadow Mode für eine kleine Opt-in-Gruppe, ohne Gerätebefehl.
3. Eine auf Ausnahmen ausgerichtete Operations-Workbench für Energiegemeinschaften
EEG-Arbeit verbindet Onboarding, Marktkommunikation, Messwerte, Aufteilung, Dokumente, Abrechnung und Teilnehmerfragen. Wir behaupten nicht, wie TIWAG diese Aufgaben heute erledigt. Wir würden prüfen, ob eine gemeinsame Workbench Status und Ausnahmen in einem vergleichbaren Service leichter betreibbar macht.
Der deterministische Workflow sollte Teilnehmerstatus, Fristen, Zählpunktvalidierung, Datenversion, Clearingstatus und Rechnungsfähigkeit besitzen. KI hilft an den Rändern: Dokumente klassifizieren, Felder zur Bestätigung extrahieren, ähnliche Anfragen gruppieren oder Antworten aus freigegebenen Anweisungen entwerfen. Sie sollte nicht entscheiden, ob ein Zählpunkt gültig oder eine Rechnung endgültig ist.
- Benötigte Daten: Workflow-Events, EDA-Bestätigungen, Datenqualitätsstatus, Dokumenttypen und Ergebnisse der Falllösung.
- Menschliche Rolle: Operatoren bestätigen extrahierte Felder und lösen Ausnahmen mit finanziellen oder vertraglichen Folgen.
- Günstiger Test: anonymisierte oder synthetische Fälle wiedergeben und Klassifikationsqualität, Bearbeitungsschritte sowie Eskalationen messen.
4. Ein quellengebundener Copilot für Energieservice-Teams
„Chatbot hinzufügen“ ist keine Strategie. Ein nützlicher Service-Copilot löst ein engeres Problem: Er findet die aktuelle freigegebene Antwort zu Tarifen, Geräten, Portalschritten und EEG-Prozessen, zeigt die Quelle und entwirft die nächste Antwort. Änderungen am Kundenkonto laufen weiter über authentifizierte, deterministische Tools mit Bestätigung.
Der Retrieval-Index enthält versionierte Produktblätter, Prozessanweisungen, Kompatibilitätslisten und Servicewissen. Jede Antwort trägt Quelle, Gültigkeitsdatum und Konfidenz. Wenn Quellen widersprechen oder die Frage vom Kontostatus abhängt, muss der Copilot stoppen und an einen Menschen übergeben.
- Benötigte Daten: freigegebenes Wissen, Versionshistorie, anonymisierte Fragekategorien und Korrekturfeedback.
- Menschliche Rolle: Service-Mitarbeiter prüfen Entwürfe; Content Owner entfernen veraltete Quellen und analysieren Korrekturen.
- Günstiger Test: Offline-Evaluation mit 50 bis 100 repräsentativen, redigierten Fragen, bevor Mitarbeiter Vorschläge sehen.
5. Eine Ebene für Produktexperimente über digitale Energieservices
Öffentliche Seiten zeigen mehrere Produktoberflächen. Öffentliche Informationen zeigen nicht, wie deren Performance gemessen wird. Wir würden ein datensparsames Eventmodell prüfen, das eine Änderung an Erklärung oder Onboarding mit einem beobachtbaren Ergebnis verbindet. Das Ziel ist keine Überwachung, sondern zu lernen, ob eine Produkthypothese Kunden bei einer sinnvollen Aufgabe hilft.
Events sollten die Journey beschreiben und kein rohes Haushaltsverhalten offenlegen. Beispiele sind: Berechtigungsprüfung abgeschlossen, Erklärung geöffnet, Override verwendet, Dokument mit Grund abgelehnt, Support-Übergabe und erfolgreiche Wiederherstellung. Ein Produktteam kann Varianten vergleichen, während Security, Datenschutz und Accessibility die Grenzen der Erfassung festlegen.
Eine mögliche technische Architektur
Das ist eine beispielhafte Architektur, keine Beschreibung der TIWAG-Umgebung.
| Schicht | Verantwortung | Designgrenze |
|---|---|---|
| Experience Layer | Web-, Mobile-, Service-Desk- und Operations-Journeys | Keine Business-Regel existiert nur im UI-Code. |
| Journey APIs | Stabile Verträge für Berechtigung, Simulation, Onboarding, Erklärung und Fallstatus | Adapter isolieren vorhandene Systeme und Anbieter. |
| Deterministischer Kern | Tarifregeln, Einwilligung, Gerätebefehle, Workflow-Status, Rechnungsfähigkeit und Audit Records | Versionierte Inputs und wiederholbare Ergebnisse. |
| Energiedaten-Ebene | Intervalldaten, Prognosen, Geräte-Events und Qualitätsstatus | Rohdaten, vorläufige und geclearte Daten bleiben unterscheidbar. |
| KI-Sidecar | Retrieval, Klassifikation, Extraktion und Entwurf von Erklärungen | Keine direkte Autorität über Abrechnung, Berechtigung oder Geräte. |
| Menschliche Operations | Ausnahme-Queues, Freigaben, Overrides und Korrekturfeedback | Jede folgenreiche Aktion hat Owner und Begründung. |
| Observability und Experimente | Journey-Kennzahlen, Modell-Evaluationen, Befehlsresultate und Rollback-Signale | Erfassung folgt Zweck, Einwilligung und Aufbewahrungsgrenzen. |
Eine neue Schicht sollte keinen Big-Bang-Austausch erfordern. Wir würden schmale Adapter um bestehende Verträge und eine erste unabhängig rückrollbare Journey bevorzugen. Das ist dieselbe Produktdisziplin hinter Wavects individueller Softwareentwicklung, produktiver KI-Entwicklung und IoT-Engineering: Kontrollpfade explizit halten, Evidenz beobachtbar machen und KI nur dort einsetzen, wo Unsicherheit das eigentliche Problem ist.
Wie wir die Hypothese in 30, 60 und 90 Tagen validieren würden
| Zeitraum | Arbeit | Entscheidung am Ende |
|---|---|---|
| Tag 1 bis 30 | Product, Service, Operations, Data, Security und Regulatory interviewen. Eine Journey mappen, Baseline erheben, Datenhoheit klären und mit synthetischen Inputs prototypen. | Ist das Problem real, wesentlich und sicher testbar? |
| Tag 31 bis 60 | Einen dünnen Vertical Slice hinter Feature Flags bauen. Nur minimale Systeme anbinden. Deterministische Tests, Accessibility Review, Threat Modelling und Offline-KI-Evaluation durchführen. | Verbessert der Slice den gewählten Mechanismus ohne inakzeptable Fehler oder Mehrarbeit? |
| Tag 61 bis 90 | Kleinen Opt-in-Pilot oder Shadow Mode betreiben. Aufgabenerfolg, Korrekturen, Eskalationen, Opt-outs und Operations-Feedback vergleichen. Rollback und Ownership dokumentieren. | Auf Basis der Evidenz skalieren, ändern oder stoppen. |
Bei einem folgenreichen Workflow können 90 Tage lediglich eine besser informierte nächste Entscheidung rechtfertigen. Das ist ein gültiges Ergebnis. Ein Pilot sollte beendet werden, wenn Datenzugang, Nutzwert, betriebliche Ownership oder Wirtschaftlichkeit keine Produktion tragen.
Möglicher Business Impact, ohne erfundenen ROI
Von außen können wir keine TIWAG-spezifischen Einsparungen, Umsätze oder Amortisation berechnen. Ein belastbarer Business Case nutzt interne Baselines und legt Annahmen offen. Statt einer erfundenen Prozentzahl würden wir Mechanismen messen:
- Kundenwert: informierter Abschluss, aktive Automatisierung, erfolgreiches Self-Service, Accessibility und Vertrauen.
- Operativer Wert: Dunkelverarbeitung, Ausnahmevolumen, Lösungszeit, Korrekturrate und Wiederholungskontakt.
- Produktwert: Conversion von Berechtigung zu Aktivierung, Opt-out, Feature-Nutzung und Supportbedarf pro Journey.
- Technischer Wert: Befehlserfolg, Datenfrische, Replay-Erfolg, Quellenkorrektheit des Modells, Latenz und Kosten pro erledigter Aufgabe.
- Risikokontrollen: blockierte unberechtigte Aktionen, unterdrückte Antworten aus veralteten Quellen, menschliche Overrides und Rollback-Zeit.
Welche internen Informationen wären nötig?
Vor einer Umsetzungsempfehlung bräuchten wir das echte Geschäftsziel, Journey Analytics, System-Ownership, Interface-Verträge, Historie der Datenqualität, Einwilligungsmodell, Sicherheitsanforderungen, regulatorische Auslegung, Accessibility-Bedarf, Vendor-Bedingungen, Servicevolumen, Fehlerkosten und einen verantwortlichen Product Owner. Ohne diese Informationen bleiben Architektur und Wirtschaftlichkeit Hypothesen.
Auch Wavect-Proof muss klar von TIWAG getrennt bleiben. Unsere IKB IoT Case Study belegt angrenzende Arbeit an vernetzter Infrastruktur. Sie bedeutet nicht, dass hier dieselbe Architektur oder Wirkung gilt. Der Leitfaden zur Software Discovery zeigt, wie aus einer Opportunity Map testbarer Scope wird, bevor ein Build beauftragt wird.
Arbeitest du an einem ähnlichen digitalen Energie-Use-Case? Bring eine Idee in einen kostenlosen, unverbindlichen Workshop. Gemeinsam prüfen wir die Annahmen, definieren den kleinsten sinnvollen Test und sagen offen, wenn sich ein Build nicht lohnt.
Kostenlosen Use-Case-Workshop anfragenFAQ zur TIWAG Opportunity Analysis
Ist das eine TIWAG Case Study oder ein Audit?
Behauptet Wavect, dass TIWAG diese Fähigkeiten fehlen?
Was sollte ein Energieversorger zuerst bauen?
Wo ist KI im Energieservice sinnvoll?
Wie sollten Menschen die KI beaufsichtigen?
Wie lässt sich der wirtschaftliche Effekt schätzen?
Fazit
Die öffentlichen Quellen zeigen bereits ernsthafte digitale Energiebausteine: dynamische Produkte, ausgewählte Gerätesteuerung, Kunden-Self-Service und EEG-Abläufe. Als Nächstes ist es prüfenswert, wie kohärent Entscheidungen, Erklärungen und Operations zusammenspielen können.
Eine sichere Architektur hält Tarife, Einwilligung, Abrechnung und Befehle deterministisch. KI bleibt ein begrenzter Assistent für Sprache und unstrukturierte Informationen, gestützt auf freigegebene Quellen und menschliche Prüfung. Starte mit einer Journey, mache Annahmen sichtbar und lass eine 30/60/90-Tage-Validierung entscheiden, ob die Chance Produktionsinvestment verdient.