Business Analyse – Macht und Ohnmacht

 

„Ihr habt die Macht“ – so verspricht es uns das Business-Analyse-Camp 2017. In unserem Beitrag zur Blogparade des BA-Camps greifen wir diese Aussage auf und untersuchen, wie mächtig wir Business Analysten tatsächlich sind – und was es bedarf, dass unsere Ideen und Konzepte auch realisiert werden.

Business Analysten sind mächtig!

Business Analysten können die Welt verändern – oder zumindest ein Unternehmen. Durch Neugestaltung von Prozessen, Neuausrichtung der Strategie initiieren Business Analysten einen tiefgreifenden Wandel in einer Organisation. Alles ist möglich!

Business Analysten sind machtlos!

Business Analysten können keine einzige Anordnung treffen. Die besten Ideen verpuffen ungenutzt, wenn sich nicht eine entscheidungsbefugte Stelle in der Organisation findet, die die Umsetzung der Vorschläge anordnet. Ohne Unterstützung der Hierarchie geht sowieso nichts. Und selbst wenn diese da ist, nutzt sie nur wenig, wenn die Ideen keinen Anklang an der Basis finden. Business Analysten vermögen eigentlich von sich aus gar nichts!

Mehr von diesem Beitrag lesen

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.

Mehr von diesem Beitrag lesen

Anforderungsmanagement meets Software Test: Erfolgsfaktoren

von Alexander Weichselberger

… idealer geht’s kaum: Man sitzt mal da (Systemanalyse 1) und mal dort (Software Test) – und jetzt gilt es einen Artikel zu verfassen, der beide Disziplinen gegenüberstellt. Der geneigte Leser erwartet sich selbstredend – wie es der Artikeltitel ankündigt – Erfolgsfaktoren.

