Digitale Qualitätsprüfung mit Power Apps in der Präzisionszerspanung

Technisches Grundkonzept und klickbares Mockup

Vor der Umsetzung habe ich ein technisches Grundkonzept geschrieben. Es legt Zielarchitektur, MVP-Umfang, bewusste Ausschlüsse, Rollen, Betriebsmodell sowie Fehler- und Abbruchbehandlung fest und benennt Plattformgrenzen wie Delegation in Power Apps und den Schwellenwert von 5.000 Elementen in SharePoint. Ein Fragenkatalog hat offene Punkte mit der QS geklärt.

Zur fachlichen Abstimmung habe ich ein Tablet-Mockup in HTML, CSS und JavaScript gebaut, das echte JSON-Prüfpläne lädt und Prüfgrund, Merkmalsfilterung, Sortierung und Abweichungserfassung durchspielt. Die Rückmeldungen der QS sind direkt in die App eingeflossen.

• Abgrenzung MVP gegenüber Messmaschinenanbindung, Power BI und CAQ-Funktionen
• Analyse des Q-DAS-Transferformats (DFQ) und Entwurf eines schlanken JSON-Zwischenformats
• Endgeräte- und UI-Strategie auf Basis der vorhandenen Produktionshardware

Responsive Canvas App für die geführte Prüfung

Die Canvas App führt in neun Bildschirmen von der Auswahl über die Merkmalsübersicht und die einzelnen Prüfschritte bis zur Ergebnisübersicht und Prüfungshistorie. Wählt der Werker eine Maschine, lädt die App das gerade dort laufende Bauteil aus dem Maschinenstatus in SQL und schlägt es vor. Das Layout basiert auf Containern mit automatischem Layout und schaltet unter 700 Pixel Breite auf eine Smartphone-Darstellung um.

• Vorauswahl des aktuell gefertigten Bauteils je Maschine aus der Maschinenstatus-View
• Prüfpläne als JSON per Flow laden und mit ParseJSON in lokale Collections überführen
• Automatische OK/NOK-Bewertung bei ein- und beidseitigen Toleranzen, Pflichtangaben bei NOK
• Mehrfachprüfung, wenn je Merkmal mehrere Teile zu prüfen sind
• Zwischenspeichern per Timer und Fortsetzen beim ersten offenen oder unvollständigen Prüfschritt
• Kataloge für 45 Messmittel, 8 Abweichungsursachen und 7 Maßnahmen

Prüfanlässe, Intervalllogik und Werkzeugwechselgruppen

Die Prüf-App unterscheidet Intervall-, Wiederanlauf-, Werkzeugwechsel- und Gruppenwechselprüfungen. Das Prüfintervall wird je Merkmal aus dem Prüfplan gelesen und mit dem Stückzähler der letzten passenden Prüfung verglichen. Ab dem Intervall gilt ein Merkmal als fällig, ab 80 Prozent als demnächst fällig. Beim Werkzeugwechsel werden nur die Merkmale der gewählten Werkzeugpositionen abgefragt, jeweils als Letztteil- und Erstteilprüfung.

• Fälligkeitsbasis je Merkmal statt je Gesamtprüfung
• Abgeschlossene Werkzeugwechsel- und Gruppenprüfungen mit Stückzähler zählen für das Intervall mit
• Sortierung nach Fertigungslogik: Erst-/Letztteil, dann Messmittel in Planreihenfolge, dann Merkmalsnummer

Power Automate Flows für Speicherung, Rollen und Benachrichtigung

Die Geschäftsprozesse im Hintergrund laufen über Cloud Flows mit dem Power-Apps-Trigger (V2). Jeder Flow hat einen eigenen Verarbeitungs- und Fehlerbereich, der fehlgeschlagene Aktionen filtert, eine Fehlermail versendet und der App einen definierten Rückgabecode liefert.

