Skip to content

Zentrale Entscheidungsfragen

Wir haben euch hier wichtige Fragen zusammengestellt, die ihr bei der Mitbestimmung zu OSIRIS klären solltet. Sie sind nicht abschließend und können je nach Einrichtung ergänzt werden. Es gibt auf jede Frage verschiedene mögliche Antworten, die jeweils Vor- und Nachteile haben. Die Entscheidung sollte gemeinsam von Arbeitgeber, Betriebsrat, Datenschutz, IT und Fachverantwortlichen getroffen werden.

1. Ist die Nutzung verpflichtend?

Beschäftigte bestimmter Gruppen müssen definierte dienstliche Aktivitäten in OSIRIS erfassen.

Vorteile

  • höhere Vollständigkeit und Vergleichbarkeit;
  • verlässliche Grundlage für Berichtspflichten;
  • weniger parallele Abfragen und Listen;
  • klare Zuständigkeit für Datenqualität.

Nachteile

  • Eingabeaufwand muss als Arbeitsaufgabe berücksichtigt werden;
  • Pflichtfelder und Fristen müssen besonders klar begründet sein;
  • Fehler oder fehlende Einträge dürfen nicht automatisch als Leistungsmangel interpretiert werden;
  • Schulung, Vertretung und barrierearme Nutzung werden wichtiger.

Notwendige Kerndaten sind verpflichtend; Profilangaben und zusätzliche Aktivitäten bleiben freiwillig.

Vorteile

  • gute Balance zwischen Berichtsfähigkeit und Selbstbestimmung;
  • freiwillige Außendarstellung lässt sich klar abgrenzen;
  • weniger unnötige Daten.

Nachteile

  • die Grenze zwischen Pflicht und Freiwilligkeit muss im Interface eindeutig sein;
  • freiwillige Felder können durch soziale Erwartungen faktisch verpflichtend werden;
  • Berichte dürfen nicht unbemerkt von freiwilligen Angaben abhängen.

Beschäftigte entscheiden selbst, ob und in welchem Umfang sie Daten eintragen.

Vorteile

  • hohe Selbstbestimmung;
  • geringerer Rechtfertigungsdruck für zusätzliche Angaben.

Nachteile

  • lückenhafte Berichte;
  • zusätzlicher Aufwand durch andere Erhebungswege;
  • mögliche Verzerrungen bei institutionellen Darstellungen.

Praxistauglicher Ausgangspunkt

Häufig ist ein verpflichtender, begrenzter Kerndatensatz mit freiwilligen Profil- und Veröffentlichungsangaben am praktikabelsten.

2. Wer darf Aktivitäten intern sehen?

Alle angemeldeten Personen können Aktivitäten aller Beschäftigten sehen.

Pro

  • fördert Vernetzung und Zusammenarbeit;
  • erleichtert das Auffinden von Expertise;
  • macht Forschungsaktivitäten transparent.

Contra

  • schafft faktisch ein internes Personen- und Leistungsregister;
  • erhöht das Risiko informeller Vergleiche;
  • kann bei Projekten, Anträgen oder vertraulichen Aktivitäten ungeeignet sein.

Aktivitäten sind nur für beteiligte Personen und zuständige Rollen sichtbar.

Pro

  • entspricht dem Prinzip der minimalen Berechtigung;
  • reduziert Vergleichs- und Missbrauchsrisiken;
  • eignet sich besser für noch nicht öffentliche Inhalte.

Contra

  • weniger interne Vernetzung;
  • komplexeres Berechtigungskonzept;
  • mögliche Unsicherheit darüber, wer einen Eintrag sehen kann.

Sichtbarkeit hängt von Aktivitätstyp, Status und Freigabe ab.

Pro

  • verbindet Datenschutz mit interner Auffindbarkeit;
  • vertrauliche Entwürfe können geschützt bleiben;
  • veröffentlichte Informationen können breiter sichtbar sein.

Contra

  • höherer Konfigurations- und Erklärungsaufwand;
  • falsche Statuswerte können zu unbeabsichtigter Sichtbarkeit führen.

3. Wie werden Daten öffentlich sichtbar?

Daten werden erst nach ausdrücklicher Freigabe durch die betroffene Person veröffentlicht.

