"Der Irrtum ist die tiefste Form der Erfahrung."
(Martin Kessel)

Geschäftsprozesse

Oft sind den Unternehmen die Prozesse besser bekannt als die Beteiligungen der Mitarbeiter daran oder gar die Anforderungen einzelner operativer Rollen im Unternehmen. Dies liegt wohl auch daran, dass in den letzten Jahren Heerscharen von Unternehmensberatern "Prozessoptimierungen" gepredigt haben. Ein anderer Grund können die ISO-9000-Zertifizierungen sein, bei denen im Qualitätsmanagementhandbuch durch die Verfahrensanweisungen sehr präzise einzelne Handlungen der Geschäftsprozesse festgelegt werden. Daher kann es für die Unternehmen verständlicher sein, mit den Teilprozessen anzufangen und daraus dann die Hauptakteure und deren Hauptanforderungen abzuleiten, als über das Hauptziel und die Teilziele die beteiligten Prozesse zu finden und zu definieren, vor allem wenn es sich um ein kleineres System handelt, das nur wenige oder gar nur einen einzelnen Geschäftsprozess abdecken soll. Dann ist es durchaus sinnvoll, im ersten Schritt genau diesen Prozess zu analysieren. Betrachten Sie als Beispiel den Mitarbeiter-Support, der in dem folgenden Sequenzdiagramm der UML beschrieben ist (IV_HelpDesk ist dabei das zu entwickelnde System):

Was die Geschäfts- prozesse zeigten.

Bei größeren Systemen werden Sie aber gar keine Chance haben, alle Prozesse verknüpft in einem einzelnen Sequenzdiagramm unterzubringen. Dies gelingt schon allein deshalb nicht, weil an jedem Prozess viele Abteilungen und damit viele Abteilungsleiter und sehr viele Mitarbeiter beteiligt sind, die alle eine andere Sicht auf die jeweiligen Prozesse haben. Wenn es dann noch Zentralabteilungen oder Stabsstellen gibt, die "von außen" auf die Prozesse schauen, wird es völlig kompliziert. Deshalb stellt ein BPM (Business Process Model, dt.: Geschäftsprozessmodell) in der Regel nur einen Ausschnitt des Geschäfts dar, den ich gerne auch als "Weltausschnitt" bezeichne. In der Version 2 der UML gibt es die neue Möglichkeit, über Referenzen zwischen den einzelnen Diagrammen Verweise zu setzen bzw. die Diagramme zu verschachteln und so bei gescheiter Tool-Unterstützung schnell zwischen den Diagrammen und Diagrammleveln zu navigieren. Dies unterstützt die Darstellung der betrachteten Modellbereiche in Diagrammform erheblich.

Wenn das zu erstellende Softwaresystem (also die innere Systemgrenze im Zweck- und Tragweiten-Diagramm) im Laufe der Anforderungsanalyse von der Blackbox zur Whitebox wird, weil es durch Anwendungsfälle mit Leben gefüllt wird, dann werden die Prozesse, an denen das System beteiligt ist, deutlich sichtbar. Dann wird auch erkennbar, welche Prozesse nur teilweise von dem neuen System begleitet werden. Dann macht es auch sehr viel Sinn, einzelne Sequenzdiagramme für diese Teilprozesse zu erstellen, und sei es nur zum Test auf Vollständigkeit und Widerspruchsfreiheit.

Es ist auf jeden Fall extrem wichtig, in der Pre-Analyse-Phase als Analytiker nur die Fachlichkeit des Kunden, also das reine Geschäftsmodell zu betrachten. Die Benutzeroberfläche oder technische Aspekte der Software spielen hier überhaupt gar keine Rolle! Ich möchte es zur Deutlichkeit noch mal anders formulieren: in dieser frühen Phase darf nur betrachtet werden, was gefordert wird, nicht wie es realisiert werden kann, denn in der Pre-Analyse-Phase geht es um das Abstecken der strategischen Ziele, das Sammeln der operativen Hauptanforderungen und ein erstes Analysieren dieser Aspekte, nicht um ein technisches Design. Bei der Vorstellung der Ergebnisse der Pre-Analyse-Phase wird auch die kaufmännische und technische Erfahrung des Analytikers (IT Systems Analyst) gefordert, weil die Machbarkeiten abgeklopft werden müssen; aber für das inhaltliche Fortkommen im Projekt darf in der Pre-Analyse-Phase eben nur die analytische Erfahrung zählen und nur das "was" betrachtet werden.

Eine weitverbreitete Definition für den Begriff "Geschäftsmodell" ist die von Timmers (Timmers, P., 1998, Business Models for Electronic Markets, Journal on Electronic Markets, 8, S. 3-8): "An architecture for the product, service and information flows, including a description of the various business actors and their roles, and a description of the potential benefits for the various business actors; and a description of the sources of revenue." (dt.: "Ein Gerüst für das Produkt, die Leistung und den Informationsfluss, mitsamt einer Beschreibung der verschiedenen Geschäftsleute und deren Rollen sowie einer Beschreibung der potentiellen Vorteile für die verschiedenen Geschäftsleute; und eine Beschreibung der Einnahmequellen."). Ein Geschäftsmodell ist also eine Abstraktion, wie ein Geschäft funktioniert. Ein Geschäftsmodell kann also immer auch nur eine Annäherung an die reale Organisation sein.

Die Akteure kennen übrigens mindestens 90% des betroffenen Geschäftsmodellteils, weil sie es jeden Tag leben! Also sollten Sie als Analytiker nicht raten, wie etwas im Unternehmen funktionieren könnte, oder womöglich gar an allen Ecken sofort vermeintliche Verbesserungen vorschlagen, sondern stattdessen Interviews führen und den Kunden kennen lernen: er sagt Ihnen schon, was Sie tun müssen, wenn Sie ihn nur fragen!

Vermeiden Sie also den heimlichen Wechsel vom Analytiker bzw. Softwareberater zum Unternehmensberater, denn dafür werden Sie wahrscheinlich nicht bezahlt! Ohnehin stehen die meisten größeren Unternehmen laufend mit Unternehmensberatern in Kontakt und sehen uns als Softwarelösungsanbieter nicht in dieser Funktion. In [B13] gibt es ein Kapitel "2.3.4. Der Umgang mit politischen Risiken". Dieses Kapitel besteht aus nur zwei Sätzen: "Dazu kann ich keine ernsthaften Ratschläge geben, da ich kein »Unternehmenspolitiker« bin. Ich raten Ihnen nachdrücklich ab, jemanden zu finden, der dies ist." Das sehe ich genauso! Wir müssen uns als Lösungsanbieter aus der Unternehmenspolitik raushalten und uns mit Entscheidungen aus dieser Richtung abfinden.

Etwas anderes ist es natürlich, wenn Sie als Analytiker genau dafür von vornherein zusätzlich engagiert werden oder bei Erkennen der Notwendigkeit der ursprünglich geplante Einsatz bewusst geändert wird. Sie werden dann aber eben nicht mehr nur die vorhandenen Geschäftsprozesse analysieren, sondern auch neue Prozesse aktiv modellieren und damit verändernd in das Geschäftsmodell des Kunden eingreifen. Damit sind Sie von der eigentlichen Software zur unterstützenden Lösung von Teilproblemen des Unternehmens aber noch - oder wieder - recht weit entfernt.