300 Fahrer, elf Standorte, eine Excel‑Mappe mit Makros.
Wie aus gewachsenen Tabellen eine Anwendung wurde, die Konditionen historisch korrekt rechnet und an der Rampe auch ohne Netz weiterläuft. Ohne Firmennamen, weil das zwischen dem Betrieb und uns bleibt — mit allen Entscheidungen, auch den unbequemen.
- Branche
- Möbelhandel, Transportlogistik
- Umfang
- rund 300 Fahrer und Partner
- Form
- Webanwendung, mehrere Standorte
- Stand
- im Betrieb, in Stufen gewachsen
Ausgangslage
Die Logistik eines Handelskonzerns wird zu einem großen Teil von Speditionspartnern gefahren. Jeder Partner stellt Fahrzeuge und Fahrer, jeder Standort verhandelt eigene Konditionen, und jeder Fahrer braucht Nachweise: Führerschein, Unterweisung, Schulung, teils Gesundheitsprüfungen. Geführt wurde das in einer Excel‑Mappe, die über Jahre gewachsen war, mit Makros, die niemand mehr vollständig erklären konnte.
Das Problem war nicht Excel. Das Problem war, dass derselbe Sachverhalt an drei Stellen stand und an jeder Stelle anders. Ein Preis, der im Mai geändert wurde, stand in der Mappe für alle Monate. Eine Rückfrage aus der Buchhaltung zu einer Fahrt im März war damit nicht mehr zu beantworten, ohne alte Dateiversionen zu durchsuchen.
Nicht „Excel ersetzen“, sondern: jede Auskunft muss zu dem Zeitpunkt stimmen, auf den sich die Frage bezieht. Alles andere ergab sich daraus.
Drei Entscheidungen, die das Projekt geprägt haben
-
Konditionen werden versioniert, nicht überschrieben
Der naheliegende Weg wäre ein Feld „Preis“ am Partner. Das hätte die erste Prüfungsfrage nicht überlebt. Stattdessen ist jede Kondition ein Datensatz mit Gültigkeitszeitraum, je Standort. Eine Auswertung für März rechnet mit den Sätzen vom März, auch wenn sie im November erstellt wird. Das kostete in der ersten Stufe mehr Arbeit und hat danach jede Diskussion über Zahlen beendet.
-
Die Ampel wird berechnet, nie gespeichert
Ob ein Fahrer einsatzbereit ist, hängt an sechs Regeln: Nachweise vorhanden, nicht abgelaufen, Partner freigegeben, und so weiter. Ein gespeichertes Ampelfeld ist nach dem ersten Tagesübergang falsch, und niemand merkt es. Die Ampel entsteht deshalb bei jeder Anzeige neu aus den Daten. Teurer in der Abfrage, dafür nie gelogen.
-
Der Check‑in funktioniert ohne Netz, oder er ist nutzlos
An der Rampe gibt es Funklöcher, und ein Fahrer wartet nicht, bis ein Tablet wieder online ist. Der Check‑in läuft deshalb als Anwendung im Browser mit eigenem Speicher: Er nimmt Anmeldungen offline an und liefert sie später nach. Wichtiger als das Nachliefern war die Regel, dass dabei nichts doppelt entsteht — jede Anmeldung trägt eine eigene Kennung, und der Server nimmt dieselbe Kennung nur einmal an.
Was dabei schiefgegangen ist
Zwei Fehler sind es wert, aufgeschrieben zu werden, weil sie typisch sind und weil sie in späteren Projekten nicht mehr vorkamen.
Eine Frist mit Zyklus „ein Monat“ war als dreißig Tage gerechnet. Das verschiebt den Termin über das Jahr um mehrere Tage und trifft den 31. Januar überhaupt nicht richtig. Seitdem gilt in allen Projekten: Monate und Jahre werden als Kalenderzeiträume gerechnet, nie in Tagen, und die Fristenrechnung liegt an genau einer Stelle im Code, damit so etwas einmal korrigiert wird und nicht siebenmal.
Der Import der Altdaten hatte einen Trockenlauf, der Formate und Pflichtfelder prüfte — aber nicht jeden Pflichtwert in jeder Zeile. Der erste echte Lauf brach deshalb mitten im Bestand ab. Kein Datenverlust, weil vorher gesichert wird und der Import als Ganzes zurückgenommen werden kann, aber ein verlorener Nachmittag. Heute prüft der Trockenlauf alles, was der echte Lauf prüft, und gibt ein Protokoll je Zeile aus.
Wie das Ergebnis aussieht
- Partner- und Fahrerakten mit Umfirmierungs-Historie: ein Partner, der den Namen wechselt, bleibt derselbe Partner, und alte Belege behalten den alten Namen.
- Konditionen je Standort und Zeitraum, mit Freigabe durch eine zweite Person, bevor eine Änderung gilt.
- Dokumente mit Fristen und eine Liste, die zeigt, wessen Nachweis als nächstes abläuft — nicht als Bericht, den man anfordert, sondern als Startseite.
- QR‑Ausweise und Check‑in am Tablet, offline tauglich, mit Tagesliste für die Pforte.
- Protokoll als verkettete Kette, auf Datenbankebene gegen stilles Ändern gesichert und auch dann vollständig, wenn ein Benutzerkonto gelöscht wird.
Zur Datensparsamkeit gehört auch das Gegenteil von Sammeln: Check‑ins werden nach 24 Monaten automatisch anonymisiert. Die Statistik bleibt, die Person verschwindet daraus.
Was davon in anderen Projekten wiederverwendet wurde
| Baustein | Hier entstanden als | Heute auch in |
|---|---|---|
| Fristenrechnung | Prüfzyklen für Nachweise | Fahrzeug- und Prüffristen, Pflegeleistungen |
| Offline-Erfassung | Check‑in an der Rampe | Leistungsnachweis auf der Baustelle, Pflege-App |
| Verkettetes Protokoll | Nachweis gegenüber der Revision | Mandantenportal, Führerscheinkontrolle |
| Feldmatrix für Rechte | Sichtbarkeit je Standort | alle größeren Anwendungen |
Das ist der eigentliche Grund, warum ein zweites Projekt schneller geht als das erste: nicht weil schneller getippt wird, sondern weil diese Teile keine Forschung mehr sind. Die Bausteine stehen auf der Startseite.
Wenn Ihr Fall ähnlich klingt
Typische Anzeichen: eine Mappe, die nur eine Person pflegen kann, Zahlen, die je nach Quelle abweichen, und die Frage „wie war das im März?“, die regelmäßig Arbeit macht. Schildern Sie das in ein paar Sätzen an kontakt@hubfox.de. Wenn ein fertiges Werkzeug reicht, sagen wir das.
Erzählen Sie, was heute weh tut.
Ein paar Sätze genügen: was gemacht wird, womit es heute gemacht wird und woran es hakt. Sie bekommen eine ehrliche Einschätzung — auch dann, wenn die Antwort lautet: dafür brauchen Sie uns nicht.