Pro

  • hohe Kontrolle und Transparenz;
  • besonders geeignet für Fotos, Biografien und freiwillige Profile.

Contra

  • Profile können unvollständig bleiben;
  • Freigaben müssen verständlich und widerrufbar gestaltet sein.

Definierte dienstliche Informationen werden standardmäßig veröffentlicht; einzelne Inhalte können ausgeblendet werden.

Pro

  • vollständigere Außendarstellung;
  • geringerer Pflegeaufwand.

Contra

  • setzt sehr klare Information und leicht zugängliche Steuerung voraus;
  • für freiwillige oder besonders persönliche Angaben ungeeignet;
  • kann Beschäftigte unter faktischen Rechtfertigungsdruck setzen.

Die Einrichtung definiert einen kleinen obligatorischen öffentlichen Datensatz; zusätzliche Inhalte benötigen eine Freigabe.

Pro

  • verlässliche Grunddarstellung;
  • freiwillige Angaben bleiben kontrollierbar;
  • Datenminimierung ist leichter nachweisbar.

Contra

  • Abgrenzung und Benutzeroberfläche müssen sorgfältig gestaltet werden.

Freiwilligkeit muss im Interface erkennbar sein

Ein Hinweis allein genügt praktisch nicht. Freiwillige Felder sollten klar markiert, nicht vorausgewählt und ohne Nachteile leer lassbar sein. Die öffentliche Vorschau sollte zeigen, welche Daten tatsächlich erscheinen.

4. Wie wird Leistungs- und Verhaltenskontrolle ausgeschlossen?

Ein pauschaler Satz wie „OSIRIS wird nicht zur Leistungs- und Verhaltenskontrolle verwendet“ ist wichtig, aber allein nicht ausreichend. Er sollte durch konkrete Regeln ergänzt werden.

Zu klären sind insbesondere:

  • Sind personenbezogene Ranglisten oder Benchmarks ausgeschlossen?
  • Dürfen Aktivitätszahlen in Personalgesprächen verwendet werden?
  • Sind Vergleiche zwischen Personen, Projekten oder Abteilungen zulässig?
  • Wer darf personenbezogene Zeitreihen sehen?
  • Welche aggregierten Auswertungen sind zulässig?
  • Wie klein dürfen Gruppen bei aggregierten Berichten sein?
  • Dürfen Nutzungs- und Änderungsprotokolle fachlich ausgewertet werden?
  • Wie wird verhindert, dass fehlende Einträge als fehlende Leistung interpretiert werden?

Personenbezogene OSIRIS-Daten dürfen nicht zur Bewertung von Leistung oder Verhalten verwendet werden.

Pro

  • einfach kommunizierbar;
  • hoher Schutz und hohes Vertrauen;
  • reduziert Zweckentfremdung.

Contra

  • kann mit legitimen individuellen Anwendungsfällen kollidieren, etwa einem selbst erstellten Lebenslauf;
  • Begriffe wie „Bewertung“, „Qualitätssicherung“ und „Planung“ müssen abgegrenzt werden.

Bestimmte personenbezogene Nutzungen werden abschließend benannt, alle anderen bleiben ausgeschlossen.

Pro

  • bildet reale Berichtspflichten und Eigeninteressen differenzierter ab;
  • schafft Klarheit für zulässige Einzelfälle.

Contra

  • höherer Regelungsaufwand;
  • Ausnahmen können schleichend erweitert werden;
  • jede Ausnahme benötigt Zweck, Rollen, Schutzmaßnahmen und Prüfung.

Technische Möglichkeit zählt

Auch wenn eine Auswertung organisatorisch verboten ist, sollte sie technisch möglichst nicht allgemein verfügbar sein. Schutzregeln sind belastbarer, wenn Oberfläche, Rollen und Exportrechte sie unterstützen.

5. Wie detailliert wird das Berechtigungskonzept geregelt?

Pro

  • hohe Verbindlichkeit und Transparenz;
  • Änderungen sind nicht unbemerkt möglich.

Contra

  • kleine organisatorische Änderungen können eine formelle Anpassung auslösen;
  • technische Rollen und Vertragstext driften leicht auseinander.

