SH

Sascha Hess xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

 

	Strategische Wissens-Roadmap 2026
	Self-Service BI Risiken & Governance
	Freiheit für die Fachabteilung — Kontrolle für das Unternehmen

WAS SIE IN DIESEM KIT ERHALTEN:

1

10 SSBI-Risiken Datenschutz, Qualität, Schatten-IT, Governance — vollständig

 

2

Governance-Framework Rollen, Rechte, Prozesse — praxiserprobte Struktur

 

3

DSGVO-Checkliste Self-Service BI rechtskonform betreiben

 

4

Report-Zertifizierung Welche Berichte darf die Fachabteilung selbst bauen?

 

5

30-Tage-Governance-Plan Von unkontrolliertem SSBI zur strukturierten Ordnung

 

 

 

 

Alle Empfehlungen, Governance-Muster und Checklisten wurden sorgfältig erarbeitet. Da jede Unternehmensumgebung individuell ist, übernimmt der Autor keinerlei Haftung für Datenschutzverstöße, fehlerhafte Auswertungen, Compliance-Verstöße oder sonstige Schäden. Lassen Sie rechtlich relevante Maßnahmen durch einen Datenschutzbeauftragten und gegebenenfalls einen Fachanwalt prüfen.

 

 

Die genannten Governance-Muster und Risikoeinschätzungen basieren auf Erfahrungswerten aus realen KMU-Projekten und allgemein anerkannten Best Practices, Stand März 2026. Tatsächliche Risiken und geeignete Gegenmaßnahmen hängen stark von der jeweiligen Systemlandschaft, Unternehmensgröße und Branche ab.

 

 

Datenschutzrechtliche Anforderungen (DSGVO, BDSG) und behördliche Auslegungen ändern sich. Prüfen Sie alle rechtlichen Hinweise regelmäßig mit Ihrem Datenschutzbeauftragten auf Aktualität.

 

 

Dieses Dokument ist für den persönlichen oder betriebsinternen Gebrauch des Käufers lizenziert. Weiterverkauf, Weitergabe an Dritte und öffentliche Veröffentlichung sind ohne schriftliche Genehmigung nicht gestattet.

 

 

Dieses Kit ist ein unabhängiges Werk ohne Verbindung zu Microsoft, Salesforce/Tableau oder anderen Softwareherstellern. Power BI ist eine eingetragene Marke der Microsoft Corporation. Tableau ist eine eingetragene Marke der Salesforce, Inc.

 

Eine ausführliche Version dieses Haftungsausschlusses befindet sich am Ende dieses Dokuments.

 

 

 

01  Einleitung

Warum Self-Service BI ohne Governance gefährlich wird

02  Die 10 SSBI-Risiken

Vollständig erkannt — bevor der Schaden entsteht

03  Datenschutz & DSGVO

Self-Service BI rechtskonform betreiben

04  Datenqualität & falsche Zahlen

Wenn jede Abteilung ihre eigene Wahrheit hat

05  Schatten-IT & unkontrollierte Berichte

Das Excel-Problem im BI-Gewand

06  Governance & Zuständigkeiten

Wer darf was — und wer verantwortet was?

07  Report-Zertifizierung

Welche Berichte sind offiziell — welche nicht?

08  Technische Schutzmaßnahmen

Row-Level Security, Datenmaskierung, Audit Logs

09  Change Management

Fachabteilungen gewinnen, nicht bevormunden

10  30-Tage-Governance-Plan

Von unkontrolliertem SSBI zur strukturierten Ordnung

 

 

Einleitung

 

 

Self-Service BI ist eine der bedeutendsten Entwicklungen in der Unternehmens-IT der letzten zehn Jahre. Die Idee ist bestechend: Fachabteilungen analysieren ihre Daten selbst, ohne jedes Mal die IT zu bemühen. Schneller, flexibler, näher am Geschäft.

 

Das Versprechen ist real. Die Risiken werden unterschätzt.

In der Praxis mittelständischer Unternehmen zeigt sich ein wiederkehrendes Muster: Power BI wird eingeführt, die Lizenzen werden verteilt, eine kurze Schulung findet statt — und dann wird die Fachabteilung sich selbst überlassen. Nach sechs Monaten existieren 47 verschiedene Versionen des Umsatzberichts. Niemand weiß mehr, welche die richtige ist. Der Vertriebsleiter präsentiert in der Geschäftsführungssitzung eine Zahl, die Controlling-Leiterin widerspricht mit einer anderen. Beide haben Recht — nach ihrer eigenen Berechnungslogik.

 

→  Self-Service BI ohne Governance erzeugt keine Demokratisierung von Daten — sondern Anarchie der Zahlen.

 

→  Datenschutzverstöße durch SSBI sind 2026 einer der häufigsten Auslöser für DSGVO-Bußgelder in KMU. Mitarbeiterdaten in einem Excel-Export, der per E-Mail geteilt wird, ist ein klassisches Beispiel.

 

→  Schatten-BI ist das neue Schatten-IT: Fachabteilungen bauen Datenmodelle und Berichte außerhalb jeglicher IT-Kontrolle — mit direktem Zugriff auf Produktivdatenbanken.

 

→  Falsche Zahlen in Führungsentscheidungen sind das teuerste mögliche Ergebnis — und sie entstehen nicht durch bösen Willen, sondern durch fehlende Definitionen und fehlende Governance.

 

Dieses Kit beschreibt die zehn wichtigsten Risiken von Self-Service BI — und liefert konkrete, praxiserprobte Gegenmaßnahmen: ein Governance-Framework, DSGVO-Checklisten, technische Schutzmaßnahmen und einen realistischen Umsetzungsplan, der Fachabteilungen nicht bevormundet, sondern strukturiert befähigt.

WAS SIE IN DIESEM KIT ERWARTEN DÜRFEN ■  10 SSBI-Risiken — Datenschutz, Datenqualität, Schatten-IT und Governance vollständig behandelt. ■  Governance-Framework — Rollen, Rechte, Prozesse: das Minimum, das jedes SSBI-Projekt braucht. ■  DSGVO-Checkliste — Self-Service BI rechtskonform gestalten und betreiben. ■  Report-Zertifizierungsmodell — Drei Klassen von Berichten mit klaren Spielregeln. ■  30-Tage-Governance-Plan — Bestehende SSBI-Wildwüchse strukturieren ohne Kulturschock.

ZIEL DIESES KITS Nach dem Lesen und Umsetzen dieses Kits haben Sie ein schlankes, praktikables Governance-Framework, das Fachabteilungen echte Freiheit gibt — innerhalb klarer Leitplanken. Kein Bürokratiemonster, das SSBI abwürgt. Sondern ein Rahmen, der Vertrauen in Zahlen schafft.

Die 10 SSBI-Risiken

 

 

Diese zehn Risiken sind die häufigsten und folgenreichsten Probleme in unkontrollierten Self-Service-BI-Umgebungen. Keines davon ist unvermeidlich.

 

 

Fachabteilungen erhalten Datenbankzugriff — und exportieren unbewusst personenbezogene Daten in unkontrollierte Umgebungen: lokale Excel-Dateien, persönliche OneDrive-Ordner, E-Mail-Anhänge. Was als praktische Arbeitsweise beginnt, ist juristisch ein DSGVO-Verstoß.

 

GEGENMASNAHME:

 

✓  Kein direkter Datenbankzugriff für Fachabteilungen — nur kuratierte semantische Schichten.

