Spedition: Dokumenten-Plattform als isolierter App-Kreis — rechtssicher, mobil, ohne Hauptsystem-Zugriff
Eine mittelständische DACH-Spedition wollte rechtliche Dokumente, interne Anweisungen, Wartungstermine und Mitarbeiter-Zertifizierungen sauber zwischen Fahrern, Dispo, Werkstatt und Verwaltung verwalten. Statt das Kernsystem zu erweitern, wurde eine eigene App-Plattform mit ca. 100 Geräten gebaut — abgesicherte Schnittstellen, klarer User-Kreis, niedrige laufende Kosten.
- Branche
- Logistik / Spedition (DACH-Mittelstand)
- Größe
- Mittelständische Spedition · DACH · ca. 100 Geräte im Einsatz
- Auslöser
- Manuelle Verwaltung rechtlicher Dokumente, interner Anweisungen und Fristen — verteilt zwischen Fahrern, Dispo, Werkstatt und Verwaltung
Ausgangslage
Eine mittelständische DACH-Spedition wickelt jeden Tag eine wachsende Menge rechtlicher und organisatorischer Dokumente ab — verteilt über vier Rollen: Fahrer, Dispo, Werkstatt und Verwaltung.
In der Praxis lief vieles über Papier, Foto-Mails und ad-hoc-Listen:
- Welche Fahrer-Zertifizierungen laufen wann ab? (Modul 95, ADR, Stapler)
- Wann muss Fahrzeug X zur Hauptuntersuchung oder zur Werkstatt?
- Welche internen Anweisungen wurden vom Fahrer gelesen und quittiert?
- Welche Pre-Trip-Checks wurden durchgeführt — und sind sie audit-fähig dokumentiert?
- Welche Wartungs-Protokolle sind nach dem Werkstatt-Termin im System?
Jede dieser Übergaben war fehleranfällig — und rechtlich heikel. Eine verpasste Frist, ein fehlendes Quittierungs-Dokument oder ein nicht auffindbares Zertifikat sind keine kosmetischen Probleme, sondern echte Compliance-Risiken.
4
beteiligte Rollen
Fahrer, Dispo, Werkstatt, Verwaltung
~100
Geräte im Einsatz
LKW-Tablets + Fahrer-Devices + Web
04/2026
Mandat gestartet
Pilot live, Roll-out laufend
Engpass-Diagnose
Bevor gebaut wurde, stand eine Architektur-Frage: Erweitern wir das bestehende Kernsystem — oder bauen wir einen eigenen, isolierten Kreis?
Drei harte Gründe sprachen gegen eine Erweiterung des Kernsystems:
Sicherheits-Perimeter wäre zu groß. Fahrer und externe Werkstätten bekämen Zugriff auf das eigentliche TMS — eine Angriffsfläche, die für die eigentliche Aufgabe nicht gebraucht wird.
Wartungs-Schulden wachsen mit jedem Mobile-Feature. Jede Funktion fürs Tablet wird im Kernsystem zu einem Lebens-langen Pflegefall — und macht das Hauptsystem fragiler, nicht stärker.
Keine Plattform für sichere Automatisierung. Wenn man später Workflow-Automatisierungen, automatische Fristen-Erinnerungen oder KI-gestütztes Document-Parsing einführen will, ist das im Kernsystem ein Risiko — in einem isolierten Kreis nicht.
Architektur-Entscheidung
Der gewählte Schnitt: dedizierte App-Plattform als isolierter User-Kreis, mit eng definierten, automatisierten Schnittstellen zum Kernsystem.
Was die Plattform aktuell abdeckt
| Bereich | Inhalt |
|---|---|
| Rechtliche Dokumente | Führerschein, Modul-95-Schulungen, ADR-Berechtigungen, Fahrzeug-Zulassungen |
| Interne Anweisungen | Sicherheits-Briefings, Pflicht-Quittierungen, Updates der Fahrer-Handbücher |
| Wartungs- und Prüf-Termine | TÜV / Hauptuntersuchung, Werkstatt-Termine, Service-Intervalle, ADR-Tankprüfungen |
| Mitarbeiter-Zertifizierungen | Wiederkehrende Schulungen, Re-Zertifizierungen, Ablauf-Erinnerungen |
| Tablet-Quittierungen | Pre-Trip-Checks, Übernahme-Bestätigungen, fahrzeugbezogene Pflicht-Routinen |
| Werkstatt-Upload | Wartungs-Protokolle, Reparatur-Berichte, Foto-Dokumentation |
Was bewusst ausgeklammert ist
- Frachtpapiere und Tour-bezogene Auftragsdaten. Bleiben (vorerst) ausschließlich im TMS — der App-Kreis berührt das Tagesgeschäft des Auftrags-Managements nicht.
- Buchhaltung und Tarif-Kalkulation — bleiben im Kernsystem.
- Direkter Zugriff auf TMS-Stammdaten — läuft ausschließlich über die kuratierte API-Brücke.
Geplante Erweiterung — externe Fahrer als Vorfeld-System
Mittelfristig sollen externe Fahrer über dieselbe Plattform eingebunden werden, ohne Zugriff auf interne Firmendaten zu erhalten. Die isolierte Architektur ist genau dafür konzipiert: externe Nutzer bekommen einen separaten User-Kreis mit eingeschränkten Rechten — die internen TMS-Daten bleiben hinter der API-Brücke unsichtbar.
Tech-Stack
| Schicht | Technologie | Begründung |
|---|---|---|
| Frontend Web (Dispo, Verwaltung, Werkstatt) | Next.js | App-Router, RSC, Vercel-Hosting, schnelle Iteration |
| Mobile (Fahrer, LKW-Tablet) | React Native | Code-Sharing mit Web, Offline-First |
| Datenbank, Auth, Storage | Supabase | Postgres + Row-Level-Security, Realtime, einfache Auditierbarkeit |
| API-Brücke zum Kernsystem | dedizierte Schnittstellen | abgesichert, automatisiert, eng kuratiert |
| Workflow-Automatisierung (geplant) | n8n | Self-hosted, breites Connector-Ökosystem, gut wartbar |
Architektur-Prinzipien
Isolierter User-Kreis statt Kernsystem-Erweiterung
Externe und mobile Nutzer bekommen keinen Touchpoint zum TMS. Das verkleinert den Sicherheits-Perimeter dauerhaft und macht zukünftige externe Nutzer (Fremdfahrer, Subunternehmen) ohne Architektur-Risiko integrierbar.
Automatisierte, eng definierte Schnittstellen
Jede Übergabe ans Kernsystem ist explizit modelliert, idempotent und audit-fähig protokolliert. Keine ad-hoc-Integrationen, keine direkte DB-Kopplung.
Plattform als Sandbox für Automatisierung
Workflow-Automatisierungen (Fristen-Erinnerungen, Auto-Eskalationen, Document-Parsing) werden im App-Kreis pilotiert. Erst wenn sie sich bewähren, wandern sie näher ans Kernsystem.
Wartbarkeit als Architektur-Vorgabe
Bewusste Tech-Wahl (Next.js + Supabase + React Native) für niedrige Betriebs-TCO und einen Pool an Entwicklern, die das langfristig pflegen können — kein proprietärer Lock-in.
Wirkung (Stand laufendes Mandat)
Da das Mandat seit April 2026 aktiv läuft, sind harte Vorher/Nachher-Werte zum Veröffentlichungszeitpunkt noch nicht final messbar. Drei beobachtete Wirkungen aus der Pilot-Phase:
Audit-Fähigkeit der Pflicht-Quittierungen
rechtssicher
Werkstatt → Verwaltung
Bruch entfällt
Fristen-Übersicht (TÜV, Zertifizierungen)
kein Termin-Verlust
Hinweis zur Wirkungsmessung
Die hier dargestellten Wirkungen sind qualitative Beobachtungen aus dem laufenden Pilotbetrieb. Belastbare Vorher/Nachher-Werte werden nach Abschluss der ersten vollen Quartals-Periode nachgereicht.
Lesson
Tool-Architektur ist eine Engpass-Frage, nicht eine Build-Frage. Die teuerste Fehlentscheidung in mittelständischen Operations-Projekten ist nicht die falsche Technologie — sie ist der falsche Schnitt: was läuft im Kernsystem, was läuft daneben, was läuft dazwischen. Wenn dieser Schnitt früh sauber ist, werden alle nachgelagerten Entscheidungen einfacher, billiger und sicherer.
Übertragbar
Das Prinzip „isolierter User-Kreis mit kuratierten, automatisierten Schnittstellen" passt überall, wo externe oder mobile Nutzer auf ein sensibles Kernsystem treffen — Logistik, Außendienst, Werkstatt-Netzwerke, Field-Service, Subunternehmer-Onboarding.
Hinweis zur Anonymisierung: Konkrete Zahlen und identifizierende Details sind anonymisiert. Die Größenordnung und das Vorzeichen entsprechen dem realen Mandat. Auf Wunsch teilen wir belastbare Zahlen im Eignungsgespräch unter NDA.
Klingt nach Ihrer Situation?
Im kostenlosen Eignungsgespräch klären wir, ob ein vergleichbarer Engpass bei Ihnen vorliegen könnte. Wenn nicht, sagen wir das direkt.