Kapitel 2: Was ist Systemanalyse 3.0?

Zum vorherigen Artikel der Reihe

Was ist Systemanalyse 3.0?

(in dem wir erläutern, was der Inhalt von Systemanalyse 3.0 ist)

Was ist nun eigentlich Systemanalyse 3.0? Die folgenden Seiten sollen auf diese Frage Antwort geben. Dafür wollen wir diesen Ansatz zunächst definieren. Im Anschluss daran wird das Wesen von Systemanalyse 3.0 durch die Behandlung einiger Aspekte näher beleuchtet werden.

Definition

Systemanalyse ist das systematische Untersuchen eines Arbeitsgebiets mit dem Ziel, eine oder mehrere IT-gestützte Lösungen für einen definierten Bedarf zu finden und zu entwerfen.

Sehen wir uns die Bestandteile dieser Definition etwas genauer an:

Systemanalyse: Analyse im hier verwendeten Sinne ist die Untersuchung eines Sachverhalts durch die gedankliche Zerlegung in kleinere Bestandteile. Wichtig in diesem Zusammenhang ist der Begriff des Systems. Das heißt, die Bestandteile, in die ein Sachverhalt zerlegt wird, stehen zueinander in Beziehung. Diese Beziehungen sind für die Arbeit des Systemanalytikers von hoher Bedeutung.

Bedarf: Der Bedarf ist der Anlass dafür, dass Systemanalyse betrieben wird. Dieser Anlass kann ein Problem in den betrieblichen Prozessen sein, das es zu lösen gilt, es kann eine Marktchance sein, die man durch die Unterstützung durch ein IT-System wahrnehmen will - oder es kann auch ein in die Jahre gekommenes Alt-System sein, das abzulösen ist. Eine Lösung für diese Problemstellungen zu finden und zu entwerfen, ist Aufgabe der Systemanalyse. Normalerweise beschäftigt sich die Systemanalyse nicht mit technischen Aufgaben, sondern mit solchen aus dem Fachbereich - aber: Ausnahmen bestätigen die Regel.

Untersuchen eines Arbeitsgebiets: Es ist die Aufgabe des Systemanalytikers, einen definierten Bedarf zu untersuchen. In der Regel ist es dafür erforderlich, Einblicke in die Prinzipien, die Prozesse, die Arbeitsweisen eines Arbeitsgebiets zu bekommen. Unter "Arbeitsgebiet" ist dabei meist ein betrieblicher Teilbereich zu verstehen. Erst durch dieses Verständnis ist es dem Systemanalytiker möglich, Problemstellungen in diesem Arbeitsgebiet zu lösen.

Diese Untersuchung erfolgt systematisch: Dem Systemanalytiker stehen für diese Untersuchung eine Menge von Techniken zur Verfügung. Diese Techniken beziehen sich auf das Erheben von Anforderungen, auf das Finden und Modellieren von Lösungsansätzen, auf die Dokumentation des Lösungsentwurfes.

Finden und Entwerfen von Lösungen: Zur Aufgabe eines Systemanalytikers gehört es definitiv, Lösungen für die Problemstellungen zu entwerfen, er ist nicht bloß ein Stenograf für die Anforderungen. Die Aufgabe endet jedoch dort, wo die Umsetzung dieser Lösungen beginnt, dort wo es um den Einsatz von ganz konkreten IT-Werkzeugen, wie Programmiersprachen, Datenbanken und dergleichen geht.

IT-gestützte Lösungen: viele der im Folgenden dargestellten Vorgehensweisen können sicher auch außerhalb eines IT-Kontexts angewendet werden, wie etwa im Prozess-Management, in der Strategieplanung oder auch - um einen ganz anderen Bereich zu nennen - beim Bau eines Hauses. Dennoch liegt der Fokus von Systemanalyse 3.0 klar im IT-Kontext- dafür ist es gemacht, dahingehend ist es abgestimmt.

Die Anforderungen und die Lösung

Eine viel diskutierte Frage ist jene, inwieweit der Analytiker (bzw. der Requirements Engineer) auch für die Lösung zuständig ist. Insbesondere das Konzept des Requirements Engineering sieht vor, dass in seinem Bereich lediglich das Erheben und Dokumentieren der Anforderungen liegt. Diese sind die Basis für das Design der Lösung, wofür dann ein Designer oder auch die Implementierung zuständig ist.

Unsere Erfahrung zeigt, dass diese Form der Arbeitsteilung in der Praxis nicht zweckmäßig ist, ja häufig auch nicht praktikabel. Das soll im Folgenden dargestellt werden.