✓  Datenkategorisierung: Welche Daten sind personenbezogen? Diese Felder werden maskiert oder ausgeblendet.

✓  Export-Beschränkungen im BI-Tool konfigurieren: Export in Excel deaktivieren für sensible Datensätze.

✓  Datenschutzbeauftragten in SSBI-Rollout einbinden — vor dem Launch, nicht danach.

 

 

Ein Bericht mit sensiblen Vertriebsdaten wird als PDF exportiert und per E-Mail an externe Berater geschickt. Oder ein Dashboard-Link wird geteilt — ohne zu prüfen, ob der Empfänger Zugriffsrechte haben sollte.

 

GEGENMASNAHME:

 

✓  Sharing-Berechtigungen zentralisieren: Nur bestimmte Rollen dürfen Berichte extern teilen.

✓  Wasserzeichen auf exportierten Berichten: Empfänger ist identifizierbar.

✓  Ablaufdaten für geteilte Links konfigurieren — kein dauerhafter externer Zugriff ohne Prüfung.

✓  Schulung: Was darf geteilt werden — und was nicht? Einfache, eindeutige Regeln.

 

 

Drei Abteilungen, drei Umsatzzahlen für denselben Monat. Jede ist nach der eigenen Logik korrekt. Keine ist die offizielle Unternehmenszahl. Entscheidungen werden auf Basis unterschiedlicher Wahrheiten getroffen.

GEGENMASNAHME:

 

✓  Zertifizierte Kennzahlen: Offizielle KPIs werden nur aus validierten, zentralen Datensätzen berechnet.

✓  Einheitliche KPI-Definitionen (aus Kit "BI-KPIs für Geschäftsführung") als verbindliche Grundlage.

✓  Report-Zertifizierungsmodell einführen (Kapitel 7 dieses Kits).

✓  "Golden Record"-Prinzip: Für jede Kernkennzahl gibt es genau eine autoritative Quelle.

 

 

Ein Vertriebsmitarbeiter baut einen Umsatzbericht in Power BI — aber zieht Bruttozahlen statt Nettoumsatz heran. Der Unterschied: 19 % Umsatzsteuer. Der Bericht wird der Geschäftsführung präsentiert. Die Entscheidung basiert auf falschen Zahlen.

 

GEGENMASNAHME:

 

✓  Berechnungslogik in der semantischen Schicht vorberechnen — Fachanwender ziehen fertige Measures, keine Rohfelder.

✓  Kritische Kennzahlen als gesperrte Measures definieren — nicht überschreibbar durch Endnutzer.

✓  Peer-Review-Pflicht für Berichte, die in GF-Meetings verwendet werden.

✓  Schulung Berechnungsgrundlagen: Was ist Netto, Brutto, DB I, DB II — einheitlich vermitteln.

 

 

Erfahrene Excel-User verbinden sich direkt per ODBC auf die ERP-Produktivdatenbank. Selbst gebastelte SQL-Abfragen laufen ohne Index, ohne Limit — und bringen das ERP zum Stillstand, wenn gerade Monatsabschluss läuft.

 

GEGENMASNAHME:

 

✓  Direktzugriff auf ERP-Produktivdatenbanken für Fachabteilungen technisch sperren.

✓  Nur lesende Verbindungen auf dedizierte Reporting-Replika oder semantische Schicht freigeben.

✓  Netzwerk-Firewall: Datenbankports nur für autorisierte BI-Server erreichbar.

✓  Aktive Überwachung: Alerts bei unbekannten Datenbankverbindungen.

 

 

Ein Mitarbeiter baut über Monate einen komplexen Bericht. Er verlässt das Unternehmen. Niemand weiß, welche Daten der Bericht zieht, was die Berechnungen bedeuten, ob er noch aktuell ist. Der Bericht wird trotzdem weiterverwendet — weil er "immer funktioniert hat".

 

GEGENMASNAHME:

 

✓  Mindestdokumentation für jeden veröffentlichten Bericht: Zweck, Datenquelle, Berechnungslogik, Verantwortlicher, letzte Prüfung.

✓  Berichts-Inventar führen: Zentrale Liste aller aktiven SSBI-Berichte mit Status (Aktiv / Veraltet / Zertifiziert).

✓  Jährlicher Bereinigungslauf: Ungenutzte und undokumentierte Berichte deaktivieren.

 

 

Ein Fachanwender filtert auf "diesen Monat" — aber das BI-Tool zieht UTC-Zeiten, das ERP speichert in lokaler Zeit. Ergebnis: Transaktionen kurz vor Mitternacht werden falsch zugeordnet. Monatsabschluss-Zahlen weichen um einige Buchungen von der Finanzbuchhaltung ab.

 

GEGENMASNAHME:

 

✓  Einheitliche Zeitzonendefinition im gesamten DWH und BI-System — dokumentiert und verbindlich.

✓  Datumsfelder im DWH immer als DATE (ohne Uhrzeit) für Tagessummen speichern.

✓  Periodendefinitionen (Monat, Quartal, Geschäftsjahr) in der Datumsdimension zentral vorhalten.

✓  Abweichungstests: Monatssummen aus BI vs. Buchhaltungsabschluss monatlich vergleichen.

 

 

Die Personalabteilung nutzt Self-Service BI für Fluktuationsanalysen. Dabei entstehen Berichte, die Rückschlüsse auf Einzelpersonen ermöglichen — Krankenstand einer bestimmten Schicht mit nur drei Mitarbeitern, Gehaltsbänder mit zu feiner Granularität.

 

GEGENMASNAHME:

 

✓  HR-Daten grundsätzlich in separater, besonders geschützter Datenzugangsebene.

✓  Mindestgruppengröße für Auswertungen definieren: Keine Kennzahl für Gruppen unter 5 Personen.

✓  Betriebsrat einbinden: HR-Datenauswertungen sind mitbestimmungspflichtig (§ 87 BetrVG).

✓  Anonymisierung und Aggregation prüfen, bevor HR-Daten in SSBI freigegeben werden.

 

 

Berichte aus dem Vorjahr werden weiterverwendet, weil niemand weiß, dass sie veraltet sind. Geschäftsregeln haben sich geändert — der Bericht spiegelt alte Logik wider. Oder die Datenquelle wurde umstrukturiert — der Bericht funktioniert noch, zieht aber andere Daten als erwartet.

 

GEGENMASNAHME:

 

✓  Jeder Bericht zeigt prominent: "Erstellt: [Datum] | Letzte Prüfung: [Datum] | Verantwortlich: [Name]".

✓  Ablaufdatum für Berichte einführen: Nach 12 Monaten ohne Prüfung wird der Bericht als "nicht geprüft" markiert.

✓  Änderungsbenachrichtigung: Wenn Datenquellen oder Kennzahlen geändert werden, werden alle betroffenen Berichtsverantwortlichen informiert.

 

 

Jeder darf alles sehen. Oder: Die Rechtevergabe ist so restriktiv, dass niemand arbeiten kann. Beides ist falsch. Das Ergebnis im ersten Fall: Datenpannen. Im zweiten Fall: Schatten-IT, weil die offizielle Lösung zu umständlich ist.

 

GEGENMASNAHME:

 

✓  Rollenkonzept nach dem Prinzip der minimalen Rechte (Least Privilege): Jeder sieht genau das, was er für seine Arbeit braucht.

