Kitabı oku: «Business-Analyse», sayfa 7

1.4 Lösungsansätze

„Nur wer sein Ziel kennt, findet seinen Weg.“

Epiktet

Abb. 1.29: Schritt Lösungsansätze in der Business-Case-Erstellung

1.4.1 Überblick

Der dritte Schritt der Business-Case-Erstellung fokussiert auf den Soll-Zustand. Welche Wege gibt es, um vom Ist-Zustand kommend die Geschäftsanforderungen zu erfüllen, das heißt, die fehlenden Leistungspotenziale auszubauen und bestehende Leistungspotenziale zu nutzen?

Auch in diesem Teil der Business-Case-Erstellung finden die Grundprinzipien (vgl. Kapitel G.3.1.2) Anwendung:

 Vom Groben zum Detail: Die Lösungsansätze werden vom Allgemeinen zum Speziellen und von außen nach innen entwickelt. Daher startet dieser Schritt damit, den Umfang bzw. die Reichweite einer möglichen Lösung festzulegen, bevor die Inhalte der Lösungsansätze bestimmt werden. Die Lösungsansätze gilt es dabei noch nicht bis ins letzte Detail auszuarbeiten. Diese weitere Detaillierung gehört zum Konzept „Requirements Engineering“ (vgl. Kapitel 2). Es gilt das „Feld abzustecken“, auf dem später die Lösung erstellt werden soll.

 Von den Zielen zur Lösung: Die Ziele sind mit dem vorhergehenden Schritt Geschäftsanforderungen festgelegt. Nun können Wege in Form von Lösungsansätzen beschrieben werden, die dazu beitragen, diese Ziele zu erreichen.

 Rationales Entscheiden: Die Lösungsansätze sollten möglichst ergebnisoffen erarbeitet werden. Bewährte und vertraute Aspekte können in die Lösungsansätze einfließen. Sie sollten allerdings nicht den Weg für neue Ideen verstellen.

Zur Erarbeitung der Lösungsansätze gehören zwei Komponenten, die wie die zwei Seiten einer Medaille eng zusammengehören:

 Lösungsumfang bestimmen (vgl. Kapitel 1.4.2)- Außerhalb des Lösungsumfangs: Welche Leistungspotenziale des Systems brauchen nicht oder dürfen nicht geändert werden? Welche Beziehungen hat die Lösung zu diesen Leistungspotenzialen?- Innerhalb des Lösungsumfangs: Welche Leistungspotenziale des Systems (z.B. Geschäftsprozesse, Organisationseinheiten und Software-Applikationen) dürfen, sollen oder müssen geändert werden?

 Lösungsvarianten ermitteln (vgl. Kapitel 1.4.3) Beschreibung der Lösungsvarianten, die bestehende Leistungspotenziale verbessern oder neue Leistungspotenziale entwickeln, um die Geschäftsanforderungen zu erfüllen.

1.4.2 Lösungsumfang bestimmen

Der Lösungsumfang grenzt das zu erstellende System nach außen ab. Mit ihm wird der Gestaltungsbereich festgelegt, in dem eine Lösung entwickelt bzw. umgesetzt werden soll. Dabei spielen der Begriff „System“ und das mit ihm verbundene „Systemdenken“ eine wesentliche Rolle.

Systembegriff

Ein System ist gegenüber seiner Umwelt abgegrenzt, besteht aus Teilen (Elementen), die bestimmte Merkmale aufweisen (Dimensionen), die miteinander verknüpft sind (Beziehungen) und die aufeinander einwirken (Elemente und Beziehungen).

Da Business-Analysten häufig in Veränderungen eingebunden sind, die mit IT zu tun haben, liegt es nahe, den Begriff „System“ mit „IT-System“ oder einem rein technischen System gleichzusetzen. Dies würde dazu führen, dass sich der Lösungsansatz und später die Stakeholder- und Lösungsanforderungen hauptsächlich oder ausschließlich auf Hardware- und Software-Komponenten, auf Handbücher, Datenbankinhalte, Masken oder Listen beziehen.

Das ist hier jedoch ausdrücklich nicht gemeint. Systementwicklung und Systemdenken, die nur auf technologische Aspekte beschränkt sind, lassen möglicherweise andere wichtige Aspekte außer Acht. Dazu gehören insbesondere die

 organisatorischen Aspekte einer Veränderung

 kulturellen Aspekte einer Veränderung

 Veränderungen, die sich auf Geschäftsprozesse und damit die Arbeitsabläufe der Beteiligten auswirken, häufig verbunden mit

 veränderten Informationsbedürfnissen der Beteiligten sowie

 veränderten Kompetenzen, Zuständigkeiten und Entscheidungsgrundlagen.

