Warum meine Störungsmeldung erst nach der Kaffeepause im System steht

Von /

Eine Maschine steht. Der Werker sieht es sofort. Bis die Meldung im System landet, vergehen oft zwanzig Minuten oder mehr, denn zuerst muss jemand zum zentralen PC laufen, der irgendwo im Büro oder an einer festen Erfassungsstation steht.

In dieser Zeit läuft die Linie weiter falsch, oder sie steht ungenutzt, während niemand reagiert. „Eine Störung, die erst nach Verzögerung gemeldet wird, ist wirtschaftlich fast so teuer wie eine Störung, die gar nicht gemeldet wird.“ Das ist der Kernpunkt, um den es in diesem Beitrag geht.

Software-Häuser, für die wir regelmäßig Access- und SQL-Server-Anbindungen bauen, kennen dieses Muster aus eigenen Produkten zur Störungserfassung: Die Datenbank im Hintergrund ist robust und ausgereift. Das Problem sitzt vorne, am Erfassungsweg.

Zwei Wege, ein Ziel

Wenn die Entscheidung ansteht, mobil zu erfassen, statt am festen PC, bleiben in der Praxis zwei ernsthafte Optionen:

  1. Power Apps aus der Microsoft Power Platform, als schnell aufgesetzte Low-Code-App.
  2. Eine eigene PHP-Anwendung, gehostet auf dem ohnehin vorhandenen Windows Server über IIS, mit Zugriff direkt auf die bestehende SQL-Server-Datenbank.

Beide Wege lösen das gleiche Problem: QR-Code am Auftrag oder an der Maschine scannen, Störung mit wenigen Klicks melden, bei Bedarf ein Foto anhängen. Die Unterschiede liegen woanders, nämlich bei den laufenden Kosten, der Souveränität über die eigenen Daten und, mittlerweile spürbar, bei der KI-Unterstützung während der Entwicklung.

Was Power Apps bei 20 aktiven Nutzern kostet

Sobald eine App auf die eigene SQL-Server-Datenbank statt auf Dataverse zugreift oder ein On-Premises Data Gateway nötig wird, reicht die kostenlose, in Microsoft 365 enthaltene Basisvariante nicht mehr aus. Es wird eine kostenpflichtige Lizenz fällig, sobald SQL Server, Dataverse, Custom Connectors oder On-Premises Gateways genutzt werden.

Der günstigere Einstieg über eine Lizenz pro einzelner App ist für Neukunden inzwischen praktisch keine Option mehr: Microsoft hat den Per-App-Plan im Januar 2026 aus dem Lizenzleitfaden entfernt, sodass er für die meisten Neukunden nicht mehr verfügbar ist. Übrig bleibt im Regelfall der Premium-Plan, mit einem Richtwert von rund 20 Euro pro Nutzer und Monat.

Bei 20 aktiven Nutzern in der Fertigung ergibt das rund 400 Euro im Monat, also knapp 4.800 Euro im Jahr, Jahr für Jahr, ohne dass sich am Funktionsumfang etwas ändert. Diese Kosten laufen weiter, egal ob die App fünfmal am Tag genutzt wird oder fünfzigmal.

Power-Apps-Premium-Plan?

Der Power-Apps-Premium-Plan ist die Lizenzstufe, die eine unbegrenzte Anzahl an Apps pro Nutzer sowie den Zugriff auf Dataverse und Premium-Connectoren wie SQL Server erlaubt.

Was die Eigenentwicklung kostet

Eine PHP-Anwendung auf IIS verursacht keine laufenden Lizenzkosten pro Nutzer. Der Windows Server, auf dem die Access-/SQL-Server-Umgebung ohnehin läuft, kann PHP über das FastCGI-Modul direkt einbinden, das ist in ein bis zwei Stunden eingerichtet und kein Sonderfall, sondern die gleiche Technik, auf der ein Großteil aller WordPress-Installationen weltweit läuft.

Der Aufwand verschiebt sich damit von laufenden Lizenzgebühren zu einem einmaligen Entwicklungsaufwand: QR-Code-Scan über die Kamera-API des Handys, Fotoaufnahme über den Browser, Formular zur Störungsmeldung, Anbindung an die bestehende SQL-Server-Datenbank per Treiber. Danach bleiben im Wesentlichen Hosting, das schon vorhanden ist, und gelegentliche Wartung übrig.

Ab einer gewissen Nutzerzahl kippt die Rechnung fast zwangsläufig zugunsten der Eigenentwicklung, weil Power Apps pro Kopf abrechnet und die Eigenentwicklung pro Funktion.

Der Unterschied, den kaum jemand einpreist: KI-Unterstützung

Hier liegt der Punkt, der sich in den letzten Monaten am stärksten verschoben hat. PHP ist Web-Standard seit über zwanzig Jahren, entsprechend riesig ist das Trainingsmaterial, auf dem KI-Assistenten arbeiten. Ein Prompt wie „PHP-Formular mit QR-Scan und Foto-Upload gegen SQL Server“ liefert brauchbaren, funktionierenden Code, oft im ersten Anlauf.

Power Fx, die Formelsprache hinter Power Apps, ist ein Nischenprodukt im Vergleich. KI-Unterstützung existiert, ist beim Debuggen komplexerer Formeln aber spürbar schwächer, weil schlicht weniger Trainingsdaten vorliegen. Wer heute mit KI-Unterstützung entwickelt, entwickelt in PHP spürbar schneller als in Power Fx.

Bei Web-Standards wie PHP ist die KI der erfahrene Kollege. Bei Power Fx ist sie eher der Praktikant, der mitdenkt, aber nachfragt.

Souveränität und Wartbarkeit

Bei der Eigenentwicklung bleiben die Daten dort, wo sie schon liegen: in der eigenen SQL-Server-Instanz, ohne Umweg über Dataverse oder eine zusätzliche Cloud-Abhängigkeit. Das ist kein Selbstzweck. Es bedeutet, dass eine Lizenzänderung bei Microsoft, wie sie gerade erst mit dem Wegfall des Per-App-Plans passiert ist, den eigenen Betrieb nicht mehr trifft.

Wartbarkeit heißt hier: Ein Standard-Webstack, den jeder Webentwickler kennt, statt einer proprietären Low-Code-Plattform, deren Lizenzmodell und Funktionsumfang sich in den vergangenen Jahren mehrfach verschoben hat.

Was für den Produktionsleiter zählt

Am Ende zählt für die Fertigung eine Zahl: die Zeit zwischen Störung und Reaktion. Läuft die Meldung übers Handy direkt in die bestehende Datenbank, verkürzt sich diese Spanne von teils Stunden auf Minuten, weil kein Weg zum zentralen PC mehr nötig ist und die Meldung sofort dort landet, wo Materialdisposition und Fertigmeldung ohnehin drauf zugreifen.

Die Datenbank bleibt exakt dieselbe. Der Zugang wird mobil, nicht das System dahinter.

Quellen

Autor

Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU im Umgang mit Access- und SQL-Server-Anwendungen. Sein Schwerpunkt liegt auf pragmatischen Frontend-Lösungen um bestehende Datenbanken herum, statt teurer Plattform-Wechsel.

Ähnliche Beiträge

Nach oben scrollen