✓  Rollen an Organisationsstruktur koppeln — nicht an Einzelpersonen.

✓  Regelmäßige Rechtereview: Halbjährlich prüfen, ob Zugriffsrechte noch zur aktuellen Rolle passen.

✓  Offboarding-Prozess: Ausscheidende Mitarbeiter verlieren sofort alle BI-Zugriffsrechte.

 

 

Datenschutz & DSGVO

 

 

Datenschutz ist im SSBI-Kontext kein abstraktes Compliance-Thema — es ist ein konkretes operatives Risiko. Bußgelder der Datenschutzbehörden für KMU im fünf- bis sechsstelligen Bereich sind keine Seltenheit mehr.

 

 

Personenbezogene Daten im Sinne der DSGVO sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Im BI-Kontext betrifft das weit mehr als offensichtliche Felder wie Name oder E-Mail-Adresse.

 

→  Direkt personenbezogen: Name, Adresse, E-Mail, Telefon, Kundennummer, Mitarbeiternummer, IP-Adresse.

 

→  Indirekt personenbezogen (häufig übersehen): Umsatz eines Einzelkunden (identifizierbar), Krankenstand einer kleinen Abteilung (Rückschluss auf Einzelpersonen), Standortdaten, Bestellhistorie (bei überschaubaren Kundenstämmen).

 

→  Besonders schützenswert (Art. 9 DSGVO): Gesundheitsdaten, Gewerkschaftszugehörigkeit, religiöse Überzeugungen, politische Meinungen — diese Kategorien unterliegen erhöhten Anforderungen.

 

 

Jede Verarbeitung personenbezogener Daten muss im Verarbeitungsverzeichnis (Art. 30 DSGVO) dokumentiert sein — auch BI-Auswertungen.

 

VERARBEITUNGSVERZEICHNIS-EINTRAG (BEISPIEL):   Bezeichnung:      Kundenanalyse im Self-Service BI   Verantwortlicher: Vertriebsleiter / IT-Leitung   Zweck:            Umsatz- und Kaufverhaltensanalyse zur Vertriebssteuerung   Rechtsgrundlage:  Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse)   Datenkategorien:  Kundenstammdaten, Transaktionsdaten (kein Sonderkat.)   Empfänger:        Interne Vertriebsmitarbeiter mit BI-Zugang   Speicherdauer:    Solange Kundenbeziehung aktiv + 3 Jahre   TOMs:             Zugriffsschutz per Rolle, Verschlüsselung at rest,                     kein Export personenbezogener Einzeldatensätze

 

 

 

TECHNISCHE MASSNAHMEN (TOMs):   ■ Zugriffskontrolle: Rollenbasierter Zugriff — nur authorisierte Personen   ■ Verschlüsselung: Daten at rest und in transit verschlüsselt   ■ Anonymisierung: Personenbezogene Felder in SSBI-Schicht maskiert oder aggregiert   ■ Protokollierung: Wer hat wann auf welche Daten zugegriffen? (Audit Log)   ■ Löschkonzept: Personenbezogene Daten werden nach Ablauf der Aufbewahrungsfrist                   auch aus DWH und BI-System gelöscht   ■ Export-Kontrolle: Export personenbezogener Einzeldatensätze technisch eingeschränkt   ORGANISATORISCHE MASSNAHMEN:   ■ Datenschutzbeauftragter in SSBI-Projektplanung eingebunden?   ■ Datenschutz-Folgenabschätzung (DSFA) für risikoreiche Verarbeitungen durchgeführt?   ■ Mitarbeiter auf Datengeheimnis verpflichtet und geschult?   ■ Auftragsverarbeitungsvertrag mit BI-Tool-Anbieter abgeschlossen?   ■ Löschanfragen von Betroffenen: Prozess definiert, der auch BI-Daten erfasst?   ■ Datenpanne: Meldepflicht binnen 72 Stunden an Aufsichtsbehörde bekannt?

 

 

 

→  Pseudonymisierung: Direktidentifikatoren (Name, E-Mail) werden durch einen technischen Schlüssel ersetzt. Rückführung ist mit dem Schlüssel möglich — gilt weiterhin als personenbezogen, aber mit reduziertem Risiko.

 

→  Anonymisierung: Rückführung auf Einzelperson ist technisch ausgeschlossen. Gilt nicht mehr als personenbezogen — unterliegt nicht der DSGVO. Aber: Echte Anonymisierung ist schwerer zu erreichen als gedacht (Kombination von Merkmalen kann re-identifizieren).

 

→  k-Anonymität als Mindeststandard: Kein Datenpunkt einer Gruppe unter k=5 Personen wird ausgegeben. In der Praxis: Auswertungen mit Gruppengrößen < 5 werden unterdrückt oder auf "< 5" aggregiert.

 

BEISPIEL: ANONYMISIERUNGSREGEL IM REPORTING Krankenstandsbericht nach Abteilung:   Abteilung A (32 Mitarbeiter) → wird angezeigt   Abteilung B (8 Mitarbeiter)  → wird angezeigt   Abteilung C (3 Mitarbeiter)  → wird NICHT angezeigt (< 5 Personen)                                   → Anzeige: "Gruppe zu klein für Ausweisung"

 

 

BETRIEBSRAT UND MITBESTIMMUNG ■  Auswertungen über Mitarbeiterverhalten und -leistung sind nach § 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig. ■  Das gilt auch für BI-Auswertungen: Krankenstand, Überstunden, Produktivität je Mitarbeiter. ■  Betriebsvereinbarung abschließen, bevor HR-Daten in SSBI freigegeben werden. ■  Ohne Betriebsvereinbarung: Unterlassungsklage des Betriebsrats möglich.

 

 

Datenqualität & falsche Zahlen

 

 

Datenqualitätsprobleme in Self-Service BI sind nicht nur ein technisches Problem — sie sind ein Vertrauensproblem. Einmal erschüttert, ist das Vertrauen in BI-Zahlen schwer zurückzugewinnen.

 

 

→  Vollständigkeit: Sind alle relevanten Datensätze vorhanden? Fehlen Buchungen, weil der Monatsabschluss noch nicht erfolgt ist? Fehlen Kunden, weil Stammdaten nicht gepflegt sind?

 

→  Korrektheit: Entsprechen die Werte der Realität? Sind Preise, Mengen, Kostenstellen korrekt erfasst? Stimmt die Berechnungslogik mit der vereinbarten Definition überein?

 

→  Konsistenz: Liefern verschiedene Quellen für dieselbe Frage dasselbe Ergebnis? Stimmt der Umsatz aus dem ERP mit dem aus der Finanzbuchhaltung überein — nach denselben Abgrenzungsregeln?

 

→  Aktualität: Wie alt sind die Daten im BI-System? Wann wurde zuletzt geladen? Sind offene Perioden noch nicht abgeschlossen und verfälschen so Periodenvergleiche?

 

 