1 Systemanalyse, genau gesagt Systemanalyse 3.0 beinhaltet für mich Business Analyse (-> http://www.iiba.org/babok-guide.aspx), Requirements Engineering (-> https://www.ireb.org/de) und noch ein bisschen mehr

Ring

Quelle: SEQIS Software Testing GmbH

 

Mehr von diesem Beitrag lesen

Systemanalyse 3.0 – Kapitel 5

Kapitel 5 – Analysieren I

(In dem wir zeigen, was die wichtigste Tätigkeit eines Systemanalytikers ist)

Nachdem wir uns im vierten Kapitel einen Gesamtüberblick über Systemanalyse 3.0 verschafft haben, wenden wir uns nun den einzelnen Elementen zu.

Analysieren als Basis-Element in Systemanalyse 3.0

Abbildung 1: Analysieren als Basis-Element in Systemanalyse 3.0

Das zentrale Element in Systemanalyse 3.0 ist – wohl keine große Überraschung – das Analysieren. In diesem Element entwickelt sich die Lösung aus einer ersten „Lösungs-Hypothese“. Durch Sammeln und Verarbeiten von Information und laufende Abstimmung durch Kommunikation mit den Stakeholdern reift die Lösung so lange, bis sie so stabil ist, dass die erforderlichen Artefakte produziert werden können.

Wenn wir dem Inhalt des Wortes „Analysieren“ auf den Grund gehen, stellen wir fest, dass das Wort aus dem Altgriechischen kommt und wörtlich „Auflösung“ bedeutet. Analyse ist eine „systematische Untersuchung, bei der das untersuchte Objekt in Bestandteile zerlegt wird und diese anschließend geordnet, untersucht und ausgewertet werden. Insbesondere betrachtet man Beziehungen und Wirkungen.“ (http://de.wikipedia.org/w/index.php?title=Analyse).

Diese – allgemeine – Definition beschreibt auch die Arbeit eines Systemanalytikers sehr gut. In diesem Artikel werden wir betrachten, was im Fall der Systemanalyse die „Bestandteile“ sind, in die das Objekt, also das Arbeitsgebiet, zerlegt wird. Die Methode, Komplexität durch Zerlegung zu reduzieren, ist nicht erst in den letzten Jahrzehnten – seit es IT und Software-Entwicklung gibt – erfunden worden, sondern ist ein altes Prinzip für das Verstehen von komplexen Sachverhalten. So gehörte die Analyse in diesem Sinne auch zu den Methoden des Philosophen René Descartes.

„Lösungsorientierte Analyse“ oder „Über rosarote Elefanten und braune Kühe“

Das Verhältnis zur Lösung unterscheidet Systemanalyse 3.0 von anderen Methoden. Requirements Engineering betrachtet die Lösung überhaupt nicht als zu seinen Aufgabenbereich gehörend. Requirements Engineering, so wie es in den Lehrplänen des IREB beschrieben ist, will Anforderungen erheben und sie entsprechend dokumentieren. Die Lösung soll anschließend auf Basis dieser Anforderungen von Designern bzw. auch den Entwicklern entworfen und realisiert werden. In Business Analyse lt. IIBA ist hingegen schon auch von der Lösung, bzw. vom Design der Lösung die Rede. Es wird von einem Lösungsansatz (Solution Approach) gesprochen, von den Anforderungen und schließlich vom Bewerten und Validieren der Lösungen. Wie eine Lösung aber zustande kommt, wie der Prozess der Lösungsfindung ist, das wird vom „Business Analysis Body of Knowledge“ (BABOK-Guide) kaum behandelt.

Systemanalyse 3.0 verfolgt hier einen anderen Ansatz, den wir Lösungsorientierte Analyse“ nennen wollen. Dieser Ansatz besagt, dass der Systemanalytiker vom ersten Moment seiner Aktivität in einem Vorhaben eine Lösungsidee im Kopf hat. Dieses Faktum lässt sich auch gar nicht verhindern. Wer ist schon einmal zu einem Gedankenexperiment eingeladen worden, in dem man aufgefordert wird, jetzt nicht an einen rosaroten Elefanten zu denken? Jeder wird bestätigen, dass das nicht möglich ist; der erste Gedanke in dieser Situation wird der an einen rosaroten Elefanten sein.

Genauso verhält es sich mit dem Gedanken an eine Lösung in einem Analysevorhaben. Nehmen wir an, Sie sollen Analyseaufgaben in einem Projekt übernehmen, in dem es um die Entwicklung eines Web-Shops für ein Handelsunternehmen geht. Sie werden kaum umhin kommen, an den Web-Shop des Online-Buchhändlers Ihrer Wahl zu denken, ob Sie es wollen oder nicht.

In Systemanalyse 3.0 stehen wir auf dem Standpunkt, dass dieses Faktum – das sich ohnehin nicht vermeiden lässt – produktiv genutzt werden sollte, anstatt es zu verdrängen. Natürlich besteht die Gefahr, dass man sich frühzeitig auf eine Lösung festlegt und die Flexibilität für neue Anforderungen und Erkenntnisse verliert. In Systemanalyse 3.0 wird dieser Gefahr dadurch begegnet, dass das „Produzieren“ aus dem „Analysieren“ ausgelagert wird – und tendenziell erst sehr spät im Prozess durchgeführt wird – dann, wenn mit keinen Informationen zu rechnen ist. Zum anderen liegt diese Flexibilität auch im Aufgabenbereich bzw. im Mindset des Analytikers – er muss lange Zeit offen für Neues sein – und bereit, sein Konzept auch zur Gänze über den Haufen zu werfen, wenn neue Informationen oder Stakeholder-Anforderungen dies erfordern.

Wenn wir von „Lösung“ sprechen, müssen wir verschiedene Dimensionen unterscheiden:

  • technisch/fachlich (how/what): es muss jeweils klar sein, ob man von der technischen Lösung spricht oder von der fachlichen Lösung. Die technische Lösung betrifft Themen, wie das exakte Screen-Design, für die Entwicklung verwendete Systeme, Datenbanken, Middleware-Systeme und dergleichen. Die fachliche Lösung wird in Konzepten ausgedrückt, wie etwa Prozessmodelle, fachliche Datenmodelle und ähnliche Darstellungsmöglichkeiten.
  • der Zeitaspekt (now/future): es muss zwischen der aktuellen und der geplanten Lösung unterschieden werden.

Suzanne und James Robertson haben diese Dimensionen im so genannten „Brown Cow“-Modell zusammengefasst [ROBERTSON2013]. Der doch etwas merkwürdige Titel dieses Modells kommt von einer englischsprachigen Aussprache-Übung, mithilfe der Englisch-Lernende die Aussprache der Vokale üben sollen – der Text dieser Übung lautet: „How Now Brown Cow“. Die aktuelle technische Lösung wird in diesem Modell als „How Now“ bezeichnet – der Rest des Aussprach-Spruchs hat dem Modell den Namen gegeben.

Abbildung 2: Das Brown-Cow-Modell [ROBERTSON2013]

Abbildung 2: Das Brown-Cow-Modell [ROBERTSON2013]

Die vier Quadranten des Brown-Cow-Modells haben folgende Bedeutung für den Systemanalytiker:

  • How Now: damit wird die aktuelle Implementierung der Lösung bezeichnet. Diese ist oft die erste Informationsquelle des Systemanalytikers. Es zeigt, wie die betrieblichen Prozesse derzeit unterstützt werden. Häufig sind Dokumentationen (Benutzerhandbücher usw.) über das Ist-System vorhanden, die einen guten Einstieg in die Analyse-Tätigkeit bilden.
  • What Now: das sind die Konzepte und Modelle, die hinter der aktuellen Lösung stehen. Eine entsprechende Dokumentation ist nicht immer verfügbar. Wenn jedoch diesbezügliche Informationen vorhanden sind, sind diese neben den Anforderungen der Stakeholder die wichtigste Informationsquelle für den Systemanalytiker.
  • What Future: dieser Quadrant ist der wichtigste für den Systemanalytiker, er bezeichnet das eigentliche Ziel der Arbeit des Systemanalytikers: die fachliche Lösung. Das Konzept wird im Basis-Element „Analysieren“ erstellt, unter Berücksichtigung der Informationen, die im Basis-Element „Kommunizieren“ gewonnen werden. Im Basis-Element „Produzieren“ erfolgt schließlich die Ausarbeitung im Format, das im jeweiligen Vorgehensmodell gefordert wird.
  • How Future: damit wird die zukünftige technische Lösung bezeichnet. Diese ist nicht Aufgabe des Systemanalytikers. Sehr häufig gibt es jedoch dennoch Beziehungen zu diesem Bereich. Die Entwickler sind wichtige Stakeholder im Analyse-Prozess. Wenn die Technik schon bekannt ist, mit der das Vorhaben letztendlich umgesetzt werden soll, wird das der Systemanalytiker in seinen Konzepten entsprechend berücksichtigen.

Das Brown-Cow-Modell ist eine Hilfe für den Systemanalytiker, Gedanken und Ideen richtig einzuordnen, sodass schließlich das Ziel – das „What Future“ erreicht wird. Es ist jedoch kein Prozess in dem Sinne, dass die verschiedenen Quadranten in einer bestimmten Reihenfolge durchlaufen werden müssen.

Analyse ist Zerlegen – aber in was?

Wie wir oben schon festgestellt haben, bedeutet „Analysieren“ dem Wortsinn nach „Zerlegen“ in Elemente. Dabei stellt sich jetzt die Frage, was sind denn die Elemente, in die wir in der Systemanalyse zerlegen?

Im Bereich der IT-Analyse haben wir es nahezu immer mit zwei Themenkreisen zu tun: mit der Welt der Daten auf der einen Seite und mit der Welt der Funktionen auf der anderen. Die Welt der Daten beschreibt die Informationen, die bearbeitet und festgehalten werden (statische Sicht), die Welt der Funktionen, welche Tätigkeiten bzw. Algorithmen diese Informationen erzeugen und bearbeiten (dynamische Sicht).

Die Objektorientierte Analyse, die vor einiger Zeit sehr modern war, wollte diese beiden Bereiche in einem Konzept vereinen. Dabei werden die Daten in Klassen gegliedert, die die Funktionen in der Form von so genannten Methoden inkludieren. Die Trennung in Daten und Funktionen wäre aufgehoben gewesen. Nur – anders als in der Welt der Programmiersprachen – hat sich in der Analyse dieser objektorientierte Ansatz nicht durchgesetzt. Es entspricht eben doch nicht der Realität, dass die Objekte von sich aus etwas tun. Vielmehr wird – durch die Funktionen – mit ihnen etwas getan.

Aus diesem Grund wollen auch wir in unserer weiteren Betrachtung der Elemente in der Systemanalyse von dieser Trennung in Daten und Funktionen ausgehen. In jeder der beiden Bereiche wollen wir ein „Primäres Analyse-Objekt“ definieren. Das ist nicht notwendigerweise das kleinstmögliche Element. Es ist vielmehr das Objekt, das im Zentrum der Analyse-Überlegungen steht, aus denen sich das Gesamtsystem zusammensetzt – auch wenn eine noch detailliertere Betrachtung möglich ist.

Das Primäre Daten-Analyse-Objekt

Jedes Arbeitsgebiet, das wir als Systemanalytiker untersuchen, setzt sich aus vielen „Dingen“ zusammen. „Dinge“ – das ist jetzt im weitesten Sinne zu sehen. Selbstverständlich können das auch Menschen sein, man denke nur an ein Personal-Informationssystem. Diese Dinge sind häufig materiell, sehr häufig auch immateriell, z. B. eine Reise oder eine andere Dienstleistung. Ja, sie können darüber hinaus auch abstrakt sein, also etwas, das es so in der Realität überhaupt nicht gibt, etwa ein Konto (wobei man jetzt diskutieren könnte, ob es einen Unterschied gibt zwischen immateriell und abstrakt). Da man unter einem „Ding“ allgemein doch etwas versteht, das man angreifen kann – und das kein Mensch ist, wollen wir allgemeiner von „Objekten“ sprechen. Und da uns auch weniger diese Objekte an und für sich interessieren, sondern alles was mit Informationen über diese Objekte zusammenhängt, sprechen wir von „Informationsobjekten“.

Aufgabe des Systemanalytikers ist es, diese Informationsobjekte zu finden – das Arbeitsgebiet in diese Informationsobjekte zu zerlegen. Das Primäre Daten-Analyse-Objekt ist also dieses Informationsobjekt.

Bis zu einem gewissen Punkt ist das auch recht einfach und bedarf weder viel Wissens noch Erfahrung. Viele der Informationsobjekte sind ganz offensichtlich – ein IT-System, das Fahrzeuge verwaltet, wird eben diese Fahrzeuge als Informationsobjekte haben. Daneben wird es jedoch auch etliche Informationsobjekte geben, die erst auftauchen, wenn der Systemanalytiker einiges an Wissen über das Arbeitsgebiet gesammelt hat. Und schließlich kommt dann der Punkt, wo man tiefer in die Analyse eintauchen wird müssen. Da geht es dann um Fragen, wie: Ist es zweckmäßig, ein Informationsobjekt, das auf den ersten Blick wie eines erscheint in zwei aufzuteilen? Es wird auch etliche Informationsobjekte geben, die keinerlei Entsprechung in der Realität haben, die der Systemanalytiker erfindet, um die erforderlichen Informationen in sauberer Form verwalten zu können.

Mit der Identifikation der Informationsobjekte ist es jedoch nicht getan. Die Informationsobjekte sind Träger von Informationen, wie ja der Name schon sagt. Herauszufinden, welcher Art und welchen Umfangs die Informationen sind, die ein Informationsobjekt trägt, ist eine weitere Aufgabe des Systemanalytikers. Die gefundenen Informationsobjekte werden um Attribute ergänzt. Die Attribute für das Objekt „Person“ sind z. B. Vorname und Zuname und – je nach Arbeitsgebiet – eine Menge weiterer Attribute.

Die dritte Art von Information, die mit den Informationsobjekten verbunden ist – neben den Objekten und ihren Attributen, sind die Beziehungen zwischen den Objekten. Diese herauszufinden und zu dokumentieren gehört ebenfalls zu den Aufgaben des Systemanalytikers. Sehr viel Wissen über das Arbeitsgebiet steckt in diesen Beziehungen.

Abbildung 3: Aus "Dingen" werden Informationsobjekte

Abbildung 3: Aus „Dingen“ werden Informationsobjekte

Alles zusammen – das Informationsobjekt, seine Attribute und die Beziehungen zwischen den Informationsobjekten – wird das Datenmodell des Arbeitsgebietes genannt. Es gibt mehrere Möglichkeiten, dieses Datenmodell darzustellen.

Lange Zeit waren die so genannten Entity-Relationship-Diagramme vorherrschend. Diese bezeichnen die Informationsobjekte als Entities und die Beziehungen als Relationships. Seit vielen Jahren hat sich auf dem Gebiet der Modellierung jedoch die UML (Unified Modeling Language) durchgesetzt. Diese sieht für die Datenmodellierung die Klassendiagramme vor. Die Klassendiagramme kommen aus der Objektorientierten Analyse, d. h. es wäre an und für sich vorgesehen, dass in den Informationsobjekten, die in diesem Fall ‚Klassen‘ genannt werden, auch die Methoden – also die Funktionen – modelliert werden. In der Praxis werden die Methoden aber zumeist weggelassen, sodass die Entity-Relationship- und Klassen-Diagramme in ähnlicher Weise verwendet werden und sich lediglich in der Syntax unterscheiden.

Wir fassen also zusammen: Aus der Datensicht zerlegt die Systemanalyse ein Arbeitsgebiet in Informationsobjekte. Diese werden durch die Attribute beschrieben und durch Beziehungen in ein Gesamtsystem gebracht. Das ist die statische Sicht eines Arbeitsgebietes.

Zur vollständigen Beschreibung muss die dynamische Sicht ergänzt werden. Wir müssen also herausfinden, was mit den Daten der statischen Sicht geschieht. Wie entstehen sie, wie werden sie modifiziert und bearbeitet, sodass letztlich Geschäftsnutzen entsteht. Was sind die Primären Funktions-Analyse-Objekte?

Das Primäre Funktions-Analyse-Objekt

Es gibt eine Menge an Tätigkeiten und Aufgaben, die in einem zu analysierenden Arbeitsgebiet anfallen, es werden neue Daten erfasst (Bestellungen, Aufträge, Kunden, …), es müssen Änderungen an bestehenden Daten vorgenommen werden und es gibt Informationsbedürfnisse, die befriedigt werden müssen. Analyse bedeutet, Ordnung in diese zunächst ungeordnete Menge an Aktionen zu bringen.

Dafür sind verschiedene Möglichkeiten vorstellbar. Die gängige und häufig empfohlene Gliederung dieser Aktivitäten sind jene nach Prozessen. Es werden die Arbeitsabläufe mit ihren einzelnen Schritten beschrieben, die zu einem bestimmten Ergebnis führen und ihrer Gesamtheit Wert schaffen sollen.

Ein Begriff, der in diesem Zusammenhang weite Verbreitung gefunden hat, ist der „Use-Case“. Ein Use-Case beschreibt die Reaktion des Systems auf ein externes Ereignis. Beispiel für Use-Cases wären: „Ein Buch entlehnen“, „Geld abheben“, „Kontostand abfragen“. Use-Cases und Prozesse stehen in einem Zusammenhang, sind aber nicht ident. Ein Use-Case stellt das Verhalten eines Systems aus der Außensicht dar, während der Schwerpunkt eines Prozesses auf den einzelnen Prozessschritten liegt und diese in Beziehung zueinander setzt. Die Detaillierung eines Use-Cases erfolgt durch die Beschreibung des dazugehörigen Prozesses.

Die Arbeit des Systemanalytikers muss jedoch über die Use-Case- bzw. Prozess-Ebene hinausgehen. Ein Prozess besteht aus mehreren Schritten. Jeder Prozess-Schritt beinhaltet eine Aktion, die von einem Akteur ausgeführt wird. Jede derartige Aktion kann Prozessschritt in mehreren Prozessen sein. Zum Beispiel kann die Aktion „Kontostand abfragen“ in mehreren Prozessen vorgesehen werden. Diese Mehrfach-Verwendung von Aktionen muss in der Systemanalyse berücksichtigt werden.

Das Hauptaugenmerk des Systemanalytikers liegt auf dieser Aktion, die in einem Prozessschritt ausgeführt wird. Sie ist das „Primäre Funktions-Analyse-Objekt“. Diese Aktion kann wiederum aus mehreren Handlungen bestehen. Herausforderung ist es nun, die Aktionen so voneinander abzugrenzen, dass kompakte Einheiten entstehen, die klar nach außen abzugrenzen sind.

Ein Beispiel für eine derartige Aktion könnte „Kundendaten erfassen“ heißen. Die Aktion kann in mehreren Use-Cases bzw. Prozessen vorkommen und besteht aus mehreren Einzelhandlungen, z. B. „Vorname erfassen“, „Zuname erfassen“, „Adresse erfassen“.

In Systemanalyse 3.0 wollen wir diese Aktion „Transaktion“ nennen. Dieser Begriff wird ursprünglich in der Software-Technik verwendet und bedeutet, dass eine bestimmte Funktion mit allen Schritten ganz oder gar nicht durchgeführt wird. So soll verhindert werden, dass etwa bei einer Bank-Überweisung nur die Abbuchung, nicht jedoch die Zugangsbuchung durchgeführt wird.

Im Bereich der Systemanalyse 3.0 wird der Begriff „Transaktion“ in ähnlicher Weise gebraucht; er bezeichnet ebenso eine Funktion, die eine Einheit darstellt und (in der Regel) ganz oder gar nicht durchgeführt wird. Diese fachliche Transaktion kann, muss aber nicht mit der technischen Transaktion übereinstimmen.

Transaktionen sind also die Bausteine, aus denen die Prozesse zusammengesetzt werden.

Abbildung 4: Aus Handlungen werden Transaktionen

Abbildung 4: Aus Handlungen werden Transaktionen

Aus dynamischer Sicht ist es also Aufgabe der Systemanalyse, die Menge an Tätigkeiten und Aufgaben, die in einem Arbeitsgebiet anfallen, in Transaktionen zu gliedern und zusammenzufassen. Die Transaktionen stehen in einer Beziehung zueinander. Diese Beziehungen bilden die Prozesse. Aus der Außensicht entsprechen diese Prozesse den Use-Cases.

Daten und Funktionen – eine Einheit

Daten und Funktionen müssen letzten Endes in der Lösung eine Einheit bilden. Dennoch können sie in der Analyse bis zu einem gewissen Grad getrennt behandelt werden. Und dann stellt sich natürlich die Frage nach der Reihenfolge. Sollen zuerst die Daten oder zuerst die Funktionen analysiert werden?

Im Prinzip ist das ein Henne-Ei-Problem. Daten sind wertlos, wenn sie in keinen Funktionen verwendet werden. Ebenso sind Funktionen ohne Daten nicht denkbar. Deshalb besteht auch eine enge Abhängigkeit zwischen der Funktions- und der Datenanalyse. Aber trotz dieser Abhängigkeit zeigt die Erfahrung, dass die Welt der Daten wesentlich stabiler ist als jene der Funktionen.

Wenn ein durchdachtes, stabiles Datenmodell vorliegt, dann ergeben sich die dazugehörigen Funktionen häufig wie von allein. Aus diesem Grund sprechen wir die Empfehlung aus: Konzentrieren Sie sich zunächst auf das Datenmodell. Finden Sie die Informationsobjekte, die Attribute zwischen den Informationsobjekten. Und suchen Sie eine klare, auf einfache Grundprinzipien basierende Struktur. Wenn die Basis-Struktur bereits sehr komplex ist, wird es Ihnen schwer fallen, die Komplexität, die sich im Laufe der Analyse zwangsläufig ergeben wird, abzubilden.

Eine Technik, mit der der Zusammenhang formal dargestellt werden kann, ist die so genannate CRUD-Matrix – CRUD steht dabei für „Create – Read – Update – Delete“ – die Basis-Aktionen für die Bearbeitung von Daten.

Die CRUD-Matrix gibt Auskunft darüber, welche Informationsobjekte in welchen Transaktionen wie angezeigt und bearbeitet werden. Zu diesem Zweck werden die Transaktionen, die das Ergebnis der Funktionsanalyse sind, in den Zeilen dargestellt und die ermittelten Informationsobjekte in den Spalten der Matrix. In den Schnittpunkten der Zeilen und der Spalten wird jeweils angegeben, ob und wie das jeweilige Informationsobjekt in der Transaktion behandelt wird, wobei das „C“ für „Create“ (Neuanlage), das „R“ für „Read“ (Lesen), das „U“ für „Update“ (Ändern) und das „D“ für „Delete“ (Löschen) steht.

Das gibt nur einen sehr guten Gesamt-Überblick über die Primären Analyse-Objekte, sondern es kann auch auf einfache Art und Weise festgestellt werden ob noch Lücken in der Analyse bestehen. Wenn etwa ein Informationsobjekt in keiner Zelle ein „C“ stehen hat, so muss sich der Analytiker die Frage stellen, wo dieses Informationsobjekt herkommt. In Einzelfällen kann es gute Gründe dafür geben, häufig ist das aber auch ein Indiz dafür, dass noch eine Transaktion fehlt.

Umgekehrt – falls für ein Informationsobjekt nur ein „C“ eingetragen ist, wird man sich die Frage stellen, ob es überhaupt benötigt wird.

Abbildung 5: CRUD-Matrix

Abbildung 5: CRUD-Matrix

Zusammenfassung

In diesem Artikel haben wir uns mit dem ersten Basis-Element der Systemanalyse, dem „Analysieren“ beschäftigt. Wir haben festgestellt, dass in diesem Basis-Element die Lösung entwickelt und ausgearbeitet wird. Mithilfe des Brown-Cow-Modells werden die verschiedenen Dimensionen der Lösung dargestellt.

Analysieren bedeutet Zerlegen. In Systemanalyse 3.0 sind die Elemente, in die zerlegt wird, die Informationsobjeke aus datenorientierter Sicht und die Transaktionen aus funktionsorientierter Sicht. Mithilfe einer CRUD-Matrix können die beiden Sichten vereinheitlicht dargestellt werden.

Im nächsten Artikel werden wir noch beim Analysieren bleiben. Es soll konkret dargestellt werden, wie der Prozess der Zerlegung in die Primären Analyse-Objekte abläuft. Dabei soll vor allem auch darauf eingegangen werden, wie der Systemanalytiker eine kreative Lösung finden kann.

Strategische Partnerschaft zwischen IIBA und IREB

Am 20.08.2015 hat das IIBA (International Institute of Business Analysis) bekannt gegeben, dass globale strategische Allianzen mit mehreren Organisationen geschlossen wurden (http://www.iiba.org/mou.aspx). Unter diesen Organisationen ist auch das International Requirements Engineering Board (IREB), das insbesondere durch seine CPRE (Certified Professional for Requirements Engineering)-Zertifizierungen bekannt geworden ist.

Die Zusammenarbeit soll folgenden Zielen dienen:

  • Förderung des Einsatzes von Business Analyse und Requirements Engineering als Standard-Techniken sowie die Förderung von Zertifizierung und deren gegenseitige Ausrichtung.
  • Ausrichtung der Zertifizierungsprogramme und Schaffung größerer Klarheit über den Kontext und den Zweck.
  • Bewerbung der Ansätze bei Konferenzen und anderen Events.
  • Zusammenarbeit bei akademischen Engagement und weiterer Entwicklung der Fachgebiete.

Diese Entwicklung bestätigt die Entscheidung von SEQIS, seinen Kunden beide Disziplinen in kombinierter Form zur Verfügung zu stellen und so maximalen Wert zu schaffen.

SEQIS setzt in seinen Projekten eine auf die jeweilige Situation abgestimmte Kombination aus Business Analyse und Requirements Engineering ein. Neben diesem praktischen Einsatz entwickelt SEQIS mit „Systemanalyse 3.0“ eine Vorgehensweise, die ebenfalls Business Analyse und Requirements Engineering kombiniert und speziell auf IT-Projekte unter besonderer Berücksichtigung der Lösungsfindung abgestimmt ist (https://blog.seqis.com/systemanalyse-3-0/).

Die nun geschlossene Allianz zwischen IIBA und IREB bestätigt unseren Weg und ermöglicht es uns, noch besser unsere Kunden bei der Erreichung ihrer Ziele zu unterstützen.

Systemanalyse 3.0 – Glossar

Glossar

  • Analysieren: eines der drei Basis-Elemente in Systemanalyse 3.0; das Arbeitsgebiet wird in die Primären Analyse-Elemente zerlegt, die anschließend in ein System gebracht werden, das das Design der Lösung darstellt
  • Anforderung: Aussage eines Stakeholders über eine benötigte Eigenschaft der Lösung; Ausdruck eines Bedarfs
  • Arbeitsgebiet: Bereich, in dem der Bedarf aufgetreten ist, der zur Systemanalyse geführt hat, in den meisten Fällen ein betrieblicher Teilbereich
  • Bedarf: Auslöser der Systemanalyse; erforderliche Änderung in einer Organisation
  • Basis-Elemente: Analysieren – Kommunizieren – Produzieren; die Grundbestandteile von Systemanalyse 3.0
  • Design: Darstellung der Lösung in Form von Text und Modellen
  • Kommunizieren: eines der drei Basis-Elemente in Systemanalyse 3.0; die Lösungs-Hypothese wird mit den Stakeholdern abgestimmt
  • Lösung: das Ziel der Systemanalyse; entwickelt sich aus der Lösungs-Hypothese; wird durch das Design dargestellt
  • Lösungsorientierte Analyse: eine Analyse-Methode, bei der die Lösung von Anfang an im Zentrum steht
  • Lösungs-Hypothese: die aktuelle Vorstellung, die der Systemanalytiker über die Lösung hat; ist während des Analyse-Prozesses einer stetigen Änderung unterworfen
  • Makro-Prozess der Systemanalyse: Zusammenstellung von Mikro-Prozessen zu einem Gesamtprozess
  • Mikro-Prozess der Systemanalyse: Zusammenstellung der Basis-Elemente zu einem Prozess
  • Primäres Analyse-Objekt: Element, in das ein Arbeitsgebiet bei der Analyse zerlegt wird
  • Primäres Daten-Analyse-Objekt: Element, in das ein Arbeitsgebiet in der Datensicht zerlegt wird; ist in Systemanalyse 3.0 das „Informationsobjekt“, das auch „Klasse“ oder „Entität“ genannt wird
  • Primäres Funktions-Analyse-Objekt: Element, in das ein Arbeitsgebiet in der Funktionssicht zerlegt wird; ist in Systemanalyse 3.0 die „Transaktion“
  • Produzieren: eines der drei Basis-Elemente in Systemanalyse 3.0; die in der Analyse ermittelte Lösung wird in den Artefakten festgehalten
  • Stakeholder: Person, die von einer Lösung betroffen ist
  • Transaktion: eine Summe von zusammengehörenden Tätigkeiten, die eine Einheit bilden und in der Regel von einer IT-Funktion unterstützt werden; Transaktionen sind das Primäre Funktions-Analyse-Element; aus Transaktionen werden die Prozesse zusammengesetzt
  • Waste: ein Begriff aus den agilen Methoden; Tätigkeiten und Dokumente, die während des Analyse- und Entwicklungsprozesses ausgeführt bzw. erstellt werden, die aber keinen sinnvollen Beitrag zur Lösung liefern. Diese sind nach Möglichkeit zu vermeiden

 

Systemanalyse 3.0 – Literatur

Literatur

 

[BABOK2015] Business Analysis Body of Knowledge, Version 3.0, IIBA, 2015

[GERSTBACH2015] Gerstbach, Ingrid, Peter: Basiswissen Business-Analyse, Redline 2015

[HEAP2013]  Heap, Tony: There’s no such thing as a requirement; http://www.its-all-design.com/theres-no-such-thing-as-a-requirement/

[HRUSCHKA2014] Hruschka Peter: Business Analyse und Requirements Engineering, Hanser 2014

[IIBA] International Institute of Business Analysis, http://www.iiba.org

[IREB] International Requirements Engineering Board, http://www.ireb.org

[KONNERTH] Konnerth, Tania: Der kreative Prozess; http://www.zeitzuleben.de/2452-kreativitat-was-ist-das-eigentlich/2/

[KRALLMANN2013] Krallmann, Hermann; Trier, Mathias: Systemanalyse; http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/daten-wissen/Informationsmanagement/Information-/System/Systemanalyse

[ROBERTSON2013] Robertson, Suzanne, James: Mastering the Requirements Process, Addison Wesley 2013

[VOLERE] Das VOLERE-Requirements-Portal; http://www.volere.de

%d Bloggern gefällt das: