"Wir bringen immer nur eins auf einmal durcheinander."
(Kernighan/Ritchie)

Was also ist die Geschäftsprozessanalyse?

Die Geschäftsprozessanalyse in der Pre-Analyse-Phase des Projekts dient eigentlich nur dazu, aus verschiedenen Perspektiven grob einen Claim abzustecken, der danach im Rahmen des Softwareprojekts bearbeitet wird! Daher muss jede Pre-Analyse-Phase per Definition unvollständig sein. Auch die Geschäftsprozessanalyse umfasst daher noch nicht alle Details. Es geht vielmehr darum, festzustellen, was das Projekt eigentlich umfasst, in welcher Liga das Projekt spielt und welche Bedeutung es für den Kunden hat. Nach der Pre-Analyse-Phase können daher bereits erste grobe - und sicher durchaus noch recht mutige - Aussagen zu Machbarkeiten, Risiken, Aufwänden und Kosten getroffen werden. Als Anbieter haben Sie natürlich auch den Vorteil, dass Sie schon mal einen Spaten in der Baustelle stecken haben und sich damit vielleicht sogar schon die ganze Baustelle erst mal gesichert haben!

Wichtigstes Ergebnis der Geschäftsprozessanalyse sollte meines Erachtens genau ein Blatt Papier sein, das die vier Elemente "Name", "Hauptziel", "Zweck- und Tragweiten-Diagramm" und "Teilziele als Prosatext" enthält. Damit zeigen Sie als Auftragnehmer nämlich, ob Sie die Aufgabenstellung verstanden und den abzubildenden Weltausschnitt präzise bestimmt haben.

Zur Selbstbeschränkung ist es sehr wichtig, dieses Dokument wirklich so knapp wie möglich zu halten. Nur so können Sie als Auftragnehmer eine kurze Sitzung einberufen, an der alle teilnehmen und auf der Sie schnell und konzentriert (und ohne große Angriffsfläche) das Ergebnis vorstellen. Machen Sie hier also keine fetten Powerpoint-Präsentationen, legen Sie hier keine dicken Ordner vor und machen Sie hier nicht zu viel Wind. Denn Sie befinden sich jetzt am Ende der Pre-Analyse-Phase, die in der Regel nur wenige Tage umfasst, und wollen ja mit kurzen, präzisen Aussagen einen objektiven Ergebnisbericht geben. Wenn der so knapp ist, dass ihn jeder behalten kann, haben Sie viel erreicht! Wenn hier noch ausführlich erklärt und umfangreich begründet und heftig diskutiert werden muss, war die Pre-Analyse-Phase mitsamt der Geschäftsprozessanalyse wahrscheinlich noch lange nicht abgeschlossen oder Sie befinden sich am Anfang eines Klopper-Projektes, dass Sie ja vielleicht besser gar nicht machen wollen!

Das erste Bild zeigt mein Pre-Analyse-Blatt nur mit dem Zweck- und Tragweiten-Diagramm als wesentliches Ergebnis der Geschäftsprozessanalyse. Das zweite Bild zeigt - auf verständlichen Wunsch des Kunden dieses Beispiels unleserlich - den Endzustand des Blattes. Für die oben erwähnte Abschlusssitzung falte ich das Blatt für jeden Teilnehmer so, wie Sie es in den drei rechten Bildern sehen. Nachdem wir uns das Ziel in Erinnerung gerufen haben, lesen wir gemeinsam den kurzen Prosatext, mit dem wir die Teilziele einzeln vorstellen (gemäß dem Spruch oben zu einem Sortieralgorithmus in dem Originalbuch zur Programmiersprache C). Ergibt sich eine Diskussion (was fast immer der Fall ist), so klappen wir das Blatt auseinander, weil ein Diagramm gegenüber Text den großen Vorteil hat, dass ein Einstieg an jedem Punkt möglich ist. Meine Erfahrung mit dem Diagramm ist bei dieser Vorgehensweise durchweg positiv, weil der Kunde einerseits bereits am Text gemerkt hat, das ich ihn ernst nehme und verstanden habe und andererseits jeder Kunde das Diagramm nach nur kurzen Erklärungen auch versteht. Diese kurzen Erklärungen inkl. der Begründung für die Diagrammform sollten Sie als Moderator aber geben, denn nicht jeder Teilnehmer der Sitzung war von Anfang an bei dem Projekt aktiv dabei. Durch das Diagramm und die Diskussion werden auch die Leute entschädigt, die eigentlich mehr als nur ein Blatt Papier erwartet haben.

Auch wenn sich keine Diskussion ergibt, sollten Sie das Diagramm vorstellen. Dies dient auch als Einstieg zur Erläuterung der weiteren Vorgehensweise im Projekt. Sie wollen als Anbieter ja nicht nur das Ergebnis der Pre-Analyse-Phase vorstellen, sondern auch erste Aussagen zu zeitlichen, finanziellen und technischen Machbarkeiten treffen und den Aufwand für die folgende Analysephase verkaufen. Hier sollten Sie unbedingt auf die Chance des nächsten Exits aus dem Projekt nach der Analysephase hinweisen - jeder hat nämlich gerne immer ein Hintertürchen offen.