FALLE 1: BRUTTO STATT NETTO   Fachanwender zieht Umsatzfeld aus ERP → enthält Mehrwertsteuer.   Richtig: Nettoumsatz aus Erlöskonten der Finanzbuchhaltung.   Differenz: 19 % — bei 1 Mio. EUR Umsatz = 159.664 EUR Abweichung.   FALLE 2: STORNOS NICHT ABGEZOGEN   Bericht summiert alle Auftragspositionen ohne Stornopositionen.   Richtig: Nettoumsatz = Umsatz − Stornos − Retouren − Rabattgutschriften.   FALLE 3: INTERCOMPANY NICHT ELIMINIERT   Konzernumsatz enthält konzerninterne Lieferungen.   Richtig: Nur Umsatz mit externen Dritten zählt zum konsolidierten Umsatz.   FALLE 4: OFFENE POSTEN ALS UMSATZ   Auftragseingänge = noch nicht fakturierter Umsatz werden als Umsatz gezeigt.   Richtig: Klar trennen zwischen Auftragsbestand und fakturiertem Umsatz.   FALLE 5: PERIODENABGRENZUNG   Lieferung am 31. März, Rechnung am 2. April → in welchem Monat buchen?   Richtig: Immer nach Lieferdatum (Erfüllung) oder nach einheitlicher Abgrenzungsregel.

 

 

 

-- Konsistenzprüfung: BI-Umsatz vs. Buchhaltungs-Umsatz (monatlich ausführen) SELECT     b.Monat,     b.Umsatz_Buchhaltung,     bi.Umsatz_BI,     bi.Umsatz_BI - b.Umsatz_Buchhaltung        AS Differenz_EUR,     (bi.Umsatz_BI - b.Umsatz_Buchhaltung)         / NULLIF(b.Umsatz_Buchhaltung, 0) * 100 AS Differenz_Pct FROM      meta.Umsatz_Buchhaltung_Abschluss b   -- manuell gepflegte Referenztabelle JOIN      mart.Umsatz_Monat               bi ON b.Monat = bi.Monat WHERE     ABS(bi.Umsatz_BI - b.Umsatz_Buchhaltung)               / NULLIF(b.Umsatz_Buchhaltung, 0) > 0.005  -- Alert ab 0,5 % Abweichung ORDER BY  b.Monat DESC;

 

 

 

Das Konzept der "Single Source of Truth" klingt selbstverständlich — ist es in der Praxis aber nicht. Es erfordert aktive Entscheidungen und Konventionen.

 

→  Für jede Kernkennzahl gilt: Genau eine Berechnungslogik, genau eine Datenquelle, genau ein verantwortlicher KPI-Owner.

 

→  Zertifizierte Measures: Im semantischen Modell des BI-Tools werden offizielle Kennzahlen als zertifiziert markiert — visuell erkennbar für alle Anwender.

 

→  Verbindliche KPI-Definitionen: Das KPI-Glossar aus dem Kit "BI-KPIs für Geschäftsführung" wird zur vertraglichen Grundlage aller SSBI-Aktivitäten erklärt.

 

→  Abnahme durch Controlling: Neue Kennzahlen in SSBI-Berichten werden vor Veröffentlichung durch das Controlling geprüft und freigegeben.

 

 

Schatten-IT & unkontrollierte Berichte

 

 

Schatten-BI ist die direkte Nachfolgeproblematik der klassischen Schatten-IT. Früher waren es Excel-Dateien mit handgepflegten Makros. Heute sind es Power-BI-Berichte mit direktem Datenbankzugriff — außerhalb jeglicher IT-Kontrolle, aber mit erheblich mehr Reichweite.

 

 

Schatten-BI entsteht nicht aus böser Absicht — sondern aus konkreten Bedürfnissen, die das offizielle System nicht erfüllt.

 

→  Die IT ist zu langsam: Eine Anfrage für einen neuen Report dauert sechs Wochen. Die Fachabteilung braucht die Zahl für nächste Woche. Sie baut den Report selbst.

 

→  Das zentrale Dashboard zeigt nicht das Richtige: Die Standardansicht passt nicht zu den spezifischen Anforderungen der Abteilung. Also wird eine eigene Version gebaut.

 

→  Der Weg über die IT ist umständlich: Ticket öffnen, warten, erklären, warten, Feedback geben, warten. Selbst machen geht schneller.

 

→  Werkzeuge sind leicht verfügbar: Power BI Desktop ist kostenlos. Excel ist überall. Der Einstieg ist niedrig — die Konsequenzen werden später sichtbar.

 

 

Bevor Governance eingeführt werden kann, muss bekannt sein, was existiert. In vielen Unternehmen gibt es keine vollständige Übersicht über vorhandene SSBI-Berichte.

 

INVENTARISIERUNGS-WORKSHOP (AGENDA — 2 STUNDEN):     SCHRITT 1: SAMMLUNG (30 Min.)     Jede Abteilung listet alle regelmäßig genutzten eigenen Berichte:     → Welche Excel-Dateien werden monatlich/wöchentlich befüllt?     → Welche BI-Berichte wurden selbst gebaut?     → Welche Datenquellen werden direkt abgefragt?     → Wer nutzt diese Berichte — intern, extern?     SCHRITT 2: BEWERTUNG (45 Min.)     Je Bericht bewerten:     → Datenschutzrelevanz: Enthält er personenbezogene Daten?     → Kritikalität: Fließt er in Entscheidungen der GF oder des Controllings?     → Qualitätsstatus: Wurde die Berechnungslogik jemals geprüft?     → Dokumentation: Gibt es eine Beschreibung des Berichts?     SCHRITT 3: PRIORISIERUNG (45 Min.)     Berichte in drei Kategorien einteilen:     → Kritisch: Sofortiger Handlungsbedarf (personenbezogen + unkontrolliert)     → Relevant: Mittelfristig in Governance überführen     → Unkritisch: Tolerierbar, dokumentieren und beobachten

 

 

 

Der Umgang mit bereits existierenden Schatten-BI-Lösungen erfordert Fingerspitzengefühl. Verbote ohne Alternativen erzeugen Widerstand und treiben die Aktivitäten weiter in den Untergrund.

 

→  Nicht verbieten — strukturieren: Schatten-BI-Berichte, die echte Bedürfnisse erfüllen, werden in die offizielle Struktur überführt — mit Dokumentation, Prüfung und Verantwortlichen.

 

→  Schnelle Alternativen anbieten: Wenn die IT schnell auf Berichtsanfragen reagiert — innerhalb von Tagen statt Wochen — sinkt die Motivation zur Eigenentwicklung drastisch.

 

→  Bestandsberichte migrieren, nicht löschen: Wertvolle Schatten-BI-Berichte werden als offizieller Berichtskandidat aufgenommen, geprüft und zertifiziert.

 

→  Klare Regeln für neue Eigenentwicklungen: Was darf die Fachabteilung selbst bauen — und was nicht? (Kapitel 6 und 7 dieses Kits)

 

DAS EXCEL-PROBLEM BLEIBT ■  Auch mit bestem SSBI-Governance-Framework: Excel wird nicht verschwinden. ■  Ziel ist nicht die Elimination von Excel — sondern die Kontrolle kritischer Auswertungen. ■  Excel für persönliche Ad-hoc-Analysen: tolerierbar. ■  Excel als Datenquelle für GF-Entscheidungen: nicht tolerierbar ohne Prüfung. ■  Klare Kommunikation: "Für diese Zwecke Excel — für jene Zwecke das offizielle BI."

 

 

Governance & Zuständigkeiten

 

 

Ein SSBI-Governance-Framework muss zwei scheinbar gegensätzliche Anforderungen erfüllen: maximale Freiheit für die Fachabteilung — bei gleichzeitiger minimaler Kontrolle für die Unternehmensführung. Das Geheimnis liegt in der richtigen Granularität der Regeln.

 

 

