Shared Services, Wiederverwendung und Vendor Hosting
Zentrale Plattformen wiederverwenden und zugleich Mandantentrennung, lokale Authority, Lieferkette, Exit und Betriebsnachweise sichern.
Shared Services vermeiden Doppelentwicklung und können Controls professionalisieren. Sie konzentrieren jedoch Abhängigkeit, privilegierten Zugriff und Ausfallwirkung. Vendor Hosting ergänzt Vertrags-, Support-, Unterauftragnehmer- und Souveränitätsgrenzen.
Vorher: Transparenz und Klassifikation. Überblick: Governance im Public Sector.
Ansatz
Jeder zentrale Dienst erhält einen Service Grenze Contract:
- Service, Mandanten, Datenklassen und ausgeschlossene Nutzungen;
- fachliche Authority der nutzenden Stellen;
- Controls des zentralen Betreibers und Pflichten der Mandanten;
- Admin-, Support- und Subprozessorzugriffe;
- Logging, Incident, Recovery und Kommunikationswege;
- Portabilität, Exit, Löschung und Nachweisrückgabe.
Die Beschaffung eines Dienstes überträgt weder Zweckentscheidung noch fachliche Verantwortung an Anbieter oder Plattformteam. Legal, Datenschutz, Security und Beschaffung bestätigen ihren jeweiligen Rahmen.
Shared-Responsibility-Workflow
1. Wiederverwendungsgrenze definieren
Standardisiert werden Technik, Schnittstellen und Mindestcontrols. Fachliche Zwecke und Entscheidungen bleiben explizit je Mandant.
2. Mandantentrennung testen
Positive und negative Zugriffe, Admin-Bypass, Log-Trennung, Schlüssel und Backup-Restore werden real geprüft.
3. Lieferkette sichtbar machen
Hosting-Ort, Control Plane, Supportländer, Unterauftragnehmer und Remote-Zugriff werden zusammen betrachtet.
4. Incident-Handoffs üben
Ein Szenario testet Erkennung, Meldung, Zuständigkeit, Betroffenenkontext, Fachaufsicht und Evidence.
5. Exit praktisch erproben
Exportformat, Vollständigkeit, Schlüssel, Metadaten, Audit Logs und Löschbestätigung werden anhand einer Stichprobe validiert.
6. Änderungen kontrollieren
Neue AI-Funktion, Region, Subprozessor oder Servicekomponente löst Grenze- und Authority-Review aus.
Evidence Pack
- freigegebener Servicekatalog und ausgeschlossene Nutzungen;
- Responsibility Matrix je Kontrollregel;
- Mandanten- und Admin-Deny-Tests;
- Subprozessor- und Supportpfad;
- Recovery- und Incident-Protokoll;
- Ausstieg-Stichprobe und Löschbestätigung;
- offene Exceptions mit Ablauf und Remediation verantwortliche Person.
Anti-Patterns
- Ein Rahmenvertrag gilt als vollständige Produktfreigabe.
- Der Betreiber wird fachlicher Data Owner aller Mandanten.
- Mandantentrennung wird nur aus Architekturdiagrammen abgeleitet.
- Ausstieg bedeutet lediglich CSV-Export ohne Metadaten und Logs.
- Neue Dienstleister-KI-Funktionen werden automatisch aktiviert.
Erster Umsetzungsschnitt
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Einen kritischen Shared Service wählen.
- Betreiber- und Mandantenpflichten je Control trennen.
- Einen Cross-Tenant-Deny-Test durchführen.
- Support- und Subprozessorzugriff nachvollziehen.
- Incident-Handoff simulieren.
- Einen exportierten Datensatz samt Metadaten wiederherstellen.
Serienabschluss
Der Public-Sector-Vertrag ist belastbar, wenn Registerabruf, Akten-Lifecycle, Veröffentlichung und Shared Service über gemeinsame Identifiers verbunden bleiben, ohne ihre Authorities zu vermischen. Wiederverwendung ist dann kein Kontrollverlust, sondern ein bewusst begrenztes Betriebsmodell.
Weiterlesen
Governance in the public-sector landscape
Part 5 of 5
View series