Showcase · Werkleiter-Perspektive

Wie entsteht ein
OEE-Dashboard
in Wasabi Works?

Ein konkretes Beispiel durch alle sechs Entwicklungsphasen — von der ersten Frage bis zum produktionsreifen Baustein. Gezeigt am OEE-Dashboard, dem zentralen Werkzeug des Werkleiters.

Baustein
OEE-Dashboard
Zielrolle
Werkleiter, GF
Service
reporting-service
Entwicklungszeit
~8 Tage
Test-Coverage
100 % Klassen
Status
Production Ready
Das Ergebnis So sieht es am Ende aus
wasabi.local / reporting / oee-dashboard?site=werk-a&range=7d
Dashboard
OEE-Analyse
Schichtbericht
Störungsanalyse
Maschinenhistorie
Analytics
Export
Einstellungen
OEE-Analyse · Werk A
Heute
7 Tage
30 Tage
Monat
OEE Gesamt
87.4%
vs. Vormonat +2.1 %
Verfügbarkeit
91.2%
Ziel: 90 % ✓
Leistung × Qualität
95.8% × 99.1%
Ausschuss: 0.9 %
OEE-Verlauf · Letzte 7 Schichten
Mo
Di
Mi
Do
Fr
Sa
So
Verlustanalyse (Wasserfall)
Geplant
100%
Pl. Stillstand
−4%
Ungepl. Still.
−7%
Rüstzeiten
−3%
OEE Ergebnis
87%
Maschine
OEE
Verfügbark.
Leistung
7-Tage-Trend
Status
CNC-L3
92.1%
95.3%
96.8%
● Läuft
DREHM-02
74.3%
81.2%
91.4%
⚠ Rüsten
SCHW-01
88.7%
93.1%
95.2%
● Läuft
FRÄSE-04
58.2%
67.4%
86.3%
✗ Störung
Der Entwicklungsprozess

Von der ersten Frage
zum fertigen Dashboard

Sechs Phasen, nachvollzogen am konkreten Beispiel des OEE-Dashboards. So entstehen Bausteine in Wasabi Works.

01
Phase 01 · Spezifikation
Die richtigen Fragen stellen

Vor einer einzigen Zeile Code: Claude Code erstellt eine vollständige Spezifikation mit dem gesamten Projektkontext. Anschließend Review-Zyklen mit ChatGPT und Gemini — bis alle Aspekte durchdacht sind.

🤖
Prompt an Claude Code — Iteration 1
Kontext: bestehender reporting-service, Angular-Frontend, NATS-Events von ESTS
Q1
Welche KPIs braucht ein Werkleiter täglich, um Handlungsbedarf zu erkennen — nicht um Daten zu bestätigen, die er ohnehin kennt?
Q2
Wie berechnet sich OEE nach ISO 22400-2 aus den ESTS-BookingFacts? Welche Event-Types fließen in Verfügbarkeit, Leistung, Qualität?
Q3
Welche Aggregationsebenen braucht die Auswertung — Werk, Abteilung, Maschine, Schicht, Auftrag? Welche Drill-Down-Pfade sind sinnvoll?
Q4
Was ist der Unterschied zwischen Echtzeit-OEE und historischer OEE? Welche Datenbank eignet sich für welchen Anwendungsfall?
Review-Zyklen
4 Iterationen · 2 externe KI-Reviews
🔄
Claude Code
Basisspezifikation: OEE-Berechnung aus BookingFacts, 6 KPI-Definitionen, InfluxDB für Zeitreihen / PostgreSQL für Reports
Iter. 1
🔍
ChatGPT
Feedback: Tenant-Timezone-Regel fehlt bei Schichtgrenzen-Berechnung. ISO 22400 schreibt Basiszeit ohne Pausen vor.
Iter. 2
🔍
Gemini
Feedback: Wasserfall-Diagramm als Visualisierung der OEE-Verluste hinzufügen — macht Handlungsbedarf sofort sichtbar.
Iter. 3
✅
Claude Code
Finale Spec: 19 Screens, 13 Analytics-Auswertungen, Tenant-Timezone-Regel, Drill-Down-Pfade definiert. Bereit für Phase 2.
Iter. 4
📄
Ergebnis: Vollständige Spezifikation mit 19 Screens, KPI-Definitionen (OEE, Verfügbarkeit, Leistung, Qualität, MTBF, MTTR), Datenmodell und Tenant-Timezone-Regelwerk. Kein Code noch geschrieben.
02
Phase 02 · Planung
Den Umsetzungsplan erstellen

