Mandantenfähigkeit

Für B2B-Entscheider ist die Wahl der richtigen Software eine strategische Weichenstellung. Ein Begriff, der dabei heute im Zentrum steht, ist „Mandantenfähigkeit”. Doch dieses Konzept ist längst kein isoliertes Feature mehr. Es ist das fundamentale architektonische Prinzip, das moderne Geschäftsmodelle von SaaS-Anwendungen und vor allem den sicheren Einsatz von KI-Assistenten wie Microsoft Copilot untermauert. Ein tiefes Verständnis von Mandantenfähigkeit ist entscheidend, denn ihre Umsetzung hat direkte Auswirkungen auf Kosten, Datensicherheit, die Integrität Ihrer KI-Ergebnisse und die zukünftige Skalierbarkeit Ihres Unternehmens.

Mandantenfähigkeit auf einen Blick

Mandantenfähigkeit bezeichnet die Eigenschaft einer Software, auf einer einzigen, zentralen Installation mehrere voneinander unabhängige Kunden – die Mandanten – zu bedienen. Die Daten jedes Mandanten bleiben dabei streng getrennt und sicher. Man kann es sich wie ein Mehrfamilienhaus vorstellen: eine zentrale Infrastruktur, aber viele private, digital abgeschlossene Wohnungen.

Die Hauptvorteile sind erhebliche Kosteneinsparungen durch geteilte Ressourcen, eine deutlich vereinfachte zentrale Wartung sowie eine hohe Skalierbarkeit. Entscheidend für den Erfolg ist jedoch nicht, ob eine Software mandantenfähig ist, sondern wie. Das Architekturmodell beeinflusst Sicherheit und Flexibilität, während das Lizenzmodell die tatsächlichen Kosten bestimmt.

Die Grundlagen für den Geschäftsalltag

Um fundierte Entscheidungen zu treffen, müssen die grundlegenden Begriffe klar sein. Mandantenfähigkeit ist kein monolithisches Konzept, sondern bewegt sich auf einem Spektrum von „weicher” zu „harter” Isolation. Dies definiert die Kompromisse zwischen Kosten, Sicherheit und Datenhoheit.

Der Mandant: Ihre digitale Organisationseinheit

In der IT bezeichnet der Begriff „Mandant” (englisch: Tenant) eine datentechnisch komplett abgeschlossene und eigenständige Organisationseinheit innerhalb eines Softwaresystems. Er ist die oberste Ordnungsinstanz und repräsentiert typischerweise ein Kundenunternehmen. Dies ist eine zentrale Funktion in modernen Enterprise Resource Planning (ERP)-Systemen. Für eine Konzerngesellschaft kann ein Mandant beispielsweise eine eigenständige Tochterfirma sein, was die Abbildung von Intercompany-Prozessen vereinfacht. Für einen Steuerberater wäre es ein einzelner Klient.

Die technologische Basis: Entra ID und Purview

Die moderne technologische Basis ist ein API-First-Ansatz, bei dem alle Funktionen über saubere Schnittstellen ansprechbar sind. Die Grundpfeiler moderner, mandantenfähiger Microsoft-Systeme sind zentrale Identitätsdienste und Werkzeuge zur Datenklassifizierung. Hier greifen zwei Systeme ineinander:

• Microsoft Entra ID (ehemals Azure Active Directory) agiert als zentraler Türsteher. Es stellt sicher, dass nur berechtigte Nutzer auf die Daten und KI-Funktionen ihres spezifischen Mandanten zugreifen können.
• Microsoft Purview kümmert sich um die Datenklassifizierung. Damit legen Sie fest, welche Daten als „öffentlich”, „intern” oder „vertraulich” gelten. Diese „Etiketten” werden von KI-Diensten wie Copilot erkannt und respektiert.

Architekturmodelle und ihre Business-Implikationen

Die Art und Weise, wie ein Anbieter die Mandantentrennung technisch realisiert, ist seine wichtigste architektonische Entscheidung. Sie definiert die Eigenschaften seiner Plattform bezüglich Sicherheit, Leistung, Kosten und Compliance.

