Zeiterfassungs-App mit Geo-Fencing für Teams mit mehreren Standorten

Zeiterfassung wirkt wie ein gelöstes Problem: Start, Stopp, Summe. Anspruchsvoll wird es in dem Moment, in dem die Erfassung das Büro verlässt. Gebucht wird dort, wo gearbeitet wird – an mehreren, räumlich verteilten Standorten desselben Unternehmens. Und jede Buchung ist kein beiläufiger Log-Eintrag, sondern ein Datensatz, der auch Monate später noch erklärbar sein muss: wer hat wann für welchen Standort erfasst. Damit ist die Frage nach dem Datenmodell beantwortet, bevor der erste Bildschirm entworfen ist.

Der zweite Anspruch war optionales Geo-Fencing – technisch deutlich mehr als eine Punkt-in-Polygon-Prüfung. Eine Ortung liefert nie einen Punkt, sondern einen Punkt mit Genauigkeitsradius. Auf freier Fläche ist dieser Radius klein, zwischen hohen Gebäuden, in Hallen, Tiefgaragen oder Stahlbeton-Umgebungen wächst er erheblich. Wer nahe an der Grenze einer Zone bucht, produziert mit einer naiven Prüfung beides: falsche Ablehnungen und falsche Freigaben. Dazu kommen die Plattformen selbst – iOS und Android behandeln Standort im Hintergrund unterschiedlich, mit eigenen Region-Monitoring-APIs, abgestuften Berechtigungsstufen und Energiespar-Mechanismen, die Hintergrundarbeit gezielt drosseln.

Der dritte Anspruch war das Rollen- und Rechtemodell, und es ist der eigentliche Architektur-Kern. Dieselbe App bedient Mitarbeitende, Manager und Admins mit unterschiedlichen Ansichten, Datenausschnitten und erlaubten Aktionen. Der schwierige Teil ist nicht das Ein- und Ausblenden von Schaltflächen, sondern die Frage dahinter: Welche Datensätze darf eine Rolle überhaupt lesen und schreiben, wenn mehrere verteilte Standorte im Spiel sind und Zuständigkeiten sich überschneiden? Eine Antwort, die nur in der Oberfläche existiert, ist keine Antwort.

Umgesetzt ist die App als eine einzige Flutter-Codebasis für iOS und Android. Die Fachlogik – Buchungen, Schichten, Rollenlogik, Darstellung – existiert damit genau einmal, und beide Plattformen bekommen dieselbe Änderung zur selben Zeit. Plattformspezifisch bleibt vor allem das, was tatsächlich am Betriebssystem hängt: Standortberechtigungen, Verhalten im Hintergrund, Energiesparregeln. Diese Teile sind hinter einer schmalen Schnittstelle gekapselt, sodass der Rest der Anwendung nicht wissen muss, auf welcher Plattform er gerade läuft.

Daten und Authentifizierung liegen in der Google Cloud. Die Identität stammt aus der Authentifizierung, die Rollenzuordnung hängt am Backend – nicht am Gerät und nicht an einer im Client gesetzten Variable. Die serverseitigen Regeln entscheiden pro Anfrage, welche Buchungen, Schichten und Standorte eine Rolle lesen oder ändern darf. Die rollenabhängige Oberfläche ist damit eine Projektion desselben Rechtemodells und nicht dessen Durchsetzung: Was die App einer Rolle nicht zeigt, wäre für sie serverseitig ohnehin nicht abrufbar.

Die Echtzeit-Übersicht über Schichten und Buchungen entsteht aus derselben Datenschicht. Clients hängen an aktualisierten Datenständen, statt in Intervallen nachzufragen – das hält die Ansicht aktuell, ohne dass jede geöffnete App im Minutentakt Anfragen erzeugt. Für eine Führungsrolle bedeutet das eine Übersicht, die sich mitbewegt; für die Architektur bedeutet es, dass die Rechteregeln auch für laufende Abonnements greifen müssen und nicht nur für einzelne Abrufe.

Das Geo-Fencing sitzt als optionale Schicht darüber: Standorte werden definiert, und wo die Option aktiv ist, wird eine Buchung an den passenden Standort gebunden. Optional ist dabei bewusst gewählt und nicht als Kompromiss gemeint – es gibt Einsatzorte, an denen eine zuverlässige Ortung schlicht nicht verfügbar ist. Dass Authentifizierung, Datenhaltung, Echtzeit-Verteilung und Skalierung von verwalteten Cloud-Diensten kommen, ist die Voraussetzung dafür, dass eine Anwendung dieser Größe ohne großen Betriebsapparat entwickelt und dauerhaft gepflegt werden kann: Der Betriebsaufwand bleibt dort, wo er automatisierbar ist.

• Ortsunabhängige Zeiterfassung
• Optionales Geo-Fencing pro Standort
• Rollen & Rechte (Mitarbeitende, Manager, Admins)
• Echtzeit-Übersicht über Schichten & Buchungen
• Eine Codebasis für iOS & Android

Ausgeliefert und beim Kunden in Produktion im Einsatz: eine App statt getrennter Insellösungen, mit rollenbasierten Rechten und Geo-Fencing im produktiven Alltag. Aus Rücksicht auf das Kundenverhältnis nennen wir hier keine internen Kennzahlen – die technische Umsetzung steht für sich.

Bei Vorhaben dieser Art liegt der Aufwand selten dort, wo er vermutet wird. Das Erfassen selbst – starten, stoppen, summieren – ist der kleinste Teil. Entscheidend sind das Rechtemodell und die Randfälle: Was passiert bei einer vergessenen Buchung, wer darf sie nachträglich korrigieren, bleibt die Korrektur sichtbar, wie verhält sich die App bei ungenauer Ortung, und was soll gelten, wenn am Einsatzort gerade keine Verbindung besteht. Diese Fragen gehören vor die erste Zeile Oberflächen-Code, weil sie das Datenmodell prägen. Nachträglich eingezogen, wird jede einzelne von ihnen teuer.

Für die Abwägung zwischen individueller Lösung und Standard-Software ist die nützlichste Frage nicht die nach dem Funktionsumfang, sondern die nach der Struktur: Lassen sich Rollen, Standorte und Freigabewege des Betriebs im Modell des Standardprodukts abbilden? Wenn ja, ist Standard fast immer die günstigere Wahl, und das offen zu sagen gehört zur Beratung dazu. Wenn nein, werden Prozesse dauerhaft an ein Werkzeug angepasst – und dann rechnet sich eine eigene Anwendung, die Rollenlogik, Standortbindung und Auswertungen so abbildet, wie tatsächlich gearbeitet wird.