Business Analyse in der IT – Systemanalyse 3.0

Prolog

Das ist der Beitrag der SEQIS GmbH zur Blogparade des Business-Analyse-Camp 2016.

SEQIS ist Spezialist für Business Analyse im IT-Kontext. Es ist daher nahe liegend, unseren Beitrag dem Thema „Business Analyse in der IT“ zu widmen, nicht zuletzt auch deshalb, weil wir mit dem Ansatz „Systemanalyse 3.0“ die Konzepte des Business Analysis Body of Knowledge_® (BABOK_® Guide) mit unseren eigenen umfangreichen Erfahrungen – vor allem im agilen Umfeld – verbinden.

Ziel dieses Artikels ist es – gemäß dem vorgegebenen Motto – zu zeigen, dass und wie Systemanalyse 3.0 dazu beiträgt, gute Business Analyse im IT-Umfeld zu machen und dadurch erfolgreich Veränderungen in Unternehmen zu gestalten.

Systemanalyse 3.0 – Business Analyse in der IT

Nicht jeder Business Analyst ist ein
IT-Analyst, aber jeder IT-Analyst ist
ein Business Analyst.

Die Business Analyse ist ein weites Feld. Eben deshalb wurde im BABOK_® Guide 3.0 mit den „Perspectives“ ein Instrument geschaffen, das es ermöglicht, konkreter auf einzelne Spezialgebiete einzugehen. Zwei dieser „Perspectives“ beziehen sich unmittelbar auf Vorhaben in der IT, nämlich „Agile“ und „Information Technology“. Die anderen drei – „Business Intelligence“, „Business Architecture“ und „Business Process Management“ – haben zumindest Berührungspunkte zur IT.

Und auch in der Definition für Business Analyse im BABOK_® Guide 3.0 findet sich ein IT-Analyst durchaus wieder: „Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.“  Diese Definition enthält die Elemente, die die Arbeit eines IT-Analysten ausmachen:

• Das Ziel ist es, eine Lösung zu erarbeiten
• Die Lösung soll einen definierten (Unternehmens-)Bedarf decken
• Die gefundene Lösung schafft Wert für die Organisation
• Und natürlich führt jede Lösung auch zu einer Veränderung in der Organisation

Gemessen an den Inhalten des BABOK_® Guide ist also jeder IT-Analyst ein Business Analyst. Andererseits ist aber nicht jeder Business Analyst auch ein IT-Analyst. Es gibt viele – strategische und operative – Aufgabenstellungen, deren Lösung nichts mit IT zu tun hat.

Jeder Bereich, in dem Business Analyse betrieben wird, hat seine eigenen Gesetzmäßigkeiten – und daher ist auch die Frage nach „guter Business Analyse“ unterschiedlich zu beantworten. Der Ansatz „Systemanalyse 3.0“ möchte Business Analyse gezielt auf die speziellen Erfordernisse der IT-Analyse anwenden.

Das Ziel der Business Analyse in der IT

Die Aufgabe jedes Business Analysten ist es, Lösungen vorzuschlagen. Das gilt auch für den Business Analyst in der IT. Auch hier ist es das Ziel, dass am Ende der Tätigkeit das Design einer Lösung vorliegt, das anschließend von den entsprechenden Spezialisten implementiert werden kann. Systemanalyse 3.0 beschreibt den Prozess, wie es, beginnend bei der Aufgabenstellung, zu diesem Lösungsdesign kommt.

In diesem Punkt unterscheidet sich Systemanalyse 3.0 vom Requirements Engineering, das die Lösungsfindung explizit nicht zu seinem Aufgabenbereich erklärt – und an dessen Ende eine gut organisierte Liste von priorisierten und nachverfolgbaren Anforderungen – aber eben keine Lösung – steht.

Systemanalyse 3.0 – im Mittelpunkt die Lösung

Im Ansatz Systemanalyse 3.0 steht das Design der Lösung nicht nur am Ende des Prozesses, sondern auch schon am Beginn. Sobald minimales Wissen über das Fachgebiet vorhanden ist, wird eine sogenannte „Lösungshypothese“ formuliert. Natürlich wird dieses vorläufige Design nicht vollständig ausgearbeitet, sondern besteht vielleicht nur aus einigen Skizzen, die das Konzept sehr grob beschreiben. Der Analyst darf auch an dieser Ausgangshypothese nicht festhalten, sondern es ist – ganz im Gegenteil – seine Aufgabe, Fakten herausfinden, die dazu führen, dass diese geändert werden muss. Die Lösungshypothese wird dann iterativ an den geänderten Wissensstand angepasst, bis schließlich das endgültige Lösungsdesign vorliegt, das von der Entwicklung implementiert werden kann.

