Digitale Kolonnen-Zeiterfassung: Warum wir Software lieber sauber bauen als rumzutricksen

Wenn es um neue Software für den Bauhof geht, schauen alle erst mal auf die Oberfläche: Aufträge anlegen, Zeiten stempeln, Material eintragen. Sieht alles schick aus. Aber ob eine App im echten Leben – bei Regen, Stress und Personalmangel – wirklich was taugt, entscheidet sich unter der Haube. Im Maschinenraum.

Ein kommunaler Bauhof ist kein Labor. Leute werden krank, Vorarbeiter müssen improvisieren. Eine Kolonne rückt aus, aber nicht jeder hat ein Smartphone in der Latzhose. Und wenn die Truppe arbeitet, darf sich nicht versehentlich einer allein in den Feierabend stempeln, während für den Rest die Uhr unsichtbar weiterläuft.

Wir hatten bei BauhofOS keine Lust auf wackelige Workarounds, die beim ersten Monatsabschluss zusammenbrechen. Also haben wir unser Modul für die Kolonnen-Zeiterfassung so gebaut, dass es hält: Für die Leute draußen, die Dispo im Büro – und für den Kämmerer bei der Prüfung.

Ein Auftrag ist kein Mülleimer

Unser Modul für Arbeitsaufträge ist kein Ort, wo man einfach alle Daten auf einen Haufen wirft. Es hält die Fäden zusammen: Was ist zu tun? Wo? Auf welche Kostenstelle geht das? Wer fährt mit raus?

Wichtig ist dabei: Personalzeiten, Fahrzeuge und Material bleiben in der Datenbank streng getrennt. Der Auftrag bündelt sie für die Ansicht, aber er verbiegt die Daten nicht.

Das klingt nach trockener IT, spart im Alltag aber richtig Nerven. Die Software bleibt schnell, die Zuständigkeiten sind glasklar und der FiBu-Export am Monatsende wird nicht zum Ratespiel.

Die „Fernbedienung“: Ein Klick draußen, echte Einzelbuchungen drinnen

Der wichtigste Punkt bei unserer Kolonnen-Logik: Wenn der Vorarbeiter in der App auf „Kolonne starten“ drückt, schreiben wir nicht einfach plump „Kolonne X arbeitet jetzt 4 Stunden“ in die Datenbank.

Stattdessen erzeugt das System im Hintergrund für jeden Mitarbeiter und jedes Fahrzeug eine eigene, echte Buchungszeile.

Warum machen wir das so genau? Weil die Realität das fordert. Die Lohnbuchhaltung und die Revision müssen am Ende lückenlos wissen:

• Wer war wirklich dabei?
• Wessen Zeitkonto wird belastet?
• Wer ist als Ersatzkraft ad hoc mitgefahren?
• Welche Maschine lief auf welcher Baustelle?

Die Kolonne ist bei uns also kein Sammelkonto. Sie ist eine Fernbedienung. Der Vorarbeiter drückt einen Knopf, und das System erledigt die saubere Einzelbuchung für die exakte, aktuelle Besetzung. Draußen bleibt es simpel (ein Klick). Drinnen in der Verwaltung ist es zu 100 % wasserdicht.

Das Einsatz-Protokoll: Warum Historie nicht verfälscht werden darf

Der einfachste Weg beim Programmieren wäre gewesen: Wir verknüpfen eine Zeitbuchung einfach mit dem Namen der Kolonne. Das rächt sich aber spätestens nach zwei Wochen.

Was passiert, wenn die Kolonne nächste Woche von „Winterdienst Nord“ in „Bereitschaft Nord“ umbenannt wird? Oder wenn ein Kollege das Team dauerhaft verlässt?

Wenn die Historie an veränderlichen Stammdaten hängt, verfälscht man alte Einsätze rückwirkend, ohne es zu merken. Für eine Kommune ist das ein No-Go.

Deshalb frieren wir den Zustand beim Start ein (wir nennen das intern SquadRun). Wir speichern knallhart ab: Welcher Auftrag lief? Welcher Kolonnen-Name galt exakt in dieser Sekunde? Wer und was war genau zu diesem Zeitpunkt dabei?

Ändern sich morgen die Stammdaten im System, bleiben die alten Buchungen davon völlig unberührt. Genau so muss das im öffentlichen Dienst laufen.