Wie Sie die Ergebnisse präsentieren, hängt auch wieder ganz vom Projekt und von der Situation ab. Es kann eine offizielle Sitzung in einem holzvertäfelten Saal sein, es kann aber auch eine Zusammenkunft am Besprechungstisch im Büro des Entscheiders sein. Entsprechend kann eine Präsentation per Beamer angebracht sein oder auch eine spontane Listung an einem Flipchart. Sie sollten den Rahmen als Auftragnehmer vorher in Erfahrung bringen und Ihren Auftritt sehr sorgfältig danach planen. In jedem Fall aber verwende ich das oben erläuterte Blatt, allein schon, damit jeder Teilnehmer ein erstes Projektergebnis mitnehmen kann.

Die Abschätzungen zu den Machbarkeiten sind an dieser Stellen eben genau noch das: Abschätzungen! Sie sind genauso unpräzise wie die ganze Pre-Analyse-Phase mitsamt iherer Geschäftsprozessanalyse unvollständig ist, aber sie sollen ein erstes Gefühl für den Aufwand bei der Bearbeitung des abgesteckten Claims geben. Entsprechend schwierig ist es, diese Abschätzungen vorzunehmen, vor allem, wenn Sie noch nicht auf einen ordentlichen Fundus an Projekterfahrung zurückgreifen können. Sie sollten hier nur tun, was Sie tun können, und nicht irgendwelche Luftschlösser bauen. Wenn Sie schon mal ein Projekt hatten, das unter mehreren Kriterien vergleichbar war, ziehen Sie diesen Vergleich. Wenn Sie schon grob abzählen können, wie viele Anwenderdialoge und Reports Sie erwarten und wenn Sie Erfahrungswerte zum Erstellen von Anwenderdialogen und Reports auf der geforderten technischen Plattform haben, führen Sie diese Multiplikation durch. Wenn Sie bereits wissen, dass ein Projektleiter in einem solchen Projekt 15% Managementoverhead produziert, kalkulieren Sie dies ein! Können Sie Parallelisierbarkeiten bei der Realisierung erkennen und haben mehrere Ressourcen zur Verfügung, kalkulieren Sie Termine entsprechend näher. Erkennen Sie schon technische Risiken bei der Umsetzung auf der geforderten Plattform, sollten Sie dafür Evaluierungsphasen einplanen.

Stellen Sie alle diese Kennzahlen innerhalb der Rubriken der Machbarkeiten mit vor und vermitteln Sie so einen Gesamteindruck davon, in welcher Liga dieses Projekt spielt. Nennen Sie ggf. schon einen inneren und äußeren Rahmen, und sei es: "zwischen fünf Personenmonaten und zwei Personenjahren". Das ist ein weiter Bereich, aber Sie schließen damit sechs Personenwochen genauso aus wie drei Personenjahre! Übrigens: geben Sie niemals einen Wert mit einer Plus-Minus-Abweichung an, denn alle schreiben sich nur den Wert auf, nicht aber die Plus-Minus-Abweichung! Haben Sie den Mut, zu sagen, was Sie wissen, aber sagen Sie nicht mehr! Sie müssen hier verkaufen, aber Sie verkaufen aus der Rolle des technischen Analytikers. Hier können Sie nur aus der Überzeugung heraus verkaufen, nicht aus der Überredung heraus; wer mir dies jetzt allerdings glaubt, der soll sich bei mir melden, damit ich ihm meinen Gebrauchtwagen verkaufen kann ;-)

Eines ist jedenfalls klar: Sie können Ihre Abschätzungen nur glaubhaft plazieren (ist das die neutrale Formulierung zwischen "überreden" und "überzeugen"?), wenn Sie eine Grundlage aus Fakten haben. Genau diese schaffen Sie mit dem Pre-Analyse-Blatt: der Kunde sieht, dass Sie ihn verstanden haben, dass Sie den zu unterstützenden Weltausschnitt bestimmen konnten, dass Sie mit all den Akteuren klar gekommen sind, dass Sie in der Lage sind, komplexe Zusammenhänge zu verdeutlichen, dass Sie auf kritische und harmlose Dinge gestoßen sind und diese auch entsprechend einstufen konnten, dass Sie offensichtlich bereits vergleichbare Projekte realisiert haben und nicht zuletzt, dass Sie offensichtlich die richtige Frau bzw. der richtige Mann für die folgende Analysephase sind.

Bei wirklich großen Projekten setzen Sie vielleicht auf eine Familie von teamfähigen mächtigen Tools. Sollten Sie sich dabei für die Firma IBM Rational [L7] entscheiden und den zugehörigen Prozess RUP lizenzieren, werden Sie am Ende der ersten Phase mit Requisite Pro ein Vision-Dokument erstellt haben, welches die Vision des Projekts vorstellt und auch so Angaben wie Ziele, Interessensgruppen, Akteure, Zweck und Tragweite enthält. Bei kleineren und mittleren Projekten, die vielleicht nicht gerade von 100 Entwicklern auf 3 Kontinenten sondern von einem Dutzend Entwicklern an einem einzigen Standort getrieben werden, genügt aber durchaus mein Pre-Analyse-Blatt.