Sehen wir uns doch zunächst einmal die Begriffe an: "Anforderung" - "Lösung". Was ist ihr Inhalt? Wir kommen einer Antwort näher, wenn wir der "Anforderung" die Frage "Was" zuordnen - und der Lösung die Frage "Wie". Mit anderen Worten: die Anforderung beschreibt das "Was" der Lösung, "was" wird benötigt - und die Lösung das "Wie", in welcher Art und Weise wird es umgesetzt.

 Eine Trennung zwischen Anforderung und Lösung ist meistens gar nicht so einfach möglich. Was in einer Detaillierungsebene die Lösung (das "Wie") ist, ist für die nächste die Anforderung (das "Was"), für die es wiederum eine Lösung zu suchen gilt ("one man's ceiling is another man's floor"). Das heißt also, jede Anforderung ist die Lösung eines Problems auf einer anderen Ebene. Betrachten wir dazu ein Beispiel: Nehmen wir an, ein Unternehmen stellt fest, dass es zu wenig Umsatz macht. Es besteht also der Bedarf, den Umsatz zu steigern ("Was"). Das ist die erste Anforderung. Nun wird nach Lösungen für diese Anforderung gesucht ("Wie"). Nach einigem Überlegen entscheidet man, dass die Vertriebskanäle ausgeweitet werden sollen. Eine mögliche Lösung ist also die Entwicklung eines Web-Auftritts mit Shop, um Online-Verkauf zu ermöglichen. An die IT-Abteilung wird das als Anforderung herangetragen: Wir brauchen einen Web-Shop. Das "Wie" wird zu einem neuen "Was". Nun wird nach Lösungen für diese Anforderung gesucht und die Alternativen "Kauf eines Standard-Produkts" und "Eigenentwicklung" geprüft. Man entscheidet sich für "Eigenentwicklung" - die Lösung für die Anforderung "Wir brauchen einen Web-Shop". Jetzt wären wir bei der Anforderung "Entwicklung eines Web-Shops". Und auch dafür wird es wieder eine Reihe von Lösungen geben. Dieses Spiel ließe sich noch auf mehreren Ebenen fortsetzen. Wir sehen aber schon: Die Antwort auf die Frage, ob etwas Anforderung oder Lösung ist, ob es das "Was" ist oder das "Wie", ist eine Frage der Betrachtungsebene.

Letztlich ist jede Anforderung die Idee eines Stakeholders, wie ein Aspekt der zugrunde liegenden Problemstellung zu lösen ist. Da der Stakeholder üblicherweise ein Experte im Arbeitsgebiet ist, wird in den meisten Fällen diese Anforderung in die Lösung einfließen. Nicht selten kommt es jedoch auch vor, dann nach näherer Analyse der Systemanalytiker gemeinsam mit dem Stakeholder auf eine andere Lösung kommt, als es in der Anforderung formuliert ist. Es gibt also immer Optionen [HEAP2013] - eine Anforderung ist keine unumstößliche Bedingung, sie ist eine Idee, die in die Lösung einfließen kann oder - nach eingehender Analyse - auch nicht.

Der Business Analysis Body of Knowledge (BABOK-Guide) in Version 3 bringt zwei weitere Begriffe ins Spiel: nämlich den (Unternehmens-)Bedarf (Business Need) und das Design. Die Zusammenhänge sind in folgender Abbildung dargestellt:

Es ist die Aufgabe des Systemanalytikers, einen (Unternehmens-)Bedarf zu analysieren. Die explizite Formulierung eines derartigen Bedarfs oder einzelner Aspekte davon wird "Anforderung" genannt. Die so ermittelten Anforderungen sind ein wesentlicher Bestandteil (wenn auch nicht der einzige) für das Design der Lösung. Ebenso wie die Anforderung die formulierte Repräsentation des Bedarfs ist, ist das Desing die formulierte Repräsentation der Lösung.

In dieser Frage liege ein wesentlicher Unterschied zwischen Systemanalyse 3.0 und dem Requirements Engineering: im Konzept der Systemanalyse 3.0 ist der Analytiker sowohl für die Erhebung und Dokumentation der Anforderungen als auch für das Design der Lösung zuständig. Der Bedarf gehört zur Sphäre des Fachbereiches und ist die Grundlage für die Anforderungen. Die Lösung wird auf Basis des Designs von Software-Entwicklern (oder anderen für die Umsetzung verantwortlichen Personen) erstellt und wiederum vom Fachbereich genutzt. Der Einfachheit halber sprechen wir hier häufig von der "Lösung", wo wir eigentlich exakt das "Design der Lösung" meinen.