ZONE 1 — OFFIZIELLE ZONE (IT/Controlling verantwortet):   Inhalt:   Zertifizierte GF-Dashboards, Monats-/Jahresberichte, KPI-Definitionen,             semantisches Datenmodell, Datumsdimension, Kernkennzahlen   Wer baut: IT / BI-Entwickler / Controlling   Wer prüft: Controlling + Datenschutzbeauftragter   Änderungen: Nur über formalen Änderungsprozess   ZONE 2 — MODERIERTE ZONE (Fachabteilung mit IT-Begleitung):   Inhalt:   Abteilungsbezogene Standardberichte, regelmäßige Exports,             Berichte die in Teambesprechungen oder mit Dritten geteilt werden   Wer baut: Key User der Fachabteilung   Wer prüft: IT / BI-Team vor Veröffentlichung (Peer-Review)   Änderungen: Über einfachen Prüfprozess (< 2 Werktage)   ZONE 3 — FREIE ZONE (Fachabteilung eigenverantwortlich):   Inhalt:   Persönliche Ad-hoc-Analysen, Arbeitskopien, Explorationen,             Berichte die nicht geteilt und nicht in Entscheidungen genutzt werden   Wer baut: Jeder Anwender mit BI-Zugang   Wer prüft: Keine Prüfpflicht — aber klare Regeln: nicht teilen, nicht als offizielle              Zahl kommunizieren   Änderungen: Frei

 

 

 

→  BI-Governance-Owner (i.d.R. IT-Leitung oder CDO): Gesamtverantwortung für das Framework. Entscheidet bei Eskalationen. Prüft das Framework halbjährlich.

 

→  Data Steward (i.d.R. Controlling): Verantwortet KPI-Definitionen, Datenqualität und Zertifizierung. Prüft neue Berichte in Zone 2 auf korrekte Berechnungslogik.

 

→  Datenschutzbeauftragter: Prüft alle Berichte mit personenbezogenen Daten. Gibt Freigabe für Zone-1- und Zone-2-Berichte mit Personenbezug.

 

→  Key User (Fachabteilung): Erstellt und pflegt Zone-2-Berichte. Ist Ansprechpartner für BI-Fragen in der eigenen Abteilung. Nimmt an regelmäßigen BI-Community-Treffen teil.

→  Endanwender: Nutzt offizielle Berichte (Zone 1) und erstellt eigene Ad-hoc-Analysen (Zone 3). Kennt die Regeln — was darf geteilt werden, was nicht.

 

 

PROZESS 1: NEUER BERICHT ANFRAGEN   Fachabteilung → Ticket/Formular → BI-Team prüft (1 Werktag):   Einfach und schnell umsetzbar? → Key User selbst bauen (Zone 2 mit Review)   Komplex oder datenschutzrelevant? → IT/BI-Team übernimmt (Zone 1)   Ziel: Antwort in 24 Stunden — kein wochenlanger Wartestau   PROZESS 2: BERICHT VERÖFFENTLICHEN (ZONE 2)   Key User fertig → Peer-Review durch BI-Team (max. 2 Werktage):   Datenschutzcheck: Personenbezogene Daten enthalten?   Qualitätscheck:   Berechnungslogik korrekt? KPI-Definitionen eingehalten?   Freigabe → Bericht erhält Status "Geprüft" + Datum + Prüfer   Ablehnung → Feedback mit konkreten Änderungspunkten   PROZESS 3: JÄHRLICHE BEREINIGUNG   IT erstellt Liste aller aktiven Berichte:   Nicht genutzt seit > 6 Monaten → Benachrichtigung an Verantwortlichen   Keine Reaktion in 4 Wochen → Bericht wird deaktiviert   Letzte Prüfung > 12 Monate → Prüfung anfordern oder deaktivieren

 

 

 

Jedes Unternehmen mit SSBI braucht eine schriftliche Richtlinie. Diese muss nicht lang sein — aber sie muss existieren und kommuniziert worden sein.

 

SSBI-RICHTLINIE — PFLICHTINHALTE:   1. Zweck und Geltungsbereich   2. Drei-Zonen-Modell: Was darf wo gebaut werden?   3. Datenschutzregeln: Was darf nicht in SSBI-Berichte?   4. Sharing-Regeln: Was darf wie geteilt werden?   5. Qualitätsregeln: Welche Berichte brauchen eine Prüfung?   6. Rollen und Verantwortlichkeiten   7. Meldepflicht bei Datenpannen   8. Konsequenzen bei Regelverstößen

 

 

 

Report-Zertifizierung

 

 

Das Report-Zertifizierungsmodell ist das sichtbarste Element der SSBI-Governance — und das wirksamste Werkzeug gegen Versionschaos und Vertrauensverlust.

 

 

Klasse GOLD — Zertifiziert (Offizielle Unternehmensberichte)

 

KRITERIEN:   ■ Vom Controlling und Datenschutzbeauftragten geprüft und freigegeben   ■ KPI-Definitionen entsprechen dem offiziellen KPI-Glossar   ■ Datenquelle: ausschließlich zertifizierte Schichten des DWH   ■ Dokumentation vollständig: Zweck, Datenquelle, Berechnungslogik, Verantwortlicher   ■ Jährliche Wiederholungsprüfung eingeplant VERWENDUNG:   ■ GF-Meetings, Aufsichtsratspräsentationen, externe Berichte   ■ Basis für offizielle Unternehmenskennzahlen KENNZEICHNUNG IM TOOL:   ■ Goldenes Siegel / Badge sichtbar im Bericht   ■ "Zertifiziert von: [Name] am [Datum] | Nächste Prüfung: [Datum]"

 

 

Klasse SILBER — Geprüft (Abteilungsberichte)

 

KRITERIEN:   ■ Vom BI-Team auf Qualität und Datenschutz geprüft   ■ Dokumentation vorhanden (Zweck, Verantwortlicher)   ■ Darf innerhalb der Abteilung und mit direkt Beteiligten geteilt werden VERWENDUNG:   ■ Abteilungsmeetings, interne Steuerung, Teamreports   ■ Nicht für GF-Entscheidungen ohne Rückfrage beim Controlling KENNZEICHNUNG:   ■ Silbernes Siegel / Badge   ■ "Geprüft von: [Name] am [Datum]"

 

 

Klasse BRONZE — Nicht geprüft (Persönliche Analysen)

 

KRITERIEN:   ■ Keine formale Prüfung   ■ Nur für persönlichen Gebrauch oder informellen Austausch   ■ Darf nicht als Grundlage für offizielle Entscheidungen dienen VERWENDUNG:   ■ Ad-hoc-Analysen, Exploration, persönliche Arbeitshilfen   ■ Explizit: Kein Teilen außerhalb der direkten Arbeitsgruppe KENNZEICHNUNG:   ■ Deutlicher Hinweis: "NICHT GEPRÜFT — Keine offizielle Unternehmenszahl"   ■ Standardmäßig alle neuen Berichte in dieser Klasse

 

 

 