Pro

  • flexibel und wartungsarm;
  • technische Details können schneller angepasst werden.

Contra

  • ohne kontrollierte Anlage besteht das Risiko zu weiter Berechtigungen;
  • Beschäftigte können ihre tatsächliche Sichtbarkeit schlechter nachvollziehen.

Die BV definiert Rollenprinzipien und Änderungsschwellen; eine versionierte Anlage enthält die konkreten Rechte.

Pro

  • verbindet Verbindlichkeit und Wartbarkeit;
  • Änderungen und Freigaben sind nachvollziehbar.

Contra

  • erfordert konsequentes Versions- und Änderungsmanagement.

6. Wer darf Daten korrigieren?

Pro:

  • effiziente Qualitätssicherung und schnelle Berichte.
  • Korrekturen werden mit der Versionshistorie festgehalten
  • Autoren werden benachrichtigt und können Änderungen nachvollziehen.

Contra: Änderungen können inhaltliche Verantwortung verschieben.

Pro: hohe Kontrolle und klare Verantwortlichkeit.

Contra: Qualitätsprobleme können nur über Rückfragen behoben werden; Berichte verzögern sich.

Formale Angaben dürfen direkt korrigiert werden; inhaltliche Änderungen werden zur Überarbeitung zurückgegeben.

Pro: gute Balance aus Qualität und Selbstkontrolle.

Contra: Abgrenzung zwischen formaler und inhaltlicher Änderung muss definiert sein. Mehr Arbeit für die eintragende Person, da sie Korrekturen prüfen und freigeben muss.

OSIRIS unterstützt die Nachvollziehbarkeit von Änderungen, denn:

  • Ändernde Person, Zeitpunkt und Art der Änderung sind nachvollziehbar.
  • Die betroffene Person wird über wesentliche Korrekturen informiert.
  • Inhaltliche Konflikte haben einen geregelten Klärungsweg.
  • Technische Administration greift nur bei begründeten Betriebsfällen auf Inhalte zu.

7. Wie werden Systemänderungen behandelt?

Jede funktionale Änderung benötigt vorab die Zustimmung des Betriebsrats.

Pro

  • maximale Kontrolle;
  • geringe Gefahr schleichender Zweck- oder Funktionsausweitung.

Contra

  • hoher Abstimmungsaufwand;
  • Sicherheits-, Fehler- und Komfortverbesserungen können verzögert werden;
  • der Begriff „funktionale Änderung“ bleibt häufig auslegungsbedürftig.

Normale technische Fortentwicklung ist freigegeben; nur neue Funktionen benötigen Zustimmung.

Pro

  • geringer Pflegeaufwand;
  • Updates bleiben praktikabel.

Contra

  • die Grenze zu einer neuen oder wesentlich veränderten Funktion ist unklar;
  • kumulative kleine Änderungen können die Verarbeitung deutlich verändern.

Änderungen werden anhand fester Kriterien klassifiziert.

Pro

  • nachvollziehbar, skalierbar und alltagstauglich;
  • Beteiligung konzentriert sich auf materielle Risiken.

Contra

  • benötigt eine gepflegte Änderungsdokumentation;
  • Grenzfälle brauchen einen Eskalationsweg.

Empfohlene Änderungsmatrix

Änderung Beispiele Verfahren
Technischer Betrieb Sicherheitsupdate, Fehlerbehebung, Update von externen Bibliotheken, keine neuen Datenflüsse durchführen, dokumentieren; regelmäßige Information
Geringfügige Konfiguration Bezeichnung, Hilfetext, barrierearme Darstellung, Sortierung ohne neue Aussage dokumentieren; bei vereinbartem Turnus informieren
Relevante Funktionsänderung neuer Workflow, neue Rollenrechte, neue Protokollierung, neue personenbezogene Ansicht vorab Datenschutz- und Mitbestimmungsprüfung
Neue oder geänderte Verarbeitung neue Zwecke, Datenkategorien, Schnittstellen, Empfänger, öffentliche Sichtbarkeit oder personenbezogene Auswertung vor Umsetzung förmliche Freigabe; BV/VVT/Konzepte aktualisieren
Eiländerung zur Sicherheit akute Schwachstelle oder notwendige Schadensbegrenzung sofortige Schutzmaßnahme möglich; unverzügliche Dokumentation und nachgelagerte Beteiligung