Selbst bei Vorhaben, in denen die IT im Zentrum steht, sind Veränderungen dieser Nicht-IT-Aspekte wichtiger Bestandteil der Arbeit der Business-Analysten.

Die Business-Analysten der TREND Möbelhäuser erkennen bald, dass es zu eng gefasst wäre, als Lösungsansatz nur technisch einen Online-Shop zu beschreiben. Denn darüber hinaus sind Geschäftsprozesse zu klären, wie z.B. Bestell-, Auslieferungs-, Zahlungs-, Rücknahmeprozesse. Zu den kulturellen Aspekten gehört, Mitarbeiter in den Filialen „mitzunehmen“, da Befürchtungen über Arbeitszeitverkürzung oder sogar Arbeitsplatzverluste zu erwarten sind, wenn die Verkäufe von den Filialen in den Shop abwandern. Informationen zu Lagerung, Logistik, Sortiment des Shops erscheinen notwendig. Zu klären ist, wer bezüglich des Shops entscheiden darf, welche Kompetenzen und Regelungen notwendig sind, wenn ein Online-Kunde in eine der Filialen kommt etc.

Systemdenken

Das Systemdenken unterstützt dabei, die Ist-Situation mit ihren Abhängigkeiten zu beschreiben und von Aspekten abzugrenzen, die nicht verändert werden. Mehrere Gründe sprechen dafür, Lösungsansätze mithilfe des Systemdenkens zu entwickeln.

Das Richtige anfassen

 Es soll frühzeitig präzisiert werden, was überhaupt gestaltet oder verändert werden darf.

 Außerdem soll frühzeitig erkannt werden, was unbedingt herauskommen muss bzw. auf keinen Fall herauskommen darf.

Beherrschen komplexer Probleme

 Komplexe Probleme sollen in leichter beherrschbare Teilprobleme untergliedert werden.

 Bei der späteren Arbeit im Detail soll der Überblick erhalten bleiben.

 Integrationsfähige Lösungen sollen entwickelt und Insellösungen vermieden werden.

 Systeme sollen in ihre technische und sozio-kulturelle Umwelt passen.

Realistischen Aufwand abschätzen

 Durch das Systemdenken soll frühzeitig und besser erkannt werden, welcher Aufwand mit der Veränderung verbunden sein wird.

Rationalisierungspotenziale nutzen

 Gleiche Probleme sollen gleich gelöst werden.

 Standardisierte Lösungselemente sollen mehrfach genutzt werden (Modularisierung).

 Überflüssige Bestandteile (z.B. redundante Daten oder Doppelspurigkeiten) sollen erkannt und vermieden werden.

1.4.2.1 Scope-Modellierung

Grundsätzlich lässt sich der Lösungsumfang auch durch eine textliche oder tabellarische Beschreibung festlegen. Dies ist eine pragmatische Form, die sich insbesondere bei kleinen Veränderungen anbietet.

Bei mittleren und großen Veränderungen werden die Teilsysteme und Elemente in der Regel vielfältiger und ihre Beziehungen wichtiger. Dies lässt sich mit einem textlichen oder tabellarischen Lösungsumfang nur bedingt darstellen. Die folgenden Ausführungen zur Bestimmung des Lösungsumfangs beziehen sich sowohl auf Texte und Tabellen als auch auf Modelle; hier wird die Modellierung des Lösungsumfangs besonders hervorgehoben.

Um den Lösungsumfang grafisch zu bestimmen, bietet sich als Technik Scope-Modellierung an. Die zu erstellende Lösung soll nach außen abgegrenzt und nach innen beschrieben werden. Daher gehen Business-Analysten zwei Schritte, um den Lösungsumfang zu bestimmen.

Scope-Modellierung nach außen: den Gestaltungsbereich klären und damit die Systemgrenze bestimmen (vgl. Kapitel 1.4.2.2).

 Welche Leistungspotenziale (Organisationseinheiten, Geschäftsprozesse, (IT-)Systeme etc.) müssen nicht oder sollen nicht geändert werden?

 Was darf nicht verändert werden, ist quasi „Tabuzone“?

 Welche Schnittstellen sind dennoch zu beachten (zu Elementen, Organisationseinheiten, Prozessen, Systemen außerhalb des Gestaltungsbereichs)?

 Wo sind Schnittstellen entbehrlich, da die Elemente oder Systeme der Umgebung für die geplante Lösung irrelevant sind?