SCHRITT 1: ANTRAG (Key User oder BI-Team)   → Formular ausfüllen: Zweck, Zielgruppe, verwendete Datenquellen, KPIs   → Bericht in Prüfungsworkspace hochladen   SCHRITT 2: TECHNISCHE PRÜFUNG (BI-Team, max. 3 Werktage)   → Datenquelle korrekt? Nur zertifizierte DWH-Schichten?   → Performance: Ladezeit unter 5 Sekunden bei typischer Datenmenge?   → Datenschutz: Personenbezogene Daten korrekt behandelt?   SCHRITT 3: FACHLICHE PRÜFUNG (Controlling, max. 3 Werktage)   → KPI-Definitionen korrekt umgesetzt?   → Berechnungslogik mit Buchhaltungsabschluss abgeglichen?   → Zielwerte und Ampellogik korrekt konfiguriert?   SCHRITT 4: DATENSCHUTZ-FREIGABE (DSB, nur wenn personenbezogen)   → Verarbeitungsverzeichnis aktualisiert?   → TOMs ausreichend für die Sensitivität der Daten?   SCHRITT 5: ZERTIFIZIERUNG   → Goldenes Siegel wird gesetzt   → Bericht in offiziellem Berichtskatalog veröffentlicht   → Wiederholungsprüfung nach 12 Monaten eingeplant

 

 

 

Ein zentraler Berichtskatalog ist die Grundlage für Transparenz und Governance. Er muss aktuell, auffindbar und vollständig sein.

 

BERICHTSKATALOG — PFLICHTFELDER JE EINTRAG:   ■ Name und Beschreibung des Berichts   ■ Klasse (Gold / Silber / Bronze)   ■ Fachbereich und Verantwortlicher (KPI-Owner)   ■ Technischer Verantwortlicher (BI-Team)   ■ Datenquellen und Aktualisierungsfrequenz   ■ Zielgruppe (Rollen, die Zugriff haben)   ■ Letzte Prüfung und nächste geplante Prüfung   ■ Status (Aktiv / Überarbeitung / Veraltet / Deaktiviert)

 

 

 

Technische Schutzmaßnahmen

 

 

Governance ohne technische Durchsetzung bleibt Theorie. Die folgenden technischen Maßnahmen sind das Fundament, auf dem das Governance-Framework aufbaut.

 

 

Row-Level Security sorgt dafür, dass Anwender im BI-Tool nur die Datenzeilen sehen, für die sie berechtigt sind — ohne dass separate Berichte für jede Zielgruppe gebaut werden müssen.

 

-- Row-Level Security im SQL Server (für BI-Zugriff auf Verkaufsdaten) -- Jeder Vertriebsmitarbeiter sieht nur seine eigene Region   -- Schritt 1: Security-Funktion erstellen CREATE FUNCTION security.fn_Vertriebsregion_Filter (@Region NVARCHAR(100)) RETURNS TABLE WITH SCHEMABINDING AS RETURN     SELECT 1 AS fn_result     WHERE         -- Admins und Controller sehen alles         IS_MEMBER('BI_Admin') = 1         OR IS_MEMBER('BI_Controller') = 1         OR         -- Vertriebsmitarbeiter sehen nur ihre Region         EXISTS (             SELECT 1 FROM dbo.Benutzer_Region br             WHERE br.LoginName = USER_NAME()               AND br.Region    = @Region         );   -- Schritt 2: Security Policy auf Dimensionstabelle anwenden CREATE SECURITY POLICY sec.Vertriebsregion_Policy ADD FILTER PREDICATE security.fn_Vertriebsregion_Filter(Region) ON dim.Kunde WITH (STATE = ON); -- Ergebnis: Jeder Nutzer sieht in dim.Kunde nur Kunden seiner Region — -- automatisch in allen Berichten, die auf diese Tabelle zugreifen.

 

 

 

Für Felder, die technisch vorhanden sein müssen (z. B. für Joins), aber nicht lesbar sein sollen, bietet SQL Server Dynamic Data Masking.

 

-- Dynamic Data Masking: E-Mail-Adresse für nicht autorisierte Nutzer maskieren ALTER TABLE dim.Kunde ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()'); -- Nicht autorisierte Nutzer sehen: aXXX@XXXX.com statt max.mustermann@beispiel.de   -- Vollständige Maskierung für Gehaltsdaten ALTER TABLE dim.Mitarbeiter ALTER COLUMN Gehalt ADD MASKED WITH (FUNCTION = 'default()'); -- Nicht autorisierte Nutzer sehen: 0 statt des echten Werts   -- Berechtigung zum Lesen unmaskierter Daten vergeben GRANT UNMASK TO [BI_Controller]; -- Controller sehen echte Werte, alle anderen die Maske

 

 

 

-- SQL Server Audit: Datenzugriffe auf sensible Tabellen protokollieren -- (Erfordert SQL Server Enterprise oder Developer Edition für vollständige Funktion)   -- Vereinfachte Alternative: Zugriffs-Trigger für Audit-Trail CREATE TABLE meta.Zugriffsprotokoll (     ProtokolID   BIGINT IDENTITY(1,1) PRIMARY KEY,     Zeitpunkt    DATETIME2      NOT NULL DEFAULT SYSUTCDATETIME(),     LoginName    NVARCHAR(128)  NOT NULL DEFAULT SYSTEM_USER,     Tabelle      NVARCHAR(128)  NOT NULL,     Aktion       NVARCHAR(10)   NOT NULL,  -- SELECT / EXPORT     ZeilenAnzahl INT            NULL,     Bemerkung    NVARCHAR(500)  NULL );   -- In Views für sensible Daten: Zugriff protokollieren CREATE VIEW mart.v_Kundenumsatz_Protokolliert AS SELECT     k.KundenNr, k.Kundenname, k.Region,     SUM(f.Umsatz_Netto) AS Umsatz FROM  fakt.Auftragsposition f JOIN  dim.Kunde             k ON f.KundeKey = k.KundeKey WHERE k.IstAktuell = 1 GROUP BY k.KundenNr, k.Kundenname, k.Region; -- Zugriff über diese View wird über BI-Tool-eigenes Audit Log erfasst

 

 

ZONE 1 (OFFIZIELLE BERICHTE):   ✓ Row-Level Security aktiv auf allen relevanten Tabellen   ✓ Datenmaskierung für alle personenbezogenen Felder   ✓ Audit Log für alle Datenzugriffe   ✓ Export nur mit expliziter Berechtigung — Standard: deaktiviert   ✓ Verschlüsselung at rest und in transit   ✓ Zugriffsberechtigungen über Gruppen (nie Einzelpersonen)   ZONE 2 (GEPRÜFTE BERICHTE):   ✓ Row-Level Security geerbt aus semantischem Modell   ✓ Datenmaskierung geerbt aus DWH-Schicht   ✓ Export: nur nicht-personenbezogene Aggregationen erlaubt   ✓ Sharing: nur intern, keine externen Links   ZONE 3 (PERSÖNLICHE ANALYSEN):   ✓ Zugriff nur auf freigegebene, nicht-personenbezogene Datensätze   ✓ Kein Direktzugriff auf Rohtabellen oder ERP   ✓ Berichte standardmäßig privat — Teilen erfordert bewusste Aktion

 

Change Management

 

 

Das beste Governance-Framework scheitert, wenn es von den Fachabteilungen als Bürokratie wahrgenommen wird. Change Management ist kein weicher Zusatz — es ist die Voraussetzung für Akzeptanz.

 

 

→  "Wir werden kontrolliert": Governance wird als Misstrauen gegenüber der Fachabteilung interpretiert. Gegenmaßnahme: Kommunizieren, dass Governance Vertrauen schafft — nicht einschränkt. Wer nach zertifizierten Zahlen gefragt wird, kann sie liefern.

 

