„Was muss das Tool können?“ ist die Frage, mit der die meisten Auswahlprojekte anfangen — und sie ist der Grund, warum so viele hinterher mit einem System dastehen, das jemand anderes entworfen hat. Diese Seite beschreibt die Methode, mit der Sie vorher klären, was Sie eigentlich tun wollen: Use Cases und Drehbuch.
Warum vor der Auswahl und nicht danach
Wer ohne beschriebene Abläufe in eine Anbieterpräsentation geht, bewertet, was ihm gezeigt wird. Gezeigt wird die beste Demo, die der Anbieter hat — nicht Ihr Alltag. Mit beschriebenen Use Cases drehen Sie die Richtung um: Sie sagen, was Sie sehen wollen, und der Anbieter muss zeigen, ob er es kann.
Das hat einen Nebeneffekt, der mehr wert ist als die Auswahl selbst. Beim Beschreiben stellen Teams regelmäßig fest, dass es auf eine ganz normale Frage keine eindeutige Antwort gibt — wer entscheidet, was Priorität 1 ist? Was passiert, wenn der Kunde nicht erreichbar ist? Das ist keine Panne, das ist der eigentliche Befund.
Tool-neutral beschreiben: Was will ich tun — nicht, womit will ich das tun.
Der Satz klingt banal und ist der schwerste Teil der Übung. Wer jahrelang mit einem System gearbeitet hat, beschreibt automatisch dessen Masken. Typischer Satz: „Das geht nicht, weil die Software das nicht kann.“ Doch — in der Beschreibung geht es. Ob es das neue System dann kann, ist die nächste Frage, nicht diese.
Was ein Use Case ist — und was nicht
Ein Use Case ist keine Prozessbeschreibung und keine Liste von Funktionen. Er ist die situative Beschreibung eines Schrittes in seinem Zusammenhang: konkret, aus der Sicht der Beteiligten, mit dem, was gut laufen soll, und dem, was nicht passieren darf.
| Ein Use Case ist … | … und ist nicht |
|---|---|
| ein einzelner Schritt im Zusammenhang | der ganze Prozess von vorn bis hinten |
| aus Sicht der handelnden Person geschrieben | aus Sicht des Systems geschrieben |
| konkret und situativ | allgemein und abstrakt |
| frei von Produktnamen und Masken | eine Beschreibung der heutigen Software |
| mit Qualitätsmerkmalen und Schnittstellen | nur mit Wunschfunktionen |
Die Ich-Perspektive
Beschrieben wird in der ersten Person, und zwar aus zwei Perspektiven: der des Kunden und der des Mitarbeitenden im Service.
Als Kunde sehe ich … erlebe ich … brauche ich … werde ich gefragt …
Als Agent sehe ich … mache ich … brauche ich … schaue ich nach …
Die Ich-Form ist kein Stilmittel. Sie zwingt dazu, eine Rolle einzunehmen — und genau dabei fallen die Lücken auf, die in einer Prozessgrafik unsichtbar bleiben.
„Was soll nicht passieren“ — der Teil, den sonst niemand hat
Zu jedem Use Case gehört die Gegenprobe. Was darf an dieser Stelle auf keinen Fall geschehen? Welche Information darf nicht fehlen? Welcher Weg darf nicht offenstehen?
Dieser Abschnitt ist in der Praxis der nützlichste. Er macht aus einem Wunsch eine prüfbare Anforderung — und er ist später die Vorlage für die Abnahme: Was nicht passieren soll, lässt sich testen.
Dazu kommen zwei Angaben, die klein wirken und den Unterschied machen: Woran messen wir, ob dieser Schritt gut läuft? und wo braucht es eine Schnittstelle zu etwas anderem? Wer beides schon beim Beschreiben notiert, muss es nicht in der Projektphase nachholen, in der es teuer wird.
Vom Use Case zum Drehbuch
Einzelne Use Cases sind Bausteine. Aneinandergereiht ergeben sie ein Drehbuch: einen durchgehenden Ablauf, den man von Anfang bis Ende lesen — und später durchspielen — kann.
Das Drehbuch ist der Punkt, an dem aus einer Sammlung von Anforderungen ein Bild wird. Es zeigt Brüche, die in Einzelbeschreibungen nicht auffallen: Eine Information, die in Schritt 2 gebraucht wird, aber erst in Schritt 5 erhoben wird. Ein Kunde, der zweimal dasselbe gefragt wird.
Vom Drehbuch zu den Testszenarien
Hier zahlt sich die Arbeit zum zweiten Mal aus. Das Drehbuch ist das Testszenario. In der Anbieterpräsentation sagen Sie nicht mehr „zeigen Sie mal“, sondern geben das Drehbuch vor und lassen es durchspielen.
Das verändert die Präsentation grundlegend. Sie bewerten nicht mehr, wie gut jemand sein Produkt vorführt, sondern ob Ihr Ablauf darin funktioniert. Und Sie hören Antworten, die Sie sonst nie bekommen — etwa: „Das machen wir eigentlich nur in Projekten, und auch nur selten.“ An dieser Stelle darf man nervös werden.
„Das dauert ja ewig“
Der häufigste Einwand, und er stimmt zur Hälfte: Es dauert einen Moment. Was er übersieht, ist die Rechnung dahinter.
Kürzere Projektlaufzeit
Je genauer beschrieben ist, was passieren soll, desto weniger Klärungsschleifen braucht die Einführung. Die Zeit wird nicht zusätzlich ausgegeben, sondern vorgezogen.
Belastbare Angebote
Mit Use Cases kann der Anbieter einschätzen, wie viel davon Standard ist und wo es Anpassung braucht. Erst dann ist ein Preis mehr als eine Hausnummer.
Höhere Akzeptanz
Wer seinen eigenen Alltag in der Beschreibung wiederfindet, trägt die Einführung mit. Das ist dieselbe Arbeit, die später Change Management heißt — nur früher und billiger.
Wer das schreibt
Nicht die Projektleitung allein und nicht die IT. Die Use Cases entstehen mit den Menschen, die den Schritt täglich tun — im Workshop, nicht am Schreibtisch. Zwei Rollen haben sich dabei bewährt:
| Rolle | Aufgabe |
|---|---|
| Leuchttürme | Freiwillige aus dem Team, die mitgestalten. Ausdrücklich auch Kritiker — wer früh eingebunden ist und ernst genommen wird, trägt später mit. Und die Frage „warum machen wir das?“ gehört an den Anfang, nicht ans Ende |
| Projektleitung von außerhalb des Teams | Jemand, der nicht Teil der Fachdiskussion ist. Diese Rolle kann unangenehme Dinge aussprechen und Aufgaben einfordern, ohne sich in Detailfragen zu verfangen |
Zum Mitnehmen
Eine Vorlage, mit der Sie den ersten Use Case heute beschreiben können.
Use-Case-Vorlage herunterladenWeiterlesen
Marktüberblick: Service-Software im Mittelstand →
Softwareauswahl moderiert begleiten lassen →
Digitalisierung im Service →