Mandantenfähigkeit heißt: Ein System bedient mehrere getrennte Organisationseinheiten mit eigenen Daten, Nutzern und Einstellungen. Nötig wird sie bei Tochtergesellschaften, mehreren Standorten, Kundenbetrieb durch einen Dienstleister oder White-Label-Angeboten. Drei Isolationsgrade stehen zur Wahl: eigene Datenbank, eigenes Schema oder gemeinsame Tabellen mit Mandantenschlüssel.
Was steckt eigentlich hinter dem Begriff Mandant?
Ein Mandant ist eine abgegrenzte Einheit, deren Daten von den Daten anderer Einheiten getrennt bleiben. Wer sich in Mandant A anmeldet, sieht ausschließlich dessen Vorgänge — auch dann, wenn beide Mandanten dieselbe Anwendung auf demselben Server nutzen. Die Trennung ist eine Zusage des Systems, keine Frage der Bildschirmmaske.
Vier Ausgangslagen führen typischerweise zu dieser Anforderung. Eine Unternehmensgruppe mit rechtlich eigenständigen Tochtergesellschaften braucht getrennte Buchungskreise. Ein Unternehmen mit mehreren Niederlassungen will Zahlen je Standort führen. Ein Dienstleister betreibt eine Anwendung für seine Kunden. Und ein Softwareanbieter verkauft dieselbe Lösung unter fremdem Namen weiter.
Diese Fälle unterscheiden sich stark im Anspruch. Standorte innerhalb einer Gesellschaft brauchen meist nur eine saubere Filterung. Kunden eines Dienstleisters brauchen eine belastbare Trennung, die auch einer Prüfung standhält, weil sie untereinander Wettbewerber sein können.
Welche drei Isolationsgrade gibt es?
Die Frage nach dem Isolationsgrad ist die zentrale Architekturentscheidung. Sie bestimmt die Betriebskosten, die Geschwindigkeit von Anpassungen und die Antwort auf jede spätere Datenschutzfrage.
Eigene Datenbank je Mandant
Jeder Mandant erhält eine physisch getrennte Datenbank. Die Trennung ist damit am stärksten: Eine fehlerhafte Abfrage kann konstruktionsbedingt keine fremden Daten treffen. Eine Sicherung lässt sich für einen einzelnen Mandanten zurückspielen, ohne andere zu berühren, und ein Kunde kann seinen Datenbestand vollständig ausgehändigt bekommen.
Der Preis liegt im Betrieb. Jede Schemaänderung muss über alle Datenbanken laufen, jede Sicherung überwacht, jedes Zertifikat gepflegt werden. Bei fünf Mandanten ist das unproblematisch, bei zweihundert wird es zu einem eigenen Betriebsaufwand mit entsprechendem Werkzeugbedarf.
Gemeinsame Datenbank, getrennte Schemata
Alle Mandanten liegen in einer Datenbank, aber in je eigenen Namensräumen. Der Betrieb ist einfacher als bei vollständiger Trennung, die Isolation bleibt spürbar besser als bei einem gemeinsamen Datenbestand. Diese Variante wird häufig unterschätzt und ist für zehn bis fünfzig Mandanten oft der vernünftigste Kompromiss.
Gemeinsame Tabellen mit Mandantenschlüssel
Alle Daten liegen in denselben Tabellen, unterschieden durch eine Mandantenspalte. Das ist die günstigste und am besten skalierende Variante — und die riskanteste. Jede einzelne Abfrage muss den Mandantenfilter enthalten. Eine vergessene Bedingung in einem Auswertungsbericht zeigt fremde Daten.
Wer diesen Weg wählt, darf den Filter nicht der Disziplin einzelner Entwicklerinnen überlassen. Er gehört tief in die Datenzugriffsschicht oder in Sicherheitsregeln der Datenbank, sodass ein Zugriff ohne gesetzten Mandanten technisch scheitert statt stillschweigend alles zu liefern.
Was ändert sich dadurch im laufenden Betrieb?
Mandantenfähigkeit ist keine einmalige Entwicklungsleistung, sondern eine dauerhafte Betriebsaufgabe. Aufsetzen eines neuen Mandanten, Einspielen von Aktualisierungen, Sicherung und Wiederherstellung, Überwachung — all das vervielfacht sich mit dem gewählten Isolationsgrad.
- Aktualisierungen: Bei getrennten Datenbanken brauchen Sie einen automatisierten Ablauf, der Schemaänderungen zuverlässig überall ausführt und Teilfehler meldet.
- Wiederherstellung: Klären Sie vorab, ob ein einzelner Mandant separat zurückgesetzt werden kann, ohne die übrigen anzufassen.
- Überwachung: Kennzahlen sollten je Mandant vorliegen, sonst bemerkt niemand, dass nur einer von dreißig ein Problem hat.
- Lastverhalten: Ein Mandant mit großem Datenvolumen darf die Antwortzeiten der anderen nicht spürbar beeinträchtigen.
Ein Personaldienstleister, der eine Bewerbungsplattform für dreißig Kundenunternehmen betreibt, hat damit einen laufenden Posten, der sich im Wartungsvertrag niederschlagen muss. Die Entwicklungskosten sind einmalig, der Betriebsaufwand nicht.
Wie werten Sie über mehrere Mandanten hinweg aus?
Sobald die Geschäftsführung eine Zahl über alle Gesellschaften sehen will, kollidiert die Trennung mit dem Berichtswesen. Diese Anforderung kommt zuverlässig — meist etwa ein halbes Jahr nach dem Produktivstart und selten im ursprünglichen Lastenheft.
Bei gemeinsamen Tabellen ist die Auswertung technisch einfach und fachlich heikel: Sie brauchen eine gesonderte Rolle, die den Mandantenfilter bewusst aufhebt, und ein Protokoll über deren Nutzung. Bei getrennten Datenbanken ist der umgekehrte Weg üblich — ein eigener Auswertungsbestand, in den nachts verdichtete Kennzahlen aus allen Mandanten laufen.
Der zweite Weg hat einen unterschätzten Vorteil: Aggregierte Kennzahlen ohne Personenbezug lassen sich zusammenführen, ohne die eigentliche Trennung aufzuweichen. Wer nur Umsatz je Standort und Monat braucht, muss keine Einzelbelege zusammenlegen.
Wo hört Konfiguration auf und fängt die Sonderlocke an?
Mandanten wollen Unterschiede: eigenes Logo, eigene Nummernkreise, eigene Freigabeschwellen, eigene Textbausteine. Solange sich das über Einstellungswerte abbilden lässt, ist alles in Ordnung. Kritisch wird es, wenn ein Mandant einen abweichenden Ablauf verlangt.
Eine Immobilienverwaltung mit zwei Tochtergesellschaften kann problemlos unterschiedliche Mahnstufen und Briefköpfe führen. Wenn eine der beiden aber einen völlig anderen Genehmigungsweg für Instandhaltungsaufträge braucht, entsteht eine Verzweigung im Programmcode, die dauerhaft mitgepflegt und bei jeder Änderung mitgetestet werden muss.
Jede mandantenspezifische Abweichung im Code ist ein zweites Produkt, das Sie ab sofort mitpflegen — auch wenn sie an dem Tag nur zehn Zeilen groß war.
Eine brauchbare Grenze: Alles, was ein Administrator in der Oberfläche einstellen kann, ist Konfiguration. Alles, was eine neue Auslieferung braucht, ist eine Sonderlocke und gehört bepreist, dokumentiert und ausdrücklich entschieden.
Welche Datenschutz- und Löschanforderungen kommen dazu?
Wenn Sie eine Anwendung für Kunden betreiben, verarbeiten Sie deren Daten in der Regel im Auftrag. Das verlangt einen entsprechenden Vertrag und die Fähigkeit, Auskunfts- und Löschersuchen mandantenscharf zu beantworten. Die Frage „Können Sie alle Daten dieses einen Kunden vollständig löschen, ohne andere zu beeinträchtigen?“ sollte Ihre Architektur beantworten können.
Denken Sie dabei über die Fachdaten hinaus. Protokolldateien, Suchindizes, Zwischenspeicher, Dateianhänge, E-Mail-Versandarchive und vor allem Sicherungen enthalten Mandantendaten. Bei getrennten Datenbanken ist die Antwort meist unkompliziert, bei gemeinsamen Tabellen wird sie zu einem eigenen Entwicklungsvorhaben.
Klären Sie außerdem den Serverstandort und die Frage, ob einzelne Mandanten abweichende Anforderungen mitbringen. Ein öffentlicher Auftraggeber als Mandant kann Vorgaben stellen, die für die übrigen nicht gelten — und die Sie dann für alle erfüllen oder gar nicht anbieten.
Wann darf man Mandantenfähigkeit trotzdem verschieben?
Nachrüsten ist teuer, weil der Mandantenbezug jede Tabelle, jede Abfrage und jede Auswertung berührt. Realistisch liegt der Aufwand für eine bestehende Anwendung mittlerer Größe bei 20 bis 40 Prozent einer Neuentwicklung — bei Individualsoftware im Bereich von 60.000 € also schnell im mittleren fünfstelligen Bereich.
Trotzdem gibt es gute Gründe zu warten. Wenn der zweite Mandant hypothetisch ist und die erste Fassung ihren Nutzen erst beweisen muss, ist eine Investition in eine ungenutzte Fähigkeit schlecht angelegt. Ein pragmatischer Mittelweg: Führen Sie von Beginn an eine Mandantenspalte in den zentralen Tabellen mit, auch wenn sie zunächst überall denselben Wert enthält.
Diese Vorbereitung kostet wenige Personentage und erspart später den schmerzhaftesten Teil des Umbaus — die nachträgliche Zuordnung bestehender Datensätze zu Mandanten, für die es keine verlässliche Quelle mehr gibt.
Welche Fragen sollte die Geschäftsführung vorab beantworten?
- Wie viele Mandanten sind in drei Jahren realistisch — drei, dreißig oder dreihundert?
- Können zwei Mandanten Wettbewerber sein, oder gehören alle zur eigenen Gruppe?
- Muss ein Mandant seine Daten jederzeit vollständig und getrennt ausgehändigt bekommen können?
- Braucht die Geschäftsführung Auswertungen über alle Mandanten hinweg, und in welcher Verdichtung?
- Wer trägt die Betriebskosten je Mandant, und wie werden sie verrechnet?
Diese fünf Antworten bestimmen den Isolationsgrad zuverlässiger als jede technische Diskussion. Wir empfehlen, sie schriftlich festzuhalten und der Architekturentscheidung als Begründung beizulegen — spätestens beim nächsten Dienstleisterwechsel ist nachvollziehbar, warum das System so gebaut wurde.
Hilfreich ist außerdem eine Rechnung, die selten jemand aufstellt: Was kostet ein einzelner Mandant im Jahr an Betrieb? Rechenleistung, Speicher, Sicherungen, Überwachung und der anteilige Aufwand für Aktualisierungen ergeben zusammen einen Betrag je Mandant. Erst mit dieser Zahl lässt sich beurteilen, ob ein Preismodell trägt oder ob jeder neue Mandant die Marge senkt.
Halten Sie zuletzt fest, wie ein Mandant wieder verschwindet. Ein Aufnahmeprozess wird immer gebaut, ein Abgangsprozess fast nie — und dann liegen nach drei Jahren Datenbestände gekündigter Einheiten im System, für die niemand mehr eine Löschgrundlage oder eine Zuständigkeit findet. Ein definierter Ablauf mit Export, Sperrfrist und endgültiger Löschung kostet wenige Tage und erspart genau diese Altlast.