Claude Code im Plan-Modus liest die Spec und erstellt einen detaillierten Implementierungsplan. Welche Komponenten in welcher Reihenfolge, welche Abhängigkeiten, welche Tests.

IMPLEMENTATION_PLAN.md
Claude Code · Plan Mode
## OEE-Dashboard · Implementierungsplan
Geschätzte Dauer: 8 Tage | Abhängigkeiten: ESTS-Service, reporting-service (Read-Side)
Tag 1–2 Backend: OeeCalculationService, KpiDefinitionService, TenantTimezoneRule
Tag 3   Backend: MaterializerConsumer (NATS → InfluxDB), rpt_machine_daily View
Tag 4–5 Frontend: OeeDashboard-Component, KpiCard, WaterfallChart (D3.js), BarChart
Tag 6   Frontend: MachineTable mit Sparklines, Drill-Down-Routing, Filter-Controls
Tag 7   Tests: Unit (OeeCalculation), Integration (Testcontainers), E2E (Playwright)
Tag 8   Review, Härtung, Dokumentation
🗺️
Ergebnis: Vollständiger Umsetzungsplan mit 23 Komponenten, klarer Reihenfolge und Test-Strategie. Review-Freigabe erteilt — Implementation kann starten.
03
Phase 03 · Umsetzung
Code schreiben — mit aktivem Oversight

Claude Code generiert den Großteil des Codes. Aktive Begleitung in jedem Schritt: Architekturentscheidungen prüfen, Abweichungen vom Regelwerk korrigieren, Builds grün halten.

OeeCalculationService.java
Java 25 · Quarkus · Reaktiv
1// OEE nach ISO 22400-2: Verfügbarkeit × Leistung × Qualität
2@ApplicationScoped
3public class OeeCalculationService {
4
5 public Uni<OeeResult> calculate(OeeQuery query) {
6 return resolveTimezone(query.tenantId())
7 .flatMap(tz -> bookingFacts.findInRange(
8 query.from().atZone(tz), query.to().atZone(tz)))
9 .map(facts -> {
10 var avail = calcAvailability(facts); // (PlannedTime − Downtime) / PlannedTime
11 var perf = calcPerformance(facts); // ActualOutput / TheoreticalOutput
12 var qual = calcQuality(facts); // GoodParts / TotalParts
13 return new OeeResult(avail, perf, qual, avail * perf * qual);
14 });
15 }
16}
⚙️
Ergebnis nach Tag 5: Backend vollständig, alle Builds grün. Frontend-Grundstruktur steht. Reifegrad ~65 % — bereit für Phase 4.
04
Phase 04 · Feintuning
Ping-Pong bis zum Qualitätsniveau

Nach der ersten Umsetzung: ~65 % Reifegrad. Testen, Probleme identifizieren, anpassen — iterativ bis das System sich wie ein fertiges Produkt anfühlt, nicht wie ein Prototyp.

Feintuning-Log
11 Iterationen · ~2,5 Tage
🐛
Test
Bug: OEE-Berechnung ignoriert Pausenzeiten bei Nachtschicht-Übergang. TenantTimezone-Regel greift nicht für Zeiträume > Mitternacht.
It. 1
✅
Fix
Schichtgrenzen-Berechnung auf ZonedDateTime mit DST-Handling umgestellt. Nachtschicht-Split korrekt.
It. 2
🎨
UX
Wasserfall-Diagram: Drill-Down auf Störungsgrund beim Click auf "Ungeplanter Stillstand" — direkter Sprung in Störungsanalyse.
It. 5
⚡
Performance
30-Tage-OEE-Query zu langsam (1.8s). Materialisierter View rpt_machine_daily eingeführt. Query jetzt: 45ms.
It. 8
✅
Abnahme
Alle definierten Screens funktionieren, alle Drill-Downs korrekt, Performance akzeptabel. Reifegrad: ~92 % — bereit für Phase 5.
It. 11
05
Phase 05 · Härtung & QS
KI in drei Rollen: Security, Quality, Architektur