Modell 1: Shared Database (Geteilte Datenbank) – das Pool-Modell

Alle Mandanten teilen sich eine einzige Datenbank sowie dieselben Tabellen. Die Trennung erfolgt auf Softwareebene durch eine „Tenant-ID” in jeder Datenbankabfrage, die sicherstellt, dass jeder nur seine eigenen Daten sieht.

• Business-Implikationen: Dieses Modell ist für Anbieter am kostengünstigsten und ermöglicht eine extrem schnelle Bereitstellung neuer Mandanten. Es ist ideal für hochstandardisierte SaaS-Anwendungen mit vielen kleineren Kunden.
• Risiken: Die Effizienz wird durch inhärente Risiken erkauft. Ein Programmierfehler kann zu Datenlecks führen. Zudem besteht das Risiko des „Noisy-Neighbor“-Problems, bei dem ein Mandant die Leistung für alle anderen beeinträchtigt.

Modell 2: Database per Tenant (Eigene Datenbank pro Mandant) – Das Silo-Modell

Jeder Mandant erhält eine eigene, logisch und oft auch physisch getrennte Datenbank. Die Anwendung ist zwar zentral, die Datenspeicher für sensible Bewegungsdaten sind es aber nicht.

• Business-Implikationen: Dieses Modell bietet maximale Datensicherheit und eliminiert das „Noisy-Neighbor“-Problem auf Datenbankebene. Es ist die bevorzugte Wahl für Enterprise-Kunden und stark regulierte Branchen.
• Nachteile: Diese robusten Vorteile führen zu signifikant höheren Betriebs- und Wartungskosten sowie zu einem komplexeren Onboarding-Prozess für neue Mandanten.

Realitäts-Check: Die neue Klarheit durch KI und Copilot

Mit der Integration von KI-Assistenten wie Microsoft Copilot direkt in die gewohnten Anwendungen wird eine saubere Mandantentrennung zur absoluten Grundvoraussetzung. Die Sicherheit von Copilot hängt direkt von der sauberen Konfiguration Ihres Mandanten ab.

Die Frage ist nicht, ob Sie eine komplexe Datenplattform brauchen, sondern: Wie stellen Sie sicher, dass Ihr Copilot nur auf Ihre eigenen, korrekten Unternehmensdaten zugreift?

Die Antwort liegt in einer soliden Basis. Ein System wie Microsoft Dynamics 365 Business Central bietet genau diese robuste, mandantenfähige Architektur. Es dient als sichere und strukturierte Datenquelle. Copilot greift auf diese Daten zu und respektiert dabei strikt die in Microsoft Entra ID festgelegten Benutzerrechte. So wird sichergestellt, dass sensible Informationen nicht zwischen Mandanten oder unberechtigten Mitarbeitern vermischt werden.

Mandantenfähigkeit im Business-Kontext

Die wahre Bedeutung von Mandantenfähigkeit zeigt sich im Geschäftsalltag. Sie ist nicht nur eine technische Lösung, sondern der Wegbereiter für eine erfolgreiche Prozessoptimierung und kosteneffiziente Abläufe.

Das Lizenzmodell: Named User statt Concurrent-Pool

Die Wahl des Lizenzmodells beeinflusst Ihre Softwarekosten spürbar — und genau hier wird Mandantenfähigkeit oft mit Lizenzierung verwechselt. Beides gehört getrennt betrachtet.

Dynamics 365 Business Central lizenziert grundsätzlich pro benannter Person (Named User). Jede Nutzerin, jeder Nutzer bekommt eine eigene Lizenz — Essentials, Premium, Team Member oder External Accountant, bezogen über einen Microsoft-Partner im CSP-Programm. In der Cloud steuert Microsoft die Zugriffsrechte über Entra-ID-Entitlements; die klassischen Lizenzdateien (.flf) aus NAV-Zeiten gibt es online nicht mehr. Einen frei geteilten „Concurrent-Slot"-Pool für Büroarbeitsplätze kennt Business Central nicht.