• Prüfergebnis als JSON-Datei anlegen oder aktualisieren und Metadaten setzen
• Rollenermittlung über die Mitgliedschaft in drei Microsoft 365-Gruppen
• QS-Benachrichtigung per HTML-Mail bei NOK, gesteuert über Triggerbedingungen und ein Versandkennzeichen
• Einheitliche Flow-Konfiguration für Umgebung und Mandant als Objektvariable

Produktionslauf abschließen ohne historische Zähler zu ändern

Für einen neuen Fertigungsauftrag sollte der Stückzähler neu beginnen, ohne alte Prüfdaten umzuschreiben. Ich habe das über einen Produktionslauf gelöst: Ein Flow mit 77 Aktionen prüft Pflichtangaben und Berechtigung, sucht die offenen Datensätze der Maschine-Bauteil-Kombination, verlangt genau eine eindeutige Laufkennung und blockiert den Abschluss, solange noch eine Prüfung offen ist. Erst dann wird der Lauf geschlossen und jeder Schritt in einer Protokollliste festgehalten.

• Eigene Rückgabecodes für Erfolg, offene Prüfung, kein offener Lauf, uneindeutiger Lauf, fehlende Berechtigung und technischen Fehler
• Paginierung bis 5.000 Datensätze und parallele Verarbeitung beim Schließen
• Nur für QS und Administration freigegeben

Automatische Archivierung gegen die SharePoint-Schwelle

Mit wachsendem Bestand an Prüfergebnissen näherten sich die Abfragen der Schwelle von 5.000 Elementen. Ich habe dafür einen Archivierungsflow gebaut, der abgeschlossene Prüfungen nach zwei Monaten in eine eigene Archivbibliothek verschiebt. Er läuft sonntags zwischen 0 und 6 Uhr in 10-Minuten-Schritten mit je 50 Dateien und prüft zusätzlich selbst, ob das Zeitfenster aktiv ist.

• Analysemodus, der Kandidaten nur zählt und protokolliert, und Archivmodus
• Protokollstatus STARTED, COMPLETED, COMPLETED-WITH-ERRORS und FAILED mit Stichtag, Mengen und Batchkennung
• Fehler je Datei getrennt von technischen Gesamtfehlern behandelt, Mengenabgleich am Ende

Solutions, Umgebungen und Berechtigungen

Die Prüf-App und alle Flows liegen in einer Lösung mit Verbindungsreferenzen. Zwischen März und Oktober 2026 sind 30 Solution-Versionen entstanden, die als verwaltete Lösungen in Test und Produktion bereitgestellt wurden. Bei der Einführung habe ich gemeinsam mit der IT Run-only-Freigaben, Verbindungen und Flow-Berechtigungen so eingestellt, dass Werker keine Maker- oder Administratorrechte brauchen.

Migrationskonzept für eine gewachsene Produktions-App

Für die bestehende Produktions-App mit Modulen wie Teilesperrung und Ausschuss, Maschinenstatus und OEE, Störmeldung, Schichtübergabe und Gruppenplanung habe ich eine technische Vorprüfung und ein Strategie- und Migrationspapier mit 33 Kapiteln erstellt. Analysiert habe ich die App-Datei mit 26 Bildschirmen, 11 eingebundenen Flows, 7 Dataverse-Tabellen und mehreren SQL-Datenbanken.

Das Papier beschreibt Zielbild, Solution-Strategie, verwaltete und nicht verwaltete Lösungen, Verbindungs-, Identitäts- und Service-Account-Konzept, Umgebungsvariablen, Berechtigungen, Lizenzindikation, Datenlebenszyklus, App-Checker-Befunde, Risikoregister, Test-, Cutover- und Rollback-Konzept. Die Geschäftsführung hat daraufhin das Zielbild mit drei Umgebungen und den manuellen Solution-Transport bestätigt.

Schnittstelle zu Business Central

Aktuell baue ich die Power Automate Flows für eine Schnittstelle zwischen einer Power App und Microsoft Dynamics 365 Business Central. SQL-Anbindung und App-Entwicklung liegen bei der internen IT bzw. Entwicklung des Kunden.