→  "Das dauert zu lange": Der Prüfprozess wird als Bremse empfunden. Gegenmaßnahme: SLA für Prüfungen einhalten — 2 Werktage, nicht 2 Wochen. Schnelle IT ist die beste Prävention gegen Schatten-BI.

 

→  "Das war früher einfacher": Excel-Workflows werden als komfortabler erlebt. Gegenmaßnahme: SSBI muss einfacher sein als Excel — nicht schwieriger. Schulung und Vorlagen senken die Einstiegshürde.

 

→  "Ich verstehe das Tool nicht": Fehlende Kompetenz führt zu Frustration und Rückfall auf alte Wege. Gegenmaßnahme: Kontinuierliche, niedrigschwellige Schulungsangebote.

 

 

Key User sind die wichtigsten Multiplikatoren im SSBI-Rollout. Sie sind Brücke zwischen Fachabteilung und IT — technisch kompetenter als der durchschnittliche Anwender, aber nah am fachlichen Bedarf.

KEY USER — PROFIL UND AUFGABEN:   PROFIL:     ■ Freiwillig und motiviert — nie delegiert     ■ Affinität zu Daten und Zahlen vorhanden     ■ Respektiert von Kollegen in der Abteilung     ■ Bereit, 10-20 % der Arbeitszeit für BI-Themen zu investieren     AUFGABEN:     ■ Erste Anlaufstelle für BI-Fragen in der Abteilung     ■ Baut Zone-2-Berichte für die Abteilung     ■ Meldet Datenqualitätsprobleme an den Data Steward     ■ Nimmt an monatlichem BI-Community-Treffen teil     ■ Gibt Feedback zu neuen Features und Problemen     FÖRDERUNG:     ■ Erweiterte Schulung und Zertifizierung     ■ Früher Zugang zu neuen Features (Beta)     ■ Anerkennung: Key-User-Status ist sichtbar (z. B. im Intranet)     ■ Direkte Verbindung zur IT-Leitung — kurzer Kommunikationsweg

 

PHASE 1 — VOR DEM LAUNCH (4 Wochen vorher):   ■ GF-Kommunikation: Warum Governance? Was ändert sich? Was bleibt?   ■ Abteilungsleiter-Briefing: Persönlich, nicht per E-Mail   ■ Key User identifizieren und einbinden   ■ FAQ-Dokument erstellen: Die 10 häufigsten Fragen beantwortet   PHASE 2 — LAUNCH:   ■ Alle-Mitarbeiter-Kommunikation: Kurz, klar, positiv formuliert   ■ "Was bedeutet das für mich?" — je Rolle eine klare Botschaft   ■ Schulungsangebote ankündigen (Termine, Formate, Themen)   ■ Feedback-Kanal öffnen: Wo melde ich Probleme und Fragen?   PHASE 3 — NACH DEM LAUNCH (laufend):   ■ Monatliches BI-Community-Treffen (60 Min.): Key User + IT + Controlling   ■ Erfolge kommunizieren: "Dank zertifizierter Berichte konnten wir..."   ■ Quick Wins zeigen: Welche neuen Berichte wurden in kurzer Zeit geliefert?   ■ Feedback aufnehmen und umsetzen — sichtbar machen, was sich geändert hat

 

 

 

ZIELGRUPPE 1 — ENDANWENDER (alle BI-Nutzer):   Format:   1-stündiges Online-Training + kurzes Praxis-Tutorial   Inhalt:   Offizielle Berichte finden und nutzen, Grundnavigation,             Was darf ich teilen? Was nicht?   Frequenz: Einmalig bei Onboarding, Auffrischung jährlich   ZIELGRUPPE 2 — KEY USER (je Abteilung 1–2 Personen):   Format:   2-tägige Präsenzschulung + monatliches Community-Treffen   Inhalt:   Berichte bauen (Zone 2), Datenmodell verstehen, Qualitätsprüfung,             Governance-Prozesse, DSGVO-Grundlagen für BI   Frequenz: Grundschulung + laufende Community-Treffen   ZIELGRUPPE 3 — BI-ENTWICKLER (IT/Controlling):   Format:   Externe Zertifizierung + interne Deep-Dives   Inhalt:   Datenmodellierung, ETL, Sicherheitskonzepte, Tool-Administration,             Advanced Analytics, DSGVO-technische Umsetzung   Frequenz: Mindestens eine Weiterbildungsmaßnahme pro Jahr

 

 

 

30-Tage-Governance-Plan

 

 

Governance in ein bestehendes, gewachsenes SSBI-Umfeld einzuführen ist anders als ein Greenfield-Projekt. Es braucht Fingerspitzengefühl, klare Kommunikation — und realistische Erwartungen.

 

VOR DEM START Holen Sie sich das Mandat der Geschäftsführung — schriftlich, mit klarer Botschaft: "Governance ist Unternehmensinteresse, nicht IT-Wunsch." Ohne GF-Rückendeckung wird jede Governance-Initiative von Fachabteilungen unterlaufen. Mit GF-Rückendeckung ist der Weg frei.

 

 

■ TAG 1-2: SSBI-INVENTARISIERUNG

 

■  Inventarisierungs-Workshop mit allen Abteilungsleitern (Agenda aus Kapitel 5.2)

■  Alle bekannten SSBI-Berichte, Excel-Auswertungen und Direktverbindungen sammeln

■  Berichts-Inventar-Tabelle anlegen: Name, Abteilung, Verantwortlicher, Datenbasis

■  Offene Datenbankverbindungen identifizieren: Wer greift direkt auf welche Systeme zu?

 

■ TAG 3-4: RISIKOBEWERTUNG

 

■  Jeden inventarisierten Bericht nach Datenschutzrelevanz bewerten (hoch/mittel/niedrig)

■  Kritische Funde: Berichte mit personenbezogenen Daten ohne Datenschutzprüfung

■  Direkte ERP-Verbindungen aus Fachabteilungen: Liste für sofortige Maßnahme

■  Datenschutzbeauftragten einbinden: Erstbewertung der kritischen Funde

 

■ TAG 5-7: SOFORTMASSNAHMEN

 

■  Kritische Datenschutzverstöße sofort adressieren — nicht auf Konzept warten

■  Direkte Produktiv-DB-Verbindungen aus Fachabteilungen sperren (mit Alternativangebot!)

■  Key User je Abteilung identifizieren und ansprechen

■  GF-Briefing: Ergebnisse der Bestandsaufnahme — was wurde gefunden, was ist zu tun?

 

 

 

 

■ TAG 8-10: GOVERNANCE-FRAMEWORK AUSARBEITEN

 

■  Drei-Zonen-Modell (Kapitel 6.1) auf Unternehmenssituation anpassen

■  Rollen und Verantwortlichkeiten festlegen — konkrete Namen, nicht nur Funktionen

■  SSBI-Richtlinie (Kapitel 6.4) ausarbeiten — maximal 2 Seiten, klar formuliert

■  Datenschutzbeauftragten: DSGVO-Checkliste (Kapitel 3.3) durchgehen

 

■ TAG 11-12: TECHNISCHE SCHUTZMASSNAHMEN PLANEN

 

■  Row-Level Security: Für welche Tabellen und Dimensionen ist sie notwendig?

■  Datenmaskierung: Welche Felder müssen für welche Rollen maskiert werden?

■  Audit Logging: Welche Zugriffe sollen protokolliert werden?