Scope-Modellierung nach innen: den Gestaltungsbereich klären und (grob) die zu verändernden Aspekte darstellen (vgl. Kapitel 1.4.2.3).

 Welche Leistungspotenziale (z.B. Geschäftsprozesse, Organisationseinheiten und Software-Applikationen) sollen, müssen oder dürfen geändert werden?

 Wie lassen sich die Leistungspotenziale innerhalb des Gestaltungsbereichs sinnvoll gliedern und ggf. zusammenfassen?

 Welche Schnittstellen und Beziehungen bestehen untereinander und müssen beachtet werden?

1.4.2.2 Scope-Modellierung nach außen

Die Systemgrenze separiert das geplante System (Lösung) von seiner Umgebung. Sie grenzt das System von den Teilen der Umgebung ab, die nicht verändert werden können oder dürfen.

Die Grauzone umfasst Aspekte der Umgebung, für die unklar ist, ob sie eine Beziehung zur Lösung haben oder nicht.

Die Kontextgrenze trennt den relevanten Teil der Umgebung einer Lösung vom irrelevanten Teil, d.h. dem Teil, der keinen Einfluss auf die Lösung hat und daher nicht betrachtet wird.

Abb. 1.30: System, Systemgrenze, Grauzone, Kontextgrenze und irrelevante Umgebung

Tipps und Vorgehen

 Außerhalb der Systemgrenze- Akteure benennen: Person mit Rolle bezeichnen (nicht mit Namen), Firma oder Organisationseinheit- Nachbarsysteme bestimmen: Software, Hardware- Weitere Umsysteme identifizieren: z.B. Geschäftsprozesse, Dokumente

 Vollständigkeit beachten: Alle Nachbar- und Umsysteme, die mit dem System interagieren, sollten im Modell enthalten sein

 Klarheit sicherstellen: Alle Nachbar- und Umsysteme sollten benannt sein

 Schnittstellen beschreiben: Assoziationen (verbindende Linien oder Pfeile) zwischen Nachbar-/Umsystemen und dem System sollten mit der Art der Interaktion beschriftet sein

 Grauzone beachten: Elemente besonders kennzeichnen, die sich in der Grauzone befinden, da noch unklar ist, ob sie verändert werden (und damit in die Systemgrenze verschoben werden) oder nicht verändert werden (und damit in den Systemkontext verschoben werden)

 Übersichtlichkeit wahren: Leistungspotenziale, die in der irrelevanten Umgebung liegen, nur dann aufführen, wenn eine bewusste Entscheidung getroffen wurde, dass sie keinen Bezug zum System haben. Ansonsten ließe sich die Liste der Leistungspotenziale in der irrelevanten Umgebung fast beliebig verlängern.

Für die Möbelhäuser TREND sortieren die Business-Analysten zusammen mit einer Arbeitsgruppe folgende Leistungspotenziale in den Systemkontext, die Grauzone bzw. in die irrelevante Umgebung.

Abb. 1.31: Systemkontext, Grauzone, irrelevante Umgebung der TREND Möbelhäuser

Zur Scope-Modellierung nach außen eignet sich als Technik grundsätzlich auch das Kontextdiagramm (siehe Kapitel 2.7.2). Das Kontextdiagramm wird allerdings typischerweise zur Beschreibung des Kontexts eines technischen Systems eingesetzt, nicht jedoch eines sozio-technischen Systems, in dem auch Menschen mitwirken. Außerhalb der Systemgrenze werden daher Akteure und Nachbarsysteme dargestellt. Auf eine Abbildung von anderen Systemen oder Elementen, die mit dem geplanten System verbunden sind, wie z.B. Geschäftsprozesse oder Dokumente, wird bei einem Kontextdiagramm in der Regel verzichtet.

Als weitere Technik bietet sich auch das Datenflussdiagramm an. Da in einem Datenflussdiagramm auch Scope-Modellierung nach innen erfolgen kann, wird die Technik im folgenden Abschnitt beschrieben.

1.4.2.3 Scope-Modellierung nach innen

