Business Analyse ist ein kreativer Prozess und enthält viel mehr Tätigkeiten als das einfache Dokumentieren von Anforderungen. Besonders in frühen Projektenphasen ist der Business Analyst oft der einzige Mitarbeiter im Projekt. In vielen Unternehmen wird diese Tätigkeit auch nicht explizit als „Business Analyse“ bezeichnet, sondern wird vom Projektleiter übernommen, der dann später auch die Umsetzung begleiten wird.

In frühen Phasen des Projekts ist es wichtig, dass an alle Themen und Aufgaben aktiv herangegangen wird. Es gibt noch keinen Projektplan, es gibt keinen Projektleiter oder Vorgesetzten der die Effizienz des Teams überwacht – weil es noch kein Team gibt. Es ist oft die alleinige Verantwortung des Business Analysten schnell und effektiv den Umfang der Lösung oder des Projekts zu ermitteln. Um diese Ansprüche erfüllen zu können ist viel Selbstdisziplin gefragt…

Ein Beispiel:

In einem Unternehmen ist der Wunsch geäußert worden einen Prozessschritt zu automatisieren. An dem Prozess sind drei Systeme beteiligt, aber keines der drei Systeme deckt den Prozessschritt gut ab. Durch die Automatisierung erhofft man sich eine Einsparung der Prozesskosten und eine Erhöhung der Durchlaufzeit. Ein Business Analyst soll sich um das Thema kümmern und eine Lösung skizzieren, die Umsetzungs-Aufwände  schätzen und weitere Schritte klären.

Wie könnten nun erste Schritte aussehen? Wie sollte an das Thema herangegangen werden? Eventuell existiert im Unternehmen ein Projektmodell wie dieses hier:

Eine Detaillierung, wie in der ersten Phase in der Praxis vorgegangen werden soll, ist aber in den wenigsten Fällen enthalten. Möglicherweise verweist die Prozessdokumentation auch auf den BABOK (Business Analysis Body of Knowledge). Dort sind Knowledge Areas definiert wie:

• Elicitation (Erhebung),
• Requirements Analysis (Anforderungsanalyse) und
• Solution Assessment and Validation (Lösungskonzeption).

Diese können natürlich in eine sinnvolle Prozess-Reihenfolge gebracht werden oder auch iterativ in mehreren Schleifen durchlaufen werden, um das Ziel zu erreichen.

Für die praktische Anwendbarkeit dieser theoretischen Prozessschritte hilft dem Business Analysten eine gute Portion Selbstmotivation. Mit Selbstmotivation meine ich in diesem Kontext die Fähigkeit aus eigenem Antrieb alle notwendigen Schritte effizient und effektiv durchzuführen – auch wenn niemand da ist, der den Weg vorgibt. Ein Analyst, der in dieser Phase zögerlich handelt oder auf Anweisungen wartet, kann zum Problem werden. Mit dem oben angerissenen Beispiel gesprochen, könnte dies folgendes bedeuten:

Ein kurzes Meeting mit der Person abhalten, die die Anforderung gestellt hat. Hier geht es hauptsächlich darum, das Thema und die Umgebung kennenzulernen. Als ein wichtiges Ergebnis sollte in diesem Schritt die Liste der Stakeholder entstehen: Gibt es einen Prozess-Owner für das Thema? Wer sind die fachlichen Ansprechpartner der Systeme A, B und C, die im Prozess involviert sind? Wer kümmert sich auf technischer Seite um diese Systeme? Wer hat sich schon einmal mit einer ähnlichen Fragestellung befasst?

Als nächstes geht es dann darum mit jedem Stakeholder kurze Gespräche zu führen. Per Telefon könnte sich bereits schnell herausstellen, dass die gewünschte Automatisierung für System A fachlich nicht relevant ist. Der Ansprechpartner für System C ist gerade auf Urlaub, aber der für System B erinnert sich, dass so ein Wunsch bereits einmal in irgendeinem Projekt ein Thema war. Der Projektleiter von damals ist jedoch nicht mehr in der Firma.

An so einem Punkt ist dann Selbstmotivation gefragt, weil sich alle Wege (vorerst) als Sackgasse herausstellen. Das einzige was dann hilft, ist jedem Thema nachzugehen und jede Spur zu verfolgen bis sich Lösungs-Möglichkeiten abzeichen.

Lösungsfindung bedeutet für mich aus den einzelnen Puzzle-Steinen, ein Bild zu schaffen und solange weiterzumachen bis kein Stein mehr fehlt – oder zumindest so lange bis das Motiv erkennbar ist. In dieser Phase muss ganz bewusst die nötige Detailtiefe gewählt werden. Bei einem 5000-Stück Puzzle sind die Teile zu klein und das Bild wird nie fertig. Ein Puzzle mit 4 Steinen ist wohl kein echtes Puzzle. Es geht also hauptsächlich darum, ein in sich stimmiges Bild von der Lösung zu bekommen und trotzdem Mut zur Lücke zu haben.

Auf dieser Basis ist es dann relativ einfach die Lösung zu dokumentieren, die Umsetzungs-Aufwände zu schätzen und organisatorischen Auswirkungen zu bestimmen.