■  Export-Beschränkungen im BI-Tool konfigurieren

 

■ TAG 13-14: ZERTIFIZIERUNGSMODELL EINFÜHREN

 

■  Drei Klassen definieren (Gold/Silber/Bronze — Kapitel 7.1)

■  Visuelles Kennzeichnungssystem im BI-Tool einrichten

■  Alle bestehenden Berichte vorläufig auf "Bronze/Nicht geprüft" setzen

■  Liste der Berichte, die als Gold zertifiziert werden sollen, priorisieren

 

 

■ TAG 15-17: TECHNISCHE UMSETZUNG

 

■  Row-Level Security für die wichtigsten Dimensionstabellen implementieren

■  Datenmaskierung für personenbezogene Felder aktivieren

■  Audit-Log-Tabelle anlegen und ETL-Protokollierung erweitern

■  Export-Berechtigungen im BI-Tool überarbeiten

 

■ TAG 18-19: KEY-USER-SCHULUNG

 

■  Key User (alle Abteilungen zusammen): Halbtägige Schulung

■  Inhalte: Governance-Framework, Zonen-Modell, Prüfprozess, Zone-2-Berichte bauen

■  DSGVO-Grundlagen: Was darf in einen Bericht — was nicht?

■  Feedback sammeln: Was fehlt? Was ist unklar?

 

■ TAG 20-21: ERSTE GOLD-ZERTIFIZIERUNGEN

 

■  Top-3-GF-Berichte durch Gold-Zertifizierungsprozess führen (Kapitel 7.2)

■  Controlling prüft Berechnungslogik, Datenschutzbeauftragter gibt Freigabe

■  Erste zertifizierte Berichte als Vorzeigebeispiele kommunizieren

■  Berichtskatalog mit ersten Einträgen live schalten

 

 

■ TAG 22-24: KOMMUNIKATIONS-LAUNCH

 

■  GF-Kommunikation an alle Mitarbeiter: Was ist Governance, was ändert sich?

■  Abteilungs-Briefings durch Key User — mit Unterstützung der IT

■  FAQ-Dokument veröffentlichen — im Intranet, nicht als E-Mail-Anhang

■  Feedback-Kanal aktivieren: Eine E-Mail-Adresse, ein Ansprechpartner

 

■ TAG 25-27: ENDANWENDER-SCHULUNG

 

■  1-stündiges Online-Training für alle BI-Nutzer

■  Aufzeichnung erstellen für neue Mitarbeiter (Onboarding-Pflichttraining)

■  Kurzanleitung (1 Seite): Was ist Gold/Silber/Bronze, was darf ich teilen?

 

■ TAG 28-30: REVIEW & ROADMAP

 

■  Erste Feedback-Runde mit Key Usern: Was funktioniert, was nicht?

■  Offene Punkte priorisieren: Was wird in Monat 2 angegangen?

■  Berichtskatalog Stand: Wie viele Berichte inventarisiert, wie viele zertifiziert?

■  Datum für erstes monatliches BI-Community-Treffen festlegen

■  90-Tage-Roadmap: Welche weiteren Berichte werden zertifiziert? Welche technischen Maßnahmen folgen? ■

 

ERGEBNIS NACH 30 TAGEN Sie haben ein dokumentiertes SSBI-Governance-Framework, eine schriftliche SSBI-Richtlinie, ein Berichtsinventar mit Risikobewertung, erste zertifizierte Gold-Berichte, geschulte Key User und technische Basisschutzmaßnahmen aktiv. Kein perfektes System — aber ein funktionierendes Fundament, das in den nächsten Monaten konsequent ausgebaut wird.

 

 

 

 

Die in diesem Dokument enthaltenen Empfehlungen, Governance-Muster, SQL-Skripte und Checklisten wurden nach bestem Wissen und Gewissen auf Grundlage langjähriger praktischer Erfahrung erarbeitet. Dennoch kann keine Gewähr für Vollständigkeit, Richtigkeit oder Aktualität übernommen werden.

 

Der Autor übernimmt ausdrücklich keinerlei Haftung für Datenschutzverstöße, Bußgelder, Compliance-Verstöße, fehlerhafte Auswertungen, Systemausfälle oder sonstige unmittelbare oder mittelbare Schäden, die aus der Nutzung dieses Kits entstehen.

 

 

Die datenschutzrechtlichen Hinweise (DSGVO, BDSG, BetrVG) ersetzen keine juristische Beratung. Lassen Sie Ihre konkrete SSBI-Umgebung durch einen zertifizierten Datenschutzbeauftragten und gegebenenfalls einen Fachanwalt für IT-Recht prüfen. Rechtliche Anforderungen können sich ändern — prüfen Sie alle Hinweise regelmäßig auf Aktualität.

 

 

Alle SQL-Skripte wurden für Microsoft SQL Server 2022/2025 entwickelt. Testen Sie alle Skripte ausnahmslos zunächst in einer Nicht-Produktivumgebung. Der Autor haftet nicht für Schäden durch unsachgemäße Anwendung.

 

 

Dieses Dokument und alle Inhalte sind urheberrechtlich geschützt. © 2026 Sascha Hess, xenosystems.de. Alle Rechte vorbehalten.

 

 

Power BI ist eine eingetragene Marke der Microsoft Corporation. Tableau ist eine eingetragene Marke der Salesforce, Inc. Alle weiteren Produktnamen sind Eigentum ihrer jeweiligen Inhaber.

 

 

Es gilt ausschließlich deutsches Recht. Gerichtsstand ist, soweit gesetzlich zulässig, Weimar, Thüringen, Deutschland.

 

 

 

Sascha Hess ist Diplom-Biologe und IT-Professional mit über 20 Jahren Erfahrung in der Administration von ERP-, BI- und Datenbanksystemen. Er hat Self-Service-BI-Rollouts, Governance-Frameworks und Datenschutzkonzepte für mittelständische Unternehmen, Universitäten und Energieversorger konzipiert und umgesetzt — mit besonderem Fokus auf die Verbindung von technischer Solidität und organisatorischer Akzeptanz.

 

Sein Ansatz: Governance, die Fachabteilungen befähigt statt einschränkt — und IT-Sicherheit, die im Alltag funktioniert statt auf dem Papier zu existieren.

 

Web: www.xenosystems.de | E-Mail: info@xenosystems.de | Standort: Weimar, Thüringen / Remote

 

Service	Beschreibung
BI-Governance-Setup	Aufbau eines praxistauglichen SSBI-Governance-Frameworks — Inventarisierung, Richtlinie, Zertifizierungsmodell, Key-User-Konzept. Scope: 5–10 Tage.
BI-Dashboard-Aufbau	Power BI / DeltaMaster GF-Dashboards inkl. KPI-Definition, Datenmodell und ETL-Strecken — für KMU ab 1 Woche Projektumfang.
DSGVO-Check BI-Umgebung	Datenschutz-Audit Ihrer BI-Landschaft — Risikoanalyse, Maßnahmenplan, Abstimmung mit DSB. Scope: 2–3 Tage.
SQL Server DB Health Check	Professioneller Audit Ihres SQL Servers — Managementreport, Risikobewertung und Maßnahmenplan. Scope: 3–5 Tage.
Interim IT-Management	Übernahme der IT-Steuerung auf Zeit — Budgetplanung, Dienstleister-Management, strategische IT-Ausrichtung.