Je nach Blickwinkel eignen sich unterschiedliche Techniken oder eine Kombination mehrerer Techniken, um den Lösungsumfang nach innen zu modellieren. Alle Techniken bieten gleichzeitig auch die Möglichkeit, den Lösungsumfang nach außen zu bestimmen und Nachbar- bzw. Umsysteme mit der Systemgrenze zu verknüpfen.

Die Techniken nehmen unterschiedliche Blickwinkel ein:

 Aus einem organisatorischen Blickwinkel: Organigramm (vgl. Kapitel 1.4.2.3.1)

 Aus einem prozessualen Blickwinkel: Geschäftsprozessmodellierung, insbesondere SIPOC als gröbere Darstellung eines Geschäftsprozesses (vgl. Kapitel 1.4.2.3.2)

 Aus einem Blickwinkel auf Daten und Informationen: Datenflussdiagramm (vgl. Kapitel 1.4.2.3.3)

 Aus einem systemischen Blickwinkel: Systemdiagramm, das es erlaubt, organisatorische, technische oder prozessuale Aspekte abzubilden (vgl. Kapitel 1.4.2.3.4).

1.4.2.3.1 Organigramm

Ein vorhandenes Organigramm kann zur Scope-Modellierung genutzt werden, wenn insbesondere aufbauorganisatorische Aspekte einer Veränderung betrachtet werden.

 Welche Stellen, Teams, Abteilungen oder andere Organisationseinheiten sollen verändert werden?

 Welche Organisationseinheiten müssen oder sollten neu im Organigramm entstehen, um Leistungspotenziale zu schaffen?

 Welche Organisationseinheiten sollen von einer Veränderung ausgenommen werden? Sei es, dass sie thematisch nicht zu einer Veränderung beitragen können; sei es, dass sie z.B. innerhalb kurzer Zeit nicht erneut eine Veränderung erfahren sollen.

 Welche Schnittstellen zu Organisationseinheiten sind zu beachten, selbst wenn diese selbst nicht verändert werden? Schnittstellen können dabei z.B. Geschäftsprozesse, Informations- oder Entscheidungswege sein.

Abb. 1.32: Organigramm der TREND Möbelhäuser mit Systemgrenze

1.4.2.3.2 SIPOC

SIPOC ist eine Technik zur Erhebung und Darstellung eines Prozesses auf grober Ebene. SIPOC steht als Akronym für

 S=Supplier (Lieferant),

 I=Input (Einsatzfaktor),

 P=Process (Prozess),

 O=Output (Ergebnis) und

 C=Customer (Kunde).

Der SIPOC ist mit seiner tabellarischen Struktur keine grafische Modellierung eines Geschäftsprozesses im engeren Sinne. Er eignet sich allerdings gut, um einen Prozess grob darzustellen und damit einen Überblick zu den wesentlichen Bestandteilen eines Prozesses zu erhalten.

Ein Geschäftsprozess ist eine Struktur, deren Elemente Aufgaben, Aufgabenträger, Sachmittel und Informationen sind, die durch logische Folgebeziehungen verknüpft sind. Darüber hinaus werden zeitliche, räumliche und mengenmäßige Dimensionen konkretisiert. Ein Prozess hat ein definiertes Startereignis (Input) und Ergebnis (Output) und dient dazu, einen Wert für Kunden zu schaffen.

Abb. 1.33: Grobstruktur eines Geschäftsprozesses mit ergänzenden Fragen

Die Struktur des SIPOC mit fünf Spalten lehnt sich stark an die Grobstruktur eines End-to-End-Prozesses an: Customer, Input, Process, Output, Customer.

Abb. 1.34: SIPOC für Bestellprozess nicht vorrätiger Möbel

Für einen SIPOC sind besonders relevant der Supplier sowie Input in der obersten Zeile (im Beispiel „Kunde“ und „Kaufwunsch“), die Spalte Process und in der letzten Zeile Output sowie Customer („Möbel, Rechnung“ und „Kunde“). Durch diese Angaben werden wesentliche Aspekte des Prozesses beschrieben.

Die Einträge bei Supplier, Input, Output und Customer in den anderen Zeilen können vorgenommen werden, um den Prozess mit weiteren Aspekten zu ergänzen.