Das Design im Fokus

Das Design der Lösung befindet sich nicht nur innerhalb des Aufgabenbereichs des Systemanalytikers - es steht darüber hinaus auch im Zentrum seiner Bemühungen. Im Zweifel ist das Design der Lösung auch wichtiger als die Anforderungen.

Die Anforderungen sind wichtig - zweifellos, schließlich kommen sie von denen, die das Arbeitsgebiet am besten kennen. Sehr häufig werden sie eins-zu-eins in das Design der Lösung einfließen - manchmal werden sie durch den Systemanalytiker - immer in Zusammenarbeit mit den Stakeholdern - modifiziert oder sogar verworfen werden.

In der Systemanalyse ist das Ziel immer die Lösung - die Anforderungen sind ein wertvoller Input dafür, nicht mehr und nicht weniger.

Etwas plakativ könnte man formulieren: Systemanalyse 3.0 ist "Solution Engineering" und nicht "Requirements Engineering". Dieser "lösungsorientierte Ansatz" hat unter anderem folgende Vorteile:

1. Aufwand: Dadurch, dass von Anfang an die Lösung im Zentrum der Überlegung steht, wird sichergestellt, dass nur Aktivitäten ausgeführt und Artefakte erstellt werden, die auch der Lösung dienen. Wenn die Anforderungen im Mittelpunkt stehen, ist man versucht, sich mehr mit den Anforderungen und ihrem Management zu beschäftigen, als es für das Design der Lösung nützlich ist. Im Sinne und in der Ausdrucksweise der agilen Methoden ist also dieser lösungsorientierte Ansatz ein Mittel zur Vermeidung von "Waste".
2. Qualität: Systemanalyse 3.0 betrachtet nur das als "Anforderung", was die Stakeholder auch als solche aussprechen bzw. was sich aus diversen Bestimmungen ergibt. Dadurch kommt der einzelnen Anforderung ein höherer Stellenwert zu. In den Vorgangsweisen, wo Anforderungserhebung und Lösungsfindung (theoretisch) getrennt sind, muss die gesamte Lösung in Form von Anforderungen beschrieben sein. Man spricht auch von "Anforderungen ERfinden". Dadurch steigt die Zahl der Anforderungen dramatisch und die "echten" Anforderungen gehen möglicherweise in der Masse jener Lösungsfaktoren unter, die von niemand angefordert wurden - und eigentlich "nur" die Ideen des Systemanalytikers sind.

Business Analyse im IT-Kontext

Viele Diskussionen über das Wesen der Business Analyse entzünden sich an der Frage, wie sehr diese mit einem IT-Kontext verknüpft ist. Tatsächlich sind die Methoden und Techniken des BABOK-Guide sehr allgemein formuliert, sodass sie in vielen Anwendungsgebieten anwendbar sind - nicht nur in der IT, aber auch. Die Version 3 des BABOK-Guide macht das durch die so genannten "Perspektiven" klar. Die "Perspektiven" sind Spezialisierungen für einzelne Anwendungsgebiete.

Systemanalyse 3.0 hat seinen Schwerpunkt dagegen ganz eindeutig im IT-Kontext. Systemanalyse ist "Business Analyse im IT-Kontext".

Der Systemanalytiker und Entscheidungen

Darf ein Systemanalytiker (Business Analyst / Requirements Engineer) Entscheidungen treffen? Sehr oft wird diese Frage verneint. Der Analytiker oder Requirements Engineer erhebt die Anforderungen und dokumentiert diese. Entscheidungen werden auf dieser Basis vom Auftraggeber oder auch vom Designer getroffen.

Systemanalyse 3.0 hat einen anderen Blickwinkel auf diese Frage. Da der Systemanalytiker das Design der Lösung entwirft, wird er nicht darum herumkommen, Entscheidungen zu treffen. Natürlich trifft er diese nicht endgültig. Er wird sein Design "verkaufen" müssen - dem Auftraggeber, den Anwendern - allen Stakeholdern. Wenn er seine Entscheidung also nicht rechtzeitig mit diesen Gruppen abstimmt, wird er letztlich scheitern. Wenn er aber gar keine Entscheidungen trifft, wird er zu keiner Lösung kommen und so auch nicht erfolgreich sein können.

Zum folgenden Artikel der Reihe