Künstliche Intelligenz im Dienste der Diversität

C2: Spezifische PdV-Anforderungsklärung

PreviousC1: Vorstellung der Software für das PdV NextC3: Testfall Definition

Last updated 1 year ago

C2: Spezifische PdV-Anforderungsklärung

Formulierung von KIDD-KPIs im KIDD-Prozess

Einordnung in den KIDD-Prozess Vor der Formulierung von KIDD-KPIs steht die Formulierung konkreter KIDD-Ziele bezüglich Diversität im .

Im (Adaption/Entwicklung) beginnt das PdV einen Aushandlungsprozess mit den Softwareentwicklern über ethische und diskriminierungssensible Gestaltungsoptionen der Software und formuliert konkrete, softwarebezogene Empfehlungen (). Dabei wird auch die Formulierung von KIDD-KPIs vorgenommen, die als Fairness-Kennzahlen dienen.

Anschließend erfolgt in die Definition von Testfällen, um die PdV-Anforderungen/Ziele sowie die formulierten KPIs und die am System vorgenommenen Anpassungen zu überprüfen.

Begriffsdefinitionen

KPI (Key Performance Indicator): Eine Leistungskennzahl, mit der der Fortschritt oder Erfüllungsgrad bezüglich einer Zielsetzung gemessen werden kann. Die Messung erfolgt im Betrieb, ex post.

Testfälle: Überprüfung der gewünschten Funktionsweise eines Systems in einem spezifischen Anwendungsfall. Ein Testfall definiert Inputs ins System, die erwartete Funktionsweise und die erwarteten Outputs des Systems. Während der Testphase wird die tatsächliche Funktionsweise mit der erwarteten verglichen.

Beispiel: „Wenn im Lebenslauf nur der Geburtsort geändert wird, sollte dies keinen Einfluss auf die Platzierung in einer Shortlist für eine Stelle haben.“

Um sicherzustellen, dass ein System aus Sicht des Panels der Vielfalt fair ist, müssen Zielsetzungen, KPIs und Testfälle definiert und überwacht werden (Monitoring).

Formulierung von KIDD-KPIs (ex post)

Neben der Möglichkeit, die Fairness des AES bezüglich Diversität anhand konkreter KIDD-Ziele zu überprüfen, besteht die Option, relevante Daten im Betrieb zu erheben, in KPIs darzustellen und mit einem definierten Fairness-Zielkorridor zu vergleichen.

Die Fairness-Kennzahlen gehen nicht von Anfang an in die Zielvorgaben des AES ein. Sie werden im Nachhinein (ex post) erhoben und mit einem Zielkorridor verglichen. Bewegt sich ein KPI außerhalb dieses Korridors, müssen Maßnahmen diskutiert und ergriffen werden.

Das AES erhält eine Reihe von Zielvorgaben.

Beispiel:

„Eine Person sollte eher auf der Shortlist erscheinen, wenn sie mehr Erfahrung mit den geforderten Skills hat.“ oder „Eine Person sollte eher auf der Shortlist erscheinen, wenn sie bereits Erfahrung in der Branche hat.“

Zusätzlich werden KIDD-Ergebnis-KPIs definiert, die im Betrieb überwacht werden sollen. Beispiele hierfür sind:

„Anteil der Personen aus Gruppe Y auf der Shortlist“
„Anteil der Personen aus Gruppe Y auf der Shortlist im Verhältnis zum Anteil der Personen aus Gruppe Y unter den Bewerbern für diese Stelle“
„Anteil der Personen aus Gruppe Y auf der Shortlist im Verhältnis zum Anteil der Personen aus Gruppe Y in der Gesamtbevölkerung.“

Für jede KIDD-KPI wird zudem ein Zielkorridor definiert, beispielsweise: „Der Wert darf nicht mehr als 10 % nach oben oder nach unten abweichen.“

Sollte eine KPI im Betrieb einen Messwert außerhalb des Zielkorridors zeigen, wird eine Warnmeldung ausgegeben. Ein Beispiel hierfür wäre: „Der Anteil der Personen aus Gruppe Y auf der Shortlist ist zu niedrig.“

In einem solchen Fall werden von den zuständigen Stellen die Gründe analysiert und Maßnahmen ergriffen, um dies zu ändern. Beispielsweise:

Es gibt nicht genügend Bewerber aus Gruppe Y → Es sind bessere Werbemaßnahmen erforderlich.
Es gibt nicht genügend Bewerber mit Qualifikation Z in Gruppe Y → Es sollte diskutiert werden, ob Qualifikation Z tatsächlich für die Aufgabe erforderlich ist. Falls ja, könnten Schulungsmaßnahmen für Gruppe Y eingeführt werden. Falls nein, könnte die Bewertung von Qualifikation Z im AES herabgesetzt werden.

Es gibt zwei Ansätze, um Fairness-Kennzahlen im AES abzubilden, beide haben ihre Vor- und Nachteile:

Wenn Fairness-Kennzahlen als feste Zielvariablen verwendet werden, die die Funktionsweise des AES bestimmen, führen sie direkt zum festgelegten Ziel. Nachteil dabei ist, dass sich die Ergebnisse im Vergleich zu anderen Zielvariablen tendenziell verschlechtern.

Der zweite Ansatz verwendet Fairness-Kennzahlen als im Betrieb überwachte KPIs. Ihre Wirkung tritt indirekt ein und erfordert organisatorische Maßnahmen, die zuerst analysiert und dann umgesetzt werden müssen. Vorteil ist, dass er die Möglichkeit bietet, durch diese Maßnahmen und die Feinjustierung der Zielvariablen des AES eine qualitativ hochwertigere Gesamtlösung für das Unternehmen zu entwickeln.

Ticket-System mit Backlog

Die spezifischen Anforderungen werden in der Regel in einem Ticket-System als Features erfasst, um die Priorisierung und den Fortschritt der Umsetzung nachverfolgen zu können. Häufig werden Vorlagen für Features vorgegeben, die mehrere Felder beinhalten. Beispielhaft sind folgende Felder angegeben:

Feature Nummer:

(Eindeutige Nummer des Features)

Feature Name:

(Prägnanter Name des Features)

Problembeschreibung:

(welches Problem soll gelöst werden)

Hypothese:

(was wird sich ändern, wenn das Feature da ist)

Beschreibung des Features:

(Allgemeine Beschreibung des Features, evtl. mit Zeichnung von einzelnen Prozess-Schritten oder als konkrete UserStory: „Als ... möchte ich ..., damit ...“)

Abhängigkeiten und Risiken:

(Zu welchen anderen Features gibt es Abhängigkeiten und welche? Welche Risiken gibt es bei der Umsetzung dieses Features?)

Akzeptanzkriterien:

(welche Eigenschaften müssen erfüllt sein, damit dieses Feature abgenommen werden kann.)

Literatur