Ausgangslage
Nordwind betreibt Windparks und verkauft die erzeugte Energie an Stadtwerke und Gewerbekunden. Die operative Steuerung lag in Excel: Produktionsdaten aus drei Anlagen, Wartungspläne, Einspeiseprognosen und Kundenverträge in getrennten Dateien. Das Team verbrachte jeden Montag mehrere Stunden damit, Kennzahlen zusammenzutragen, bevor eine Entscheidung möglich war.
Die Geschäftsführung wollte ein „Dashboard“. Im ersten Gespräch wurde schnell klar: Das eigentliche Problem war nicht die Visualisierung, sondern die fehlende gemeinsame Datenbasis. Ein Dashboard auf falschen oder verspäteten Daten hätte den Aufwand nur verschoben.
Meine Rolle
Ich war als Lead Product Engineer für Konzeption, Datenmodell, Umsetzung und den Pilot verantwortlich. Eine Designerin lieferte das Interface, ein Kollege aus dem Betrieb steuerte die fachlichen Regeln bei. Das Team war bewusst klein: drei Personen, kurze Wege, wöchentliche Entscheidungen.
Vorgehen
1. Den Entscheidungsprozess verstehen, nicht die Excel-Dateien.
Statt Anforderungen zu sammeln, habe ich zwei Wochen lang die wöchentlichen Abstimmungen begleitet. Die entscheidende Frage war: Welche Zahl führt zu welcher Handlung? Daraus entstanden vier Kernansichten: Anlagenstatus, Einspeisung, Wartung und Vertragsvolumen. Alles andere wurde zunächst bewusst weggelassen.
2. Ein Domänenmodell vor dem Interface.
Wir haben die Begriffe des Betriebs in ein PostgreSQL-Schema übersetzt: Anlage, Messpunkt, Zeitfenster, Vertrag, Wartungsfenster. Die Daten kommen über einen nächtlichen Import aus CSV und einer schmalen API. Die Importstrecke ist idempotent, protokolliert Fehler und kann denselben Tag mehrfach verarbeiten. Das klingt unspektakulär, war aber die Voraussetzung dafür, dass die Zahlen im Dashboard vertrauenswürdig blieben.
3. Eine dünne, nachvollziehbare Anwendung.
Das Frontend ist eine Next.js-Anwendung mit Server Components für die Übersichten und wenigen Client-Inseln für Filter und Diagramme. Die Datenbankzugriffe laufen über Drizzle; jede Abfrage ist typisiert und nachvollziehbar. Die wichtigsten Kennzahlen werden serverseitig berechnet, damit alle Nutzer dieselbe Zahl sehen. Für den Pilot reichte ein einziges Deployment auf Cloudflare mit einer verwalteten Postgres-Instanz.
4. Pilot statt Big Bang.
Nach vier Wochen ging eine erste Version an zwei Personen im Betrieb. Eine Woche später kam der dritte Pilotkunde dazu. Feedback wurde direkt in den wöchentlichen Rhythmus aufgenommen. Die mutigste Entscheidung war, den Export nach Excel zunächst nicht zu bauen – obwohl er ganz oben auf der Wunschliste stand. Erst als der Pilot zeigte, dass die Leute dem Dashboard vertrauten, wurde der Export überflüssig.
Ergebnis
- Der Pilot ging nach sechs Wochen live, nicht nach dem ursprünglich geplanten Quartal.
- Die manuelle Report-Erstellung sank um rund 40 Prozent.
- Drei Pilotkunden nutzten die Anwendung täglich; zwei davon verlängerten nach dem Pilot.
- Die wichtigste Kennzahl – Zeit von der Datenlieferung bis zur Entscheidung – sank von einem Tag auf unter eine Stunde.
Was ich mitgenommen habe
Ein Dashboard ist kein Produkt. Ein Produkt ist die Entscheidung, die jemand danach treffen kann. Die technisch schwierigste Aufgabe war nicht das Frontend, sondern die Bereinigung der Daten und die Definition der Begriffe. Wer ein Dashboard baut, baut zuerst ein Datenmodell und einen Prozess – und erst dann eine Oberfläche.