Die Ablehnung, die keine war
Am Montag kommt eine Anfrage herein: ein Raum, fünf Tage, Beginn nächste Woche. Sie öffnen den Kalender. Dienstag, Mittwoch und Donnerstag sind frei. Montag und Freitag sind von einer Gruppe belegt, die vor Monaten gebucht hat. Die Anfrage ist ein Datensatz, an dem eine einzige Entscheidung hängt, und diese Entscheidung kennt zwei Werte: freigeben oder ablehnen. Also lehnen Sie ab, schreiben eine Notiz mit den drei freien Tagen und bitten den Antragsteller, noch einmal zu buchen. Die meisten tun das. Manche nicht, und Sie erfahren nie, warum.
Nichts im System zählt diesen Vorgang als Fehlschlag. Die Anfrage wurde innerhalb der Zielvorgabe bearbeitet, und der Raum wird vermutlich genutzt. Die einzige Spur, dass etwas schiefgelaufen ist, ist Ihre Notiz, und die steht in einer E-Mail, die nie jemand auswerten wird.
Wo Modell und Entscheidung auseinandergingen
Wer das Buchungsformular entworfen hat, lag nicht falsch. Ein Antragsteller erlebt eine fünftägige Buchung als ein Ganzes, also hat das Formular sie als ein Ganzes erfasst, und die Freigabe hing daran. Das ist die natürliche erste Version der meisten Workflows.
Der Konflikt liegt zwischen zwei Einheiten, die gleich sein sollten und es nicht sind. Die Entscheidungseinheit ist die Ressource an einem bestimmten Tag: ob dieser Raum an diesem Dienstag frei ist. Die Datensatzeinheit ist die gesamte Anfrage. Die Freigabe hängt am Datensatz, also können Sie nur in dieser Auflösung antworten, obwohl die ehrliche Antwort für jeden Tag anders ausfällt.
Jeder Workaround, den Sie sich angewöhnt haben, gleicht diese Lücke aus. Der übliche ist das Kommentarfeld an der Ablehnung, und das ist derselbe Workaround in geringerer Auflösung: Die Entscheidung pro Tag existiert, aber nur als Fließtext, den jemand lesen und abtippen muss. Sie wird nie zu einem Status, also taucht sie nie in einer Auswertung oder einem Backlog auf.
Den Datensatz aufteilen, ohne dass der Antragsteller es merkt
Die Lösung, die wir mit einer nationalen Jugendplattform vereinbart haben und gerade bauen, ändert die Granularität der Datensätze und nicht das Formular. Eine Anfrage über fünf Tage wird als fünf Datensätze gespeichert, einer pro Tag, jeder für sich freigebbar. Entscheidungseinheit und Datensatzeinheit fallen jetzt zusammen.
Für sich genommen würde das die Lage verschlimmern. Bei fünf zusammenhanglosen Zeilen geht die Absicht des Antragstellers verloren, und ein Formular, das fünf Buchungen statt einer verlangt, verlagert die Arbeit auf ihn. Deshalb bleibt die Aufteilung unterhalb der Oberfläche: Der Antragsteller füllt wie bisher ein Formular aus und sieht eine Buchung in seiner Liste. Ein Kennzeichen an jedem Tagesdatensatz markiert, dass er zu einer mehrtägigen Anfrage gehört, sodass der Bearbeiter weiterhin ein zusammenhängendes Anliegen sieht.
Das ist eine Änderung am Datenmodell, kein Funktionswunsch. Produktivsysteme sammeln Workarounds an, weil niemand das Modell anfassen will. Legen Sie die Granularität einmal bewusst fest, mit einem Plan für bestehende Datensätze, statt weiter darum herumzuflicken.
Teilfreigabe als echtes Ergebnis
Sobald jeder Tag seine eigene Entscheidung trägt, kann eine Anfrage in drei Zuständen enden statt in zwei: freigegeben, abgelehnt oder teilweise freigegeben. Der dritte braucht einen eigenen Status, denn im alten Modell war die Teilerfüllung nie ein gültiges Ergebnis, sondern immer nur eine nicht erfüllte Anfrage.
Er braucht auch eine eigene Benachrichtigung, denn eine Ablehnung sagt dem Antragsteller das Gegenteil von dem, was tatsächlich passiert ist. Was er danach tut, wird dann zur Wahl statt zur Pflicht: die drei Tage behalten oder nach Alternativen für die anderen beiden fragen.
Wenn Sie erwarten, dass Nutzer eine Teilfreigabe verwirrend finden, halten Sie dagegen, was sie heute bekommen: eine Ablehnung, die sie nicht verstehen, gefolgt von der Aufforderung, es noch einmal zu versuchen.
Was der Bearbeiter sieht
In der Verwaltungsansicht, die gerade entsteht, liegen die Tage einer Anfrage als einzelne Datensätze beieinander, jeder mit einem Kennzeichen, dass sie zu einer mehrtägigen Anfrage gehören. Der Bearbeiter öffnet die Anfrage, sieht fünf Tage mit der jeweiligen Verfügbarkeit, gibt drei in einem Durchgang frei und lehnt die anderen beiden in derselben Aktion ab.
Für den Systemverantwortlichen ändert sich, wo die Entscheidung liegt. Jeder Tag trägt seinen eigenen Status, eine teilweise freigegebene Anfrage wird also zu einem Zustand, den das System hält, und nicht zu einem Satz, den ein Bearbeiter einmal in eine E-Mail geschrieben hat. Wenn die Entscheidungen in den Datensätzen stehen, kann die Auswertung anfangen, sich mit dem zu decken, was tatsächlich passiert ist.
Derselbe Konflikt an anderer Stelle
Die Buchung ist das Beispiel, aber das Muster ist allgemein: eine Anfrage, modelliert in der Auflösung, in der der Antragsteller sie erlebt, und eine Entscheidung, die in einer feineren getroffen wird. Eine Bestellanforderung mit acht Positionen, von denen sechs freigegeben werden sollten. Eine Woche Urlaub, in der der Donnerstag kollidiert. Ein Schichtplan, in dem eine Person die Hälfte der Schichten abdecken kann. Eine Bestellung, bei der zwei Artikel auf Lager sind und einer nicht.
Das Erkennungszeichen ist jedes Mal dasselbe: Mitarbeiter lehnen ab und bitten um erneute Einreichung, oder sie entscheiden per E-Mail und tippen die Antwort nachträglich ein. Die Checkliste zu diesem Beitrag führt diese Anzeichen auf, zusammen mit der Modellierungsentscheidung dahinter, damit Sie benennen können, was Ihr Team bislang aufgefangen hat.