Die einzige Ausnahme ist die Device-Lizenz. Sie lizenziert ein gemeinsam genutztes Gerät — etwa eine Kasse, ein Werkstatt- oder Lagerterminal —, das sich mehrere Mitarbeitende teilen. Sie ist damit auf geteilte Geräte im Schichtbetrieb zugeschnitten, nicht auf Wissensarbeiter mit eigenem Arbeitsplatz, und ersetzt keine benannten Lizenzen im Büro.

Der Business Enabler: Microsofts CSP-Programm & Entra ID

Mandantenfähigkeit ist die technologische Grundlage des Microsoft Cloud Solution Provider (CSP)-Programms. Die Verwaltungsebene wird durch Microsoft Entra ID und dessen granulare Berechtigungsmodelle abgebildet. Werkzeuge zur delegierten Administration ermöglichen es Partnern wie uns, Kundenmandanten von einer einzigen, sicheren Konsole aus effizient zu verwalten – immer basierend auf dem Prinzip der minimalen Rechtevergabe.

Experten-Checkliste: Die 6 Fallstricke bei der Anbieterauswahl

Nutzen Sie diese aktualisierte Checkliste, um die Qualität und Zukunftsfähigkeit einer mandantenfähigen Lösung zu prüfen.

• Fehlende administrative Delegation
  Frage an den Anbieter: „Bietet Ihre Lösung eine delegierte Administration über Microsoft Entra ID, damit wir eigene Mandanten-Administratoren mit klar definierten, eingeschränkten Rechten definieren können?”
• Unzureichende Performance-Isolation („Noisy Neighbor”)
  Frage an den Anbieter: „Welche konkreten technischen Maßnahmen (z.B. Resource Quotas, API Rate Limiting) haben Sie implementiert, um die Performance-Isolation vertraglich via SLAs zu garantieren?”
• Komplexer Daten-Export („Vendor Lock-in”)
  Frage an den Anbieter: „Gibt es vertragliche Garantien für einen vollständigen Datenexport? Verfolgen Sie einen API-First-Ansatz, der uns jederzeit den Zugriff auf unsere Daten sichert?”
• Mangelnde Revisionssicherheit (DSGVO)
  Frage an den Anbieter: „Implementiert Ihr System eine revisionssichere Protokollierung, die sowohl unsere internen Nutzerzugriffe als auch die administrativen Zugriffe Ihres Personals DSGVO-konform und für uns transparent aufzeichnet?”
• Unzureichende kryptografische Trennung
  Frage an den Anbieter: „Bieten Sie eine Verschlüsselung mit mandantenspezifischen Schlüsseln (Per-Tenant-Encryption) an? Unterstützen Sie ein Bring-Your-Own-Key-(BYOK)-Modell für maximale Kontrolle?”
• Die KI-Daten-Frage
  Frage an den Anbieter: „Wie stellen Sie die mandantenscharfe Trennung von Daten bei KI-Funktionen wie Copilot sicher? Wird unser Input zur Trainierung eines globalen Modells verwendet oder sind die KI-Prozesse strikt auf unseren Mandanten gekapselt und greifen nur auf unsere freigegebenen Daten zu?”

Fazit: Mehr als nur ein Feature

Mandantenfähigkeit ist keine technische Checkbox mehr. Sie ist die DNA einer modernen SaaS-Anwendung – eine Architekturentscheidung mit weitreichenden Konsequenzen für Kosten, DSGVO-Compliance, KI-Sicherheit und Flexibilität. Ein System ist niemals „nur” mandantenfähig, sondern immer auf eine bestimmte Art und Weise. Wenn Sie die Unterschiede zwischen den Architekturmodellen verstehen und die richtigen kritischen Fragen – insbesondere zur Datenhoheit und KI-Isolation – stellen, verwandeln Sie den Fachbegriff in ein wirkungsvolles Werkzeug zur Auswahl der richtigen, pragmatischen und zukunftssicheren Plattform für Ihr Unternehmen.