Der Code wird systematisch geprüft. KI übernimmt verschiedene Reviewer-Perspektiven — nicht als Bestätigung, sondern als aktive Schwachstellensuche.

🛡️
Security ✓
Tenant-Isolation auf Query-Ebene: TenantFilter greift vor jedem DB-Zugriff. Kein Cross-Tenant-Datenzugriff möglich.
🧪
Test-Coverage ✓
100 % Klassen-Coverage im OeeCalculationService. Testcontainers-IT für alle NATS-Consumer.
⚠️
Gefunden & Behoben
OEE-Export-Endpoint: fehlende Autorisierungsprüfung für GF-Rolle. Behoben: @RolesAllowed ergänzt.
🏗️
Architektur ✓
Reporting-Service bleibt Read-Only. Kein direkter DB-Write. CQRS-Trennung konsequent eingehalten.
✅
Ergebnis: 1 Security-Finding identifiziert und behoben. 100 % Test-Coverage auf Kernlogik. OWASP-Check in CI grün. Production-Ready-Freigabe erteilt.
06
Phase 06 · Dokumentation
Vollständig dokumentiert — automatisch

KI generiert Dokumentation aus dem fertigen Code: technische Docs, Benutzerhandbuch für den Werkleiter, OpenAPI-Spec, Architekturübersicht. Review und Finalisierung durch das Team.

📘
Technische Docs
21 Seiten
👤
User Guide
Werkleiter
🔌
OpenAPI Spec
31 Endpoints
🗺️
Architektur
ADR + Diagramm
🎯
Fertig nach 8 Tagen: OEE-Dashboard vollständig produktionsreif. 19 Screens, 31 Endpoints, 100 % Test-Coverage, vollständig dokumentiert. Bereit für den ersten Werkleiter-Login.
Datenfluss

Wie die OEE-Daten
von der Maschine ins Dashboard fließen

🏭
Maschine / Terminal
Werker bucht Störung, Menge, Maschinenstatus
touch input
⏱️
ESTS-Service
Event → TimeSlice → BookingFact. Bi-temporal, REFA-konform
NATS publish
📊
Reporting-Service
MaterializerConsumer berechnet OEE, schreibt rpt_machine_daily
InfluxDB + PG
🔌
REST-API
31 Endpoints, OpenAPI-dokumentiert, Multi-Tenant gesichert
JWT · TenantFilter
🖥️
OEE-Dashboard
Angular, Live-Updates, Drill-Down, Wasserfall, Export
Werkleiter-Sicht
Latenz Maschine → Dashboard:
< 2 Sekunden
30-Tage-Report Query:
~45 ms
Tenant-Isolation:
Row-Level · JWT
Deployment-Optionen

Community oder Enterprise —
Sie entscheiden wo es läuft

Community

Self-Hosted

Sie hosten das System selbst auf Ihrer Infrastruktur. Vollständige Kontrolle, kein externer Zugriff. On-Premise auf Ihrer Infrastruktur.

Hetzner Dedicated, eigenes RZ oder Cloud Ihrer Wahl
Ansible-Deployment, systemd, ~90s Cold-Start
Offener Stack — transparente Technologie
DSGVO-konform: Produktionsdaten verlassen nie Ihr Haus
Framework-Updates aus der Community
Enterprise

Managed by Wasabi Works

Wir betreiben das System in Ihrer Infrastruktur oder in einer dedizierten Umgebung — inklusive Monitoring, Updates und Support.

Wir deployen, wir monitoren, wir patchen
Security-Audits, CVE-Monitoring, Performance-Reviews
SLA-basierter Support, direkter Ansprechpartner
Weiterentwicklung nach individuellem Bedarf
Kein Vendor Lock-in — Wechsel zu Community jederzeit möglich

Das OEE-Dashboard
in Ihrer Produktion?

Als Founding Partner wird dieses System für Ihre Maschinen, Ihre Schichten und Ihre KPI-Definitionen konfiguriert. Nicht für einen Durchschnittskunden — für Sie.