Leistungen
Web-App-Entwicklung für betriebliche Abläufe
Eine Web-App ist keine Website mit Login. Sie ist eine Arbeitsanwendung: Nutzer haben Rollen, Vorgänge besitzen Zustände, Fachregeln erlauben oder verhindern Aktionen und bestehende Systeme liefern oder erhalten Daten.
WIRKLAUF entwickelt Web-Anwendungen für betriebliche Abläufe, wenn Browserzugang die passende Form ist — und prüft ebenso, wann PWA, mobile App oder eine vorhandene Funktion sinnvoller wäre.
Web-App ist nicht Website
Eine Marketingseite informiert. Eine Web-App führt Arbeit aus.
Typische betriebliche Aufgaben:
- Aufträge disponieren;
- Fälle prüfen und freigeben;
- Service dokumentieren;
- Daten erfassen und validieren;
- Status sichtbar machen;
- externe Nutzer über ein Portal einbinden;
- Fachlogik zwischen mehreren Systemen abbilden.
Der Qualitätsmaßstab ist nicht, wie „appig“ die Oberfläche aussieht. Sondern ob der Nutzer den Prozess sicher und nachvollziehbar bearbeiten kann.
Wann Web häufig gewinnt
Eine responsive Web-App ist oft sinnvoll, wenn:
- mehrere Nutzergruppen zentral zugreifen;
- Desktop und mobile Browser relevant sind;
- Updates zentral ausgerollt werden sollen;
- Geschäftslogik serverseitig gepflegt wird;
- App-Store-Verteilung keinen eigenen Nutzen hat;
- die Anwendung eng mit ERP/CRM/APIs zusammenarbeitet.
Das ist ein Muster, keine Universalregel.
Wann Mobile oder PWA gewinnt
Eine native oder plattformübergreifende App kann besser passen, wenn tiefe Gerätefunktionen, robuste Offline-Nutzung, Push, Scanner/Kamera/GPS oder App-Distribution entscheidend sind.
Eine PWA kann zwischen beiden Welten liegen, wenn installierbares Web-Erlebnis und begrenzte Offline- oder Gerätefunktionen genügen.
Fachlogik vor Oberfläche
Ein Button „Abschließen“ ist einfach. Die Frage ist, wann Abschluss fachlich zulässig ist.
Im Demonstrator darf ein Auftrag nur abgeschlossen werden, wenn:
- der Nutzer berechtigt ist;
- die Pflichtdokumentation vollständig ist;
- kein offener Klärfall besteht;
- der fachliche Status den Übergang erlaubt.
Wenn eine Regel verletzt ist, muss die Oberfläche nicht nur „Fehler“ sagen, sondern den korrekten nächsten Schritt erklären.
Fachobjekte tragen die Anwendung
Die betriebliche Anwendung modelliert reale Objekte:
- KUNDE
- ANFRAGE
- AUFTRAG
- ZUWEISUNG
- DOKUMENTATION
- KLÄRFALL / SYNCHRONISATION / VERLAUF
Das verhindert, dass die Software zu einer zufälligen Sammlung von Formularen wird.
Rollen und Berechtigungen
- Disposition
- strukturiert und weist zu.
- Techniker
- bearbeitet eigene Aufträge.
- Fachliche Leitung
- entscheidet fachliche Sonderfälle.
- Administration
- verwaltet technische Einstellungen, darf aber nicht automatisch fachliche Entscheidungen überschreiben.
Rechte folgen Verantwortung.
Zustände sind Fachlogik
Mit bewussten Abzweigungen wie WARTET oder KLÄRUNG NÖTIG.
Gleichzeitig kann die ERP-Integration Wiederholversuch ausstehend sein. Fachlicher und technischer Zustand werden getrennt, damit ein API-Fehler nicht den tatsächlichen Arbeitsstatus verfälscht.
- PLANUNG
- ZUGEWIESEN
- IN BEARBEITUNG
- ABSCHLUSSBEREIT
- ABGESCHLOSSEN
Bestehende Systeme einbetten
Web-App, ERP und CRM müssen nicht um dieselben Daten konkurrieren.
Für jedes Objekt wird definiert, welches System führend ist. Die Web-App kann operative Zustände besitzen, während das ERP kaufmännische Aufträge und Rechnungsdaten führt.
Integration ist damit Teil der Architektur, keine später angeklebte Funktion.
Demonstrator: echte Arbeitszustände
- Arbeitsliste
Mitarbeiter sehen offene Aufträge, Status, Verantwortlichkeit und nächste Aktion.
- Auftragsdetail
Relevante Fachinformationen, Zuweisung, Dokumentation und Verlauf — keine Fantasie-Kennzahlen.
- Mobile Technikeransicht
Auf dem Smartphone nur das, was für den konkreten Auftrag nötig ist.
- Prüfung
Abschluss wird blockiert, weil Pflichtdokumentation fehlt.
- Verlauf
Wer hat wann zugewiesen, begonnen, dokumentiert, Klärfall erzeugt oder abgeschlossen?
- Technischer Fehler
ERP-Synchronisierung schlägt fehl und geht kontrolliert in Wiederholversuch, ohne den fachlichen Abschluss zurückzusetzen.
Arbeitsliste · 1 Auftrag
A-1042
Technischer Service
In Bearbeitung
Zuständigkeit
Techniker
Zuweisung aktiv seit 09:48
Auftrag A-1042 · Beispielbetrieb
Prüfung und Wiederinbetriebnahme einer Anlage
Zeitfenster
Heute · 10:00–12:00
Fachlicher Status
In Bearbeitung
Integrationsstatus
Keine offene Integration
Auftrag in Bearbeitung
Nächste zulässige Aktion: Dokumentation vervollständigen
- Arbeitszusammenfassungoffen
- Ergebnisoffen
- Sicherheitsprüfungbestätigt
- Funktionsprüfungoffen
- Abschlussoffen
Historie
- 09:41FachlichAuftrag aus ERP übernommenBüro / Disposition
- 09:48FachlichTechniker zugewiesenBüro / Disposition
- 10:07FachlichBearbeitung gestartetTechniker
- 11:18PrüfungAbschluss versucht – Pflichtprüfung offenTechniker
- 11:26FachlichDokumentation vervollständigtTechniker
- 11:27TechnischERP-Rückmeldung fehlgeschlagenIntegration
- 11:29TechnischWiederholversuch erfolgreichIntegration
Technikeransicht · A-1042
Auftrag in Bearbeitung
Auftragskopf
A-1042
Nächster Schritt
Pflichtprüfung
Funktionsprüfung
Dokumentation
Abschluss
Sicherheit und Datenschutz
Zugriff, Rollen, sensible Daten und Nachvollziehbarkeit werden aus dem konkreten Risiko abgeleitet. Dazu gehören je nach Projekt Authentifizierung, Autorisierung, Sitzungs- und Token-Verwaltung, Verschlüsselung, Rechte auf Datenobjekte, Grenzen der Protokollierung und technische Schutzmaßnahmen.
Keine pauschalen „100 % sicher“- oder „DSGVO-konform“-Versprechen ohne konkreten Umfang und Prüfung.
Änderungen bleiben nachvollziehbar
In betrieblichen Anwendungen ist oft wichtig, nicht nur den aktuellen Wert, sondern die Entscheidungsgeschichte zu verstehen:
- wer hat geändert?
- wann?
- von welchem Zustand zu welchem?
- warum entstand ein Klärfall?
- welche Synchronisierung scheiterte?
Änderungsverlauf ist dann eine Fachfunktion, nicht nur ein Entwicklerprotokoll.
Datenmigration
Wenn bestehende Listen oder Systeme ersetzt/ergänzt werden, muss geklärt werden:
- welche historischen Daten nötig sind;
- welche Qualität sie besitzen;
- wie IDs/Beziehungen gemappt werden;
- was bewusst nicht migriert wird.
Mehr historische Daten sind nicht automatisch besser.
Tests und Einführung
Tests decken Normalfall, Randfälle, fehlende/ungültige Daten, Berechtigungen, fachliche Ausnahmen, API-Ausfall, Dubletten und Wiederherstellung ab.
Vor Einführung folgt Abnahmetest mit den tatsächlichen Nutzerrollen. Die Anwendung wird nicht nur vom Entwickler „durchgeklickt“.
Betrieb & Weiterentwicklung
Nach Go-live ändern sich Anforderungen, Browser, Schnittstellen und Regeln. Betriebsüberwachung, Fehlerbehebung, Updates und kontrollierte Weiterentwicklung gehören deshalb zum Produktleben.
Kostenlogik
Aufwand entsteht durch Fachlogik, Rollen, Integrationen, Daten, Migration, Mobile/Offline, Sicherheit, Tests, Einführung und Betrieb. Eine einfache Übersicht kann schnell gebaut sein; eine unsichtbare Fachregel kann trotzdem kritisch sein.
FAQ
Web-App oder Website?
Wenn Nutzer darin Arbeit ausführen, Daten bearbeiten und Fachlogik durchlaufen, handelt es sich um eine Anwendung. Eine Website informiert primär.
Muss eine Web-App mobil funktionieren?
Nutzung auf unterschiedlichen Bildschirmgrößen ist häufig sinnvoll. Ob eine native mobile App zusätzlich nötig ist, hängt von der Nutzungssituation ab.
Brauchen wir eine eigene Datenbank?
Nicht zwingend. Die Architektur hängt davon ab, welche Daten die Anwendung selbst besitzt und welche aus Bestandssystemen kommen.
Kann sie an ERP/CRM angebunden werden?
Wenn technisch zugänglich und fachlich sinnvoll. Datenhoheit und Fehlerpfad werden vorher geklärt.
Was kostet eine Web-App?
Erst belastbar, wenn Fachlogik, Nutzer, Integrationen und Umfang ausreichend klar sind.
Web-App besprechen
Bitte nennen Sie:
- Nutzergruppen;
- heutigen Ablauf/Tools;
- wichtigste Fachlogik;
- beteiligte Systeme;
- mobile und Offline-Anforderungen;
- wie klar der Lösungsweg bereits ist.
- hallo@wirklauf.com
- Telefon
- 05921 8198432