Damit der Analyst zunächst die erste Lösungshypothese und schließlich auch die endgültige Lösung formulieren kann, braucht er drei „Rohstoffe“:

1. Wissen über das Fachgebiet: Der Analyst kennt die Domäne möglicherweise bereits aus seiner bisherigen Tätigkeit. Wenn das nicht der Fall ist, muss er sich möglichst viel Wissen aneignen. Es gibt dazu vielerlei Quellen, angefangen von Lehrbüchern, über innerbetriebliche Verfahrensregelungen bis zu Gesprächen mit den End-Usern.
2. Anforderungen der Stakeholder (das sind alle Personen, die in irgend einer Form mit dem Vorhaben verbunden sind): genau genommen sind die Anforderungen (Requirements) ein Teil des „Wissens über das Fachgebiet“. Es ist jedoch sinnvoll, diese getrennt zu betrachten, da für deren Erhebung immer eine intensive Zusammenarbeit mit den Stakeholdern erforderlich ist.
3. Kreativität und Ideen: Für eine gute Lösung ist immer auch die Kreativität des Analysten gefragt. Er muss das Wissen und die Anforderungen zu etwas Neuem verbinden, das Nutzen für die Organisation schafft.

Drei Hauptaktivitäten auf dem Weg zum finalen Lösungsdesign

Um aus den oben genannten „Rohstoffen“ von der Lösungshypothese zum endgültigen Lösungsdesign zu kommen, führt der IT-Analyst drei Basis-Elemente aus:

1. Analysieren
2. Kommunizieren
3. Produzieren

Erstes Basis-Element: „Analysieren“

Es mag tautologisch erscheinen, dass die Hauptätigkeit der Systemanalyse das „Analysieren“ ist. Es ist aber wichtig, zu betonen, dass die Tätigkeit des Analysten im Finden und Ausarbeiten eines Lösungsdesigns besteht, und nicht in der Auflistung von Anforderungen. Das Wort „Analysieren“ kommt aus dem Griechischen und bedeutet „Zerlegen“. Die Aufgabe des Analysten ist es also, das Fachgebiet in Elemente zu zerlegen und diese durch Beziehungen so neu aufzubauen, dass ein sinnvolles Ganzes entsteht.

Was sind nun die Elemente, in die das Fachgebiet zerlegt wird? Systemanalyse 3.0 unterscheidet – so wie die IT seit jeher – zwischen zwei Bereichen: Die Welt der Daten und die Welt der Prozesse.

• Die Welt der Daten: Jedes Arbeitsgebiet, das ein IT-Analytiker untersucht, setzt sich aus einer Menge an „Dingen“ zusammen. Aufgabe der Analyse ist es, diese „Dinge“ zu identifizieren und sie so zueinander in Beziehung zu setzen, dass ein schlüssiges Datenmodell entsteht.
• Die Welt der Aktivitäten: Neben den „Dingen“ gibt es in jedem Fachgebiet auch Aktivitäten und Handlungen, mithilfe derer diese „Dinge“ in irgendeiner Weise bearbeitet werden, sie werden neu angelegt, geändert und irgendwann auch wieder gelöscht. Auch diese Aktivitäten gilt es herauszufinden und zueinander in Beziehung zu setzen. Die Aktivitäten mit ihren Beziehungen bezeichnen wir als „Prozess“.

Daten- und Prozessmodell sind gemeinsam der wesentliche Teil des Lösungsdesigns. Sobald beide vorliegen und alle wesentlichen Informationen und Anforderungen beinhalten, ist die Arbeit des Analytikers getan. Damit es aber so weit kommen kann, sind zwei weitere Aktivitäten erforderlich.

Zweites Basis-Element: „Kommunizieren“

Der Analytiker erarbeitet die Lösung nicht für sich selbst. Er hat einen Auftraggeber. Es gibt Know-How-Träger, die Informationen liefern können. Und schließlich gibt es Menschen, die mit der vom Analytiker erarbeiteten Lösung leben und arbeiten müssen.

Daraus ergeben sich auch die Funktionen der Kommunikation in Systemanalyse 3.0:

• Einholen von Informationen
• Erheben der Anforderungen
• Abstimmung von Lösungsvorschlägen
• Abstimmung unterschiedlicher Vorstellungen
• Abnahme des Lösungsvorschlags des Analytikers.