Revisionssicherheit ist eine Entscheidung im Code

Viele Software-Anbieter schreiben „revisionssicher“ auf ihre Flyer. In der Realität heißt das oft nur: Sie haben den Löschen-Button in der Benutzeroberfläche versteckt.

Das reicht nicht. Revisionssicherheit beginnt tief in der Datenbank, wenn man sich bewusst gegen bequeme, aber wackelige Lösungen entscheidet. Das sieht man auf dem Bildschirm vielleicht nicht sofort.

Aber bei der Rechnungsprüfung in einem Jahr sind Sie froh, dass das System gerichtsfest weiß, wer mit welchem Fahrzeug vor Ort war.

Ad-hoc-Tätigkeiten: Wir blockieren niemanden, wenn das Büro etwas vergisst

Noch ein typischer Praxisfall: Ein Auftrag ist angelegt, aber das Büro hat vergessen, die genaue Tätigkeit (z.B. Grünpflege) einzutragen. Ein Wasserrohrbruch wartet aber nicht auf die Dateneingabe.

Schlechte Software blockiert den Vorarbeiter dann mit einer Fehlermeldung: „Bitte erst Tätigkeit im Büro nachtragen.“ Das mag in einem Prozesshandbuch gut aussehen, ist morgens um 6:00 Uhr auf dem Hof aber völliger Quatsch.

Bei BauhofOS kann der Vorarbeiter die fehlende Tätigkeit direkt beim Start auf dem Smartphone ergänzen. Wir wollen die Leute draußen nicht ausbremsen.

Gleichzeitig braucht die FiBu eine saubere Kontierung. Also lassen wir den Vorarbeiter entscheiden und der Einsatz kann starten. Handfest und praxistauglich.

Schutz vor Geisterstunden: Warum es keinen schnellen Solo-Stopp gibt

Das Beenden von Einsätzen ist heikel. Wer alleine arbeitet, drückt auf Stopp und hat Feierabend. In einer Kolonne ist das gefährlich.

Wenn da jemand einfach auf dem Handy auf „Beenden“ drückt, ist er selbst zwar ausgestempelt, aber für den Rest der Truppe läuft die Uhr technisch weiter. Niemand merkt es sofort, und am Ende hat man unerklärliche Geisterstunden im System, die später mühsam korrigiert werden müssen.

Um das zu verhindern, haben wir eine harte Grenze eingebaut:

• Wer alleine arbeitet, darf direkt auf dem Dashboard stoppen.
• Wer Teil einer aktiven Kolonne ist, bekommt keinen direkten Stopp-Button.
• Er wird stattdessen zwingend in das Einsatz-Cockpit geleitet.

Das heißt aber nicht, dass wir die Flexibilität einschränken – im Gegenteil.
Im Cockpit sieht der Vorarbeiter den exakten Team-Kontext. Hier hat er die volle, bewusste Kontrolle: Er kann den Einsatz für die komplette Truppe beenden. Oder – typischer Bauhof-Alltag – er stempelt nur den Kollegen Müller um 14:00 Uhr vorzeitig aus, weil der zum Arzt muss oder krankheitsbedingt abbricht, während die restliche Mannschaft nahtlos weiterarbeitet.

Das ist eine bewusste Hürde in der Bedienung. Wir wollen keine gefährlichen Schnellklicks erlauben. Das Richtige (präzise Steuerung) soll einfach sein, das Falsche (Geisterstunden) technisch unmöglich.

Klartext schafft Vertrauen

Wir glauben nicht daran, dass Verwaltungssoftware durch noch mehr Buzzwords auf bunten Werbebannern besser wird. Sie wird besser, wenn sie unter Druck fehlerfrei funktioniert und die Daten sauber bleiben.

Deshalb reden wir so offen über unsere Architektur. Wer im Regen arbeitet, will wissen: „Lässt mich die App im Stich?“ Wer im Büro steuert, will wissen: „Landen die Daten sauber in der FiBu?“ Und wer Verantwortung trägt, muss wissen: „Ist das System GoBD- und DSGVO-konform?“

Das müssen Sie uns nicht einfach glauben. Das können Sie an unserer Systemarchitektur sehen.