Firmen fordern ihn, die meisten Business-Analysten wissen, dass sie ihn haben müssen und wir von Gerstbach haben, unter Verwendung der wissenschaftliche anerkannten Big-Five Methode in einem Persönlichkeitstest nachgewiesen, dass ihn die meisten BAs haben: Den Hang zur Genauigkeit!

Was in Unternehmen für die Arbeit als Business-Analyst absolut notwendig ist, kann jedoch beim Implementieren von BA-Tools sogar hinderlich sein. Tools für Business-Analyse oder auch Requirements Engineering werden eingesetzt, um Ziele zu erfassen, Anforderungen zu beschreiben, zu modellieren und zu verwalten, die Aufteilung in realisierbare Einheiten vorzunehmen und vieles mehr. Die Lösung muss jedoch vor allem einfach und anwendbar sein.

Im Rahmen von BA-Coachings bei unterschiedlichsten Unternehmen sehe ich es immer wieder: Bei der Auswahl von Tools gewinnt jener Hersteller, der beim Vergleich die meisten Features anpreisen konnte. Und bei der Konfiguration des Werkzeugs wird dann für jeden Arbeitsschritt und jede Aufgabe ein spezielles Feature genutzt oder eigene Attribute angelegt und Elemente in tiefen Hierarchien miteinander verknüpft. Business-Analysen müssen dann (neben ihrer eigentlich Aufgabe) viel Dokumentation erstellen und pflegen.

Die dabei zu erstellende Struktur in den Tools sieht dann häufig wie folgt aus:

1. Projekt: Über allen Initiativen im Unternehmen steht ein Projekt (oder auch noch darüber ein Programm), das die zu erreichenden Ziele festlegt.
2. Demand: Eine Verknüpfung zum „IT-Demand“ zeigt auf, wer eigentlich die Änderung haben wollte, wodurch erst das Projekt ins Leben gerufen wurde.
3. Themen: Einzelne Themen, die umgesetzt werden müssen, werden in einer frühen Phase gesammelt und (hoffentlich sinnvoll) gruppiert.
4. Anforderungen: Daraus entstehen dann Anforderungen, die eigenständig dokumentiert werden.
5. Use Case: Weil ja die Use Case Methodik (zurecht!) immer noch als non-plus-ultra des Anforderungsmanagement gilt, gibt es auch hierfür ein eigenes Artefakt.
6. User Story: Und weil Unternehmen ja heutzutage agil sind (oder sein wollen), gibt es die User Story (natürlich neben oder noch schlimmer als Synonym für einen Use Case)
7. Epics: Die User Stories können wiederum gemäß dem üblichen Vorgehen in Epics gruppiert werden, die wiederum eine Verlinkung zu den Themen erlaubt.
8. Tasks: Eine konkrete Aufgabe (z.B. für Software-Entwickler) wird dann als Task angelegt, schließlich muss ja jemand auch die eigentliche Arbeit machen.

Alles klar?

Kennen Sie Unternehmen, die mit einer solch komplizierten Struktur mit der Einführung gestartet (und gescheitert) sind? Ich selbst habe solche bzw. ähnliche Strukturen in den letzten Jahren leider sehr häufig gesehen – und funktioniert haben sie selten. Denn eines wird dabei vergessen: Auch Tools für die Business-Analyse sollen die Arbeit unterstützen und haben nicht den alleinigen Zweck jeden Schritt, den Business-Analysten setzen, zu dokumentieren. Die Nachteile dieses Vorgehens werde ich in einem eigenen Blog-Artikel beschreiben (Update: Hier ist er).

Ein Tool muss so einfach wie möglich aufgebaut sein und die eigentliche Arbeit in der Business-Analyse unterstützen: Das Erheben von Anforderungen, die Analyse der Anforderungen (und das ist ein kreativer Prozess) und die Kommunikation der Anforderungen. Eine Dokumentation ist nur ein (optionales) Unterziel der Kommunikation! Nicht umsonst heißt ein Wissensgebiet im neuen BABOK^® Guide v3 nur noch „Elicitation and Collaboration“ und nicht „Documentation“.

Falls Sie mit der Einführung eines solchen Tools für das Team der Business-Analysten oder Anforderungsmanager betraut sind, dann passen Sie gut auf, dass Sie es mit der Genauigkeit nicht übertreiben und legen Sie vor allem Wert auf ein Tool, das auch genutzt werden wird! Wenn Sie dabei Unterstützung benötigen, zögern Sie bitte nicht, mich anzurufen und auf BA Tools anzusprechen!

Lesen Sie hier weiter über BA- und RE-Tools und die Veränderungskurve.