msolarczekandClaude Opus 5
c8e6f30a27
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
47 KiB
Technische Spezifikation – Handwerker- und Montageeinsatz-App
Dokumenttyp: Software Design Specification / Technisches Umsetzungskonzept
Zielgruppe: Codex, Claude Code, Softwareentwickler und technische Projektleitung
Status: Entwurf für MVP
Version: 1.0
Sprache: Deutsch
1. Zielsetzung
Ziel ist die Entwicklung einer mandantenfähigen Webanwendung für Handwerks- und Montagebetriebe.
Die Anwendung soll den vollständigen Ablauf eines Kunden- oder Baustelleneinsatzes digital unterstützen:
- Auftragsbestätigung oder Einsatzdokument importieren
- Auftragsdaten automatisch erkennen
- Auftrag prüfen und einem Montageteam zuweisen
- Auftrag auf Tablet oder Smartphone bearbeiten
- Leistungen, Arbeitszeiten, Material, Fotos und Notizen dokumentieren
- Tagesbericht oder Abschlussbericht erzeugen
- Auftrag an das Backoffice zur Abrechnung übergeben
- Einsatzhistorie je Kunde und Objekt dauerhaft verfügbar halten
Für den MVP wird keine native iOS- oder Android-App entwickelt. Die Lösung wird als responsive Progressive Web App, kurz PWA, umgesetzt.
2. Produktvision
Die Anwendung soll keine vollständige ERP-, Buchhaltungs- oder Warenwirtschaftslösung ersetzen.
Sie bildet die operative Verbindung zwischen:
- Backoffice
- Montageteams
- Kunden
- Baustellen
- Objekten
- Auftragsdokumenten
- Einsatzdokumentation
- Abrechnungsvorbereitung
Das System soll modular aufgebaut werden, sodass später weitere Funktionen und Schnittstellen ergänzt werden können.
Mögliche spätere Erweiterungen:
- direkte ERP- und Buchhaltungsschnittstellen
- digitale Zeiterfassung
- Lager- und Bestandsverwaltung
- Artikelstammdaten
- Anlagen- und Geräteverwaltung
- Wartungsintervalle
- Angebots- und Rechnungsstellung
- Kundenportal
- Tourenplanung
- Kalenderintegration
- automatische Einsatzplanung
- KI-Assistent für Monteure und Backoffice
3. Grundlegende Architekturentscheidung
3.1 Anwendungstyp
Der MVP wird als responsive Webanwendung mit PWA-Funktionen umgesetzt.
Die Anwendung muss auf folgenden Geräten nutzbar sein:
- Desktop-PC
- Notebook
- iPad
- Android-Tablet
- iPhone
- Android-Smartphone
3.2 Vorteile der PWA
- keine separate Entwicklung für iOS und Android
- Installation auf dem Startbildschirm möglich
- Nutzung der Gerätekamera
- Nutzung des Mikrofons
- lokale Zwischenspeicherung
- eingeschränkte Offline-Fähigkeit
- zentrale Bereitstellung von Updates
- geringerer Entwicklungs- und Wartungsaufwand
3.3 Mandantenfähigkeit
Die Anwendung muss von Beginn an vollständig mandantenfähig aufgebaut werden.
Jeder Handwerksbetrieb stellt einen eigenen Mandanten dar.
Mandanten dürfen ausschließlich auf ihre eigenen Daten zugreifen.
Eine Vermischung von Daten verschiedener Mandanten muss technisch ausgeschlossen werden.
4. Rollenmodell
4.1 Plattformadministrator
Der Plattformadministrator verwaltet die gesamte SaaS-Plattform.
Berechtigungen:
- Mandanten anlegen
- Mandanten deaktivieren
- Mandantenadministratoren anlegen
- Systemstatus einsehen
- globale Systemeinstellungen verwalten
- Funktionsmodule je Mandant aktivieren
- Speicherverbrauch und Nutzung einsehen
- Supportzugriff nach expliziter Freigabe durchführen
Der Plattformadministrator soll nicht standardmäßig auf fachliche Mandantendaten zugreifen können.
4.2 Mandantenadministrator
Der Mandantenadministrator verwaltet die Organisation eines Kunden.
Berechtigungen:
- Benutzer anlegen
- Benutzer deaktivieren
- Rollen vergeben
- Montageteams anlegen
- Mitarbeiter Teams zuordnen
- Kunden verwalten
- Objekte verwalten
- Vorlagen verwalten
- Auftragsstatus konfigurieren
- E-Mail-Empfänger konfigurieren
- Unternehmensdaten verwalten
- Berichtsvorlagen verwalten
- Nummernkreise konfigurieren
4.3 Backoffice
Das Backoffice plant, verwaltet und kontrolliert Aufträge.
Berechtigungen:
- Auftragsdokumente importieren
- erkannte Daten prüfen
- Kunden und Objekte anlegen
- Aufträge erstellen
- Aufträge bearbeiten
- Montageteams zuweisen
- Dokumente und technische Zeichnungen hinterlegen
- Auftragsfortschritt einsehen
- Berichte prüfen
- Aufträge zur Abrechnung freigeben
- Einsatzhistorie einsehen
- Notdiensteinsätze nachbearbeiten
4.4 Monteur
Der Monteur bearbeitet zugewiesene Aufträge.
Berechtigungen:
- eigene und dem Team zugewiesene Aufträge einsehen
- Auftragsinformationen anzeigen
- Kundendaten und Objektinformationen anzeigen
- technische Dokumente und Zeichnungen anzeigen
- Einsatz starten und beenden
- Arbeitszeiten dokumentieren
- Material dokumentieren
- Fotos aufnehmen
- Notizen erfassen
- Sprachnotizen aufnehmen
- Tagesberichte erstellen
- Abschlussberichte erstellen
- Kundenunterschrift erfassen
- Notdiensteinsatz anlegen
- vorherige freigegebene Einsätze am Objekt einsehen
Ein Monteur darf keine Aufträge oder Kundendaten anderer Teams einsehen, sofern ihm hierzu keine zusätzliche Berechtigung erteilt wurde.
4.5 Teamleiter
Der Teamleiter besitzt die Rechte eines Monteurs und zusätzlich:
- Teamaufträge einsehen
- Aufträge innerhalb des Teams koordinieren
- Tagesberichte prüfen
- Abschlussberichte freigeben
- Teammitglieder einem Einsatz zuordnen
- Korrekturen vor Abschluss anfordern
5. Mandantenmodell
Jeder Datensatz muss eindeutig einem Mandanten zugeordnet sein.
Dies betrifft insbesondere:
- Benutzer
- Rollen
- Teams
- Kunden
- Ansprechpartner
- Objekte
- Aufträge
- Einsätze
- Berichte
- Dokumente
- Fotos
- Materialien
- Benachrichtigungen
- Audit-Logs
- Vorlagen
5.1 Technische Anforderung
Jede relevante Datenbanktabelle erhält ein Feld:
tenant_id
Der Zugriff auf Daten muss serverseitig immer über den aktuellen Mandantenkontext eingeschränkt werden.
Eine reine Filterung im Frontend ist nicht ausreichend.
5.2 Empfohlene Umsetzung
Für den MVP kann eine gemeinsame Datenbank mit mandantenbezogener Datenisolation verwendet werden.
Empfehlung:
- PostgreSQL
- Row-Level Security oder zentraler Repository-Filter
- tenant_id in allen fachlichen Tabellen
- serverseitige Autorisierungsprüfung bei jedem Zugriff
- getrennte Dateipfade oder Buckets je Mandant
Später kann optional ein Datenbank-pro-Mandant-Modell ergänzt werden.
6. Kernmodule des MVP
Der MVP besteht aus folgenden Modulen:
- Benutzer- und Rollenverwaltung
- Mandantenverwaltung
- Kundenverwaltung
- Objektverwaltung
- Teamverwaltung
- Auftragsimport
- Auftragsverwaltung
- Einsatzbearbeitung
- Materialdokumentation
- Foto- und Dokumentenverwaltung
- Tages- und Abschlussberichte
- Notdiensteinsätze
- Objekt- und Einsatzhistorie
- Benachrichtigungen
- Audit-Logging
- PWA- und Offline-Funktionen
7. Kundenverwaltung
7.1 Kundendaten
Folgende Daten sollen verwaltet werden:
- Kundennummer
- Firmenname
- Anrede
- Vorname
- Nachname
- Straße
- Hausnummer
- Postleitzahl
- Ort
- Land
- Telefonnummer
- Mobilnummer
- E-Mail-Adresse
- allgemeine Hinweise
- Abrechnungshinweise
- Status
- Erstellungsdatum
- Änderungsdatum
7.2 Ansprechpartner
Ein Kunde kann mehrere Ansprechpartner besitzen.
Daten:
- Name
- Funktion
- Telefonnummer
- Mobilnummer
- E-Mail-Adresse
- bevorzugter Kontaktweg
- Bemerkungen
7.3 Dublettenprüfung
Beim Import eines Auftrags muss geprüft werden, ob der Kunde bereits existiert.
Mögliche Vergleichswerte:
- Kundennummer
- Firmenname
- Adresse
- E-Mail-Adresse
- Telefonnummer
Bei unsicherer Übereinstimmung muss das Backoffice entscheiden:
- bestehenden Kunden verwenden
- neuen Kunden anlegen
- Datensätze zusammenführen
Eine automatische Zusammenführung darf im MVP nicht ohne Bestätigung erfolgen.
8. Objektverwaltung
Ein Kunde kann mehrere Objekte besitzen.
Beispiele:
- Baustelle
- Filiale
- Wohnhaus
- Produktionsstandort
- Bürogebäude
- technische Anlage
- Wartungsstandort
8.1 Objektdaten
- Objektbezeichnung
- Kunde
- Straße
- Hausnummer
- Postleitzahl
- Ort
- Land
- Ansprechpartner vor Ort
- Telefonnummer
- Zugangshinweise
- Parkhinweise
- Sicherheitsinformationen
- allgemeine technische Hinweise
- Status
- geografische Koordinaten optional
8.2 Objektbezogene Dokumente
Pro Objekt können Dokumente hinterlegt werden:
- technische Zeichnungen
- Grundrisse
- Schaltpläne
- Montageanleitungen
- Sicherheitsunterlagen
- Produktunterlagen
- Kundenhinweise
- Fotos vorheriger Einsätze
- sonstige PDF-Dateien
8.3 Objekt-Historie
Die Anwendung muss pro Objekt eine chronologische Einsatzhistorie anzeigen.
Anzuzeigen sind:
- Datum
- Auftrag
- Einsatzart
- eingesetztes Team
- durchgeführte Arbeiten
- verwendetes Material
- Fotos
- Berichte
- besondere Hinweise
- Kundenunterschrift
- Status
- offene Folgearbeiten
Für den MVP ist keine vollständige Geräte-, Anlagen- oder Seriennummernverwaltung erforderlich.
9. Auftragsimport per PDF
9.1 Ziel
Das Backoffice soll Auftragsdaten nicht vollständig manuell erfassen müssen.
Eine Auftragsbestätigung oder ein vergleichbares PDF-Dokument wird in die Anwendung hochgeladen.
Das System extrahiert daraus möglichst viele relevante Daten und erstellt einen Auftragsentwurf.
9.2 Unterstützte Dateien
MVP:
- PDF mit eingebettetem Text
- gescannte PDF-Dateien
- optional Bilddateien wie JPG und PNG
9.3 Verarbeitung
Der Importprozess besteht aus:
- Datei hochladen
- Malware- und Dateitypprüfung
- Texterkennung
- Dokumentenanalyse
- strukturierte Datenextraktion
- Plausibilitätsprüfung
- Dublettenprüfung
- Anzeige einer Prüfmaske
- Bestätigung durch das Backoffice
- Erstellung oder Zuordnung von Kunde, Objekt und Auftrag
9.4 OCR und KI-Extraktion
Für gescannte Dokumente wird OCR eingesetzt.
Für die strukturierte Extraktion kann ein KI-Modell verwendet werden.
Zu extrahierende Felder:
- Auftragsnummer
- Angebotsnummer
- Kundennummer
- Firmenname
- Kundenadresse
- Objektadresse
- Ansprechpartner
- Telefonnummer
- E-Mail-Adresse
- Auftragsdatum
- geplanter Ausführungszeitraum
- Leistungsbeschreibung
- Positionen
- Mengen
- Materialinformationen
- besondere Hinweise
- Gesamtbetrag optional
- Referenzen
- Dokumentdatum
9.5 Vertrauenswerte
Für jedes erkannte Feld soll ein Vertrauenswert gespeichert werden.
Beispiel:
{
"field": "customer_name",
"value": "Musterbau GmbH",
"confidence": 0.96
}
Unsichere Felder müssen in der Prüfmaske hervorgehoben werden.
9.6 Manuelle Prüfung
Ein importierter Auftrag darf nicht automatisch produktiv freigegeben werden.
Status nach Import:
Entwurf – Prüfung erforderlich
Das Backoffice muss die erkannten Daten bestätigen oder korrigieren.
9.7 Originaldokument
Das Originaldokument wird dauerhaft am Auftrag gespeichert.
Zusätzlich werden gespeichert:
- Importdatum
- importierender Benutzer
- erkannter Text
- strukturierte Extraktion
- Extraktionsversion
- verwendetes Extraktionsmodell
- Korrekturen des Benutzers
10. Auftragsverwaltung
10.1 Auftragsdaten
- interne Auftrags-ID
- externe Auftragsnummer
- Mandant
- Kunde
- Objekt
- Ansprechpartner
- Auftragsart
- Priorität
- Status
- Beschreibung
- Leistungsumfang
- geplantes Datum
- geplanter Zeitraum
- zugewiesenes Team
- zuständiger Teamleiter
- Dokumente
- Materialvorgabe
- Pflichtfotos
- Pflichtfelder
- Unterschrift erforderlich
- Abrechnungsart
- interne Hinweise
- Hinweise für Monteure
- Erstellungsdatum
- Änderungsdatum
10.2 Auftragsarten
Beispiele:
- Montage
- Reparatur
- Wartung
- Störung
- Notdienst
- Besichtigung
- Abnahme
- Nacharbeit
Die Auftragsarten sollen je Mandant konfigurierbar sein.
10.3 Statusmodell
Empfohlene Statuswerte:
Entwurf
Prüfung erforderlich
Geplant
Zugewiesen
Angenommen
In Anfahrt
In Bearbeitung
Pausiert
Wartet auf Material
Tagesbericht erstellt
Technisch abgeschlossen
Unterschrift ausstehend
Zur Prüfung
Zur Abrechnung freigegeben
Abgerechnet
Storniert
Statusübergänge müssen serverseitig geprüft werden.
10.4 Teamzuweisung
Ein Auftrag kann einem Montageteam zugewiesen werden.
Optional können zusätzlich einzelne Mitarbeiter ausgewählt werden.
Ein Team erhält nach Zuweisung eine Benachrichtigung.
11. Montageteams
11.1 Teamdaten
- Teamname
- Teamleiter
- Mitglieder
- Status
- Telefonnummer
- Fahrzeug optional
- Einsatzgebiet optional
- interne Hinweise
11.2 Auftragsansicht
Monteure sehen:
- heutige Aufträge
- kommende Aufträge
- laufende Aufträge
- pausierte Aufträge
- abzuschließende Aufträge
- vergangene eigene Aufträge
Darstellung als:
- Listenansicht
- Kalenderansicht optional
- Kartenansicht erst nach dem MVP
12. Einsatzbearbeitung durch Monteure
12.1 Einsatzstart
Beim Start eines Einsatzes werden gespeichert:
- Startzeit
- Benutzer
- Team
- Auftrag
- optional Standort
- Gerätestatus
- Online- oder Offline-Status
Optional kann ein Status „In Anfahrt“ vor dem eigentlichen Arbeitsbeginn gesetzt werden.
12.2 Arbeitszeiten
Ein Einsatz kann mehrere Zeitabschnitte besitzen.
Beispiele:
- Anfahrt
- Arbeitszeit
- Pause
- Materialbeschaffung
- Rückfahrt
- Unterbrechung
Für den MVP genügt eine einfache Start-, Pause- und Stopp-Funktion.
Manuelle Korrekturen müssen protokolliert werden.
12.3 Tätigkeitsdokumentation
Monteure können dokumentieren:
- durchgeführte Arbeiten
- Abweichungen vom Auftrag
- Probleme
- zusätzliche Leistungen
- nicht ausführbare Arbeiten
- erforderliche Folgearbeiten
- Empfehlungen
- Kundenhinweise
Eingabemöglichkeiten:
- Text
- strukturierte Auswahlfelder
- Sprachnotiz
- Foto
12.4 Checklisten
Ein Auftrag kann eine Checkliste enthalten.
Beispiele:
- Anlage spannungsfrei geschaltet
- Arbeitsbereich abgesichert
- Material geprüft
- Funktionsprüfung durchgeführt
- Arbeitsbereich gereinigt
- Kunde eingewiesen
- Pflichtfotos erstellt
Checklisten können je Auftragsart als Vorlage definiert werden.
13. Materialdokumentation
13.1 Materialvorgabe
Das Backoffice kann geplantes Material am Auftrag hinterlegen.
Felder:
- Bezeichnung
- Artikelnummer optional
- geplante Menge
- Einheit
- Bemerkung
13.2 Tatsächlich verwendetes Material
Der Monteur bestätigt oder ändert je Position:
- vollständig verwendet
- teilweise verwendet
- nicht verwendet
- zusätzlich verwendet
Zu erfassen:
- tatsächliche Menge
- Einheit
- Begründung bei Abweichung
- Foto optional
- Notiz optional
13.3 Zusatzmaterial
Monteure können nicht geplantes Material ergänzen.
Felder:
- Bezeichnung
- Artikelnummer optional
- Menge
- Einheit
- Grund
- Foto optional
13.4 MVP-Abgrenzung
Im MVP erfolgt keine automatische Lagerbuchung.
Die Materialdokumentation dient:
- dem Arbeitsnachweis
- der Abrechnungsvorbereitung
- der Nachkalkulation
- der Information des Backoffice
14. Foto- und Dateidokumentation
14.1 Fotofunktionen
Monteure können Fotos:
- direkt mit der Kamera aufnehmen
- aus der Galerie auswählen
- einem Auftrag zuordnen
- einer Checklistenposition zuordnen
- als Vorher-, Während- oder Nachher-Foto kennzeichnen
- mit Kommentar versehen
14.2 Pflichtfotos
Das Backoffice kann Pflichtfotos definieren.
Beispiele:
- Ausgangszustand
- Typenschild
- Leitungsverlauf
- Zwischenschritt
- fertige Montage
- Funktionsprüfung
- Arbeitsbereich nach Abschluss
Ein Auftrag kann nicht abgeschlossen werden, wenn verpflichtende Fotos fehlen.
14.3 Metadaten
Zu jedem Foto werden gespeichert:
- Auftrag
- Einsatz
- Benutzer
- Zeitstempel
- Kategorie
- Kommentar
- Dateigröße
- MIME-Type
- optional Standort
- Uploadstatus
- Prüfsumme
14.4 Bildoptimierung
Bilder sollen vor dem Upload komprimiert werden.
Das Original kann optional erhalten bleiben.
Empfehlung:
- Vorschaubild
- optimierte Arbeitskopie
- optional Originaldatei
15. Sprachaufnahmen und KI-Unterstützung
15.1 Sprachnotizen
Monteure können Sprachnotizen aufnehmen.
Das System speichert:
- Audiodatei
- Transkription
- Zeitstempel
- Benutzer
- Bezug zum Auftrag oder Einsatz
15.2 KI-Verarbeitung
Die KI kann aus den vorhandenen Informationen einen Berichtsentwurf erstellen.
Datenquellen:
- Auftragsbeschreibung
- Tätigkeitsnotizen
- Sprachnotizen
- Checklisten
- Materialabweichungen
- Fotos und Bildkommentare
- Arbeitszeiten
- offene Folgearbeiten
15.3 Freigabeprinzip
KI-generierte Inhalte dürfen nicht automatisch als endgültiger Bericht versendet werden.
Der Monteur oder das Backoffice muss den Bericht prüfen und freigeben.
15.4 Transparenz
KI-generierte Texte werden als Entwurf gekennzeichnet.
Die ursprünglichen Notizen bleiben erhalten.
16. Tagesbericht
16.1 Zweck
Ein Tagesbericht wird erstellt, wenn ein Auftrag über mehrere Tage läuft oder noch nicht abgeschlossen wurde.
16.2 Inhalte
- Kunde
- Objekt
- Auftrag
- Datum
- eingesetzte Mitarbeiter
- Arbeitszeiten
- durchgeführte Tätigkeiten
- verwendetes Material
- Fotos
- Abweichungen
- Probleme
- offene Punkte
- geplante nächste Schritte
- Status
- Unterschrift optional
16.3 Ablauf
- Monteur beendet den Arbeitstag
- System prüft Pflichtangaben
- Berichtsentwurf wird erzeugt
- Monteur prüft und ergänzt
- Bericht wird gespeichert
- Backoffice wird optional informiert
- Auftrag bleibt geöffnet
17. Abschlussbericht und Arbeitsnachweis
17.1 Zweck
Der Abschlussbericht dient als:
- Leistungsnachweis
- Montagebericht
- Arbeitsnachweis
- Grundlage für die Rechnungsstellung
- interne Dokumentation
- Kundendokumentation
17.2 Inhalte
- Logo und Unternehmensdaten des Mandanten
- Kunde
- Objekt
- Ansprechpartner
- Auftragsnummer
- Einsatzdatum
- eingesetzte Mitarbeiter
- Arbeitszeiten
- Auftragsbeschreibung
- ausgeführte Leistungen
- Abweichungen
- Zusatzleistungen
- verwendetes Material
- nicht verwendetes Material
- offene Restarbeiten
- Hinweise
- Fotos
- Kundenunterschrift
- Name des Unterzeichners
- Datum und Uhrzeit
- Name des Monteurs
- Berichtsversion
17.3 PDF-Erstellung
Nach Freigabe wird ein nicht veränderbares PDF erzeugt.
Das PDF wird:
- am Auftrag gespeichert
- in der Objekt-Historie abgelegt
- dem Backoffice zur Verfügung gestellt
- optional per E-Mail versendet
17.4 Versionierung
Änderungen nach Freigabe erzeugen eine neue Berichtsversion.
Bereits freigegebene Versionen dürfen nicht überschrieben werden.
18. Digitale Kundenunterschrift
18.1 Funktionen
Der Kunde kann auf dem Tablet oder Smartphone unterschreiben.
Zusätzlich werden erfasst:
- Name des Unterzeichners
- Funktion optional
- Datum
- Uhrzeit
- Bestätigungstext
- Bezug zum Bericht
- Benutzer, der die Unterschrift aufgenommen hat
18.2 Ablehnung oder Abwesenheit
Folgende Optionen müssen vorhanden sein:
- Kunde nicht anwesend
- Kunde verweigert Unterschrift
- Unterschrift wird später eingeholt
- Unterschrift nicht erforderlich
Eine Begründung kann verpflichtend sein.
19. Notdiensteinsatz
19.1 Ziel
Ein Monteur muss außerhalb der Geschäftszeiten selbstständig einen neuen Einsatz anlegen können.
19.2 Erfassungsmaske
Pflichtfelder:
- Kunde
- Objekt oder Einsatzadresse
- Ansprechpartner
- Telefonnummer
- Grund des Notdiensteinsatzes
- Beginn
- Team oder Monteur
Optionale Felder:
- bestehender Kunde auswählen
- neuen vorläufigen Kunden anlegen
- vorhandenes Objekt auswählen
- Fotos
- Sprachnotiz
- Material
- Tätigkeiten
- Kundenunterschrift
19.3 Vorläufige Datensätze
Falls der Kunde noch nicht existiert, wird ein vorläufiger Kundendatensatz angelegt.
Status:
Vorläufig – Prüfung durch Backoffice erforderlich
Das Backoffice kann am nächsten Arbeitstag:
- Kunden bestätigen
- bestehenden Kunden zuordnen
- Dublette zusammenführen
- Objekt korrigieren
- Auftrag ergänzen
- Abrechnung freigeben
19.4 Benachrichtigung
Nach Abschluss eines Notdiensteinsatzes wird das Backoffice automatisch informiert.
Beispiel:
Neuer Notdiensteinsatz abgeschlossen
Monteur: Martin Solarczek
Kunde: Lutz Meier
Einsatzbeginn: 28.07.2026, 23:42 Uhr
Einsatzende: 29.07.2026, 01:18 Uhr
Status: Zur Prüfung und Abrechnung
Benachrichtigungskanäle im MVP:
- interne Benachrichtigung im Dashboard
Push-Benachrichtigungen können später ergänzt werden.
20. Benachrichtigungen
20.1 Ereignisse
Benachrichtigungen sollen unter anderem ausgelöst werden bei:
- neuer Teamzuweisung
- Änderung eines Auftrags
- Auftrag storniert
- Auftrag gestartet
- Tagesbericht erstellt
- Auftrag technisch abgeschlossen
- Unterschrift fehlt
- Bericht zur Prüfung eingereicht
- Auftrag zur Abrechnung freigegeben
- Notdiensteinsatz erstellt
- Notdiensteinsatz abgeschlossen
- Pflichtangaben fehlen
- Synchronisationsfehler
20.2 Kanäle
MVP:
- In-App-Benachrichtigung
Später:
- Web Push
- SMS
- Microsoft Teams
- Slack
- ERP-Webhook
21. Backoffice-Dashboard
Das Dashboard zeigt mindestens:
- offene Aufträge
- heutige Einsätze
- laufende Einsätze
- nicht angenommene Aufträge
- überfällige Aufträge
- Berichte zur Prüfung
- abgeschlossene Aufträge
- Aufträge zur Abrechnung
- neue Notdiensteinsätze
- fehlende Unterschriften
- Synchronisationsfehler
Filter:
- Zeitraum
- Kunde
- Objekt
- Team
- Monteur
- Status
- Auftragsart
- Priorität
22. Mobile Auftragsansicht
Die mobile Ansicht muss für die Bedienung auf Baustellen optimiert sein.
Anforderungen:
- große Schaltflächen
- geringe Texteingabe
- klare Statusanzeige
- gute Lesbarkeit bei Tageslicht
- wenige Navigationsebenen
- Kamera direkt erreichbar
- Materialerfassung mit wenigen Eingaben
- automatische Zwischenspeicherung
- Offline-Hinweis
- Synchronisationsstatus sichtbar
Empfohlene Hauptnavigation:
Heute
Aufträge
Notdienst
Synchronisation
Profil
23. Offline-Fähigkeit
23.1 Ziel
Ein Auftrag soll auch bei schlechter oder fehlender Internetverbindung bearbeitet werden können.
23.2 Offline verfügbare Daten
Vor einem Einsatz sollen lokal gespeichert werden:
- Auftragsdaten
- Kundendaten
- Objektdaten
- Ansprechpartner
- Checklisten
- Materialvorgaben
- relevante Dokumente
- technische Zeichnungen
- letzte freigegebene Einsatzberichte
- notwendige Vorlagen
23.3 Offline erfassbare Daten
- Arbeitsbeginn und Arbeitsende
- Tätigkeitsnotizen
- Checklisten
- Material
- Fotos
- Sprachnotizen
- Unterschrift
- Tagesbericht
- Abschlussbericht
23.4 Synchronisation
Lokale Änderungen werden in einer Warteschlange gespeichert.
Sobald eine Internetverbindung vorhanden ist, erfolgt die Synchronisation.
Jede Änderung erhält:
- lokale ID
- Server-ID nach Synchronisation
- Zeitstempel
- Benutzer
- Versionsnummer
- Synchronisationsstatus
- Fehlerstatus
23.5 Konfliktbehandlung
Bei Konflikten gilt:
- Daten dürfen nicht stillschweigend überschrieben werden
- Konflikte werden protokolliert
- konfliktfreie Felder werden automatisch synchronisiert
- kritische Konflikte müssen im Backoffice geprüft werden
24. Dokumentenverwaltung
24.1 Dokumentkategorien
- Auftragsbestätigung
- technische Zeichnung
- Montageanleitung
- Sicherheitsunterlage
- Arbeitsnachweis
- Tagesbericht
- Abschlussbericht
- Kundenfreigabe
- Foto
- sonstiges Dokument
24.2 Versionierung
Dokumente müssen versionierbar sein.
Zu speichern:
- Version
- Dateiname
- Kategorie
- Ersteller
- Uploaddatum
- Änderungsdatum
- Freigabestatus
- Prüfsumme
24.3 Zugriffsrechte
Dokumente können markiert werden als:
- nur Backoffice
- für Teamleiter
- für Montageteam
- für Kundenbericht freigegeben
25. Suche
Die Anwendung benötigt eine mandantenbezogene Suche.
Suchbereiche:
- Kunden
- Objekte
- Aufträge
- Einsatzberichte
- Auftragsnummern
- Ansprechpartner
- Adressen
- Dokumentnamen
- Notizen
Filterbare Suchergebnisse:
- Zeitraum
- Kunde
- Objekt
- Auftragsart
- Status
- Team
- Monteur
Eine KI-basierte semantische Suche ist nicht Bestandteil des MVP, kann aber später ergänzt werden.
26. Audit-Logging
Sicherheits- und fachlich relevante Aktionen müssen protokolliert werden.
Beispiele:
- Anmeldung
- fehlgeschlagene Anmeldung
- Benutzer angelegt
- Rolle geändert
- Auftrag importiert
- Extraktionsdaten geändert
- Auftrag zugewiesen
- Status geändert
- Arbeitszeit korrigiert
- Material geändert
- Bericht freigegeben
- PDF erzeugt
- Dokument gelöscht
- Unterschrift erfasst
- Mandanteneinstellung geändert
Ein Audit-Log enthält:
- Mandant
- Benutzer
- Aktion
- Objektart
- Objekt-ID
- Zeitstempel
- alte Werte
- neue Werte
- IP-Adresse
- User-Agent
- Ergebnis
Audit-Logs dürfen durch normale Benutzer nicht verändert oder gelöscht werden.
27. Datenschutz und Informationssicherheit
27.1 Grundprinzipien
- Datenschutz durch Technikgestaltung
- Mandantentrennung
- minimale Berechtigungen
- verschlüsselte Datenübertragung
- verschlüsselte Speicherung sensibler Daten
- sichere Passworthashes
- revisionsfähige Protokollierung
- definierte Löschfristen
- Datensicherung
- Wiederherstellbarkeit
27.2 Authentifizierung
MVP:
- E-Mail-Adresse und Passwort
- sichere Passwortanforderungen
- Passwort-Reset
- Sitzungsverwaltung
- optional verpflichtende Mehrfaktor-Authentifizierung für Administratoren
Empfehlung:
- MFA von Beginn an technisch vorbereiten
- später Microsoft Entra ID und weitere Identity Provider über OIDC integrieren
27.3 Autorisierung
Autorisierung muss serverseitig erfolgen.
Prüfung mindestens auf:
- Mandant
- Rolle
- Team
- Auftragszuweisung
- Dokumentenfreigabe
- Aktion
27.4 Dateisicherheit
- erlaubte Dateitypen einschränken
- Dateigröße begrenzen
- MIME-Type prüfen
- Dateinamen normalisieren
- Malware-Scan
- direkte öffentliche Dateilinks vermeiden
- zeitlich begrenzte Download-URLs verwenden
27.5 Löschkonzept
Daten dürfen nicht ausschließlich durch hartes Löschen entfernt werden.
Für fachliche Datensätze wird zunächst Soft Delete verwendet.
Berichte und abrechnungsrelevante Nachweise erhalten mandantenbezogene Aufbewahrungsfristen.
28. Datenmodell – Hauptentitäten
28.1 Tenant
Tenant
- id
- name
- slug
- status
- settings
- created_at
- updated_at
28.2 User
User
- id
- tenant_id
- email
- password_hash
- first_name
- last_name
- phone
- status
- last_login_at
- created_at
- updated_at
28.3 Role
Role
- id
- tenant_id
- name
- permissions
28.4 Team
Team
- id
- tenant_id
- name
- leader_user_id
- status
28.5 TeamMember
TeamMember
- team_id
- user_id
- valid_from
- valid_to
28.6 Customer
Customer
- id
- tenant_id
- customer_number
- company_name
- first_name
- last_name
- address
- contact_data
- status
- is_provisional
28.7 Site
Site
- id
- tenant_id
- customer_id
- name
- address
- contact_person_id
- access_notes
- safety_notes
- technical_notes
28.8 WorkOrder
WorkOrder
- id
- tenant_id
- customer_id
- site_id
- external_order_number
- order_type
- priority
- status
- title
- description
- planned_start
- planned_end
- assigned_team_id
- signature_required
- source_document_id
28.9 WorkSession
WorkSession
- id
- tenant_id
- work_order_id
- user_id
- team_id
- type
- started_at
- ended_at
- status
28.10 MaterialPlan
MaterialPlan
- id
- tenant_id
- work_order_id
- name
- article_number
- planned_quantity
- unit
28.11 MaterialUsage
MaterialUsage
- id
- tenant_id
- work_order_id
- material_plan_id
- name
- article_number
- actual_quantity
- unit
- usage_status
- deviation_reason
28.12 Report
Report
- id
- tenant_id
- work_order_id
- type
- version
- status
- content
- pdf_document_id
- approved_by
- approved_at
28.13 Document
Document
- id
- tenant_id
- customer_id
- site_id
- work_order_id
- category
- file_name
- storage_key
- mime_type
- file_size
- checksum
- version
- visibility
28.14 Notification
Notification
- id
- tenant_id
- user_id
- type
- title
- message
- read_at
- sent_at
28.15 AuditLog
AuditLog
- id
- tenant_id
- user_id
- action
- entity_type
- entity_id
- old_values
- new_values
- ip_address
- user_agent
- created_at
29. API-Konzept
Die Anwendung soll über eine versionierte API verfügen.
Beispiel:
/api/v1/
29.1 Beispiel-Endpunkte
POST /api/v1/auth/login
POST /api/v1/auth/logout
POST /api/v1/auth/refresh
GET /api/v1/customers
POST /api/v1/customers
GET /api/v1/customers/{id}
PATCH /api/v1/customers/{id}
GET /api/v1/sites
POST /api/v1/sites
GET /api/v1/sites/{id}/history
GET /api/v1/work-orders
POST /api/v1/work-orders
GET /api/v1/work-orders/{id}
PATCH /api/v1/work-orders/{id}
POST /api/v1/work-orders/{id}/assign
POST /api/v1/work-orders/{id}/start
POST /api/v1/work-orders/{id}/pause
POST /api/v1/work-orders/{id}/complete
POST /api/v1/work-orders/import
GET /api/v1/imports/{id}
POST /api/v1/imports/{id}/confirm
POST /api/v1/work-orders/{id}/materials
POST /api/v1/work-orders/{id}/photos
POST /api/v1/work-orders/{id}/voice-notes
POST /api/v1/work-orders/{id}/daily-report
POST /api/v1/work-orders/{id}/completion-report
POST /api/v1/reports/{id}/approve
GET /api/v1/reports/{id}/pdf
POST /api/v1/emergency-orders
POST /api/v1/sync
29.2 API-Anforderungen
- REST oder vergleichbares klar definiertes API-Modell
- OpenAPI-Dokumentation
- konsistente Fehlercodes
- Pagination
- Filter
- Sortierung
- Idempotency Keys für kritische mobile Aktionen
- Rate Limiting
- Mandantenprüfung
- Rollenprüfung
- Audit-Logging
30. Technologievorschlag
Der konkrete Stack kann angepasst werden.
30.1 Frontend
Empfehlung:
- Next.js oder React
- TypeScript
- responsive UI-Komponenten
- PWA Service Worker
- IndexedDB für Offline-Daten
- React Query oder vergleichbare Datenabstraktion
- Formularvalidierung mit Zod
- PDF- und Bildvorschau
30.2 Backend
Mögliche Varianten:
Variante A
- TypeScript
- NestJS
- Prisma ORM
- PostgreSQL
Variante B
- Python
- FastAPI
- SQLAlchemy
- PostgreSQL
Für eine einheitliche TypeScript-Codebasis wird Variante A empfohlen.
30.3 Dateispeicher
- S3-kompatibler Object Storage
- MinIO für lokale oder selbst gehostete Umgebungen
- alternativ Cloudflare R2, AWS S3 oder Azure Blob Storage
30.4 Hintergrundverarbeitung
Für folgende Aufgaben ist eine Job Queue erforderlich:
- OCR
- KI-Extraktion
- Transkription
- PDF-Erstellung
- Bildoptimierung
- E-Mail-Versand
- Benachrichtigungen
- Synchronisationsnachverarbeitung
Mögliche Technologien:
- Redis
- BullMQ
- Celery bei Python
- RabbitMQ optional
30.5 Bereitstellung
Empfehlung:
- Docker
- Docker Compose für Entwicklung
- Coolify für Hosting
- PostgreSQL
- Redis
- Object Storage
- Reverse Proxy
- TLS
- getrennte Entwicklungs-, Test- und Produktionsumgebung
31. KI- und OCR-Abstraktion
KI- und OCR-Funktionen dürfen nicht fest mit einem einzigen Anbieter verbunden werden.
Es wird eine Provider-Abstraktion empfohlen.
Beispiel:
interface DocumentExtractionProvider {
extractText(file: Buffer): Promise<ExtractedText>;
extractStructuredData(text: string): Promise<WorkOrderExtraction>;
}
Mögliche Provider:
- Azure AI Document Intelligence
- Google Document AI
- AWS Textract
- Tesseract OCR
- OpenAI
- Anthropic
- lokales Sprachmodell
Konfiguration je Mandant oder Plattform:
- Provider
- Modell
- Region
- Datenschutzoptionen
- Aufbewahrung
- maximale Dateigröße
- Kostenlimit
32. PDF-Berichtsgenerierung
Berichte sollen über HTML-Templates erzeugt und als PDF gerendert werden.
Mögliche Technologien:
- Playwright
- Puppeteer
- serverseitige HTML-zu-PDF-Engine
Vorteile:
- anpassbares Layout
- Mandantenlogo
- individuelle Berichtsvorlagen
- saubere Seitenumbrüche
- Fotoübersichten
- Unterschriftenintegration
Jeder erzeugte Bericht erhält:
- eindeutige Bericht-ID
- Versionsnummer
- Erstellungsdatum
- Prüfsumme
- Freigabestatus
33. E-Mail-Versand
33.1 E-Mail-Ereignisse
- Teamzuweisung
- Bericht zur Prüfung
- Auftrag zur Abrechnung
- Notdiensteinsatz
- Fehler bei der Dokumentverarbeitung
33.2 Konfiguration
Je Mandant konfigurierbar:
- Absendername
- Absenderadresse
- Empfänger für Notdienste
- Empfänger für Abrechnung
- Antwortadresse
- E-Mail-Vorlagen
33.3 Technische Umsetzung
Mögliche Anbindung:
- SMTP
- Microsoft Graph
- Amazon SES
- Mailgun
- Postmark
E-Mails werden über eine Warteschlange versendet.
Versandstatus und Fehler werden protokolliert.
34. Nichtfunktionale Anforderungen
34.1 Performance
- Standardseiten sollen innerhalb von zwei Sekunden reagieren
- Auftragslisten müssen paginiert werden
- Bilder werden asynchron geladen
- große Dokumente werden im Hintergrund verarbeitet
- Uploadfortschritt muss sichtbar sein
34.2 Verfügbarkeit
Für den MVP wird eine Zielverfügbarkeit von 99,5 Prozent empfohlen.
34.3 Skalierbarkeit
Die Architektur muss horizontal erweiterbar sein.
Insbesondere:
- stateless Backend
- externer Dateispeicher
- zentrale Datenbank
- Redis oder Queue-System
- getrennte Worker
34.4 Browserunterstützung
- aktuelle Version von Chrome
- aktuelle Version von Edge
- aktuelle Version von Safari
- aktuelle Version von Firefox
- mobile Browser unter iOS und Android
34.5 Barrierearme Bedienung
- ausreichende Kontraste
- verständliche Beschriftungen
- Tastaturbedienung im Backoffice
- große Touch-Ziele
- Fehlermeldungen in Klartext
35. MVP-Abgrenzung
Nicht Bestandteil des initialen MVP:
- native iOS-App
- native Android-App
- vollständige Lagerverwaltung
- automatische Bestandsbuchung
- vollständige Anlagenverwaltung
- Seriennummern- und Gerätehistorie
- Rechnungsstellung
- Finanzbuchhaltung
- direkte DATEV-Schnittstelle
- direkte ERP-Schnittstellen
- automatische Tourenoptimierung
- GPS-Dauertracking
- Fahrzeugverwaltung
- Kundenportal
- Lieferantenportal
- automatische Angebotserstellung
- komplexe Ressourcenplanung
- Lohnabrechnung
- vollautomatische KI-Freigaben
- semantische Suche über alle Dokumente
36. Priorisierung
36.1 Muss-Funktionen für den MVP
- Multitenancy
- Benutzer und Rollen
- Kunden
- Objekte
- Teams
- PDF-Import
- OCR und Datenextraktion
- manuelle Prüfmaske
- Aufträge
- Teamzuweisung
- mobile PWA
- eingeschränkte Offline-Nutzung
- Arbeitszeiten
- Tätigkeitsdokumentation
- Materialdokumentation
- Fotos
- Checklisten
- Tagesbericht
- Abschlussbericht
- PDF-Erstellung
- Kundenunterschrift
- Notdiensteinsatz
- Backoffice-Benachrichtigung
- Objekt-Historie
- technische Dokumente
- Audit-Logging
36.2 Soll-Funktionen
- Sprachnotizen
- Transkription
- KI-Berichtsentwurf
- konfigurierbare Vorlagen
- E-Mail-Versand von Berichten
- Berichtsversionierung
- MFA
- Kartenlink zur Einsatzadresse
36.3 Kann-Funktionen
- Push-Benachrichtigungen
- Kalenderansicht
- Standorterfassung beim Einsatzstart
- Barcode- oder QR-Code-Erfassung
- kundenspezifische Statusmodelle
- digitale Einsatzfreigabe durch Teamleiter
37. User Stories
US-001 – Mandant anlegen
Als Plattformadministrator
möchte ich einen neuen Handwerksbetrieb als Mandanten anlegen,
damit dieser die Anwendung mit vollständig getrennten Daten nutzen kann.
Akzeptanzkriterien:
- Mandant erhält eine eindeutige ID
- Mandantenadministrator kann angelegt werden
- Daten anderer Mandanten sind nicht sichtbar
- Mandant kann deaktiviert werden
US-002 – Auftragsbestätigung importieren
Als Backoffice-Mitarbeiter
möchte ich eine Auftragsbestätigung als PDF hochladen,
damit Kunden-, Objekt- und Auftragsdaten automatisch übernommen werden.
Akzeptanzkriterien:
- PDF kann hochgeladen werden
- Text wird erkannt
- strukturierte Felder werden extrahiert
- unsichere Felder werden markiert
- Daten können korrigiert werden
- Auftrag wird erst nach Bestätigung angelegt
- Originaldokument bleibt gespeichert
US-003 – Bestehenden Kunden erkennen
Als Backoffice-Mitarbeiter
möchte ich beim Import erkennen, ob der Kunde bereits existiert,
damit keine unnötigen Dubletten entstehen.
Akzeptanzkriterien:
- System prüft Kundennummer, Name und Adresse
- mögliche Treffer werden angezeigt
- Benutzer entscheidet über Zuordnung
- keine automatische Zusammenführung ohne Bestätigung
US-004 – Auftrag einem Team zuweisen
Als Backoffice-Mitarbeiter
möchte ich einen Auftrag einem Montageteam zuweisen,
damit das Team den Auftrag auf dem Tablet bearbeiten kann.
Akzeptanzkriterien:
- Team kann ausgewählt werden
- Auftrag erscheint in der mobilen Ansicht
- Team wird benachrichtigt
- Zuweisung wird protokolliert
US-005 – Technische Unterlagen ansehen
Als Monteur
möchte ich technische Zeichnungen und frühere Einsatzberichte am Objekt ansehen,
damit ich den aktuellen Einsatz korrekt durchführen kann.
Akzeptanzkriterien:
- relevante Dokumente sind am Auftrag sichtbar
- freigegebene frühere Berichte sind sichtbar
- Dokumente können vorab offline gespeichert werden
- Backoffice-interne Dokumente bleiben verborgen
US-006 – Einsatz dokumentieren
Als Monteur
möchte ich Arbeiten, Zeiten, Fotos, Material und Notizen erfassen,
damit ein vollständiger Arbeitsnachweis entsteht.
Akzeptanzkriterien:
- Einsatz kann gestartet und beendet werden
- Fotos können aufgenommen werden
- Materialmengen können bestätigt oder geändert werden
- Zusatzmaterial kann erfasst werden
- Notizen bleiben bei Verbindungsabbruch erhalten
US-007 – Tagesbericht erstellen
Als Monteur
möchte ich am Ende eines Arbeitstages einen Tagesbericht erstellen,
damit der Fortschritt eines mehrtägigen Auftrags dokumentiert ist.
Akzeptanzkriterien:
- Bericht enthält Arbeitszeiten und Tätigkeiten
- offene Punkte können dokumentiert werden
- Fotos können eingebunden werden
- Auftrag bleibt geöffnet
- Bericht erscheint in der Objekt-Historie
US-008 – Abschlussbericht erstellen
Als Monteur
möchte ich nach Abschluss einen Bericht erzeugen,
damit der Kunde und das Backoffice einen Leistungsnachweis erhalten.
Akzeptanzkriterien:
- Pflichtangaben werden geprüft
- Pflichtfotos werden geprüft
- Materialabweichungen sind enthalten
- Kundenunterschrift kann erfasst werden
- PDF wird erzeugt
- Auftrag erhält den Status „Zur Prüfung“
US-009 – Auftrag zur Abrechnung freigeben
Als Backoffice-Mitarbeiter
möchte ich einen abgeschlossenen Auftrag prüfen und zur Abrechnung freigeben,
damit die Rechnung erstellt werden kann.
Akzeptanzkriterien:
- Bericht ist einsehbar
- Arbeitszeiten sind einsehbar
- Material ist einsehbar
- Bericht kann freigegeben oder zurückgewiesen werden
- Freigabe wird protokolliert
- zuständige Stelle wird benachrichtigt
US-010 – Notdiensteinsatz anlegen
Als Monteur
möchte ich außerhalb der Geschäftszeiten selbst einen Notdiensteinsatz anlegen,
damit der Einsatz vollständig dokumentiert und später abgerechnet werden kann.
Akzeptanzkriterien:
- bestehender Kunde kann ausgewählt werden
- vorläufiger Kunde kann angelegt werden
- Objekt oder Einsatzadresse kann erfasst werden
- Zeiten, Tätigkeiten, Material und Fotos können dokumentiert werden
- Abschlussbericht kann erstellt werden
- Backoffice wird automatisch informiert
- Einsatz ist am nächsten Arbeitstag zur Prüfung sichtbar
US-011 – Objekt-Historie aufrufen
Als Monteur oder Backoffice-Mitarbeiter
möchte ich die bisherigen Einsätze eines Objekts einsehen,
damit frühere Arbeiten und technische Hinweise berücksichtigt werden.
Akzeptanzkriterien:
- chronologische Liste aller freigegebenen Einsätze
- Berichte und Fotos sind abrufbar
- verwendetes Material ist sichtbar
- offene Folgearbeiten werden hervorgehoben
US-012 – Offline arbeiten
Als Monteur
möchte ich einen Auftrag ohne stabile Internetverbindung bearbeiten,
damit die Dokumentation auf Baustellen nicht unterbrochen wird.
Akzeptanzkriterien:
- Auftragsdaten sind offline verfügbar
- Eingaben werden lokal gespeichert
- Fotos werden in die Uploadwarteschlange aufgenommen
- Synchronisationsstatus ist sichtbar
- Daten werden nach Wiederherstellung der Verbindung übertragen
- Konflikte werden nicht stillschweigend überschrieben
38. Beispielprozess – regulärer Auftrag
Backoffice lädt Auftragsbestätigung hoch
↓
OCR und KI extrahieren Daten
↓
Backoffice prüft Kunden-, Objekt- und Auftragsdaten
↓
Bestehender Kunde und bestehendes Objekt werden zugeordnet
↓
Auftrag wird einem Montageteam zugewiesen
↓
Team lädt Auftrag und Dokumente auf das Tablet
↓
Monteur startet Einsatz
↓
Arbeiten, Zeiten, Material, Fotos und Notizen werden erfasst
↓
Monteur erstellt Abschlussbericht
↓
Kunde unterschreibt
↓
PDF-Arbeitsnachweis wird erzeugt
↓
Backoffice prüft Bericht
↓
Auftrag wird zur Abrechnung freigegeben
↓
Einsatz erscheint in der Objekt-Historie
39. Beispielprozess – Notdiensteinsatz
Monteur erhält außerhalb der Geschäftszeit einen Anruf
↓
Monteur öffnet „Notdienst“
↓
Bestehender Kunde wird ausgewählt oder vorläufig angelegt
↓
Einsatzadresse und Störungsgrund werden erfasst
↓
Einsatz wird gestartet
↓
Arbeiten, Material, Fotos und Zeiten werden dokumentiert
↓
Kunde unterschreibt oder Abwesenheit wird dokumentiert
↓
Abschlussbericht wird erzeugt
↓
Backoffice erhält E-Mail und In-App-Benachrichtigung
↓
Backoffice prüft am nächsten Arbeitstag die Stammdaten
↓
Auftrag wird zur Abrechnung freigegeben
40. Akzeptanzkriterien für den Gesamt-MVP
Der MVP gilt als fachlich abnahmefähig, wenn:
- mehrere Mandanten mit sicher getrennter Datenhaltung betrieben werden können
- Benutzer, Rollen und Montageteams verwaltet werden können
- Auftragsbestätigungen als PDF importiert werden können
- Kunden-, Objekt- und Auftragsdaten automatisiert extrahiert werden
- das Backoffice die erkannten Daten prüfen und korrigieren kann
- Aufträge Teams zugewiesen werden können
- Monteure Aufträge auf Tablets und Smartphones bearbeiten können
- wesentliche Daten offline erfasst werden können
- Arbeitszeiten, Tätigkeiten, Material und Fotos dokumentiert werden können
- Tagesberichte erzeugt werden können
- Abschlussberichte inklusive Kundenunterschrift erzeugt werden können
- ein PDF-Arbeitsnachweis erstellt wird
- das Backoffice abgeschlossene Aufträge zur Abrechnung freigeben kann
- Monteure selbstständig Notdiensteinsätze anlegen können
- das Backoffice über Notdiensteinsätze informiert wird
- frühere Einsätze und technische Dokumente pro Objekt abrufbar sind
- relevante Änderungen revisionsfähig protokolliert werden
41. Empfohlene Entwicklungsphasen
Phase 0 – Technische Basis
- Repository
- CI/CD
- Docker
- Datenbank
- Authentifizierung
- Mandantenkontext
- Rollen und Berechtigungen
- Logging
- Object Storage
- Grundlayout
Phase 1 – Stammdaten und Aufträge
- Kunden
- Ansprechpartner
- Objekte
- Teams
- Benutzer
- Aufträge
- Statusmodell
- Dokumentenupload
- Teamzuweisung
Phase 2 – PDF-Import
- Upload
- OCR
- Extraktion
- Prüfmaske
- Dublettenprüfung
- Auftragsentwurf
- Originaldokument
Phase 3 – Mobile Einsatzbearbeitung
- PWA
- mobile Auftragsliste
- Einsatzstart
- Arbeitszeiten
- Checklisten
- Material
- Fotos
- Notizen
- Offline-Speicherung
Phase 4 – Berichte
- Tagesbericht
- Abschlussbericht
- Unterschrift
- PDF-Erstellung
- Berichtsversionen
- Backoffice-Freigabe
Phase 5 – Notdienst
- Notdiensteinsatz
- vorläufiger Kunde
- vorläufiges Objekt
- Benachrichtigungen
- Nachbearbeitung im Backoffice
Phase 6 – Stabilisierung
- Audit-Logging
- Sicherheitsprüfungen
- Lasttests
- Offline-Konflikte
- Backup und Restore
- Monitoring
- Fehlerbehandlung
- Pilotbetrieb
42. Definition of Done
Eine Funktion gilt als fertig, wenn:
- fachliche Anforderungen umgesetzt sind
- Mandantentrennung geprüft wurde
- Rollen- und Rechteprüfung vorhanden ist
- Eingaben validiert werden
- Fehlerfälle behandelt werden
- relevante Aktionen protokolliert werden
- automatisierte Tests vorhanden sind
- API dokumentiert ist
- responsive Darstellung geprüft wurde
- Offline-Verhalten geprüft wurde, sofern relevant
- Datenschutzanforderungen berücksichtigt sind
- technische Dokumentation aktualisiert wurde
- Funktion in einer Testumgebung abgenommen wurde
43. Teststrategie
43.1 Unit-Tests
- Datenvalidierung
- Statusübergänge
- Berechtigungen
- Mandantenfilter
- Materialberechnungen
- Berichtsgenerierung
- Extraktionsmapping
43.2 Integrationstests
- PDF-Import
- OCR-Verarbeitung
- Dateiupload
- E-Mail-Versand
- PDF-Erstellung
- Datenbank
- Object Storage
- Queue-Verarbeitung
43.3 End-to-End-Tests
- regulärer Auftrag vom Import bis zur Freigabe
- mehrtägiger Auftrag mit Tagesbericht
- Notdiensteinsatz
- Offline-Erfassung und Synchronisation
- fehlende Pflichtfotos
- fehlende Unterschrift
- Dublettenprüfung
- Mandantentrennung
43.4 Sicherheitstests
- Zugriff auf fremde Mandantendaten
- manipulierte IDs
- unzulässige Rollenaktionen
- schädliche Uploads
- Session-Handling
- Rate Limiting
- Passwort-Reset
- Audit-Log-Manipulation
44. Offene fachliche Entscheidungen vor Produktivbetrieb
Folgende Punkte müssen spätestens während der Umsetzung konkretisiert werden:
- genaue Berichtsvorlage des Pilotkunden
- Pflichtfelder je Auftragsart
- erforderliche Fotoarten
- Regelung der Arbeitszeitkorrektur
- Aufbewahrungsfristen
- Empfänger der Abrechnungsbenachrichtigung
- bevorzugter OCR- und KI-Anbieter
- gewünschter E-Mail-Dienst
- Hostingstandort
- gewünschte MFA-Regelung
- Umgang mit Standortdaten
- maximale Offline-Dauer
- maximale Dateigrößen
- konkrete Buchhaltungssoftware des Pilotkunden
- später gewünschte Schnittstellen
- Unternehmensbranding der PWA
- Berichtssprache
- Lösch- und Archivierungskonzept
45. Perspektive für Version 2
Für Version 2 werden folgende Erweiterungen empfohlen:
- direkte Schnittstelle zum Buchhaltungs- oder ERP-System
- Artikel- und Materialstamm
- Lagerbestände
- automatische Übergabe abrechnungsrelevanter Positionen
- Kalender und Einsatzplanung
- Routenplanung
- Kundenportal
- Wartungsplanung
- Anlagen- und Geräteverwaltung
- Seriennummern
- QR-Codes an Objekten oder Anlagen
- automatische Erinnerungen
- Web-Push-Benachrichtigungen
- Microsoft-365-Integration
- DATEV-Export
- KI-Suche in Einsatzhistorien
- KI-Assistent für Monteure
- automatische Zusammenfassung früherer Einsätze
- Auswertung von Nachkalkulationen
- Kennzahlen je Team, Auftrag und Kunde
- konfigurierbare Workflows je Mandant
46. Zusammenfassung
Der MVP soll eine mandantenfähige PWA für Handwerks- und Montagebetriebe bereitstellen.
Der Kernnutzen besteht darin, Auftragsdaten aus bestehenden PDF-Dokumenten zu übernehmen, Montageteams digital mit allen notwendigen Informationen zu versorgen und aus der tatsächlichen Arbeit vor Ort einen vollständigen, abrechnungsfähigen Nachweis zu erzeugen.
Besonders wichtig sind:
- geringe manuelle Datenerfassung
- einfache Bedienung auf der Baustelle
- Offline-Fähigkeit
- vollständige Foto- und Materialdokumentation
- Tages- und Abschlussberichte
- Notdiensteinsätze ohne Backoffice
- dauerhafte Objekt-Historie
- technische Dokumente am Objekt
- sichere Mandantentrennung
- modular erweiterbare Architektur
Die Lösung bildet damit die Grundlage für eine später umfassendere SaaS-Plattform für Handwerks- und Montagebetriebe.