Eine individuelle Web-App lohnt sich im Handwerk, wenn ein klar begrenzter, häufig wiederkehrender Ablauf mit Papier, Excel oder vorhandener Software dauerhaft umständlich bleibt. Sie sollte kein vollständiges ERP-System nachbauen, sondern einen konkreten Engpass für Baustelle und Büro zuverlässig lösen.
Der beste Ausgangspunkt ist daher nicht die Idee „Wir brauchen eine App“, sondern eine genaue Beschreibung des heutigen Problems: Wer erfasst welche Information, wann wird sie benötigt und wo entstehen Doppelarbeit oder Rückfragen?
Typische Engpässe zwischen Baustelle und Büro
In kleinen und mittleren Handwerksbetrieben liegen Informationen oft an mehreren Stellen. Zeiten werden auf Zetteln notiert, Material ergänzt jemand später in einer Tabelle und Rückfragen laufen über Telefon oder Messenger. Jeder einzelne Schritt wirkt überschaubar, zusammen verursachen sie jedoch Verzögerungen und fehlende Übersicht.
Gute Kandidaten für eine fokussierte Web-App sind beispielsweise:
- mobile Zeiterfassung je Projekt oder Tätigkeit,
- Material- und Tätigkeitsdokumentation,
- Projektstatus und Rückmeldungen von der Baustelle,
- strukturierte Fotos oder Notizen zu einem Auftrag,
- einfache interne Prüf- und Freigabeschritte,
- gezielte Übergabe von Daten an eine bestehende Bürosoftware.
Der Nutzen entsteht, wenn Informationen einmal dort erfasst werden, wo sie entstehen, und anschließend für die zuständigen Personen verfügbar sind.
Wann Standardsoftware die bessere Wahl bleibt
Besitzt ein Betrieb bereits eine etablierte Software, die den Ablauf gut unterstützt, ist eine weitere Anwendung meist unnötig. Oft genügen Konfiguration, Schulung oder eine vorhandene Zusatzfunktion. Auch eine Schnittstelle kann sinnvoller sein als ein neues System.
Vor einer Individualentwicklung sollten deshalb drei Möglichkeiten geprüft werden:
- Kann die vorhandene Software den Prozess bereits abbilden?
- Gibt es eine passende Standardlösung mit vertretbarer Anpassung?
- Bleibt danach ein betrieblicher Kern, der wirklich individuell ist?
Erst wenn die dritte Frage klar beantwortet werden kann, entsteht eine belastbare Grundlage für eigene Entwicklung.
Mobile Bedienung ist Teil des Fachkonzepts
Eine Anwendung auf der Baustelle muss anders funktionieren als eine Verwaltungsoberfläche im Büro. Eingaben sollten kurz sein, zentrale Schaltflächen gut erreichbar und die nächsten Schritte ohne lange Schulung verständlich bleiben. Auch Lichtverhältnisse, Arbeitshandschuhe, kleine Displays und Unterbrechungen im Arbeitsablauf beeinflussen die Gestaltung.
Ebenso wichtig ist die Netzsituation. Eine responsive Web-App funktioniert grundsätzlich auf Smartphones, benötigt aber normalerweise eine Verbindung. Wenn wichtige Eingaben auch ohne Netz möglich sein müssen, gehört das als eigene Anforderung in die Konzeption. Offline-Funktionalität sollte nicht erst nachträglich als vermeintlich kleine Ergänzung auftauchen.
Beispiel: Projektzeiten
Die Web-App Projektzeiten wurde als schlanke Lösung für mobile Projektzeiterfassung konzipiert. Mitarbeitende erfassen Zeiten direkt am Projekt, während Büro und Verantwortliche Auswertungen nach Projekt, Rolle und Tätigkeit erhalten.
Der klare Kern ist entscheidend: Die erste Aufgabe lautet nicht, sämtliche Unternehmensprozesse in einer Anwendung zusammenzuführen. Sie lautet, projektbezogene Zeiten verständlich zu erfassen und auswertbar zu machen. Ergänzungen können anschließend dort entstehen, wo sie in der Praxis einen belegbaren Nutzen besitzen.
Schnittstellen gezielt statt pauschal planen
Eine Verbindung zu Büro- oder Rechnungssystemen wie Open3A kann projektbezogen geprüft werden. Dafür muss zunächst feststehen, welche Daten in welche Richtung fließen sollen, welches System führend bleibt und wie Fehler behandelt werden.
Eine klar begrenzte Übergabe kann viel manuelle Arbeit sparen. Eine vollständige Synchronisation aller Daten ist dagegen nicht automatisch besser: Sie erhöht Abhängigkeiten, Testaufwand und die Zahl möglicher Fehlerfälle. Die Schnittstelle sollte so klein wie möglich und so vollständig wie nötig geplant werden.
Mit einem nutzbaren Kern starten
Eine erste Version sollte klein sein, aber einen Ablauf vollständig abdecken. Ein halbfertiges System mit vielen begonnenen Funktionen hilft im Alltag weniger als ein sauber gelöster Kernprozess.
Ein pragmatischer Start umfasst:
- den heutigen Ablauf und seine Engpässe dokumentieren,
- Nutzergruppen und benötigte Rechte klären,
- Pflichtdaten von optionalen Informationen trennen,
- den wichtigsten mobilen Ablauf als Prototyp prüfen,
- eine erste nutzbare Version im realen Betrieb testen,
- Erweiterungen anhand konkreter Rückmeldungen priorisieren.
So wird nicht auf Vermutungen hin entwickelt. Mitarbeitende können früh zeigen, welche Schritte funktionieren und wo die Oberfläche noch nicht zum Arbeitsalltag passt.
Der Nutzen muss den Betrieb erreichen
Eine individuelle Web-App ist dann erfolgreich, wenn sie weniger Rückfragen, schnellere Verfügbarkeit von Informationen oder verlässlichere Auswertungen ermöglicht. Technische Besonderheit allein ist kein Ziel.
Weitere Anwendungsfälle und der Ablauf einer solchen Konzeption stehen unter digitale Lösungen für Unternehmen. Wer bereits einen konkreten Medienbruch oder wiederkehrenden Engpass benennen kann, kann ihn in einer Projektanfrage beschreiben.
