Fallstudie · Industrie · Fertigung
Wie wir ein industrielles Ökosystem aus drei Apps ausgeliefert haben — einen Kotlin-Android-Bediener-Client, ein Laravel + React-Admin-Panel und ein Controller-Dashboard — bereitgestellt innerhalb eines isolierten Werksnetzes und darauf ausgelegt, Papierjournale durch einen audit-fähigen Workflow für Anlagen in den Vereinigten Staaten und der Europäischen Union zu ersetzen.
Der CheckList-Kunde betrieb ein Fertigungswerk, in dem Reaktorprozesse mit Papierjournalen erfasst wurden: Bediener schrieben Stufenzeiten von Hand, Vorgesetzte blätterten durch Logbücher, um Schichten zu rekonstruieren, und es gab keine Echtzeit-Transparenz über Verfügbarkeit oder Fehlerzahlen. Das Werk arbeitete ohne Internet innerhalb seines Perimeters — eine harte Einschränkung, keine Präferenz — sodass jeder digitale Ersatz vollständig offline funktionieren und synchronisieren musste, sobald eine LAN-Verbindung verfügbar war. Wir lieferten ein Ökosystem aus drei Apps, bereitgestellt innerhalb des isolierten Werksnetzes: Bediener nutzen eine Kotlin-Android-App, um Stufen mit Zeitstempeln und Fotonachweis zu protokollieren; Admins konfigurieren Anlagen, Checklisten, Benutzer und Berechtigungen in einem Laravel- und React-Admin-Panel; Controller beobachten ein Live-Dashboard mit Verfügbarkeit, Fehlerzahlen und einem Not-Halt-Knopf. Lokale Authentifizierung und Offline-first-Synchronisation machen das System ohne Internetzugang nutzbar, und ein Reaktor-/Prozesskonstruktor erlaubt es dem Werk, neue Anlagen ohne eine Code-Änderung hinzuzufügen. Das Ergebnis ist ein audit-fähiger Workflow, der einer Werks-Audit-Prüfung sowohl in US- als auch in EU-Jurisdiktionen standhält und jede Zeile des Papier-Logbuchs ersetzt.
Ein Überblick über das, was die CheckList-Umsetzung über die Bediener-App, das Admin-Panel und das Controller-Dashboard im ersten Produktivzyklus in der Produktion geliefert hat.
Die Stack-Entscheidung dominiert jede andere architektonische Wahl bei einer industriellen MES-Umsetzung. Wir wählten einen individuellen Kotlin-Android-Bediener-Client in Kombination mit einem Laravel-Backend und einer React-Web-Fläche, weil die Trade-offs sauber zu einer Produktion passen, die ohne Internet arbeitet. Die Android-App läuft per Design offline, das Laravel-Backend wird auf einer einzigen On-Premise-Maschine innerhalb des Werks-LAN bereitgestellt, und die React-Admin- und Controller-Dashboards teilen den Session-State über WebSockets, sodass ein Vorgesetzter eine Fehlerzahl in dem Moment hochzählen sieht, in dem ein Bediener eine Abweichung protokolliert.
SaaS-MES-Anbieter schieden früh aus: Sie setzen zuverlässiges Internet voraus, sie ziehen Werksdaten aus dem Perimeter heraus und sie rechnen pro Node auf eine Weise ab, die mit dem Wachstum des Werks unbeherrschbar wird. Standard-SCADA ist hochgradig konfigurierbar, doch seine Workflow-Fläche — Schichtübergabe, Fotonachweis, ein audit-fähiges Archiv — liegt außerhalb seiner Kernkompetenz. Ein generischer Formular-Builder plus ein Automatisierungswerkzeug näht eine fragile Pipeline zusammen, die beim ersten Mal bricht, wenn das Werks-LAN ein Paket verliert.
| Dimension | CheckList (Kotlin + Laravel + React) | SaaS-MES-Anbieter | Standard-SCADA / Formular-Builder |
|---|---|---|---|
| Offline-first-Verhalten | Nativ — lokale SQLite-Warteschlange, leert sich im LAN | Setzt zuverlässiges Internet voraus | SCADA: ja; Formular-Builder: meist nein |
| Bereitstellungstopologie | On-Premise im Werks-LAN; air-gap-fähig | Mandantenfähige Cloud; Preise pro Sitzplatz | SCADA: On-Premise; Formulare: nur Cloud |
| Datenhoheit | Das Werk besitzt die Datenbank durchgängig | Anbieter hält die Produktionsdaten | SCADA: Werk; Formulare: Anbieter + Automatisierung |
| Passung der Workflow-Fläche | Schicht-Workflow, Stufenzeiten, Fotonachweis nativ | Stark, aber modellgebunden | SCADA: prozessfokussiert; Formulare: fragil |
| Anpassungstiefe | DSL für Reaktor- / Prozesskonstruktor — Werk fügt Anlagen hinzu | Anbieter-Zyklen + Konfigurationsgrenzen | SCADA: tief; Formulare: oberflächlich |
| Rollenbasierte Zugriffssteuerung | Bediener / Admin / Controller integriert | Stark, erbt aber das RBAC-Modell des Anbieters | SCADA: stark; Formulare: typischerweise schwach |
| Audit-fähiges Archiv | Archiv abgeschlossener Zyklen mit Fotonachweis | Anbieterabhängig; Export-Qualität variiert | SCADA: Historian; Formulare: Tabellenkalkulation |
Stack-Quellen: Laravel-Dokumentation, Android-SQLite-Entwicklerleitfaden, React-Dokumentation.
Der Android-Client ist in Kotlin geschrieben und läuft auf Produktions-Tablets, die beim ersten Start an eine eindeutige Gerätekennung gebunden werden. Eine lokale Authentifizierung ist erforderlich — es wird nicht erwartet, dass das Gerät einen Cloud-Identity-Provider erreichen kann — und jede Bediener-Aktion wird vor jedem Sync-Versuch zuerst in einen lokalen SQLite-Speicher geschrieben. Der Schicht-Workflow führt den Bediener mit einem integrierten Timer durch die Stufen, erfasst Fotonachweise an den vom Audit benötigten Punkten und leitet das Archiv abgeschlossener Zyklen in den On-Premise-Server, sobald eine LAN-Verbindung verfügbar ist. Die UI ist auf dicke Handschuhe, Produktionsbeleuchtung und schnelle Tipp-Eingaben abgestimmt statt auf ein Consumer-Muster eines Smartphones in der Hosentasche.
Ein Hintergrund-Sync-Worker leert die lokale Warteschlange über WebSockets zum On-Premise-Laravel-Server, mit idempotenten Operationen, die über eine vom Client erzeugte ID gekennzeichnet sind, sodass Wiederholungen niemals Arbeit duplizieren. Eine automatische Schichtübergabe überträgt einen laufenden Reaktorzyklus vom Tablet eines Bedieners auf das nächste, ohne den Zustand zu verlieren, und Konflikte werden serverseitig von der Workflow-Engine aufgelöst. Die Bediener-Fläche ist Teil unserer Praxis für Mobile App-Entwicklung, und der Offline-first-Vertrag ist das Herzstück — wenn das Werks-LAN eine halbe Schicht lang ausfällt, geht keine Bediener-Aktion jemals verloren.
Die Web-Fläche hat zwei klar getrennte Personas, jede mit einer eingegrenzten Ansicht, gestützt auf eine rollenbasierte Zugriffssteuerung. Das Admin-Panel — in React gegen ein Laravel-Backend gebaut — erlaubt es Vorgesetzten, Anlagen zu konfigurieren, Checklisten zu bearbeiten, Benutzer und Berechtigungen zu verwalten und Tablets an bestimmte Bediener zu binden. Die DSL für den Reaktor- / Prozesskonstruktor ist hier das Herzstück: Ein Werk fügt einen neuen Reaktor hinzu oder erweitert einen bestehenden Prozessfluss, indem es Checklisten-Vorlagen im Admin-Panel bearbeitet, statt auf einen Engineering-Zyklus zu warten. Neue Anlagen, neue Stufendefinitionen, neue Fotonachweis-Anforderungen landen allesamt über Konfiguration.
Das Controller-Dashboard ist eine Echtzeit-Überwachungsfläche, die den Zustand des Werks über WebSockets streamt — aktuelle Reaktor-Verfügbarkeit, Fehlerzahlen, laufende Schichten, das Wachstum des Archivs abgeschlossener Zyklen — und einen Not-Halt-Knopf bereitstellt, der durch RBAC abgesichert ist, sodass nur ein Benutzer mit Controller-Rolle ihn drücken kann. Das Dashboard läuft in jedem modernen Browser innerhalb des Werks-LAN, was bedeutet, dass der Controller von einer festen Workstation, einem Wartungs-Laptop oder einem wandmontierten Bildschirm über der Produktionslinie überwachen kann. Die gesamte Web-Fläche wird im Rahmen unserer Praxis für individuelle Softwareentwicklung geliefert und ist so strukturiert, dass Werke neue Dashboards (KPI-Export, mobile Vorgesetzten-Ansicht) hinzufügen können, ohne die Datenschicht umzustrukturieren.
CheckLists Architektur wurde um die Einschränkung herum gebaut, dass das Werks-LAN keinen Internet-Ausgang hat. Das Laravel-Backend und die MariaDB-Datenbank werden auf einem einzigen On-Premise-Server innerhalb des Werks-Perimeters bereitgestellt, die React-Admin- und Controller-Dashboards werden von derselben Maschine ausgeliefert, und die Android-Tablets erreichen das Backend über WebSockets im Werks-LAN. Es gibt keinen Drittanbieter-Broker, keine reine Cloud-Telemetrie und keinen Schatten-Analytics-Tracker. Hintergrund-Worker übernehmen Audit-Log-Schreibvorgänge und das Einlesen von Fotonachweisen, und das Archiv abgeschlossener Zyklen wird unbegrenzt aufbewahrt, mit pro Anlage konfigurierbaren Aufbewahrungsrichtlinien.
Die rollenbasierte Zugriffssteuerung sichert jeden API-Endpunkt und jede Dashboard-Route — ein Bediener sieht nur seine Schicht, ein Admin sieht Konfiguration und Benutzerverwaltung, ein Controller sieht die Live-Metriken-Fläche plus die Not-Halt-Steuerung. Die Gerätebindung verknüpft jedes Tablet mit einer eindeutigen Kennung, sodass ein verlorenes Tablet außerhalb der Produktion nicht zweckentfremdet werden kann. Die Aufstellung im Umgang mit Daten ist sowohl für die DSGVO-Pflichten bei Betrieben in der Europäischen Union als auch für die CCPA / CPRA-Pflichten bei Betrieben in Kalifornien und den übrigen Vereinigten Staaten dokumentiert, wobei die Audit-Log-Aufbewahrung pro Anlage konfigurierbar ist, um den lokalen regulatorischen Fristen zu entsprechen. Die Härtungsaufstellung steht im Einklang mit unserer breiteren Cloud & DevOps-Hygiene.
Compliance-Aufstellung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Eine fünfphasige Umsetzung, die CheckList von Papierjournalen zu einem industriellen Ökosystem aus drei Apps brachte, bereitgestellt innerhalb eines isolierten Werksnetzes.
Interviews mit Bedienern und Controllern, Taxonomie der Papierjournale, Modellierung des Schicht-Workflows, Fotonachweis-Anforderungen, Einschränkungen der On-Premise-Bereitstellung, Mapping der DSGVO- und CCPA-Aufstellung.
Auswahl des Laravel + React + Kotlin-Stacks, Design der DSL für den Reaktor- / Prozesskonstruktor, rollenbasierte Zugriffssteuerungsfläche, Schema des Audit-Log-Speichers, Gerätebindungsschema.
Kotlin-Android-Bediener-App mit Offline-first-Synchronisation, Laravel + React-Admin-Panel, Controller-Dashboard mit WebSocket-Streaming, Not-Halt-Steuerung.
Härtung der Fotonachweis-Pipeline, Audit-Log-Aufbewahrungsrichtlinien, RBAC-Testdurchlauf, Konfliktlösungsregeln in der Workflow-Engine, UX-Abstimmung für die Produktion.
Bereitstellung des On-Premise-Servers, Tablet-Provisionierung und Gerätebindung, Bedienerschulung, Passungsprüfungen des Controller-Dashboards, Verifikation des Archivs abgeschlossener Zyklen.
CheckList wurde zunächst innerhalb eines einzelnen Werks bereitgestellt, doch die Architektur ist auf eine Erweiterung über mehrere Anlagen ausgelegt, ohne die Bediener-App oder das Admin-Panel zu ändern. Jede Anlage betreibt ihren eigenen On-Premise-Laravel-Server und ihre eigene MariaDB-Datenbank — das Werks-LAN bleibt der Sicherheitsperimeter — und eine künftige Föderationsschicht kann Archive abgeschlossener Zyklen, KPI-Exporte und BI-Feeds in einen unternehmensweiten Überblick aggregieren, ohne den Offline-first-Vertrag in der Produktion zu brechen. Die DSL für den Reaktor- / Prozesskonstruktor bedeutet, dass eine neue Anlage ihre eigene Anlagenbibliothek, Checklisten und Schicht-Workflows ohne ein Engineering-Ticket konfigurieren kann; das Gerätebindungsschema bedeutet, dass Tablets lokal provisioniert und rotiert werden können; die rollenbasierte Zugriffssteuerungsfläche bedeutet, dass die Rollen Bediener, Admin und Controller anlagenübergreifend identisch funktionieren, selbst wenn die zugrunde liegenden Anlagen variieren. Dieselbe Aufstellung lässt Raum für einen künftigen BI-Exportpfad — Daten aus dem Archiv abgeschlossener Zyklen fließen nur dann aus dem Werks-Perimeter heraus, wenn der Werksbetreiber dies ausdrücklich autorisiert, mit pro Anlage konfigurierten Aufbewahrungsfristen, die dem lokalen Regulierungsregime entsprechen. Werke in den USA und der EU können mit demselben Bereitstellungsrezept laufen und Aufbewahrung, RBAC-Geltungsbereiche und BI-Exportregeln lokal anpassen, ohne die Codebasis zu forken.
CheckList wurde für den Produktions-Rollout in den Vereinigten Staaten und der Europäischen Union gebaut, ohne eine separate Codebasis pro Region. Die englischsprachige UI bedient Bediener und Controller in Kalifornien, New York, Texas, Florida und Washington in den USA sowie Bediener und Controller in den Niederlanden, Deutschland, Frankreich, Irland und Schweden in der EU. Die Praktiken im Umgang mit Daten stehen im Einklang mit der DSGVO für Betriebe in der Europäischen Union und mit dem Flickenteppich der US-Datenschutzgesetze auf Bundesstaatenebene — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA. Da die On-Premise-Bereitstellung die Produktionsdaten innerhalb des Perimeters jeder Anlage hält und die rollenbasierte Zugriffssteuerungsfläche jeden Lese- und Schreibvorgang absichert, reduziert sich die regionale Compliance auf ehrliche Offenlegung und die Konfiguration der Audit-Log-Aufbewahrung statt auf eine Datentrennung pro Jurisdiktion.
Das On-Premise-Bereitstellungsrezept ist über US- und EU-Anlagen hinweg identisch — dasselbe Laravel-Backend, dieselbe MariaDB-Datenbank, dieselbe Kotlin-Android-Bediener-App, dieselben React-Admin- und Controller-Dashboards. Die Aufbewahrungsfristen für das Archiv abgeschlossener Zyklen sind pro Anlage konfigurierbar, um den lokalen regulatorischen Erwartungen zu entsprechen, und der Audit-Log-Speicher ist so strukturiert, dass er die DSGVO-Pflichten im Umgang mit Daten für Nutzer in der Europäischen Union und die kalifornischen CCPA-Pflichten für Anlagen in den USA erfüllt. Das Engineering-Team hinter der Umsetzung sitzt in der MEZ-Zone und arbeitet einen MEZ-Arbeitstag mit Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, Rollout-Choreografie und Incident-Response — die Zeitzone, die es einem US-Werksbetriebsteam und einem EU-Engineering-Team erlaubt, jeden Tag vier Stunden Live-Überlappung zu teilen.
Die aktive Roadmap für individuelle Softwareentwicklung für CheckList umfasst eine Mehr-Werk-Föderationsschicht, die Archive abgeschlossener Zyklen über Anlagen hinweg aggregiert, einen BI-Exportpfad, der bereinigte KPIs in unternehmensweite Data Lakes streamt, eine offline-first Fotonachweis-Pipeline, die lange LAN-Ausfälle an entlegenen Standorten übersteht, und ein gehärtetes On-Premise-Upgrade-Rezept, das es nicht erfordert, ein Werk offline zu nehmen. Ein US-fokussiertes und ein EU-fokussiertes Rollout-Playbook sind geplant, wobei die bestehende rollenbasierte Zugriffssteuerungsfläche bereits so strukturiert ist, dass sie eine anlagenlokale Aufbewahrungskonfiguration unterstützt.
Wenn Sie ein MES für die Fertigung, eine offline-first Produktions-App oder einen beliebigen industriellen Prozesssteuerungs-Build planen, bei dem die Daten für Zielgruppen in den USA und der EU innerhalb des Werks-Perimeters bleiben müssen, haben wir diesen Stack durchgängig ausgeliefert und können die Umsetzungszeit spürbar verkürzen. Das Engineering-Team dahinter sitzt bei YuSMP Group. Wir arbeiten zum Festpreis für gut abgegrenzte MVPs und mit dedizierten Entwicklerteams für die laufende Auslieferung, mit einem MEZ-Arbeitstag und einem garantierten Überlappungsfenster mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und Incident-Response.
Ein Drei-App-MES-MVP, das einen Kotlin-Android-Bediener-Client, ein Laravel + React-Admin-Panel, ein Controller-Dashboard, eine On-Premise-Bereitstellung und Offline-first-Synchronisation umfasst, kostet typischerweise 140.000–320.000 $. Kommen eine DSL für einen Reaktor- und Prozesskonstruktor, eine Mehr-Werk-Föderation, Fotonachweis-Pipelines, ein gehärteter Audit-Log-Speicher und ein BI-Export hinzu, erreicht ein voll ausgestattetes Industrieprodukt 400.000–780.000 $. Die maßgeblichen Kostentreiber sind die Korrektheit der Offline-first-Synchronisation, die On-Premise-Härtungsarbeit und die rollenbasierte Zugriffssteuerung, die ein echtes Werks-Audit überstehen muss.
SaaS-MES-Anbieter setzen voraus, dass das Werk über zuverlässiges Internet verfügt und dass Kundendaten den Perimeter verlassen; beides ist für eine Anlage, die per Design offline arbeitet, ein Ausschlusskriterium. Standard-SCADA ist konfigurierbar, doch die Workflow-Fläche rund um Schichtübergabe, Fotonachweis und ein audit-fähiges Archiv liegt außerhalb seines Kernmodells. Ein generischer Formular-Builder plus Automatisierung näht eine fragile Pipeline zusammen. Eine individuelle Kotlin-Android- plus Laravel- und React-Umsetzung besitzt die Daten, die Bereitstellungstopologie und die Workflow-Fläche durchgängig.
Jede Bediener-Aktion — Stufenstart, Timer-Event, Foto-Upload, Schichtübergabe — wird zuerst in einen lokalen SQLite-Speicher auf dem Gerät geschrieben, unter einer gerätegebundenen Authentifizierungsidentität. Ein Hintergrund-Sync-Worker leert die Warteschlange über WebSockets zum On-Premise-Laravel-Server, sobald das Werks-LAN erreichbar ist, mit idempotenten Operationen, die über eine vom Client erzeugte ID gekennzeichnet sind, sodass Wiederholungen keine Arbeit duplizieren. Konflikte werden serverseitig von der Workflow-Engine aufgelöst, und die Bediener-UI zeigt den zuletzt bekannten guten Zustand an, bis der Server die Annahme bestätigt.
Das System erfasst nur die Bediener- und Prozessdaten, die das Werk tatsächlich benötigt — Bedienerrolle, Schicht, Stufenzeiten, Fotonachweis — und speichert sie auf dem On-Premise-Server innerhalb des Werks-Perimeters. Es gibt keinen Drittanbieter-Broker, keine reine Cloud-Telemetrie und keinen Schatten-Analytics-Tracker. Die rollenbasierte Zugriffssteuerung regelt, wer welche Fotos und welche Schichtarchive sehen darf. Die Aufstellung im Umgang mit Daten ist sowohl für die DSGVO bei Betrieben in der Europäischen Union als auch für CCPA bei Betrieben in Kalifornien dokumentiert, wobei die Aufbewahrung des Audit-Logs pro Anlage konfigurierbar ist.
Ein fokussiertes MVP mit einer Kotlin-Android-Bediener-App, einem Laravel + React-Admin-Panel, einem Controller-Dashboard, einer On-Premise-Bereitstellung und Offline-first-Synchronisation dauert typischerweise 20–32 Wochen Kalenderzeit. Eine DSL für einen Reaktor- und Prozesskonstruktor, eine Mehr-Werk-Föderation, ein BI-Export und ein gehärteter Audit-Log-Speicher fügen weitere 10–16 Wochen hinzu. Der On-Premise-Härtungsdurchgang — Gerätebindung, rollenbasierte Zugriffssteuerung, Audit-Log-Aufbewahrung und die Rollout-Choreografie über Produktionsstätten in den USA und der EU — sollte mit 4–6 Wochen dedizierter Arbeit eingeplant werden.
Verwandte Fälle
Einheitlicher Online-Fensterrechner und CRM — mandantenfähig über drei Markenwebsites, adressbasierte Suche.
Fall ansehen → Mobilität · RidesharingTaxi-Plattform aus drei Apps — Fahrer, Fahrgast, Disponent — mit Echtzeit-GPS und Dokumentenprüfung.
Fall ansehen → Automobilbranche · E-CommerceAutoteile-Marktplatz plus Verkäufer-CRM — VIN-Suche, standortübergreifender Bestand, integrierte Lieferung.
Fall ansehen →
Architektur-zuerst-Enterprise-Plattformen mit audit-fähiger Compliance und Integration zu SAP, Salesforce, Workday, Okta.
Mehr erfahren →
Strangler-Fig-Migration von Legacy-Stacks (.NET Framework, Java 8, Monolith) ohne Rip-and-Replace-Risiko.
Mehr erfahren →
Pragmatische Transformation, die liefert – Cloud-Migration, Legacy-Modernisierung, KI-Integration, Datenplattform.
Mehr erfahren →