Tipps und Vorgehen

 Name: Geschäftsprozess benennen

 Kunde: Prozessbeteiligten bestimmen, der einen Mehrwert aus der Durchführung des Prozesses erhalten soll. Kunde wird bei Kernprozessen eines Unternehmens in der Regel ein externer Kunde sein. Bei Support-Prozessen geht es um einen Mehrwert für interne Kunden.

 Output: Das wesentliche (End-)Ergebnis des Prozesses bestimmen, das dem (internen oder externen) Kunden einen Mehrwert bietet. Damit ist auch das Ende des Prozesses definiert.

 Input: Welche Voraussetzungen oder Ereignisse stoßen den Prozess an bzw. sind vor dessen Durchführung zwingend notwendig?

 Lieferant: Wer stellt diesen Input zur Verfügung?

 Prozess: Was sind die wesentliche Schritte, aus denen der Prozess besteht? In welcher Reihenfolge laufen sie ab? Um nicht zu detailliert zu werden, hilft es eine Obergrenze von 7-10 Prozessschritten zu beachten. In vielen Fällen entsprechen die Prozessschritte den Teilprozessen einer detaillierteren Geschäftsprozessmodellierung, wie z.B. BPMN (vgl. Kapitel 2.7.5).

 Supplier, Input, Output, Customer: Was sind die relevanten Inputs und Outputs der anderen Prozessschritte? Wer stellt sie bereit bzw. empfängt sie? Gibt es Schnittstellen zu anderen Prozessen?

1.4.2.3.3 Datenflussdiagramm

Ein Datenflussdiagramm ist eine diagrammorientierte Modellierungsart, die dazu genutzt wird, den Datenfluss eines Systems wiederzugeben.

Datenflussdiagramme stellen dar, woher Daten kommen, mit welchen Aktivitäten sie in einem System verarbeitet werden, wo Daten gespeichert werden und welche externen Einheiten die Daten verwenden.

Die Business-Analysten der TREND Möbelhäuser erstellen zusammen mit den Stakeholdern ein Datenflussdiagramm für Rechnungen und Zahlungseingänge.

Abb. 1.35: Datenflussdiagramm in Yourdon-Notation

Tipps und Vorgehen

 Modellierungsebene festlegen: Datenflussdiagramme können unterschiedlich detailliert dargestellt werden. Die höchste Ebene fokussiert auf die externen Entitäten und ihre Datenflüsse zum zu beschreibenden System. Die Darstellung eines Datenflussdiagramms auf dieser Ebene 0 entspricht der Scope-Modellierung nach außen (vgl. oben).Auf der nächsttieferen Ebene 1 werden die Datenprozesse und Datenspeicher des Systems mit den entsprechenden Input-Daten und Output-Daten ergänzt.Dem Prinzip vom Groben zum Detail folgend sollte zunächst ein Diagramm auf Ebene 0 erstellt und dann zu Ebene 1 detailliert werden.

 Modelltyp festlegen: Logische Datenflussdiagramme können den Soll-Zustand abbilden und eignen sich dazu, den Lösungsumfang zu bestimmen.Physische Datenflussdiagramme modellieren in der Regel detaillierter, u.a. Speicher, Drucker, Masken. Sie werden typischerweise von den Entwicklern erstellt und eignen sich aufgrund ihrer Detaillierung und starken Determiniertheit nur bedingt zur Scope-Modellierung.

 Externe Entitäten modellieren: Quelle oder Senke von Daten identifizieren, die außerhalb des Systems liegen. Dies können Personen, Organisationseinheiten oder Systeme sein. Externe Entitäten senden oder empfangen mindestens eine Dateneinheit. Sie werden mit einem Substantiv beschrieben.

 Datenflüsse ergänzen: Bewegung der Daten von externen Entitäten zum System bzw. vom System zu externen Entitäten darstellen. Diese Linien mit einem Pfeil werden mit einem Substantiv beschrieben.

 Datenprozesse modellieren: Ein Prozess transformiert (Input-) Daten in (Output-)Daten innerhalb des Systems. Ein Prozess benötigt daher mindestens einen Input und einen Output, die durch Datenflüsse dargestellt werden. Datenprozesse sollten durch die Benennung mit Substantiv und Verb eindeutig definiert werden.

 Datenspeicher ergänzen: Ein Datenspeicher ist eine Sammlung von Daten. Diese können mehrfach genutzt und für eine spätere Verwendung aufbewahrt werden. Ein Datenspeicher benötigt mindestens einen Datenfluss, der Daten zu ihm führt, oder einen Datenfluss, der Daten aus ihm heraus in einen Prozess oder eine externe Entität führt.

1.4.2.3.4 Systemdiagramm