Portale und Apps in Finanz- und Versicherungsorganisationen bedienen zwei Nutzergruppen aus derselben Systemwelt: die Endkundinnen und Endkunden am Frontend und die Beraterinnen und Berater, die dieselben Vorgänge im Hintergrund bearbeiten. Wer nur die Endkundenseite erhebt, spezifiziert die Hälfte des Systems.
Ausgangslage
In vielen Häusern mit Endkunden- und Beraterfrontends teilen sich beide Seiten die Datenbasis, die Prozesse und oft die Freigaben. Ein Antrag, den ein Endkunde im Portal stellt, erscheint in der Ansicht der Beraterin, wird dort geprüft, ergänzt und freigegeben. Die Anforderungserhebung beginnt fast immer auf der Endkundenseite, weil dort der Relaunch sichtbar ist und die Zielgruppe über Panels erreichbar. Die Beraterseite ist intern, meist nur über den Vertrieb ansprechbar, und bleibt in der Erhebung aus.
Das Ergebnis ist ein Anforderungsdokument, das die Endkundenaufgaben beschreibt und die Beraterseite aus Systemsicht ableitet: Was der Endkunde eingibt, muss die Beraterin sehen. Dass die Beraterin dabei andere Aufgaben erledigt, mit anderen Arbeitsmitteln und unter anderem Zeitdruck, kommt nicht vor.
Wir haben bei einem Finanzdienstleister über mehrere Jahre ein Portal begleitet, das mehrere Nutzergruppen aus einer Systemwelt gleichzeitig bedient. Der Erkenntnissprung kam aus Hospitationen vor Ort bei den internen Nutzergruppen. Das Vorgehen aus diesem Projekt beschreibt der Beitrag.
Beide Gruppen getrennt erheben
Der erste Schritt ist die Entscheidung, beide Gruppen als eigene Nutzergruppen nach ISO 9241-210 zu führen, mit eigenem Nutzungskontext. Für die Endkundenseite reichen oft Interviews und Tests mit rekrutierten Teilnehmenden. Für die Beraterseite ist die Hospitation das Mittel der Wahl: neben der Beraterin sitzen, die Vorgänge mitverfolgen, die Arbeitsmittel notieren, die Unterbrechungen zählen.
Die Hospitation braucht einen Zugang, den der Vertrieb oder die Bereichsleitung öffnet, und einen Rahmen für den Datenschutz, weil auf dem Bildschirm Kundendaten stehen. Beides ist zu klären, bevor die Erhebung geplant wird. Die Erfahrung aus dem Projekt: Der Zugang ist die größere Hürde, der Datenschutz die besser lösbare, weil dafür Verfahren existieren (Vertraulichkeitserklärung, keine Aufzeichnung, Protokoll ohne Kundendaten).
Zwei Kontextbeschreibungen, ein Dokument
Beide Kontextbeschreibungen stehen im selben Anforderungsdokument, als zwei Abschnitte mit derselben Struktur: Nutzende, Aufgaben, Arbeitsmittel, Umgebung. Die Aufgabenlisten werden nebeneinandergelegt. Dabei zeigt sich, welche Aufgaben nur eine Seite hat, welche beide Seiten in verschiedenen Rollen ausführen und an welchen Stellen ein Vorgang von einer Seite auf die andere übergeht.
Diese Übergabepunkte sind der Kern der Doppelnutzerschaft. Ein Antrag, der auf der Endkundenseite abgeschickt wird, ist auf der Beraterseite ein Eingang mit Prüfaufgabe. Was der Endkunde als Abschluss erlebt, ist für die Beraterin ein Anfang. Die Anforderungen an den Übergabepunkt werden für beide Seiten getrennt formuliert und aufeinander bezogen.
Anforderungen je Gruppe formulieren
Jede Nutzungsanforderung nennt die Gruppe, für die sie gilt. „Nutzende müssen den Status des Antrags erkennen können" ist unvollständig. Für den Endkunden heißt Status: eingegangen, in Prüfung, zurückgestellt, entschieden. Für die Beraterin heißt Status: wer prüft, seit wann, was fehlt, welche Frist läuft. Aus einer Anforderung werden zwei, mit unterschiedlichen Maßstäben für die Erfüllung.
Anforderungen, die beide Seiten betreffen, erhalten beide Gruppenkennungen und werden im Review aus beiden Perspektiven gelesen. Dabei entstehen Konflikte: Was für den Endkunden eine Vereinfachung ist (weniger Pflichtfelder), ist für die Beraterin eine Rückfrage mehr. Der Konflikt wird im Dokument festgehalten, mit beiden Anforderungen und ihren Quellen. Er wird nicht dadurch gelöst, dass eine Seite die andere überschreibt.
Priorisieren mit beiden Seiten
In der Priorisierung liegen die Anforderungen beider Gruppen nebeneinander. Im Projekt hat eine Kano-Analyse geholfen, die Anforderungen nach ihrer Wirkung auf die Zufriedenstellung zu ordnen; die Methode ist eine von mehreren, die für diese Stelle passen. Entscheidend ist, dass die Beraterseite mit eigenen Daten in die Priorisierung eingeht und nicht als Ableitung aus der Endkundenseite.
Grenzen
Das Vorgehen verdoppelt den Erhebungsaufwand an der Stelle, an der bisher gar nicht erhoben wurde. Es setzt voraus, dass die Organisation den Zugang zur Beraterseite öffnet. Und es stößt an Grenzen, wenn mehr als zwei Gruppen dasselbe System bedienen; dann gilt dasselbe Prinzip, mit mehr Abschnitten. Wirkungszahlen aus dem Projekt liegen nicht vor.
Was danach vorliegt
Ein Anforderungsdokument mit zwei Kontextbeschreibungen, zwei Aufgabenlisten mit markierten Übergabepunkten, Nutzungsanforderungen mit Gruppenkennung und dokumentierten Konflikten zwischen beiden Seiten. Produktmanagement kann damit beide Frontends aus derselben Grundlage steuern. Und die Beraterinnen und Berater, die das System täglich bedienen, sind mit eigenen Beobachtungen im Dokument vertreten.