1 · Firmenwebsite
Öffentliche Informationen, Preise, Referenzen, Formulare und technische Erklärungen. Keine produktive Auftrags- oder Betriebsdatenbank.
Technische Details
Eine Plattform, viele mögliche Arbeitsweisen.
Die Kundenseiten erklären den Nutzen. Hier steht die Architektur dahinter: WerkZ ist als modularer, organisationsfähiger Kern konzipiert, dessen Oberflächen und Module je Betrieb unterschiedlich zusammengestellt werden können. Die Firmenwebsite bleibt davon technisch und fachlich getrennt.
Klare Systemgrenze
Website ≠ Kundenanwendung.
Die öffentliche Website liefert Marketing, Referenzen, Vor-Check und technische Dokumentation. Produktive Betriebsdaten gehören in eine getrennte WerkZ-Instanz bzw. Web-App/PWA.
2 · WerkZ App
Eigene Kundenanwendung mit Login, Modulen, Rollen, Offline-Verhalten und Betriebsdaten. Auf Smartphone, Tablet oder Desktop erreichbar.
3 · Adapter
Verbindungen zu bestehenden Diensten wie Kalender, Buchhaltung, E-Mail, Messenger, CRM oder Fachsoftware bleiben austauschbar.
Zielarchitektur
Modularer Monolith zuerst – sauber getrennte Verantwortlichkeiten innen.
Für kleine und mittlere Installationen ist eine gemeinsame Anwendung robuster und einfacher zu betreiben als vorschnell verteilte Microservices. Fachmodule bleiben trotzdem klar getrennt, damit sie einzeln aktivierbar, testbar und später skalierbar sind.
ClientsMobile PWA · Desktop/Büro · Werkstatt-/Terminalmodus · Leitungs-/Chefmodus
FachmoduleKunden · Aufträge · Zeit · Material · Dokumente · Billing · Analyse · Simulation · Approvals
WerkZ CoreOrganisation/Mandant · Identität · Capability-Rechte · Konfiguration · Events/Audit · Sync/Offline · Datenzugriff
AdapterAPI · OAuth · Webhooks · Import/Export · E-Mail · Messenger · Karten/GPS · Buchhaltung/Fachsysteme
PersistenzAbstrahierte Datenbank + getrennte Datei-/Objektspeicherung für Fotos und Dokumente; lokal einfach, gehostet skalierbar.
Organisation statt starrer Rollen
Ein Datenmodell soll vom Solo-Betrieb bis zur großen Organisation skalieren.
Begriffe wie „Leitung“, „Büro“ oder „Monteur“ beschreiben Bedienprofile und Rollenbündel – keine starre Datenstruktur. Rechte werden als Fähigkeiten vergeben.
OrganisationOrganisationseinheit optionalStandort optionalTeam optionalBenutzer / AkteurCapabilities
Beispiel: Ein Solo-Nutzer kann Auftrag anlegen, Zeit erfassen, Rechnung freigeben und Analyse sehen. In einem größeren Betrieb können exakt dieselben Fähigkeiten auf verschiedene Personen, Teams und Standorte verteilt werden.
Mobile & Offline
Smartphone-only ist ein eigener Hauptfall – kein Notbehelf.
Ein Solo-Kunde kann WerkZ über einen separat gehosteten App-Zugang im Browser nutzen. Für Montage und schwankende Verbindung soll die Architektur lokale Arbeitsdaten und eine nachvollziehbare Synchronisationswarteschlange unterstützen.
PWA
Responsive Web-App, auf dem Homescreen installierbar. Kein App-Store-Zwang für den grundlegenden Zugriff.
Offline Queue
Zugewiesene Vorgänge und Eingaben können lokal gepuffert und bei wieder vorhandener Verbindung synchronisiert werden.
Konflikte sichtbar
Gleichzeitige Änderungen dürfen nicht still überschrieben werden. Konflikte und fehlgeschlagene Uploads müssen nachvollziehbar bleiben.
iPhone-Hinweis: Die Architektur darf nicht darauf angewiesen sein, dass iOS eine Web-App dauerhaft im Hintergrund synchronisiert. Kritische Sync-Schritte müssen spätestens beim Öffnen oder aktiven Verwenden zuverlässig nachgeholt werden können.
Events, Audit, Analyse
Der aktuelle Zustand allein reicht nicht.
Für Nachvollziehbarkeit und Langzeitauswertung braucht WerkZ neben operativen Tabellen einen strukturierten Ereignisverlauf.
Auftrag angelegtZeit gestartetEinsatz dokumentiertNachtrag gemeldetFreigabe erteiltAuftrag abgeschlossen
Operative Daten
Aktueller Kunde, Auftrag, Termin, Status, Material oder Zeitstand. Optimiert für den täglichen Betrieb.
Historie / Audit
Wer hat wann was geändert, ausgelöst oder freigegeben? Diese Ebene speist später Analyse, Nacharbeit und Simulation.
Analyse & Simulation
Reale Historie und Was-wäre-wenn strikt trennen.
EventsSnapshotsMetricsRule EngineScenario EngineSimulation RunsReality ComparatorLong-Term Evaluation
Versionierung & Reproduzierbarkeit
- Regeln und Szenarien erhalten Versionen.
- Ein historischer Simulationslauf bleibt mit seinem damaligen Regelstand reproduzierbar.
- Simulationen dürfen spätere Informationen nicht rückwirkend verwenden (Anti-Lookahead).
Keine Mutation realer Daten
- Simulationen laufen in getrennten Szenario-/Run-Daten.
- Reale Betriebswerte werden nie durch einen Simulationslauf überschrieben.
- Ergebnisse werden als Entscheidungshilfe oder Experiment dargestellt, nicht als automatisch wahre Prognose.
Integrationen & Approvals
Externe Dienste bleiben Adapter – der WerkZ-Core bleibt verantwortlich.
API, OAuth, Webhooks, Import & Export
- Offizielle APIs und widerrufbare OAuth-Zugriffe werden bevorzugt, wenn verfügbar.
- Webhooks können Änderungen ereignisbasiert melden.
- Wenn keine stabile Schnittstelle existiert, ist ein kontrollierter Import/Export oft besser als fragile Browser-Automation.
Messenger-Freigaben
- WhatsApp, E-Mail oder andere Kanäle sind nur Benachrichtigungs- und Freigabeadapter.
- Die eigentliche Aktion wird im WerkZ-Core autorisiert, eindeutig zugeordnet, idempotent verarbeitet und auditiert.
- Im Messenger stehen nur die für die Entscheidung nötigen Informationen – nicht die komplette Betriebsakte.
Führende Quelle
- Für Kunden, Rechnungen, Artikel oder andere Kernobjekte wird definiert, welches System maßgeblich ist.
- WerkZ soll nicht unbemerkt eine zweite konkurrierende Wahrheit erzeugen.
Betriebsmodelle
Cloud, Hybrid, WerkZ Box oder kundeneigene Infrastruktur.
Funktionsumfang und Betriebsort sind zwei getrennte Entscheidungen. Vor jedem Infrastrukturangebot wird geprüft, was beim Kunden bereits vorhanden und sinnvoll nutzbar ist.
WerkZ Cloud
Managed Betrieb ohne lokalen Serverzwang. Für viele Solo- und Team-Fälle der einfachste und wirtschaftlichste Start.
Hybrid + Connector
Der Core läuft gehostet; ein abgesicherter Agent verbindet ausschließlich freigegebene lokale Systeme über ausgehende Verbindungen.
WerkZ Box
Vorbereitete kleine Appliance im Betrieb. Möglich auf geeigneter Hardware wie Business-Mini-PC oder Mac mini. Vorhandene passende Hardware wird bevorzugt weiterverwendet.
Dedicated / On-Premise
Eigene isolierte Instanz oder Betrieb auf vorhandener Server-/Virtualisierungsinfrastruktur für höhere Anforderungen.
Beschaffungsregel: WerkZ kauft Hardware nicht auf Verdacht. Erst nach Auftrag und Eignungsprüfung wird entweder vorhandene Kundenhardware eingerichtet, eine konkrete Hardwareempfehlung ausgesprochen oder passende Hardware als eigene Angebotsposition beschafft, vorbereitet und dokumentiert. Herstellerkennzeichnung und Herstellergewährleistung bleiben transparent; eine fremde Hardware wird nicht einfach als eigene WerkZ-Hardware ausgegeben.
Kalkulationsregel: Lösung/Module, Infrastruktur, Hardware und laufender Betrieb werden getrennt berechnet. Dadurch kostet derselbe WerkZ-Funktionsumfang in der Managed Cloud weniger Infrastrukturaufwand als eine eigene Box oder vollständige On-Premise-Installation.
Skalierungspfad
Komplexität nur dann hinzufügen, wenn sie gebraucht wird.
Solo
Smartphone-/Browserzugriff, wenige Module, einfache Betriebsstruktur.
Kleinbetrieb
Mehrere Nutzer, mobile Arbeit, gemeinsame Aufträge, einfache Rechte und Freigaben.
Mittelstand
Teams, Standorte, Integrationen, differenzierte Rechte, zentrale Datenbank und Monitoring.
Enterprise
SSO, Organisationseinheiten, stärkere Isolation, Audit, Queues, Hochverfügbarkeit oder On-Prem – nur wenn tatsächlich erforderlich.
Technische Grundregel
Einfacher Betrieb zuerst. Erweiterbarkeit von Anfang an.
WerkZ soll für einen Ein-Personen-Betrieb nicht wie Enterprise-Software wirken – aber das Daten- und Rechtemodell darf spätere Größe nicht verbauen.