# 00 Executive Summary

Stand: 10.05.2026

## One-Liner
LASE PeCo ist ein MVP-Plan fuer eine gemeinsame digitale Plattform, die Service, IoT, Wissen, KI und Visualisierung ueber einen kontrollierten Backend-Kern verbindet.

## Warum dieser Plan relevant ist
Viele digitale Initiativen scheitern nicht an einzelnen Tools, sondern an fehlender Verbindung zwischen Prozess, Daten, Rechten, Wissen und Betrieb. LASE PeCo adressiert genau diese Luecke: Frontends koennen unterschiedlich sein, aber Identity, Projektkontext, Asset-Modell, Workflow, Event-Envelope, Dokumentation, KI-Kontext und Audit Trail laufen ueber denselben Plattformkern.

Dadurch entsteht kein weiteres isoliertes Tool, sondern ein belastbarer Rahmen fuer wiederverwendbare digitale Faehigkeiten.

## Was der MVP beweisen soll
Der MVP soll beweisen, dass ein operativer Ende-zu-Ende-Flow ueber denselben Backend-Kern laeuft:

1. Ein Ereignis oder Ticket wird erfasst.
2. Rolle, Scope und Projektkontext werden aufgeloest.
3. Der passende Asset-, Dokument- und Wissenskontext wird geladen.
4. Ein Workflow steuert Triage, Aufgabe, Eskalation und Abschluss.
5. KI unterstuetzt nur mit Quellenpflicht und Freigabelogik.
6. Entscheidungen, Statuswechsel und Dokumentation bleiben auditierbar.
7. KPI-Messpunkte entstehen direkt aus dem Flow.

Empfohlener erster Referenzflow: `Servicefall Ende-zu-Ende`.

## MVP-Gesamtfluss
```mermaid
flowchart LR
    A["Event / Ticket / Sensorimpuls"]
    B["Backend-Kern\nIdentity, Assets, Workflow, Audit"]
    C["Kontextaufloesung\nRolle, Scope, Projekt, Dokumente, Wissen"]
    D["Operativer Prozess\nTriage, Aufgabe, Eskalation, Abschluss"]
    E["Spatial / Frontend Views\nCesium MP, Service Views, Dashboards"]
    F["KI-Unterstuetzung\nmit Quellenpflicht und Freigabelogik"]
    G["Audit & KPI\nStatuswechsel, Evidence, Messpunkte"]

    A --> B --> C --> D --> E
    C --> F --> D
    D --> G
    E --> G
```

Lesart: Der MVP ist kein einzelnes Frontend, sondern ein kontrollierter Kern, der Kontext, Prozess, Visualisierung, KI-Unterstuetzung und Audit ueber denselben Flow zusammenhaelt.

## MVP-Scope
Im MVP enthalten:

- ein priorisierter Servicefall-E2E-Flow
- rollenbasierte Frontend-Sicht fuer Service, Leitung und optional Kunde
- gemeinsames Objektmodell fuer Ticket, Asset, Projekt, Dokument und Workflow
- Basis-RBAC fuer Sichtbarkeit und Schreibrechte
- Dokument- und Wissenskontext im Arbeitsfluss
- auditierbare Statuswechsel und Freigaben
- erste KPI-Baseline fuer Suchzeit, Systemwechsel, Durchlaufzeit und Dokumentationsqualitaet
- Demonstrator fuer KI-Unterstuetzung mit Quellenpflicht

Nicht im MVP enthalten:

- vollstaendige Produktionsplattform
- vollstaendige Multi-Frontend-Abdeckung
- automatisierte Freigaben ohne menschliche Kontrolle
- produktionsreife KI-Autonomie
- vollstaendige 3D-Digital-Twin-Abdeckung
- serverseitiger Multi-User-Konfliktabgleich fuer alle Editierfaelle

## Moeglichkeiten durch die Flow-Logik
Die Flow-Logik macht sichtbar, welche Plattformfaehigkeiten entstehen:

- operative Steuerung vom Event zur Aufgabe
- wiederverwendbare Backend-Services fuer mehrere Frontends
- rollenbasierte Nutzererlebnisse auf gemeinsamem Datenkern
- KI mit echtem Kontext statt isoliertem Chat
- nachvollziehbare Entscheidungen durch Audit Trail
- messbare Engpaesse fuer Roadmap und Produktsteuerung
- kontrollierter Wissensrueckfluss aus Service, Forschung und Betrieb

## Erfolgskriterien
Die MVP-Validierung sollte nicht mit unbewiesenen Zielzahlen starten, sondern mit klaren Messpunkten:

- Zeitanteil fuer Suche und Abstimmung pro Servicefall
- Anzahl Systemwechsel pro Servicefall
- Zeit von Event oder Ticket bis zur ersten belastbaren Entscheidung
- Vollstaendigkeit der Abschlussdokumentation
- Anteil der Entscheidungen mit nachvollziehbarer Quelle oder Begruendung
- Anteil wiederverwendeter Plattformdienste im Flow
- Anzahl auditierbarer Statuswechsel und Freigaben

## Risiken und Gegenmassnahmen
| Risiko | Gegenmassnahme |
|---|---|
| Scope wird zu gross | Einen Referenzflow zuerst validieren |
| Prototyp wird mit Produkt verwechselt | Plan-, MVP- und Produktionsgrenze explizit markieren |
| KI wird als Black Box wahrgenommen | Quellenpflicht, Agent Registry, Human-in-the-loop |
| Frontends entstehen wieder als Silos | Gemeinsamer Backend-Kern und Contract-first Planung |
| Nutzen bleibt abstrakt | Baseline-Messung und Review nach 4 Wochen |
| Governance bremst Umsetzung | Rechte, Rollen und Freigaben direkt im Flow modellieren |

## Entscheidungsbitte
Fuer den naechsten Schritt sollten vier Entscheidungen getroffen werden:

1. Freigabe des MVP-Scope fuer den Servicefall-E2E-Flow.
2. Benennung eines Product Owners und eines Technical Owners.
3. Freigabe einer 90-Tage-Validierungsphase mit klarem Review nach 4 Wochen.
4. Zustimmung zu den KPI-Messpunkten als Baseline, nicht als vorab behaupteter Nutzen.

## Kurzbewertung
Der Plan ist pitchfaehig, wenn er als strukturierter MVP- und Validierungsrahmen praesentiert wird. Die Staerke liegt nicht darin, bereits eine fertige Plattform zu behaupten, sondern darin, die richtigen Architektur-, Governance- und Flow-Entscheidungen vor der Umsetzung sauber zu treffen.