Neun Standorte. Ein Datenstand. Klare Zuständigkeiten.
Schematische, anonymisierte Ansicht. Standortcodes und Werte sind illustrativ; Rollenmodell, Standortvergleich und operative Steuerung entsprechen dem realen Funktionsumfang.
Ausgangslage, Aufgabe, Umsetzung.
- Preislisten auf Papier und per Mailanhang
- Schulungsunterlagen in Einzelordnern
- Filialinformationen über Rundmails
- Keine gemeinsame Basis über die Standorte hinweg
- 20 Fachmodule, zentral gepflegt
- Rollenrechte: GF alles, Filialleitung nur eigene Filiale
- Zwei Umgebungen — nichts geht ungeprüft live
- Neues Modul von Anforderung bis Freigabe in Tagen
| Branche | Optikerhandel, inhabergeführter Filialverbund |
| Größe | Rund neun Standorte |
| Laufzeit | Juni 2026 bis heute · unter zwei Monate bis zum Produktivbetrieb |
| Umfang | 20 Fachmodule · Stand Juli 2026: rund 540 Commits und mehr als 60 Testsuiten |
| Kernthema | Rollenmodell — dieselbe Seite muss drei Rollen unterschiedliche Daten zeigen |
Eine Seite, drei Sichten.
Ein Filialverbund hat ein Rechteproblem, das in einer Zentrale nicht auftritt: Dieselbe Seite muss je Rolle unterschiedliche Daten zeigen.
Zwanzig Module für den Filialalltag.
Jedes Modul ist aus einer konkreten Anforderung aus dem Tagesgeschäft entstanden — nicht aus einem Standardkatalog.
- Preislisten & Kollektionen Zentrale Pflege von Fassungs- und Kontaktlinsenpreisen, filialübergreifend verfügbar, mit getrennten Listen je Produktkategorie.
- Warenwirtschaft Bestandsführung und Warenbewegungen zwischen den Filialen, inklusive Lieferscheinerstellung als PDF.
- Filial-Cockpit & Kennzahlen Auswertung je Standort für die Filialleitung, aggregierte Sicht für die Geschäftsführung.
- Verträge Vertragsablage je Filiale — die Geschäftsführung pflegt zentral, jede Filiale sieht ausschließlich die eigenen Dokumente.
- Rechnungen & Buchhaltung Rechnungserstellung mit eigenem Briefkopf des Kunden, Belegverwaltung, Auswertungen.
- Schulungen Schulungsunterlagen und Nachweise je Mitarbeitendem, zentral gepflegt statt in Einzelordnern.
- Kollegen & Stammdaten Mitarbeitendenverzeichnis mit Filialzuordnung; Rollen und Rechte werden ausschließlich in der Administration vergeben.
- Krankenkassen & Leistungen Übersicht über Kassenleistungen und Abrechnungsgrundlagen als Nachschlagewerk für den Verkauf.
- Nachrichten, Aushang & Hinweise Interne Kommunikation an alle Standorte, ersetzt Rundmails und Papieraushänge.
- Mittagspause & Schichtplanung Abstimmung der Pausenzeiten je Filiale — eine kleine Funktion mit hoher täglicher Nutzung.
- Aufgaben & Feedback Aufgabenverfolgung und ein Rückmeldekanal, über den Mitarbeitende Verbesserungen direkt melden.
- Suche & Betriebsstatus Modulübergreifende Suche sowie eine Statusseite zu Systemzustand, Datenaktualität und Backups.
„Die Module mit dem größten Nutzen sind selten die aufwendigsten. Die Pausenabstimmung wird häufiger geöffnet als jede Auswertung."
Technischer Deep-Dive.
Rechtemodell, Zwei-Umgebungen-Betrieb und Qualitätssicherung im Detail.
Architektur & Stack aufklappen
| Ebene | Umsetzung |
|---|---|
| Hosting | Zwei getrennte Cloud-Server: Freigabe- und Produktivumgebung, jeweils in Deutschland |
| Laufzeit | Docker-Container hinter einem Reverse-Proxy mit automatischer Zertifikatsverwaltung |
| Anwendung | Python/Flask, ein Blueprint je Fachmodul — 20 klar getrennte Zuständigkeiten |
| Daten | SQLite je Umgebung, strikt getrennt; Produktivdaten werden nie in die Freigabeumgebung gespiegelt |
| Zugang | JWT-basierte Anmeldung mit Zwei-Faktor-Schutz; die zweite Stufe ist je Umgebung eigenständig eingerichtet |
| Sicherheit | HSTS und Content-Security-Policy als versioniertes Serverkonfigurations-Snippet auf beiden Umgebungen |
| Auswertung | Selbst gehostete, datenschutzfreundliche Nutzungsstatistik ohne personenbezogene Profile |
Rechtemodell — der schwierigste Teil aufklappen
Ein einfacher Zugriffsschalter je Seite reicht nicht, wenn dieselbe Seite je Rolle andere Daten zeigen muss (siehe Schaubild oben).
Umsetzung
- Eine einzige Wahrheitsquelle — Rollen und Filialzugehörigkeit werden ausschließlich über die Benutzerverwaltung vergeben. Andere Formulare im System können keine Rollen setzen, auch nicht versehentlich.
- Rechte je Modul, nicht pauschal — jedes Modul hat ein eigenes Leserecht. Eine Rolle für ein Modul freizuschalten bedeutet, genau dieses eine Recht zu vergeben — nicht einen Sammelzugriff.
- Filterung an der Datenquelle — die Einschränkung auf die eigene Filiale passiert in der Datenbankabfrage, nicht durch Ausblenden in der Oberfläche. Was jemand nicht sehen darf, wird gar nicht erst geladen.
- Dokumentierte Zugriffsmatrix — welche Rolle welches Modul sieht, ist als eigenes Dokument im Projekt hinterlegt und nicht nur im Code verstreut.
Was dabei schiefging
Eine Rechteänderung wirkte zunächst nicht, weil das System an vier Stellen prüfte — Datenbank, Rechtekatalog, Altbestand und Modullogik — und nur drei davon angepasst waren. Der Zugriff blieb verweigert, ohne dass eine Fehlermeldung darauf hinwies. Seitdem ist dokumentiert, dass ein neues Modulrecht in allen Schichten gleichzeitig eingetragen werden muss; die Reihenfolge steht in der Projektdokumentation.
Zwei-Umgebungen-Betrieb & Freigabeprozess aufklappen
Der Weg einer Änderung
Immer dieselbe Kette — kein direkter Weg vom Arbeitsplatz auf den Produktivserver:
- Stufe 1 — lokale Entwicklung mit Testlauf; rote Tests blockieren den weiteren Weg
- Stufe 2 — Ausrollen auf die Freigabeumgebung, dort Durchklicken der betroffenen Funktion mit echten Testdaten
- Stufe 3 — erst nach Bestätigung Ausrollen auf die Produktivumgebung, danach Kontrolle des Endzustands am Livesystem
Warum das den Aufwand wert ist
Bei einem System, das neun Standorte im Tagesgeschäft trägt, ist ein Ausfall zur Öffnungszeit teurer als jede Verzögerung durch einen zusätzlichen Prüfschritt. Die Freigabeumgebung ist keine Formalität, sondern der Ort, an dem Fehler gefunden werden, bevor sie jemanden betreffen.
Datentrennung
Produktivdaten werden nicht in die Freigabeumgebung übernommen. Die Testumgebung arbeitet mit eigenen Daten — das vermeidet die häufigste Datenschutzlücke bei zweistufigen Setups.
Qualitätssicherung & Datenschutz aufklappen
Automatisierte Prüfungen
Stand Juli 2026 decken mehr als 60 Testsuiten Rechtelogik, Datenzugriffe und Fachfunktionen ab. Sie laufen vor jedem Ausrollen; ein Fehlschlag stoppt den Vorgang. Ergänzend prüft ein Hook jeden Commit auf versehentlich enthaltene Zugangsdaten.
Datenschutz
- Nutzungsstatistik ohne Personenbezug — die eingesetzte Auswertung erfasst Seitenaufrufe und Standort, aber keine individuellen Nutzungsprofile
- Eingaben werden bereinigt — von Mitarbeitenden eingegebene Inhalte werden konsequent maskiert, bevor sie angezeigt werden
- Sicherheitsheader — HSTS und eine Content-Security-Policy sind als versionierte Serverkonfiguration hinterlegt und auf beiden Umgebungen identisch
- Zugangsdaten — liegen ausschließlich in Umgebungsdateien außerhalb der Versionsverwaltung; Klartext-Abfragen gegen Produktivsysteme sind ausgeschlossen
Betriebsdokumentation
Zum Projekt gehören dokumentierte Betriebsanweisungen für Wiederherstellung, Zugriffsmatrix, Architektur und Sicherheitskonfiguration. Ein System, das nur der Erbauer betreiben kann, ist kein fertiges System.