Kumulative Änderungen berücksichtigen

Mehrere einzeln kleine Änderungen können zusammen eine wesentliche Veränderung ergeben. Innerhalb von OSIRIS ist deshalb ein Changelog vorhanden, das Nutzungs- und Funktionsänderungen dokumentiert. Die Projektleitung sollte regelmäßig prüfen, ob kumulative Änderungen eine Mitbestimmungspflicht auslösen.

8. Was geschieht nach dem Ausscheiden?

Pro: Publikationen und Projekte bleiben nachvollziehbar; historische Berichte funktionieren weiter.

Contra: Personenbezug bleibt bestehen; Zweck, Sichtbarkeit und Dauer müssen begründet werden.

Pro: konsequente Datenminimierung und einfache Kommunikation.

Contra: institutionelle Forschungsleistungen, Berichte und historische Zusammenhänge können verloren gehen.

Nach dem Ausscheiden werden Personen inaktiviert und bleiben als ehemalige Person erhalten. Nach einer definierten Frist werden personenbezogene Daten gelöscht oder anonymisiert. Diese Frist kann meist aus Berichtspflichten, Archivierungs- oder Publikationsinteressen abgeleitet werden. So sollen Forschungsdaten beispielsweise für mindestens zehn Jahre erhalten bleiben. Für eine Leibniz-Evaluierung ist eine Aufbewahrung von mindestens 7 Jahren sinnvoll.

Pro: ermöglicht Berichte und historische Zusammenhänge; personenbezogene Daten werden nach Frist gelöscht.

Contra: Fristen müssen begründet und technisch umgesetzt werden; die Löschung muss überprüfbar sein.

Name ist keine Anonymisierung

Bleibt ein Name erhalten oder kann eine Person mit vertretbarem Aufwand wieder zugeordnet werden, handelt es sich grundsätzlich weiterhin um personenbezogene Daten. Für echte Anonymisierung genügt es nicht, Profilfelder zu entfernen.

9. Welche Schnittstellen und Exporte sind zulässig?

Für jede Schnittstelle und jeden Export sollten mindestens Zweck, Datenumfang, Richtung, Häufigkeit, Empfänger, Rechtsgrundlage, Zugriffsschutz und Löschung beschrieben werden.

Nur ausdrücklich vereinbarte Schnittstellen und Exporte sind zulässig.

Pro: hohe Kontrolle und klare Zweckbindung.

Contra: neue Berichtspflichten können formale Anpassungen erfordern.

Die BV definiert zulässige Kategorien; konkrete Schnittstellen werden über ein geregeltes Verfahren freigegeben.

Pro: flexibler und trotzdem nachvollziehbar.

Contra: Kategorien dürfen nicht so weit sein, dass sie praktisch keine Begrenzung darstellen.

10. Sollen spielerische Elemente oder Kennzahlen genutzt werden?

Coins, Erfolge, Fortschrittsanzeigen und ähnliche Funktionen können zur Datenpflege motivieren. Sie können aber auch als Leistungsindikatoren missverstanden werden.

Mögliche Schutzregeln:

  • standardmäßig nur für die betroffene Person sichtbar;
  • individuell deaktivierbar;
  • keine zentrale Auswertung deaktivierter Werte;
  • keine Ranglisten;
  • transparente Berechnungslogik;
  • keine Verwendung für Personalentscheidungen oder leistungsorientierte Mittelvergabe;
  • gesonderte Beteiligung vor jeder Erweiterung des Nutzerkreises oder Zwecks.

In OSIRIS sind Coins und Erfolge standardmäßig nur für die betroffene Person sichtbar. Sie können individuell deaktiviert oder öffentlich sichtbar gemacht werden. Jede Entscheidung lässt sich konsequenzlos widerrufen. Ranglisten, Auswertungen und Leistungsindikatoren sind nicht vorgesehen. Coins werden nicht in der Datenbank gespeichert sondern individuell bei Anzeige berechnet. Entsprechend sind sie auch nicht durch technisches Personal auswertbar. Die Berechnungslogik ist transparent und kann jederzeit nachvollzogen werden.