Software, die auch bei zwei Balken weiterarbeitet

Der problematischste Zustand ist nicht die fehlende Verbindung, sondern die schlechte. Eine Anwendung, die auf eine Antwort wartet, die nie kommt, blockiert die Bedienung und wirkt defekt. Nutzer schließen sie, starten neu und verlieren dabei die Eingabe.

Wir entwerfen deshalb von vornherein für den unzuverlässigen Fall. Eingaben werden lokal festgeschrieben, bevor überhaupt ein Sendeversuch startet, und die Oberfläche wartet nie darauf. Die Verbindung wird zum Hintergrundvorgang statt zur Voraussetzung der Bedienung.

Sobald mehrere Personen offline arbeiten, entstehen widersprüchliche Stände. Die technische Antwort darauf ist nicht Vermeidung, sondern eine fachlich sinnvolle Regel je Datenart. Bei einer Zeitbuchung sind zwei Einträge oft beide richtig; bei einem Auftragsstatus kann nur einer gelten.

Diese Regeln legen wir in der Analysephase gemeinsam fest und schreiben sie fachlich verständlich auf. Nicht automatisch entscheidbare Fälle landen in einer Klärungsliste, statt still überschrieben zu werden. Die Liste bleibt in der Praxis kurz – aber sie muss existieren.

Der gesamte Datenbestand hat auf einem Mobilgerät nichts zu suchen: zu groß, schnell veraltet und bei Geräteverlust ein unnötiges Risiko. Zu wenig lokale Daten machen die Anwendung offline nutzlos.

Wir grenzen deshalb bewusst ab, meist über einen Zeitraum und eine Zuständigkeit – etwa die eigenen Aufträge der kommenden zwei Wochen samt zugehöriger Stammdaten. Was darüber hinausgeht, ist nur mit Verbindung erreichbar. Der lokale Bestand wird verschlüsselt abgelegt und lässt sich aus der Ferne löschen.

Bei Entfernungen von 25 bis 40 km sind kurzfristige Vor-Ort-Termine unwirtschaftlich. Der Regelfall ist deshalb der Fernzugriff: Abstimmung über Bildschirmfreigabe, Bereitstellung neuer Versionen automatisiert, Störungsanalyse anhand von Protokolldaten.

Damit das funktioniert, muss die Anwendung von Anfang an aussagekräftige Protokolle schreiben. Eine Fehlermeldung, die nur „Fehler beim Speichern" lautet, zwingt zur Anfahrt. Eine Meldung mit Vorgangsnummer, Zeitpunkt und Ursache lässt sich vom Schreibtisch aus klären. Präsenz planen wir für Prozessaufnahme und Einweisung mit Vorlauf.

Offlinefähigkeit kostet Entwicklungsaufwand, meist ein Drittel mehr als eine reine Onlineanwendung, und sie macht die Wartung anspruchsvoller. Wenn die betroffenen Nutzer überwiegend an festen Arbeitsplätzen mit stabiler Anbindung sitzen, raten wir davon ab.

Sinnvoll ist ein Mittelweg, wenn nur ein Teil der Belegschaft im Außeneinsatz ist: Die Büroanwendung bleibt online, und für den mobilen Einsatz entsteht ein bewusst schmaler offlinefähiger Teil mit wenigen Funktionen. Das ist deutlich günstiger, als die gesamte Anwendung offlinetauglich zu bauen.