In Systemanalyse 3.0 ist Kommunizieren immer etwas Dialogisches. Der Analytiker holt sich nicht bloß die Anforderungen ab, sondern er wird immer auch schon mit der Idee einer Lösung zum Stakeholder gehen – die er vielleicht nicht immer präsentiert, die er aber doch als Hypothese verwendet, die durch die Aussagen des Stakeholders entweder bestätigt wird – oder modifiziert oder gar verworfen werden muss.

Drittes Basis-Element: „Produzieren“

Wie jede Arbeit muss auch die Arbeit des IT-Analytikers Ergebnisse liefern. Das Ziel der Arbeit des IT-Analytikers ist das Design der Lösung. Dieses Design ist etwas Geistiges und im Prinzip nicht an materielle Artefakte gebunden. In der Praxis muss dieses Ergebnis aber kommuniziert werden. Das dies normalerweise nicht nur mündlich vor sich gehen kann, muss der Output des Analytikers auch in irgendeiner Weise festgehalten werden. Diese Dokumentation kann verschiedene Formen annehmen. Sie kann durch natürlich-sprachige Texte erfolgen. Sehr häufig wird das Ergebnis der Analysetätigkeit aber auch in der Form von Modellen dokumentiert.

Die Art, wie die Ergebnisse dokumentiert werden, ist auch von der gewählten Methode abhängig. In traditionellen Vorgehensweisen entsteht meist ein Pflichtenheft oder eine Anforderungsspezifikation. In agilen Software-Entwicklungsmethoden wird das Ergebnis der Analyse häufig in Form von User-Stories festgehalten.

Der Mikro-Prozess der Systemanalyse

Die drei Basis-Elemente der Systemanalyse, Analysieren – Kommunizieren – Produzieren, werden zum so genannten Mikro-Prozess der Systemanalyse kombiniert. Dieser Mikro-Prozess ist für alle Vorhaben gültig – unabhängig davon, wie lange sie dauern. Das heißt, ein derartiger Mikro-Prozess nimmt vielleicht nur wenige Minuten in Anspruch – oder auch mehrere Monate; der prinzipielle Aufbau des Mikro-Prozesses bleibt davon unberührt.

Der Mikro-Prozess der Systemanalyse ist in Abbildung 1 dargestellt.

Zentrales Element ist das Analysieren. Diese Tätigkeit steuert den gesamten Prozess. Unmittelbar nach dem Start des Prozesses beginnt der Analytiker mit dem Sammeln von Informationen über das Arbeitsgebiet. Dadurch lernt er das Arbeitsgebiet kennen. In den meisten Fällen hat der Systemanalytiker dann schon eine Lösung vor Augen. Das lässt sich auch gar nicht verhindern. Die Lösung ist schließlich das, was letztendlich heraus kommen soll.

Diese „Lösungshypothese“ muss jedoch ständig „herausgefordert“ werden – herausgefordert durch zusätzliche Informationen, herausgefordert durch die Anforderungen der Stakeholder. Im wissenschaftlichen Kontext würde man vom Versuch der Falsifizierung sprechen. Dadurch wird sich diese „Lösungshypothese“ verändern und weiterentwickeln. Nicht selten wird sie auch zur Gänze verworfen werden und eine neue Lösungshypothese wird sie ersetzen, die nun ebenfalls wieder gegen neue Informationen und Anforderungen zu überprüfen ist.

Die wesentliche Funktion des Basis-Elements „Kommunizieren“ ist die Herausforderung der Lösungs-Hypothese. Durch die Kommunikation mit Stakeholdern sammelt der Systemanalytiker Wissen. Eine spezielle Form des Wissens sind die „Anforderungen“. Das sind Ideen und Vorstellungen, die die Stakeholder über die Lösung haben. Anforderungen haben üblicherweise große Auswirkungen auf die Lösungshypothese.

An einem gewissen Punkt des Analysierens und damit verbundenen Kommunizierens wird der Systemanalytiker die Entscheidung treffen, jetzt „fertig“ zu sein. Wann dieser Punkt erreicht ist, hängt von mehreren Faktoren ab. Diese Entscheidung hat eine fachliche Komponente. Wenn alle Stakeholder befragt sind, alle verfügbaren Informationen ausgewertet, keine neuen Aspekte mehr zu erwarten sind und ein akzeptabel scheinendes Lösungsdesign vorhanden ist, dann ist dieser Punkt erreicht. Nicht zu unterschätzen ist aber auch die planerische Komponente. Wenn ein Meilenstein-Termin näher rückt oder wenn das vorgesehene Budget erschöpft ist, auch dann wird möglicherweise die Analyse-Tätigkeit beendet, auch wenn noch eine bessere Lösung denkbar wäre. Die „Lösungshypothese“ wird zur „vorgeschlagenen Lösung“.

