Mandantenfähigkeit ist Architektur – keine Funktion zum Nachrüsten.

Was Mandantenfähigkeit wirklich bedeutet.

Mandantenfähigkeit heißt: Eine Installation bedient mehrere, strikt voneinander getrennte Organisationen. Jeder Mandant sieht ausschließlich seine Daten, seine Benutzer, seine Konfiguration — obwohl alle dieselbe Plattform nutzen. Das klingt nach einer Filterfrage, ist aber eine Strukturfrage. Denn die Trennung muss überall gelten: in jeder Abfrage, jedem Export, jedem Hintergrundjob, jeder Mail und jedem Support-Zugriff.

In unseren Systemen unterscheiden wir fünf Ebenen, die nie vermischt werden:

• Betreiber — wir als Plattformverantwortliche, mit eigenen, auditierten Zugriffswegen.
• Mandant — das Kundenunternehmen als oberste Datengrenze.
• Standort — Filialen oder Betriebsstätten mit eigener Konfiguration.
• Rolle — was ein Benutzer innerhalb seines Mandanten darf, serverseitig geprüft.
• Gerät — gekoppelte Hardware, die einem Standort zugeordnet und einzeln sperrbar ist.

Warum Nachrüsten so teuer ist.

Wer Mandantenfähigkeit nachrüstet, muss jede einzelne Stelle finden, an der das System bisher stillschweigend „es gibt nur einen Kunden" angenommen hat. Das sind nicht nur Datenbankabfragen: Es sind Caches, Suchindizes, Dateiablagen, Exportpfade, geplante Jobs, E-Mail-Versand und Berichte. Eine einzige übersehene Stelle genügt, und Daten eines Mandanten tauchen beim anderen auf — im besten Fall peinlich, im schlimmsten Fall ein meldepflichtiger Datenschutzvorfall.

Deshalb gilt für uns: Die Mandanten-Grenze wird beim ersten Entwurf des Datenmodells gezogen, nicht beim ersten Großkunden.

Rollen und Rechte gehören auf den Server.

Ein häufiger Baufehler: Die Oberfläche blendet Funktionen aus, der Server würde sie aber ausführen. Sobald jemand die API direkt anspricht, ist die „Trennung" weg. Rechteprüfungen müssen serverseitig an jedem Endpunkt stattfinden — die Oberfläche spiegelt nur wider, was der Server ohnehin durchsetzt. Wie wir Schnittstellen und Identitäten absichern, beschreibt unsere Sicherheitsseite.

Der Betreiber braucht eigene, saubere Wege.

Support gehört zum Betrieb: Irgendwann muss ein Mitarbeiter des Betreibers in einen Mandanten schauen, um zu helfen. Die Frage ist, ob das System dafür einen kontrollierten Weg hat — zeitlich begrenzt, protokolliert, mit klarer Kennzeichnung — oder ob sich jemand „kurz in die Datenbank" einloggt. Mandantenfähigkeit endet nicht an der Kundengrenze; sie regelt auch, wie der Betreiber selbst zugreift.

Woran man echte Mandantenfähigkeit erkennt.

• Jede Datenzeile trägt ihre Mandanten-Zugehörigkeit — nicht nur die „wichtigen" Tabellen.
• Rechte werden serverseitig geprüft, an jedem Endpunkt, ohne Ausnahme.
• Standorte lassen sich getrennt konfigurieren und zentral steuern — beides zugleich.
• Geräte sind gekoppelt, zugeordnet und einzeln entziehbar.
• Betreiberzugriffe sind protokolliert und begrenzt statt informell.
• Exporte, Jobs und Mails respektieren dieselben Grenzen wie die Oberfläche.

Nach diesem Modell sind UrbanBooks und UrbanPOS gebaut: Verwaltung und Kasse teilen dieselbe Trennlogik von Betreiber, Mandant, Standort, Rolle und Gerät. In der Gastronomie zeigt sich das besonders deutlich — mehr dazu im Text über Kassensysteme für die Gastronomie.