Solange die Analyse noch nicht abgeschlossen ist, muss der Analytiker weitestgehend flexibel bleiben. Es darf keinen übermäßigen Aufwand verursachen, wenn eine „Lösungshypothese“ geändert oder gar gänzlich verworfen wird. Wenn zu diesem Zeitpunkt schon viel Arbeitszeit in die Produktion des Ergebnisses geflossen ist, dann geht viel von der Flexibilität verloren. Deshalb sieht Systemanalyse 3.0 vor, dass mit dem „Produzieren“ erst begonnen wird, wenn die Lösung gedanklich – im Kopf des Analytikers – „fertig“ ist. Zu diesem Zeitpunkt sind keine gröberen Änderungen mehr zu erwarten und man kann davon ausgehen, dass die entstehenden Artefakte auch Bestand haben. Das schließt natürlich nicht aus, dass auch in der „Produzieren“-Phase noch die eine oder andere kreative Idee auftaucht. In diesem Fall sollte sich der Systemanalytiker nicht scheuen, in die Phase des „Analysierens“ zurückzuschalten. In diesem Fall ist es eine Frage der Kosten-Nutzen-Abwägung, ob bereits produzierte Artefakte verworfen werden. Deshalb sollte die Rückkehr vom „Produzieren“ in den „Analysieren“-Status die Ausnahme bleiben.

Der Makro-Prozess der Systemanalyse

Manchmal kommt ein Vorhaben mit einem einzigen Mikro-Prozess der Systemanalyse aus. Das wird vor allem dann der Fall sein, wenn es sich um ein sehr kleines Vorhaben handelt und wenn nach einem strengen Wasserfall-Modell vorgegangen wird. In allen anderen Fällen wird es sehr viele derartige Mikro-Prozesse geben. Die Summe dieser Mikro-Prozesse ergibt den Makro-Prozess der Systemanalyse. Dieser ist in Abbildung 2 dargestellt.

Der Makro-Prozess der Systemanalyse besteht im Kern aus einer Reihe von Analysieren-Kommunizieren-Produzieren-Blöcken, also von Mikro-Prozessen der Systemanalyse. Wie viele es tatsächlich sind und wie diese strukturiert sind, hängt von der Organisation des Entwicklungsprozesses ab, Der in Abbildung 2 dargestellte würde einem typischen agilen Prozess entsprechen. Nach einem Block, der einen Überblick über das gesamte Vorhaben schafft, gibt es eine ganze Reihe von kleineren Blöcken, die das iterative Vorgehen in einem agilen Projekt repräsentieren. Im Falle der Anwendung des Scrum-Prozesses würden diese Blöcke den Sprints entsprechen.

Bevor jedoch mit dem ersten Mikro-Prozess begonnen wird, sind etliche Vorbereitungen erforderlich. Dafür ist eine eigene Phase vorgesehen, die wir schlicht „Start“ nennen möchten. In dieser Start-Phase werden folgende Aktivitäten durchgeführt:

• Festlegung der Ziele: es wird definiert, was mit dem Vorhaben überhaupt erreicht werden soll
• Festlegung des initialen Scopes: es wird überblicksweise dargestellt, was sich innerhalb des Aufgabenbereichs des Vorhabens befindet und was außerhalb. Es handelt sich dabei um eine grobe Abgrenzung, die sich im Laufe des Analyseprozesses noch verschieben kann. Sie soll jedoch eine Richtlinie vorgeben, an die sich der Systemanalytiker halten kann.
• Erste Abklärung der vorhandenen Stakeholder: Auch die Auflistung der Personen, die von dem Vorhaben in irgendeiner Form betroffen sind, ist eine vorläufige. Im Zuge der Analyse-Arbeiten werden häufig weitere Personen und Personengruppen eruiert, die Interesse an der Initiative haben und dazu beitragen können.
• Festlegung der geplanten Vorgangsweise: es ist festzulegen, wie die geplanten Termine sind, welche Artefakte entstehen sollen und ähnliche Fragen mehr.