Kitabı oku: «Business-Analyse»

G.3 ibo-Anforderungstür^®

G.3.1 Übersicht

Business-Analyse ist eine ganzheitliche Methode, die Veränderungen auf ihren Nutzen prüft, Anforderungen an Veränderungen ermittelt, analysiert und dokumentiert, die Einführung von Lösungen begleitet sowie die Business-Analyse selbst plant und steuert.

Die ibo-Anforderungstür^® bildet das grafische Modell für die grundlegende Struktur der Business-Analyse. Sie dient dazu, den Überblick über das gesamte Thema zu gewinnen und zu bewahren. Die ibo-Anforderungstür^® hat sich in den letzten Jahren als Rahmenwerk (Framework) mit Vorgehensschritten und verknüpften Techniken in Training und Praxis bewährt und etabliert. Sie dient hier als Leitfaden in der Business-Analyse und als Gliederung für dieses Buch.

G.3.1.1 Konzepte

Vier Konzepte beschreiben die Anwendungsfelder, in denen Business-Analysten tätig werden: Business-Case-Erstellung, Requirements Engineering, Lösungseinführung, Business-Analyse-Planung und -Steuerung.

Das Konzept der Business-Case-Erstellung bietet vier Schritte, in denen vorab untersucht wird, ob es sinnvoll ist, sich weiter und detaillierter mit einem Vorhaben zu beschäftigen. Dazu werden unter anderem Geschäftsanforderungen, wirtschaftliche Aspekte, der Kontext und Risiken betrachtet, die die angedachte Veränderung mit sich bringen kann.

Schwerpunkt der Arbeit von Business-Analysten ist normalerweise das Ermitteln, Dokumentieren und Analysieren von Anforderungen. Im Konzept Requirements Engineering werden sinnvolle Vorgehensschritte beschrieben, die von der Vorbereitung bis hin zur Genehmigung der Anforderungen reichen, so dass diese später umgesetzt und eingeführt werden können. Bildlich gesprochen schlägt im Requirements Engineering das Herz der Business-Analyse.

Das Konzept Requirements Engineering beschreibt den Weg der Anforderungen von der Quelle, also von denjenigen, die Anforderungen einbringen, hin zu Entwicklern und Umsetzern. Bildlich gesprochen ist das der „Hinweg“ der Anforderungen.

Das Konzept Lösungseinführung beschreibt den „Rückweg“. Die Einführung einer neu erstellten oder veränderten Lösung (sei es ein IT-System, ein Geschäftsprozess oder eine andere Veränderung im Unternehmen) muss geplant werden, damit sie möglichst gut ihre gewünschte Wirkung entfalten kann. Business-Analysten sollten die Einführung der Lösung begleiten, da sie sich intensiv mit den Anforderungen an die Lösung auseinandergesetzt haben.

Das Konzept Business-Analyse-Planung und -Steuerung ist das verbindende Konzept zu den drei anderen Konzepten, mit dem gesamten Vorgehen vom Business Case über das Requirements Engineering bis zur Lösungseinführung. Durch die Schritte Planung, Ist-Erfassung, Diagnose und Steuerung soll eine effiziente und effektive Business-Analyse sichergestellt werden.

Die verbindende Klammer zwischen Business-Analyse-Planung und -Steuerung und den drei anderen Konzepten bilden jeweils drei Handlungsfelder:

  Berufliche Handlungskompetenz, die bei der Ausführung der jeweiligen Aufgaben unterstützt (z.B. Geschäftsverständnis bei der Erstellung des Business Case). Zur beruflichen Handlungskompetenz vgl. die Einführung in Kapitel 1.8.1

 Wichtige Zielgruppen für Business-Analysten im jeweiligen Konzept (z.B. Kunden, Management)

  Ergebnistyp des jeweiligen Konzepts (z.B. Business Case als Dokument).

Abb. G.07: ibo-Anforderungstür^®

Die angesprochenen Veränderungen können in unterschiedlichen Kontexten (z.B. Projekt oder Tagesgeschäft, Releases oder Einzelmaßnahmen) geschehen oder mit unterschiedlichen Vorgehensmodellen (z.B. Scrum oder Geschäftsprozessoptimierung) vorangetrieben werden.

Die ibo-Anforderungstür^® kann an unterschiedlich große Veränderungen angepasst werden. Die Kapitel 1-3 geben Hinweise, wie die ibo-Anforderungstür^® bei kleinen, mittleren und großen Veränderungen angewendet

wird. Zudem wird jeweils erläutert, wie das Modell in klassischen Vorgehensmodellen bzw. in agilen Vorgehensmodellen angewendet werden kann. Das Kapitel 5 „Business-Analyse in agilen Kontexten“ fasst wichtige Aspekte zu diesem Thema zusammen.

G.3.1.2 Grundprinzipien

Business-Analyse baut auf drei Grundprinzipien, die sich auch in anderen Aufgabengebieten und Disziplinen bewährt haben. Diese Grundprinzipien werden ebenfalls in der ibo-Anforderungstür^® angewandt.

Zu den Grundprinzipien zählen

 das Vorgehen vom Groben zum Detail

 das Vorgehen von den Zielen zur Lösung

 rationales Entscheiden.

Vom Groben zum Detail

Bevor man sich in Details verliert und möglicherweise den Überblick verliert, sollte zunächst das Gesamtbild verstanden werden. Ansonsten besteht die Gefahr, dass man „den Wald vor lauter Bäumen nicht sieht“. Für Business-Analysen gilt deswegen der Grundsatz, erst die Gesamtzusammenhänge (das Big Picture) zu erarbeiten, bevor die Details oder die konkreten Anforderungen untersucht werden.

Der Gesamtüberblick hilft später, die einzelnen Anforderungen in das Gesamtbild einzuordnen. Dann wird auch besser ersichtlich, ob einzelne Anforderungen dazu beitragen, die Geschäftsanforderungen zu erreichen. Zudem fällt es leichter, den Aufwand für die Business-Analyse abzuschätzen, wenn klar ist, wie groß beziehungsweise wie umfangreich das anstehende Vorhaben ist.

Von den Zielen zur Lösung

Maßnahmen zu ergreifen und umzusetzen verspricht oft einen schnellen und gut sichtbaren Erfolg. Dabei tritt allerdings oft das Problem auf, dass diese ergriffenen Maßnahmen sich als nicht zielführend herausstellen. Dann wurden Zeit und Ressourcen verschwendet, manchmal ist sogar eine Verschlimmbesserung die Folge – der neue Zustand ist im Ergebnis schlechter als der alte.

Ziele beschreiben einen zukünftigen Zustand beziehungsweise erwünschte Wirkungen, ohne dabei den Weg zur Umsetzung der Ziele selbst zu beschreiben. Selbst wenn der Weg etwa durch gesetzliche, strategische oder technologische Restriktionen vorgegeben ist, sollten dennoch die Ziele geklärt werden, die am Ende erreicht werden sollen.

Die Lösung ergibt sich aus der Summe der Maßnahmen, die aus einem Ist-Zustand einen künftigen Soll-Zustand entwickeln. Häufig wird bei einer Lösung nahezu zwangsläufig an eine IT-Lösung gedacht, aber nicht alle Anforderungen erfordern unbedingt die IT. Die Business-Analyse sollte in jedem Fall eine ganzheitliche Perspektive einnehmen. Neben technischen Aspekten sollte sie auch prozessuale, strukturelle, strategische und kulturelle Aspekte einer Lösung berücksichtigen. Selbst wenn es auf eine IT-Lösung hinausläuft – was sehr oft der Fall ist – hilft die beste IT-Lösung wenig, wenn ihre Auswirkungen auf Geschäftsprozesse, Aufbauorganisation (zum Beispiel das Organigramm), ihre strategische Relevanz und Akzeptanz bei Beteiligten und Betroffenen nicht analysiert und berücksichtigt wurde.

Rationales Entscheiden

Komplett neue Lösungen zu entwickeln – auf der grünen Wiese neu zu beginnen – kann unter Umständen sehr sinnvoll sein und wirklich innovative und gute Lösungen überhaupt erst möglich machen. Solche Verbesserungen sind manchmal durch ein Vorgehen in kleinen Schritten zur Verbesserung des Ist-Zustands – empirisches Vorgehen – kaum möglich. Gleichwohl setzt die Mehrzahl der Lösungen, die in der Praxis entwickelt werden, auf den Ist-Zustand auf: Bestehende IT-Systeme, vorhandene Geschäftsprozesse, eine existierende Aufbauorganisation sollen dann weiterentwickelt werden.

Wird das Prinzip des rationalen Entscheidens für die Business-Analyse angewendet, steht eine Analyse des Ist-Zustands am Anfang. Aus ihr werden Handlungsfelder und Handlungsoptionen ersichtlich. Zunächst sollten dabei Probleme und deren Ursachen analysiert sowie Ziele formuliert werden. Erst danach sollten Verbesserungsmöglichkeiten des Ist-Zustands ermittelt und Lösungsansätze entwickelt sowie der beste Lösungsansatz weiterverfolgt werden. Rationales Entscheiden bedeutet in diesem Zusammenhang auch, dass nachvollziehbar und mit plausiblen Kriterien aufgezeigt wird, welches der beste Lösungsansatz ist. Jetzt kann entschieden werden, ob „auf der grünen Wiese“ neu gestaltet oder auf dem Bestehenden aufgebaut wird.

Alle drei Prinzipien ziehen sich durch die komplette ibo-Anforderungstür^®, finden sich allerdings auch in den einzelnen Konzepten Business-Case-Erstellung, Requirements Engineering, Lösungseinführung und Business-Analyse-Planung und -Steuerung. Hier seien die wichtigsten Anwendungsfelder genannt.

Vom Groben zum Detail wird als Prinzip angewendet, indem zunächst der (gröbere) Business Case erstellt wird, bevor sich Business-Analysten im Requirements Engineering mit den detaillierteren Anforderungen beschäftigen.

Von den Zielen zur Lösung bedeutet, dass die Ziele (Geschäftsanforderungen) frühzeitig im Business Case formuliert werden, ehe über einen Lösungsansatz nachgedacht wird, dieser im Requirements Engineering näher beschrieben wird und die Lösung schließlich genutzt wird (Lösungseinführung).

Rationales Entscheiden findet sich ebenfalls in allen Konzepten wieder. Im Business Case wird beispielsweise zunächst der Ist-Zustand analysiert, bevor Lösungsansätze empfohlen werden. Im Requirements Engineering liegt dem Vorgehen (von der Vorbereitung hin zur Genehmigung) rationales Entscheiden zugrunde. In der Lösungseinführung wird die Wirksamkeit der Lösung geprüft und es wird bewertet, ob die Lösung zielgerichtet ist. In Business-Analyse-Planung und -Steuerung wird die eigene Arbeit als Business-Analyst fortlaufend daraufhin analysiert, ob sie effizient und effektiv funktioniert.

G.3.2 Business-Case-Erstellung

Abb. G.08: Business-Case-Erstellung

„Das Problem zu erkennen, ist wichtiger als die Lösung zu erkennen, denn die genaue Darstellung des Problems führt zur Lösung.“

Albert Einstein

Es gibt viele Ausgangspunkte und Auslöser für Business-Analysen, zum Beispiel:

  intern angestoßene Verbesserungsmaßnahmen

  extern ausgelöste Veränderungen, beispielsweise durch neue oder andersartige Kundenbedürfnisse oder gesetzliche beziehungsweise regulatorische Änderungen

 kleine Veränderungen, die punktuelle Chancen zur Verbesserung wahrnehmen

  große Maßnahmen, die im Rahmen von Projekten umgesetzt werden

 durch Mitarbeiter genannte Anforderungen

 durch Geschäftsführung oder Strategie initiierte Veränderungen

 eine Mischung der vorgenannten Auslöser.

Unabhängig davon, wie die Ausgangslage aussieht, sollte die Business-Analyse zuerst versuchen, das Gesamtbild zu verstehen, ehe sie sich näher mit detaillierteren Anforderungen beschäftigt und nach Wegen zu einer möglichen Lösung sucht. Ein Business Case bietet eine Struktur für ein systematisches Vorgehen an. Vier Vorgehensschritte führen von der Untersuchung und Analyse des Ist-Zustands zur Empfehlung eines Soll-Zustands. Um das Prinzip „Vom Groben zum Detail“ zu beachten, erstellt der Business-Analyst den Business Case auf „größerer Flughöhe“.

Leistungspotenziale

Im ersten Schritt der Business-Case-Erstellung analysieren Business-Analysten die Ist-Situation. Diese wird auf fehlende und bestehende Leistungspotenziale untersucht. Wo liegen aktuell Probleme, die es zu lösen gilt? Welche Ursachen führen zu diesen Problemen?

Fehlende Leistungspotenziale sind in vielen Fällen IT-Systeme beziehungsweise IT-Unterstützung, die neu zu erstellen oder zu verbessern sind. Darüber hinaus sollten allerdings auch Geschäftsprozesse, strukturelle Veränderungen und kulturelle Aspekte berücksichtigt werden.

Bei einer Fokussierung allein auf Schwächen und deren Ursachen übersieht man leicht, welche Leistungspotenziale bereits bestehen. Vorhandene Stärken sollten genutzt und nicht durch Veränderungen (leichtfertig) geopfert werden. Bestehende Leistungspotenziale können analog leistungsfähige IT-Systeme, störungsfreie Geschäftsprozesse, funktionierende Strukturen oder eine positive Kultur sein.

Die TREND Möbelhäuser haben seit einiger Zeit stagnierende und leicht rückläufige Umsätze festgestellt. Auf Vorschlag der Geschäftsführung werden nun Business-Analysten beauftragt, die Ist-Situation näher zu untersuchen. Das Problem ist durch die rückläufigen Umsätze beschrieben. Die Business-Analysten müssen nun die dahinterliegenden Ursachen analysieren.

Sie identifizieren als fehlendes Leistungspotenzial, dass Kunden im Internetauftritt von TREND nicht nach Möbeln suchen, geschweige denn diese kaufen können. Wesentliche bestehende Leistungspotenziale sind die Möbelhäuser, in denen die Kunden einen sehr guten Service erhalten. Diese vorhandenen Leistungspotenziale müssen bei allen geplanten und notwendigen Veränderungen erhalten bleiben.

Geschäftsanforderungen

Wurde die Ist-Situation auf fehlende und bestehende Leistungspotenziale untersucht, werden in einem zweiten Schritt die Geschäftsanforderungen, d.h. die Ziele formuliert. Dadurch wird der Soll-Zustand beschrieben, ohne dass bereits Maßnahmen oder Wege zur Erreichung dieses Soll-Zustands festgelegt werden. Ziele sind erwünschte Wirkungen, erwünschte Ereignisse oder Ergebnisse. Sie beschreiben, was erreicht werden soll, nicht wie es erreicht werden soll. In vielen Fällen lassen sich die Geschäftsanforderungen aus den fehlenden und bestehenden Leistungspotenzialen ableiten.

Aus dem fehlenden Leistungspotenzial „sinkende Umsätze“ formulieren die Business-Analysten „steigende Umsätze“ als eine unter mehreren Geschäftsanforderungen. Aus dem bestehenden Leistungspotenzial „guter Service in den Möbelhäusern“ wird die Geschäftsanforderung, dass dieser Service erhalten bleiben soll, unabhängig davon, welche Veränderungen beziehungsweise Lösungen bei TREND umgesetzt werden.

Die Geschäftsanforderungen sind zu vervollständigen. Die Zielklassen Wirtschaftliche Ziele, Leistungsziele, Kulturelle Ziele und Vorgehensziele können helfen, bisher nicht erkannte Ziele zu erkennen und die Sammlung zu vervollständigen (siehe dazu Kapitel 1.3).

Lösungsansätze

Lösungsansätze beschreiben grobe Wege, wie die Ist-Situation zielgerichtet verbessert und zu einem angestrebten Soll-Zustand geführt werden kann. In vielen Fällen bündeln Lösungsansätze Maßnahmen, die Veränderungen an bestehenden IT-Systemen, Geschäftsprozessen oder der Aufbauorganisation beschreiben. Im Rahmen der Erstellung eines Business Case werden mögliche Lösungsrichtungen formuliert, aus denen nach dem Schritt Empfehlung ein Lösungsansatz gewählt wird, der im Konzept Requirements Engineering detailliert und umsetzungsreif ausgearbeitet wird.

Genauso wie es diverse Ausgangssituationen für die Erstellung eines Business Case gibt, sind auch unterschiedlichste Lösungsansätze denkbar. Häufig sind die folgenden Lösungsrichtungen anzutreffen:

 Make or Buy (eine Lösung selbst erstellen oder kaufen)

 kleine, mittlere oder große Veränderung

 kurz-, mittel- oder langfristige Anpassungen

 Quick Wins (schnelle Verbesserungen).

Unabhängig vom gewählten Lösungsansatz sollte festgelegt und dokumentiert werden, was verändert werden darf, soll oder muss (in Scope), und was nicht verändert werden darf oder soll (out of Scope).

Empfehlung

Im Schritt Empfehlung fließen alle drei vorhergehenden Schritte zusammen. Es wird versucht, aus den erarbeiteten Lösungsansätzen den besten herauszufinden. Dazu wird geprüft, welcher Lösungsansatz voraussichtlich die Geschäftsanforderungen (Ziele) am besten erreichen wird. Neben einer finanziellen Analyse oder Kosten-Nutzen-Analyse wird in den meisten Fällen auch eine Risikoanalyse erstellt, welche Risiken mit den einzelnen Lösungsansätzen verbunden sind.

Handlungsfelder

Die Handlungsfelder bestehen aus den drei Komponenten berufliche Handlungskompetenz, wichtige Zielgruppe und Ergebnistyp. Die Handlungskompetenz der Business-Analysten ist gegeben, wenn sie die betrieblichen Zusammenhänge (Geschäftsverständnis) und das Big Picture verstehen. Wichtige Zielgruppe sind Kunden, seien es interne oder externe, für die eine Veränderung einen Mehrwert erbringen soll. Business-Analysten sind in den wenigsten Fällen in der Position des Entscheiders. Das Management entscheidet aufgrund des Business Case über das weitere Vorgehen. Dies kann ein Gremium sein (beispielsweise der Lenkungsausschuss eines Projekts oder ein Projekt-Portfolio-Board) oder eine Einzelperson (Führungskraft, Sponsor, Auftraggeber).

Alle vier Schritte, von den Leistungspotenzialen bis hin zur Empfehlung, fließen als Ergebnistyp dieses Konzepts im Dokument Business Case zusammen. In der Praxis werden dafür unterschiedliche Bezeichnungen verwendet, z.B. Entscheidungsvorlage, Wirtschaftlichkeitsrechnung oder eben Business Case.

Eine ausführliche Beschreibung des Konzepts Business Case findet sich in Kapitel 1.

G.3.3 Requirements Engineering

Abb. G.09: Requirements Engineering

Das zweite Konzept der ibo-Anforderungstür^®ist für viele Business-Analysten das Hauptbetätigungsfeld. Die Bezeichnungen für diesen Teil der Business-Analyse sind vielfältig: Anforderungsanalyse, Anforderungsmanagement, Feinkonzept oder auch fachliche Spezifikation finden sich in der Praxis. Allen gemein ist, dass sie die Aufgaben beschreiben, die mit der Ermittlung von Anforderungen, deren Analyse und Dokumentation verbunden sind.

In diesem Konzept Requirements Engineering wird ein praxisbewährtes sechsstufiges Vorgehensmodell dargestellt, das den Prinzipien „Vom Groben zum Detail“ und „Rationales Entscheiden“ folgt.

Vorbereitung

„In allen Dingen hängt der Erfolg von den Vorbereitungen ab.“

Konfuzius

Die Vorbereitung greift auf die Ergebnisse der Planung aus dem Konzept Business-Analyse-Planung und -Steuerung zurück. Für kleinere Veränderungen wird möglicherweise auf eine Planung und Steuerung der Business-Analyse verzichtet; dann sollte die Vorbereitung allerdings besonders sorgfältig sein.

In der Vorbereitung wird insbesondere der folgende Schritt Anforderungsermittlung detaillierter geplant. Im Sinne einer rollierenden Planung werden die weiteren Schritte erst gröber und dann zunehmend detaillierter vorbereitet.

Zunächst bestimmen Business-Analysten insbesondere die Anforderungsquellen, die Inhalte, die ermittelt werden sollen, und die Techniken, mit denen die Anforderungen erhoben werden. Eine gute Vorbereitung ist für die beteiligten Stakeholder sicht- und spürbar. Die in die Vorbereitung investierte Zeit rentiert sich in vielen Fällen, weil eine strukturierte und ergebnisorientierte Herangehensweise in der Ermittlung die Vollständigkeit und die Qualität der Anforderungen fördert.

Anforderungsermittlung

Sehr gebräuchliche Techniken der Ermittlung von Anforderungen sind Workshops und Interviews. Daneben gibt es weitere bewährte Werkzeuge, die Business-Analysten nutzen können; sie werden in Kapitel 2.3 vorgestellt.

Im Zuge der Anforderungsermittlung werden neben den Anforderungen auch geschäftliche und technische Restriktionen erhoben. Sie sind wichtige Bestandteile für das zu erstellende Anforderungsdokument, sollten aber getrennt von den Anforderungen dokumentiert werden. Die Unterscheidung zwischen Anforderungen und Restriktionen ist nicht immer trennscharf und bedarf daher in vielen Fällen einer Analyse durch die Business-Analysten. Anforderungen beschreiben die zu erstellende Lösung. Sie beziehen sich in vielen Fällen auf eine gewünschte Funktionalität einer Lösung. Restriktionen schränken die Möglichkeiten, eine Lösung zu erstellen, ein oder erzwingen bestimmte Lösungsbestandteile. Eine technische Restriktion kann zum Beispiel sein, dass die Lösung auf einer vorgegebenen technologischen oder IT-Plattform zu entwickeln ist. Eine typische geschäftliche Restriktion erzwingt, dass gesetzliche Bestimmungen einzuhalten sind.

Anforderungspriorisierung

Selbst bei einer vergleichsweise groben Ermittlung der Anforderungen treten in der Regel mehrere Anforderungen zutage. Grundsätzlich besteht natürlich die Möglichkeit, mit allen erhobenen Anforderungen in die weitere Analyse einzusteigen. Manchmal ist es aber besser, erst zu klären, ob alle den gleichen Stellenwert haben oder einige Anforderungen erst einmal zurückgestellt werden.

Agile Vorgehensmodelle setzen per se darauf, nicht gleich alle Anforderungen umzusetzen, sondern schrittweise Teilergebnisse zu produzieren. Dazu werden Anforderungen immer wieder priorisiert, um die wichtigsten und dringlichsten Anforderungen zeitnah zu analysieren und umzusetzen. Zentrales Kriterium der Priorisierung ist in aller Regel der Wert beziehungsweise der Mehrwert für den Kunden. Auch bei klassischen, stufenweisen Vorgehensmodellen fordert das Grundprinzip des rationalen Entscheidens, auf die Anforderungen zu fokussieren, die eine höhere Priorität besitzen als andere.

Unabhängig vom Vorgehensmodell übersteigen normalerweise die Wünsche und Bedürfnisse der Anforderungssteller die vorhandenen Kapazitäten für deren Umsetzung. Daher ist es sinnvoll, „die Spreu vom Weizen zu trennen“ und sich besonders um die Anforderungen zu kümmern, deren Umsetzung am wahrscheinlichsten und sinnvollsten ist, bevor die Anforderungen weiter detailliert und dokumentiert werden. Dazu legen Business-Analysten zusammen mit den Stakeholdern Priorisierungskriterien fest. Zur Priorisierung der Anforderungen können eine oder mehrere Techniken eingesetzt werden (Kapitel 2.4). Ergebnis der Anforderungspriorisierung ist ein klareres Bild, welche Anforderungen zu diesem Zeitpunkt zurückgestellt werden können und welche weiteranalysiert werden sollen.

Strukturierung, Spezifizierung, Modellierung

Business-Analysten stehen verschiedene Techniken zur Dokumentation von Anforderungen zur Verfügung. Grundsätzlich kann unterschieden werden zwischen textlicher Dokumentation von Anforderungen (Spezifizierung) und der Dokumentation von Anforderungen mittels Grafiken beziehungsweise Modellen (Modellierung).

Strukturierung ist die Wahl des passenden Werkzeugs oder eines sinnvollen Mix von Dokumentationstechniken und die Zusammenstellung der „richtigen“ Anforderungen für die Spezifizierung und Modellierung.

Während in der Praxis häufig Anforderungen freihändig in Textform dokumentiert werden, werden in Kapitel 2.6 die Vorteile einer systematischen textlichen Form aufgezeigt. Im darauffolgenden Kapitel 2.7 werden dann standardisierte Modellierungstechniken erläutert, die sich für die Dokumentation von Anforderungen besonders eignen.

Verifizierung, Validierung

Grundsätzlich sollten erhobene und dokumentierte Anforderungen geprüft werden. Fehler im Anforderungsdokument können sich ansonsten bis in die Lösung fortsetzen.

Verifizierung ist die formale Überprüfung von Anforderungen auf Fehler, Redundanzen, Lücken und Widersprüche. Im Sinne des Vier-Augen-Prinzips sollte idealerweise nicht allein der Autor des Anforderungsdokuments die Anforderungen überprüfen. Grundsätzlich können das auch die Stakeholder tun. Es hat sich bewährt, dass ein oder mehrere weitere Business-Analysten (sogenannte Peers) die Verifizierung übernehmen. Da hier die rein formale Überprüfung der Anforderungen im Vordergrund steht, benötigen die Prüfer in den meisten Fällen keine detaillierten fachlichen oder inhaltlichen Kenntnisse. Ganz im Gegenteil kann ein neutraler (nicht „betriebsblinder“) Blick sogar sehr hilfreich sein.

Validierung ist die Überprüfung der Anforderungen dahingehend, ob sie zielgerichtet sind. Business-Analysten sollten einerseits prüfen, dass keine übertriebenen Anforderungen eingebracht werden (Goldrandlösung). Andererseits überprüfen sie, ob die Ziele mit den Anforderungen voraussichtlich erreicht werden können. Die Validierung führt die Geschäftsanforderungen, die das „Warum“ und damit die erwünschten Wirkungen beschreiben, mit den Stakeholder-Anforderungen und Lösungsanforderungen zusammen, die den Weg zum Ziel beschreiben („Was“ und „Wie“).

Genehmigung

Genehmigung ist die formale oder informale Abnahme der dokumentierten Anforderungen für die weiteren Schritte, insbesondere für die Umsetzung. Business-Analysten haben in den seltensten Fällen das Recht, selbst Anforderungen zu genehmigen. In klassischen Vorgehensmodellen genehmigt das Gremium (zum Beispiel Lenkungsausschuss) oder die Person (zum Beispiel Sponsor), die dem Projekt vorsteht. In agilen Vorgehensmodellen wird die Genehmigung meistens durch eine Rolle durchgeführt; in Scrum zum Beispiel durch den Product Owner.

Anforderungsmanagement

Im Laufe der Business-Analyse werden in der Regel viele Anforderungen ermittelt und weiter analysiert. Es ist sinnvoll, diese Anforderungen über deren gesamten Lebenszyklus hinweg zu verwalten, sodass sie genutzt, gepflegt und bei Bedarf weiterverwendet werden können.

Handlungsfelder

Als berufliche Handlungskompetenz hilft Business-Analysten Teamarbeit und Konfliktmanagement. Viele Aufgaben im Requirements Engineering werden gemeinsam angegangen, beispielsweise in Workshops. Wenn dabei Anforderungen und Interessen nicht übereinstimmen, können schnell Konflikte entstehen. Dann sind Kenntnisse im Konfliktmanagement hilfreich.

Die Stakeholder – also diejenigen, die ein eigenes Interesse an der Lösung haben – sind eine wichtige Zielgruppe, da deren Anforderungen zu ermitteln, zu priorisieren und zu genehmigen sind. Ihre Beteiligung und Einbindung in die Business-Analyse entscheidet in vielen Veränderungen über den Erfolg und die Akzeptanz der zu entwickelnden Lösung.

Alle Schritte im Konzept des Requirements Engineering schlagen sich im Ergebnistyp Anforderungsdokument nieder. Abhängig vom Lösungsumfang und Lösungsansatz und auch abhängig vom Vorgehensmodell und den Standards im Unternehmen können diese Dokumente unterschiedlich strukturiert und unterschiedlich umfangreich sein. In agilen Vorgehensmodellen entsteht möglicherweise kein Anforderungsdokument im herkömmlichen Sinne, sondern die Anforderungen sind wenig strukturiert und wenig detailliert dokumentiert, zum Beispiel in Form von physischen Boards (etwa auf Pinnwänden) oder mithilfe entsprechender Tools auf elektronischen Boards.

Eine ausführliche Beschreibung des Konzepts Requirements Engineering findet sich in Kapitel 2.

G.3.4 Lösungseinführung

Abb. G.10: Lösungseinführung

„Papier ist geduldig, der Leser nicht.“

Von Unbekannt

Mit dem Konzept Business-Case-Erstellung wird eine Veränderung vorbereitet und u.a. auf Sinnhaftigkeit und Wirtschaftlichkeit untersucht. Requirements Engineering liefert als Ergebnistyp ein Anforderungsdokument. Beide Konzepte beschäftigen sich mit dem zentralen Anliegen der Business-Analyse, Anforderungen zu ermitteln und zu dokumentieren, die eine Lösung und damit eine Veränderung der Ist-Situation beschreiben.

Die Umsetzung dieser Anforderungen ist nicht mehr Bestandteil der Business-Analyse. Abhängig von der Art der beschriebenen Lösung setzen andere Rollen diese um. In vielen Fällen entwickeln Mitarbeiterinnen und Mitarbeiter der IT-Abteilung entsprechende Applikationen, Systeme sowie Infrastruktur und sorgen dafür, dass sie bereitgestellt werden.

Business-Analysten spielen eine wichtige Rolle auf dem „Hinweg“, dem Weg der Anforderungen von den Anforderungsstellern zu den Umsetzern. Es erscheint logisch und sinnvoll, dass Business-Analysten auch den „Rückweg“ begleiten sollten, den Weg der entwickelten/umgesetzten Lösung von der IT-Abteilung zu den Anforderungsstellern bzw. Nutzern dieser Lösung.

Das Konzept der Lösungseinführung in der ibo-Anforderungstür^® beschreibt Aspekte, bei denen Business-Analysten sinnvoll zum Einsatz kommen, da sie mindestens mit den Anforderungen und häufig auch mit der Lösung vertraut sind.

So sollte durch die Bewertung der Lösung untersucht werden, ob die Lösung die Verbesserungen erbringt, die über die Geschäftsanforderungen im Business Case definiert wurden. Eine anschließende bzw. fortlaufende Leistungsüberprüfung stellt sicher, dass die Lösung auch künftig einen (Mehr-)Wert erbringt.

Eine Ermittlung, Dokumentation und Umsetzung von Transitionsanforderungen, die den Übergang vom Ist- zum Soll-Zustand beschreiben, erleichtert die Einführung der Lösung. Dazu gehören insbesondere Überlegungen,

 wie mit Daten im Ist (bzw. in den Altsystemen) umgegangen wird, z.B. Migration auf die neue Lösung

 welche organisatorischen Veränderungen der Betroffenen und Beteiligten sinnvoll und notwendig sind, z.B. Information oder Schulungen

 wie Aufgaben, Geschäftsvorfälle und Geschäftsprozesse fortgeführt werden, die im Ist (bzw. in den Altsystemen) begonnen wurden, aber vor Lösungseinführung nicht beendet wurden.

In vielen Unternehmen reichen die Umsetzungskapazitäten nicht aus, um alle Anforderungen zeitnah zu realisieren. Business-Analysten können durch eine Zuordnung von Anforderungen zu Releases dabei mitwirken, gezielt Mehrwert zu schaffen, auch wenn nicht alle Anforderungen „sofort“ umgesetzt werden können oder sollen.

Mit der Einführung der Lösung verschieben sich häufig die Verantwortlichkeiten. Personen, die für die Entwicklung der Lösung verantwortlich waren, haben ihren Beitrag geleistet. Wurde die Lösung im Rahmen eines Projekts entwickelt, so neigt sich dieses dem Ende entgegen oder wurde beendet und der Projektleiter trägt (künftig) keine Verantwortung mehr. Dennoch ist immer sicherzustellen, dass der Betrieb der Lösung technisch verantwortet und weiter begleitet wird. Dieser Übergang von „Build“ to „Run“ funktioniert in vielen IT-Bereichen gut oder ist zumindest hinreichend geregelt. Die Übernahme von Verantwortung auf fachlicher Seite ist nicht immer gleich gut geregelt. Business-Analysten unterstützen eine möglichst reibungslose Einführung und ein klares Rollenverständnis, indem sie beispielsweise Prozessverantwortliche oder Fachbereichsleiter darauf hinweisen, dass „jemand den Hut aufhaben“ sollte.

Handlungsfelder

Als berufliche Handlungskompetenz hilft Business-Analysten Change Management, um Veränderungen auch kulturell zu begleiten.

Wichtige Zielgruppe sind Beteiligte, die mit der neuen oder veränderten Lösung umgehen müssen.

Ergebnistyp dieses Konzepts ist eine Lösung, die erfolgreich eingeführt und weiter begleitet wird.

Eine ausführliche Beschreibung des Konzepts Lösungseinführung findet sich in Kapitel 3.

G.3.5 Business-Analyse-Planung und -Steuerung

Die drei Konzepte Business-Case-Erstellung, Requirements Engineering und Lösungseinführung der ibo-Anforderungstür^® bilden eine sinnvolle Reihenfolge, um den Grundprinzipien „Vom Groben zum Detail“, „Von den Zielen zur Lösung“ und „Rationales Entscheiden“ zu folgen.

Abb. G.11: Business-Analyse-Planung und -Steuerung

Das Konzept Business-Analyse-Planung und -Steuerung „begleitet“ die anderen drei Konzepte und soll sicherstellen, dass die Business-Analyse selbst effektiv und effizient durchgeführt wird. Dies gilt für Business-Analysten, die alleine eine Veränderung begleiten, ebenso wie für ein Team von Business-Analysten, das zum Beispiel in einem Projekt zusammenarbeitet.

  Planung ist die geistige Vorwegnahme zukünftigen Handelns. In diesem Sinne strukturieren Business-Analysten ihre künftigen Tätigkeiten und stimmen deren Umfang und Inhalt ab.

  Ist-Erfassung ermittelt den Status und Fortschritt der Tätigkeiten, abhängig von der Planung hinsichtlich Leistung, Qualität und Termin.

  Diagnose prüft, ob es Abweichungen zwischen Ist-Werten und Plan-Werten gibt. Bei Abweichungen suchen Business-Analysten in diesem Schritt nach Ursachen und Zusammenhängen.

 Steuerung ergreift Maßnahmen, um bei einer festgestellten Abweichung mögliche Nachteile zu minimieren. Bei kritischen Abweichungen ist möglicherweise eine Eskalation an Führungskraft oder Projektleiter der Business-Analysten notwendig. In jedem Fall sollten Business-Analysten Lessons Learned betreiben, d.h. aus „der Vergangenheit lernen“, Bewährtes für weitere Business-Analysen standardisieren und begangene Fehler für die Zukunft vermeiden.

Die Planung der Business-Analyse umfasst die drei Komponenten Stakeholder-Analyse, Aufgaben und Anforderungsmanagement.

Stakeholder-Analyse

In der Stakeholder-Analyse klären Business-Analysten, wer durch eine Veränderung betroffen ist, wer auf sie Einfluss nimmt und welche Stakeholder für die Business-Analyse zu berücksichtigen sind. Die beste, technisch umgesetzte Veränderung droht an mangelnder Akzeptanz zu scheitern, wenn Personen sich übergangen fühlen, nicht ausreichend berücksichtigt wurden oder ihre Anforderungen nicht einbringen konnten.

Aufgaben

Die Planung der Aufgaben unterscheidet sich je nach dem gewählten Vorgehensmodell. In klassischen Vorgehensmodellen (z.B. Projekte nach Wasserfallprinzip) werden die künftigen Aufgaben der Business-Analyse vergleichsweise ausführlich vorab geplant, indem die Inhalte der Aufgaben beschrieben, Dauer und Termine festgelegt werden. Häufig wird die Planung formal abgenommen und später auch formal überprüft.

In agilen Vorgehensmodellen wird in der Regel lediglich die anstehende Iteration fein geplant. Weitere Iterationen werden umso gröber geplant, je weiter sie in der Zukunft liegen.

Anforderungsmanagement

Die Planung des Anforderungsmanagements umfasst unter anderem Überlegungen, in welchen Dokumenten Anforderungen hinterlegt werden und welche Software-Tools zur Verwaltung der Anforderungen genutzt werden. Sinnvollerweise planen Business-Analysten auch vorab, welche Attribute sie neben der eigentlichen Anforderung erfassen und verwalten wollen. Häufig genutzte Attribute sind eine eindeutige ID, Angaben zur Quelle der Anforderung, zum Versionsverlauf, zum Autor, zum Status der Anforderung.

Die Verfolgbarkeit (Traceability) der Anforderungen erfasst ihren Lebenszyklus, von ihrem Entstehen bis zu ihrem Ende (z.B. durch Umsetzung und Archivierung). Business-Analysten können die Verfolgbarkeit von Anforderungen unterschiedlich intensiv betreiben. Daher sollten sie vorab planen, in welcher „Ausbaustufe“ sie Traceability durchführen wollen.

Weiter ist festzulegen, wie mit Änderungen von Anforderungen umgegangen werden soll. Während agile Vorgehensmodelle eine Veränderung von vornherein vorsehen und akzeptieren, findet im Rahmen klassischer Vorgehensmodelle häufig ein explizites IT-Change-Management statt. In der Planung des IT-Change-Managements wird unter anderem festgelegt, wie über Änderungen entschieden wird und wie Anforderungen formal geändert werden (z.B. Prozess mit Change Request).

Ist-Erfassung

Die Ist-Erfassung ermittelt und dokumentiert Kennzahlen für eine effiziente und effektive Performance der Business-Analyse. Dies können z.B. Termine, Änderungshäufigkeit der Anforderungen, Anzahl benötigter Review-Zyklen für Anforderungsdokumente sein.

Diagnose

Die Diagnose vergleicht die Werte der Planung mit den Ergebnissen der Ist-Erfassung. Typische Fragen insbesondere bei Abweichungen sind:

 Wie war das Vorgehen?

 Wo bestehen Probleme in der Business-Analyse?

 Wo liegen Chancen für Verbesserungen?

Steuerung

Die Steuerung greift in die aktuelle Business-Analyse ein, um ungewollten Abweichungen von der Planung zu begegnen. Dazu ergreifen Business-Analysten korrigierende Maßnahmen, um sicherzustellen, dass Leistung, Qualität und Termine eingehalten werden.

Vorbeugende Maßnahmen mindern bei künftigen Abweichungen deren Eintrittswahrscheinlichkeit oder deren negative Auswirkung. Schließlich wird durch eine kontinuierliche Verbesserung der Business-Analyse das Vorgehen beziehungsweise der Geschäftsprozess der Business-Analyse aktualisiert.

In der Praxis sind die Schritte Ist-Erfassung, Diagnose und Steuerung kaum voneinander zu trennen. Zudem unterstützen viele Techniken gleichzeitig alle drei Schritte. Daher werden diese drei Schritte in Kapitel 4 eng miteinander verknüpft. Dort findet sich eine ausführliche Beschreibung des Konzepts Business-Analyse-Planung und -Steuerung.

G.4 Rollen und Stellen in der Business-Analyse

In diesem einleitenden Kapitel soll ein Überblick über die verschiedenen Bezeichnungen der Personen gegeben werden, die mit Anforderungen befasst sind. Anders als zum Beispiel im Projektmanagement wurden die Rollen- und Stellenbezeichnungen in der Business-Analyse (noch) nicht vereinheitlicht.

Ein Business-Analyst ist jede Person, die Aufgaben der Business-Analyse ausführt.

Die Definition berücksichtigt,

 dass Business-Analyse aus Aufgaben mit unterschiedlicher „Flughöhe“ besteht (eher strategischer, taktischer oder operativer Natur)

 dass diese Aufgaben in unterschiedlichen Themenfeldern anfallen, z.B. Automatisierung oder Geschäftsprozessoptimierung

 dass Business-Analyse in unterschiedlichen Kontexten stattfindet, in agilen oder klassischen Projekten, Veränderungsmaßnahmen großen oder mittleren Ausmaßes oder in kleinen Veränderungen im Tagesgeschäft.

Neben der weit verbreiteten Stellenbezeichnung „Business-Analyst“ gibt es weitere Rollen und Stellen, die verwandte Aufgaben rund um Anforderungen wahrnehmen bzw. die in eine Business-Analyse einbezogen werden. Die Abbildung nennt gebräuchliche Bezeichnungen dieser Personen.

Abb. G.12: Rollen und Stellen in der Business-Analyse

Rund um Anforderungen lassen sich zwei Personengruppen unterscheiden:

  Spezialisten, die sich hauptsächlich mit Anforderungen beschäftigen. „Business-Analyst“ ist hierbei eine verbreitete Stellenbezeichnung und wird im weiteren Verlauf des Buches verwendet. Darüber hinaus gibt es noch andere Bezeichnungen für Spezialisten rund um Anforderungen (vgl. linke Spalte der Abbildung G.12).

 Daneben gibt es Personen, die sich als Betroffene/Beteiligte einen Teil ihrer Arbeitszeit mit Anforderungen beschäftigen, sei es in Projekten oder im Tagesgeschäft (vgl. mittleren und rechten Teil der Abbildung G.12).

Die Aufgaben dieser Personen und ihre Verknüpfung zur Business-Analyse werden insbesondere in den Kapiteln 1 bis 4 erläutert. Die Schwerpunkte einiger Rollen werden im Folgenden skizziert.

Business-Case-Erstellung

Bei der Erstellung eines Business Case werden beispielsweise Unternehmensarchitekten oder Business-Planer tätig, die die Verträglichkeit von Lösungsansätzen und -ideen mit Architekturentscheidungen und -vorgaben des Unternehmens abgleichen. Multiprojekt- und Portfoliomanager prüfen, ob verwandte oder widersprüchliche Lösungsansätze vorhanden sind. Sie fügen nach einem erfolgreichen Business Case das Veränderungsvorhaben in das Portfolio aller Vorhaben ein, indem sie es zeitlich und inhaltlich einordnen. Produktmanager entwickeln Vorschläge, wie bestehende Produkte weiterentwickelt oder neue Produkte bzw. Dienstleistungen geschaffen werden sollen.

In plan-orientierten Vorgehensmodellen (z.B. nach Wasserfall) entscheidet ein Bewilligungsgremium oder Architektur-Board über den Business Case. In wandel-getriebenen (agilen) Vorgehensmodellen liegt diese Kompetenz z.B. beim Product Owner (als zentrale Rolle in Scrum).

Requirements Engineering

Je nach Unternehmen und Branche wird anstelle von Business-Analyst eine der anderen Bezeichnungen genutzt, wie z.B. Requirements Engineer, Anforderungsmanager, Systemanalytiker, IT-Koordinator, IT-Organisator. Unternehmen, die sich nach ITIL ausrichten, setzen häufig Demand Manager ein, die Anforderungen aufnehmen und dokumentieren.

In klassischen Projekten entscheidet ein Lenkungsausschuss oder ein Steering Committee über das Projekt im Allgemeinen und das Anforderungsdokument im Besonderen. In agilen Vorgehen bearbeitet ein Entwicklungsteam die Anforderungen und wird dabei von einem Scrum Master methodisch unterstützt.

Lösungseinführung

Bei der Lösungseinführung wird das Ergebnis des Vorhabens in die Linie bzw. in das Tagesgeschäft übergeben. Für prozessorientiert gegliederte Unternehmen spielen die Prozessverantwortlichen eine zentrale Rolle.

Sind mehrere Business-Analysten in einem Unternehmen tätig, müssen sie als Gruppe oder Team organisiert werden. Dabei können formal feste Rollen wie Senior-Business-Analyst oder Lead-Business-Analyst geschaffen werden. Es kann auch ein Business-Analyse-Center-of-Excellence oder Business-Analyse-Office eingerichtet werden, in dem die Mitarbeiter der Business-Analyse zusammengeführt werden. Ein solches Center of Excellence dient dann auch dem Informationsaustausch, dort werden Lessons Learned gezielt genutzt und es wird die Business-Analyse im Unternehmen weiterentwickelt.

Literatur zu Kapitel G

Carkenord, B. A.: Seven Steps to Mastering Business Analysis. Plantation 2009

International Institute of Business Analysis (IIBA): A Guide to the Business Analysis Body of Knowledge (Babok Guide). Version 3.0, Toronto 2015

International Institute of Business Analysis (IIBA): Business Analysis Body of Knowledge^® – BABOK 2.0^®. Leitfaden zur Business Analysis. 1. Aufl. in deutsch, Gießen 2012

Paul, D.; Yeates, D.; Cadle, J. (Editors): Business Analysis. 3rd Edition, London 2014

Podeswa, H.: The Business Analyst's Handbook. Boston 2008

Robertson, S.; Robertson, J.: Mastering the Requirements Process. 3^rd Edition, Upper Saddle River 2012

1 Business-Case-Erstellung
1.1 Einleitung

„Wenn man in einen falschen Zug einsteigt, nützt es nichts, wenn man im Gang entgegen der Fahrtrichtung läuft.“

Dietrich Bonhoeffer

1.1.1 Startpunkte für Veränderungen

Business-Analyse beschäftigt sich mit Veränderungen. Alle Veränderungen beruhen auf Anforderungen, die von unterschiedlichen Seiten eingebracht werden können. Anforderungen tragen es in sich, dass sie den Ist-Zustand verändern sollen. Häufig sind damit Verbesserungen des Ist-Zustands verbunden.

In den Fällen, dass regulatorische oder gesetzliche Auslöser eine Veränderung anstoßen, steht in der Regel keine Verbesserung, sondern die Einhaltung der regulatorischen oder gesetzlichen Auflagen im Mittelpunkt. Auch Veränderungen, die aus einer Organisation heraus initiiert werden, bringen es oft mit sich, dass regulatorische Aspekte zu beachten sind.

Seit einiger Zeit häufen sich bei den TREND Möbelhäusern die Wünsche, dass in den Filialen die Einrichtung der Bistros modernisiert werden sollte. „Die Einrichtung ist in die Jahre gekommen“, lautet es sowohl von Kunden als auch von Mitarbeitern.

Sollten diese Anforderungen weiterverfolgt werden, sind auch gesetzliche Bestimmungen einzuhalten, wie sie zum Beispiel im Gaststättengesetz und in der Verordnung über Arbeitsstätten zu finden sind.

Veränderungen (Changes) können unterschiedliche Startpunkte haben: Top-Down, Bottom-Up, Middle Management, External Drivers (vgl. Abb. 1.01).

Abb. 1.01: Startpunkte für Veränderungen (in Anlehnung an VAHS, 2015)

Veränderungen von Top-Down entstammen häufig der strategischen Ebene, ausgelöst durch die Geschäftsführung bzw. das Management eines Unternehmens. Oft sind neue oder aktualisierte Unternehmensziele, strategische Maßnahmen, Umstrukturierungen oder der Aufbau einer neuen Produktlinie die Auslöser.

Bottom-Up-Veränderungen werden in der Regel von Mitarbeitern angestoßen und betreffen operative Probleme oder Verbesserungen in Geschäftsprozessen oder IT-Systemen. Sie kommen z.B. aus dem betrieblichen Vorschlagswesen, aus einem „Kontinuierlichen Verbesserungsprozess“ (KVP), aus Behelfslösungen (Workarounds), die beseitigt oder optimiert werden sollen, aus Mitarbeiterbefragungen oder einem Ideenmanagement.

Das Middle Management stößt Veränderungen häufig an, um beispielsweise Arbeitsabläufe zu standardisieren oder zu automatisieren, um Zuständigkeiten zu klären oder Hinweise und Auflagen aus Qualitätsmanagement, Revision oder internen Audits aufzugreifen.

External Drivers stammen vom Kunden, vom Wettbewerb, von Regulatoren. Die damit verbundenen Veränderungen haben ihren Ursprung zum Beispiel im Beschwerdemanagement, Kundenbefragungen, Benchmarking, Normen und Standards.

1.1.2 Skalierbarkeit von Business Cases

Große Veränderungen werden in vielen Unternehmen im Rahmen eines Projekts abgewickelt. Kleinere Veränderungen finden im Tagesgeschäft statt. Die meisten Organisationen halten für Veränderungen mittleren Ausmaßes sogenannte Maßnahmen oder Einzelmaßnahmen bereit, die keinen echten Projektcharakter haben, aber auch nicht in den normalen Abläufen des Tagesgeschäfts (z.B. in Geschäftsprozessen) erledigt werden.

Das Konzept der Business-Case-Erstellung in der ibo-Anforderungstür^® bietet sowohl für große, mittlere als auch für kleinere Veränderungen ein strukturiertes Vorgehen, um zu einer rationalen Entscheidung zu kommen, wie die Veränderung angegangen werden sollte. Unabhängig von der Größe der Veränderung ist es sinnvoll, das „Big Picture“, also das „Große Ganze“ zu verstehen und die Gründe für eine Veränderung zu analysieren.

Ein Business Case ist eine Grundlage für eine Entscheidung, ob eine Lösung dazu beiträgt, Geschäftsanforderungen zu erreichen, und ob der Nutzen einer Lösung größer ist als die Kosten für Umsetzung und Betrieb der Lösung.

Eine Lösung ist die Summe der Veränderungen des Ist-Zustands eines Unternehmens, um einen Bedarf zu decken und/oder Ziele zu erreichen.

Mit dem Begriff Business Case wird häufig eine umfangreiche Machbarkeits- und Wirtschaftlichkeitsprüfung verbunden. Für große Veränderungen lohnt es, diese Vorüberlegungen zu treffen, bevor Anforderungen im Detail erhoben, analysiert und dokumentiert werden.

Aber auch bei kleinen Veränderungen erscheint es sinnvoll, nicht gleich loszulaufen, ohne den Weg zu kennen. In diesen Fällen sollte bei einer Realisierbarkeits- bzw. Durchführbarkeitsprüfung entsprechend weniger Aufwand betrieben werden.

Abb. 1.02: Ausprägungen und verwandte Konzepte zu einem Business Case

Die Abbildung 1.02 zeigt Synonyme bzw. verwandte Konzepte zum Business Case. Die Skala reicht von „Small“ bis „Vollversion“. Damit reicht die Spanne von kleinen Veränderungen und damit „schlanken“ und häufig informellen Dokumenten bis hin zu großen Veränderungen, die formale und umfangreiche Dokumentationen mit sich bringen.

Einige gebräuchliche Ausprägungen eines Business Case werden im Folgenden skizziert:

 Auftragsklärung, Projektantrag/-idee, Projektauftrag, Vorhabenblatt: Zusammenfassung der Ausgangslage und Gründe für eine Veränderung, der angestrebten erwünschten Wirkungen und des geplanten Zeitfensters

 One Pager, Vorstandsvorlage: Management Summary als Entscheidungsvorlage für eine Veränderung; häufig mit formalen Vorgaben hinsichtlich Inhalt und Struktur

 Machbarkeitsprüfung, -studie: Fokussierung auf die Überprüfung der technischen, organisatorischen und fachlichen Durchführbarkeit einer Veränderung mit internen oder externen Ressourcen

 Demand and Scope Management, Szenario-Analyse: Fokussierung auf die Betrachtung verschiedener Lösungsansätze oder Zukunftsszenarien und die Empfehlung, welche Maßnahmen getroffen werden sollten, um diesen bestmöglich zu begegnen

 Business Case, Wirtschaftlichkeitsprüfung: Fokussierung auf die Überprüfung des Kosten-Nutzen-Verhältnisses einer Veränderung; häufig mit vorgegebener Struktur und Angaben, wann eine Veränderung „sich rechnet“; unter Einbeziehung der möglichen Risiken, die eine Veränderung mit sich bringt.

1.1.3 Vier Schritte zur Business-Case-Erstellung

Professionelle Business-Analyse zeichnet sich insbesondere durch ein systematisches, strukturiertes Vorgehen aus. Dieses sollte auch bei der Erstellung eines Business Case gelten.

Die vier Schritte zur Business-Case-Erstellung umfassen (vgl. Abb. 1.03):

 Leistungspotenziale: Den Ist-Zustand im Gesamtzusammenhang verstehen, Probleme und tiefer liegende Ursachen analysieren, fehlende Leistungspotenziale aufdecken, vorhandene Leistungspotenziale einschätzen

 Geschäftsanforderungen: Klären, welche Ziele mit der Veränderung verfolgt werden, dabei Lösungen durch Ziele ersetzen

 Lösungsansätze: Wege zur Lösung herausfinden und dabei den Lösungsumfang definieren

 Empfehlung: Business Case vervollständigen und eine Empfehlung für eine Lösung aussprechen.

Bei den verschiedenen Ausprägungen eines Business Case (vgl. oben) werden typischerweise alle vier Schritte betrachtet. Je nach Ausprägung kann allerdings der Schwerpunkt innerhalb der vier Schritte unterschiedlich gesetzt werden.

Abb. 1.03: Vier Schritte der Business-Case-Erstellung

Je nach Ausmaß der Veränderung ist es sinnvoll, Umfang und Detaillierung des Business Case anzupassen. Große Veränderungen bringen eine umfangreichere Voruntersuchung mit sich, die in einen ausführlicheren Business Case mündet. Kleine Veränderungen kommen mit einem kompakten und „abgespeckten“ Business Case aus (vgl. auch Kapitel 1.6).

Unter Beachtung des Grundprinzips Rationales Entscheiden (vgl. Kapitel G.3) sollte vermieden werden, dass eine Entscheidung bzw. Empfehlung schon vor Beginn der Business-Case-Erstellung feststeht. Andernfalls besteht die Gefahr, dass im Business Case nur Fakten zusammengetragen werden, um diese Entscheidung zu untermauern. Oder es besteht die Herausforderung, dass für die vorab getroffene Empfehlung vermeintliche Argumente gesammelt werden, die unter objektiver Betrachtung nicht stichhaltig sind.

Daher sollte ein Business Case möglichst ergebnisoffen begonnen werden, so dass im Schritt „Lösungsansätze“ Alternativen erarbeitet werden, die eine tatsächliche Verbesserung des Ist-Zustands herbeiführen können und dabei die Ziele des Schritts „Geschäftsanforderungen“ erfüllen können.

Je nach Inhalt und Kontext des Business Case können sich die jeweiligen Empfehlungen zum weiteren Vorgehen bzw. zur Weiterverfolgung der Veränderung unterscheiden. Empfehlungen werden häufig auf der Basis eines Kriteriums oder mehrerer Kriterien ausgesprochen, wie zum Beispiel:

 Wirtschaftlichkeit: Günstiges Kosten-Nutzen-Verhältnis, ungünstiges, kein sinnvolles Kosten-Nutzen-Verhältnis, Wirtschaftlichkeit aus gesetzlichen oder regulatorischen Gründen unerheblich

 Risiko: Veränderung zu riskant, wenig riskant, Risiken vertretbar

 Zeitlich: Sofortige Umsetzung der Veränderung, zeitnahe, mittelfristige, langfristige Umsetzung der Veränderung

 Fachlich, Kontext: Alleinstehend, mit anderen Themen/Veränderungen verknüpft, in kleinere Veränderungen aufteilen

 Ressourcen, Know-how: Veränderung intern umsetzen, mit externer Unterstützung angehen, extern umsetzen

 Vorgehensweise: Mit Hilfe einer agilen Methode (z.B. Scrum), in einem klassischen Projekt (z.B. Wasserfall)

 Größe der Veränderung: Klein und damit im Tagesgeschäft möglich, mittel bis groß und damit Umsetzung im Rahmen einer Einzelmaßnahme oder eines Projekts sinnvoll, sehr groß und damit in mehreren Projekten bzw. in einem Projektportfolio oder -programm umzusetzen.

1.2 Leistungspotenziale

„Wenn ich eine Stunde Zeit hätte die Welt zu retten, würde ich 55 Minuten davon nutzen, um das Problem zu klären.“

Albert Einstein

Abb. 1.04: Schritt Leistungspotenziale in der Business-Case-Erstellung

1.2.1 Überblick

Der erste Schritt der Business-Case-Erstellung fokussiert auf den Ist-Zustand. Das Gesamtbild zu verstehen und Zusammenhänge aufzuzeigen, bietet eine fundierte Ausgangslage für die weiteren Schritte.

Die Analyse der Leistungspotenziale im Ist zeigt auf, welche Leistungspotenziale fehlen und welche bestehenden Leistungspotenziale genutzt bzw. erhalten werden sollten.

Leistungspotenziale sind die von einem Unternehmen ausgeübten Aktivitäten, das vorhandene Wissen im Unternehmen, die von einem Unternehmen angebotenen Produkte und Dienstleistungen, die von ihm unterstützten bzw. ausgeübten Arbeitsweisen sowie seine Methoden, um zu Entscheidungen zu kommen.

Die Analogie zur Medizin verdeutlicht diese Sachverhalte. Ein guter Arzt untersucht hinsichtlich der Probleme, Symptome und Ursachen einer Erkrankung. Dazu führt er eine Anamnese und Diagnose durch. Die Therapie, die eine oder mehrere Behandlungsmaßnahmen umfasst, erscheint dann erfolgversprechend, wenn sie nicht die Symptome behandelt, sondern die Ursachen bekämpft. Gerade bei komplexen Situationen ist eine umfassende Untersuchung sinnvoll. Ansonsten werden u.U. Symptome oder Auswirkungen des Problems mit den tatsächlichen Ursachen verwechselt.

Gleichzeitig sollte jegliche ergriffene Therapie mit ihren Behandlungsmaßnahmen so schonend wie möglich sein und die Gesundheit (auch einer Organisation) so wenig wie möglich beeinträchtigen.

Ein Problem stellt einen unbefriedigenden Zustand dar. Die Chance einer Verbesserung kann „nachweislich“ bestehen (z.B. festgestellt durch ein Benchmarking bei anderen Unternehmen) oder auch nur angenommen sein (z.B. durch plausible Überlegungen und Planungen).

Ein Problem stellt also eine Abweichung eines bestehenden Ist-Zustands von einem angestrebten Soll dar. Das Soll kann von innen vorgegeben sein (beispielsweise durch strategische Ziele) oder von außen (z.B. durch Kunden, Wettbewerb oder gesetzliche Auflagen).

Abweichungen haben häufig subjektiven Charakter. Hinweise, z.B. aus Benchmarking, Qualitätsmanagement, betrieblichem Vorschlagswesen, Normen, Standards, Kundenbefragungen, Mitarbeiteräußerungen oder Beschwerdemanagement liefern Anhaltspunkte dafür, dass Probleme bestehen.

Auslöser für den Business Case bei den TREND Möbelhäusern waren die seit einigen Jahren (wenn auch langsam) sinkenden Umsätze, Hinweise der Mitarbeiter („Unsere Kunden werden anscheinend immer älter.“), Klagen der Kundenbetreuer („Ich würde dem Kunden gerne mal ein Produkt am Bildschirm zeigen, auch wenn wir es nicht in der Ausstellung haben.“) und nicht zuletzt Hinweise der Kunden selbst („Warum kann man bei Ihnen im Internet nicht nach Artikeln suchen und sich diese anschauen?“).

Business-Analysten untersuchen den Ist-Zustand darauf hin, welche Probleme bestehen und welche Ursachen es für diese auftretenden Probleme gibt. Probleme und Ursachen sind deutliche Hinweise auf neu zu erstellende oder zu verbessernde Leistungspotenziale.

Um den Blick nicht nur auf „das Negative“ zu richten, ist es wichtig, dass Business-Analysten untersuchen, welche Leistungspotenziale gut funktionieren und daher erhalten werden sollten bzw. durch Veränderungen nicht abgeschwächt oder verschlechtert werden sollen. Bekannte Stärken erlauben auch abzuwägen, ob zur Beseitigung von Problemen neue Leistungspotenziale geschaffen werden sollten, oder ob es sinnvoller ist, bestehende Leistungspotenziale auszubauen und besser zu nutzen. Diese Erkenntnisse liefern Input für die spätere Erarbeitung von Lösungsansätzen (vgl. Kapitel 1.4). Daraus lässt sich ableiten, ob es sinnvoller ist, einen Ist-Zustand zu verbessern (evolutionäres Vorgehen) oder etwas radikal Neues zu schaffen (revolutionärer bzw. Grüne-Wiese-Ansatz).

Eine Arbeitsgruppe der TREND Möbelhäuser hat folgende allgemeine Leistungspotenziale identifiziert: Organisationsstruktur und -kultur, Geschäftsprozesse, Technologie und Infrastruktur, Policies und Regelungen, Unternehmensarchitektur, Mitarbeiterqualifikationen, Wissen und Fähigkeiten, Weiterbildung, Daten und Informationen, Produkte und Dienstleistungen, Vertriebswege. Diese Leistungspotenziale sollen darauf hin untersucht werden, ob sie erhalten werden können oder ob Verbesserungen notwendig sind, um den Hinweisen der Kunden und Mitarbeiter zu begegnen (s.o.).

Zur Untersuchung des Ist-Zustands bieten sich Techniken an, die auf eine Problemanalyse bzw. Ursachenanalyse fokussieren. Die meisten Techniken erlauben es Business-Analysten, neben der Analyse negativer Aspekte auch positive Aspekte aufzuführen, um ein ganzheitliches Bild zu erhalten.

Drei Kategorien von Techniken zur Analyse der Leistungspotenziale bieten sich an:

 Problembeschreibung bzw. Ist-Beschreibung in einer tabellarischen Darstellung der Ist-Situation

 Linear-kausale Ursachenanalyse für eine Untersuchung, die von einem Problem ausgeht und dessen eine Ursache oder mehrere Ursachen erforscht

 Komplexe Ursachenanalyse für eine Analyse mehrerer Probleme und mehrerer Ursachen, die in Wechselbeziehung zueinander stehen.

Eine Problembeschreibung ist eine strukturierte Benennung des Problems oder der Probleme und eine Beschreibung ihres Auftretens und ihrer Auswirkungen.

Eine Ursachenanalyse ist eine planmäßige Untersuchung einer Situation, um die Ursachen (und bei Bedarf Auswirkungen) eines oder mehrerer Probleme zu ermitteln.

Die Abbildung 1.05 ordnet die Techniken, die im Folgenden näher erörtert werden, den drei Kategorien zu.

Problembeschreibung		Linear-kausale Ursachenanalyse		Komplexe Ursachenanalyse
	Verbale BewertungSWOT-Analyse, ggf. verbunden mit World CaféKompakte ProblembeschreibungAusführliche Problembeschreibung		5W-Technik (5 Why)Vorgelagerte UrsachenIshikawa-Diagramm		Ursache-Wirkungs-DiagrammPapiercomputerPortfolio-AnalyseSchwachstellenanalyse

Abb. 1.05: Techniken der Problembeschreibung und Ursachenanalyse

Die Techniken können grundsätzlich eigenständig angewandt werden. Auch ist es möglich, mehrerer Techniken zu kombinieren bzw. eine Technik durch eine andere zu erweitern oder zu detaillieren.

Die Business-Analysten der TREND Möbelhäuser haben weitere Informationen zusammengetragen, die in die Problembeschreibung und Ursachenanalyse einfließen können.

Im Laufe der Jahre haben sich parallele EDV-Anwendungen etabliert: ein eigenes Kassensystem, ein Warenwirtschaftssystem, eine Anwendung, mit der der Internetauftritt verwaltet wird, Grafiksoftware des Marketings, ein Buchhaltungssystem, eine E-Mail-Software; dazu kommen die normalen Büroanwendungen (Textverarbeitung, Tabellenkalkulation und Terminplaner).

Die jeweiligen Systeme werden von allen Filialen benutzt. Der Datenaustausch zwischen den Systemen läuft allerdings über die zentrale IT-Abteilung. Die technische Ausstattung ist sehr unterschiedlich, da jeder Filialleiter für seinen Bereich selbst entscheiden kann, welche Hardware genutzt wird. Etwa ein Drittel der Mitarbeiter nutzt Rechner, die mehr als vier Jahre alt sind und nicht mehr dem heutigen Stand der Technik entsprechen. Auch bei den Peripheriegeräten (z.B. Drucker, Scanner) hat sich ein buntes Gemisch unterschiedlichster Technik entwickelt. Immerhin wird ein gemeinsames Netzwerk für alle Filialen und die Hauptverwaltung genutzt und von der zentralen IT-Abteilung administriert.

1.2.2 Problembeschreibung

Die Techniken der Problembeschreibung stellen in strukturierter Form den Ist-Zustand dar und bieten damit die Möglichkeit, ein gemeinsames Bild über die Ist-Situation zu erzielen.

Für kleinere und mittlere Veränderungen bieten sich mit verbaler Bewertung oder kompakter Problembeschreibung die „schlankeren“ Techniken an. Für größere Veränderungen ist eine SWOT-Analyse, World Café oder ausführliche Problembeschreibung sinnvoll.

Dabei kann eine SWOT-Analyse die Ergebnisse einer verbalen Bewertung erweitern. Analog kann eine ausführliche Problembeschreibung auf die Inhalte einer kompakten Problembeschreibung aufsetzen.

1.2.2.1 Verbale Bewertung

Die verbale Bewertung listet die bestehenden und fehlenden Leistungspotenziale auf. Sie ist einfach und lässt sich schnell erstellen. Nachteilig ist aber, dass keine weitere Strukturierung, Kategorisierung oder Gewichtung der Leistungspotenziale erfolgt. Die verbale Bewertung eignet sich daher am ehesten für kleine Veränderungen oder als Ausgangspunkt für eine oder mehrere der weiteren, hier vorgestellten Ursachenanalysen.

Bestehende Leistungspotenziale		Fehlende Leistungspotenziale
	Vorhandenes FilialnetzPersönliche Beratung in den FilialenKundenfreundlichkeitGuter Ruf, gutes ImageZentrale Software-VerwaltungZentrallager plus FiliallagerSehr gute Kenntnisse in der Möbelbranche Treue Stammkunden		Sinkende UmsätzeNicht-standardisierte IT-HardwareVeraltete IT-HardwareÄlter werdender Kundenstamm, wenige junge KundenVeralteter InternetauftrittFehlende Visualisierung des Sortiments in den Filialen

Abb. 1.06: Verbale Bewertung

1.2.2.2 SWOT-Analyse

SWOT steht als Akronym für Strengths, Weaknesses, Opportunities, Threats.

Für den Ist-Zustand werden Stärken und Schwächen gesammelt (Strengths und Weaknesses). Sie fokussieren auf interne Faktoren.

Mit Blick in die Zukunft werden (mögliche) Chancen und Gefahren zusammengetragen (Opportunities und Threats). Dabei sollten insbesondere externe Faktoren berücksichtigt werden.

Die Stärken und Schwächen entsprechen inhaltlich den bestehenden und fehlenden Leistungspotenzialen der verbalen Bewertung. Daher kann eine SWOT-Analyse eine verbale Bewertung erweitern bzw. ergänzen.

Die Business-Analysten der TREND Möbelhäuser nutzen folgende Fragestellungen, um zusammen mit weiteren Beteiligten die vier Kategorien der SWOT-Analyse zu füllen.

Stärken (Strengths)

 In welchen Bereichen, Geschäftsprozessen, Produkten und Dienstleistungen sind wir besonders gut?

 Über welche Erfahrungen und welches Know-how verfügen wir?

 Was sind unsere Kernkompetenzen?

Schwächen (Weaknesses)

 Wo erkennen wir Verbesserungspotenzial?

 Welche Schwachpunkte sollten wir künftig vermeiden?

 Welche Bereiche, Geschäftsprozesse, Produkte und Dienstleistungen sind eher schwach ausgeprägt?

 Wo haben wir unnötige Aufwände oder geben unnötig Geld aus?

Chancen (Opportunities)

 Was könnten neue Bedürfnisse unserer Kunden sein?

 In welche Richtung entwickelt sich die Nachfrage?

 Welche neuen technischen Möglichkeiten könnte es geben?

Risiken (Threats)

 Welche Vorschriften oder gesetzlichen Regelungen könnten sich ändern?

 Welche Wechsel von Technologie oder Wettbewerb bedrohen unsere Produkte, Dienstleistungen oder Kunden?

 Was machen die Wettbewerber und Marktbegleiter?

1.2.2.3 World Café

Ein World Café bindet die Workshop-Teilnehmer aktiv ein. In einem World Café können zum Beispiel die Inhalte für eine SWOT-Analyse zusammen erarbeitet werden.

Für die Erstellung des Business Case planen die Business-Analysten der TREND Möbelhäuser mehrere Workshops. Dabei sollen jeweils unterschiedliche Techniken und möglichst abwechslungsreiche Herangehensweisen eingesetzt werden. Aus diesem Grund wird die SWOT-Analyse nicht wie üblich mit den anderen Workshop-Teilnehmern erarbeitet, indem zum Beispiel Moderationskarten beschrieben oder Ergebnisse in einer Word-Datei festgehalten werden.

Um einen anderen Anreiz zu setzen, entscheiden sich die Business-Analysten für ein World Café.

Die Business-Analysten der TREND Möbelhäuser notieren die vier Kategorien der SWOT-Analyse auf je einem Flipchart. Nach einer kurzen Einleitung bitten sie die anderen Workshop-Teilnehmer, sich in etwa gleichmäßig auf die Flipcharts zu verteilen. Sie sollen ihre Gedanken notieren zu

 Stärken: „Was läuft aktuell oder in letzter Zeit gut?“

 Schwächen: „Wobei brauchen wir Unterstützung?“

 Chancen: „Was könnte sich positiv entwickeln?“

 Gefahren: „Welche Risiken seht Ihr?“

Dabei sollen die bereits auf den Flipcharts dokumentierten Ideen genutzt und weiter verfeinert oder präzisiert werden. Nach einigen Minuten wechseln die Teilnehmer zum nächsten Flipchart. Die Wechsel erfolgen so lange, bis jeder Teilnehmende mindestens einmal an jedem Flipchart war.

Um neben den vier Kategorien der SWOT-Analyse noch weiteren Ideen und Gedanken Raum zu geben, ist ein fünftes Flipchart vorbereitet: „Was ich schon immer sagen wollte zum gegenwärtigen Zustand.“

In einer abschließenden gemeinsamen Runde werden alle Ergebnisse vorgestellt und bei Bedarf korrigiert oder erweitert.

Die Vorgehensweise bei einem Word Café ist gut verständlich und benötigt wenig Erklärung. Die zu erarbeitenden Inhalte können auf mehreren Flipcharts festgehalten werden oder auf Papier, das auf mehreren Tischen ausgelegt wird. Wichtig dabei ist es, die entsprechenden Ergebnisse zu dokumentieren. Die Teilnehmenden lesen bereits notierte Punkte und entwickeln diese weiter, so dass ein besseres und umfassenderes Ergebnis erzielt wird.

1.2.2.4 Kompakte Problembeschreibung

Die kompakte Problembeschreibung stellt stichpunktartig die Ist-Situation dar:

 In der ersten Zeile wird das Problem skizziert. Aspekte, die nicht abschließend analysiert sind, können entsprechend kenntlich gemacht werden.

 „Betrifft“ benennt die Personen bzw. Personengruppen, die vom Problem betroffen sind. Hier kann auf die Ergebnisse der Stakeholder-Analyse zurückgegriffen werden (vgl. Kapitel 4.2.2). Zu diesem vergleichsweise frühen Zeitpunkt der Business-Analyse reicht es allerdings normalerweise aus, zu bestimmen, welche der drei Stakeholder-Gruppen Kunden, Management oder Mitarbeiter betroffen sind.Eine ausführlichere Stakeholder-Analyse liefert zwar konkretere Angaben, sie kann allerdings dazu führen, dass Business-Analysten zu früh Details analysieren und dann das Grundprinzip „Vom Groben zum Detail“ verlassen.

 „Hat Auswirkungen auf“ beschreibt entweder allgemein oder speziell für die betroffenen Stakeholder-Gruppen, welche Konsequenzen sich aus dem Problem für sie ergeben.

 „Eine gelungene Lösung bewirkt“ benennt erwünschte Wirkungen, die eine Veränderung erbringen soll. Dieser Abschnitt der Kompakten Problembeschreibung erlaubt einen Ausblick auf die noch konkreter zu formulierenden Ziele (vgl. Kapitel 1.3).

Kompakte Problembeschreibung

Das Problem (Beschreibung des Problems) Sinkende Umsätze, vermutlich zurückgehender Marktanteil

Betrifft (Die vom Problem betroffenen Stakeholder-Gruppen: z.B. Kunden, Management, Mitarbeiter) Management und Mitarbeiter

Hat Auswirkungen auf (Auswirkung des Problems für die jeweilige Stakeholder-Gruppe) Sinkender Unternehmensgewinn und damit Gefährdung der Arbeitsplätze

Eine gelungene Lösung bewirkt (Beschreibung einiger wesentlicher Vorteile einer gelungenen Lösung) Gesicherte Marktposition, stabilisierte oder steigende Gewinne

Abb.1.07: Kompakte Problembeschreibung

Während die kompakte Problembeschreibung durch ihre wenigen Inhalte zunächst nicht besonders hilfreich erscheint, zeigt die Praxis, dass in den Köpfen der Beteiligten häufig „unterschiedliche Bilder“ bestehen oder der Ist-Zustand unklar ist. Dies bewusst zu machen und zusammenzuführen, bietet einen wesentlichen Mehrwert.

Die kompakte Problembeschreibung eignet sich insbesondere für kleinere Veränderungen. Für mittlere oder größere Veränderungen bietet sich die nächste Technik an.

1.2.2.5 Ausführliche Problembeschreibung

Während die kompakte Problembeschreibung auf die wichtigsten Punkte fokussiert, erweitert die ausführliche Problembeschreibung die Inhalte insbesondere durch die Abgrenzung, woraus das Problem nicht besteht. Ein Vergleich der betroffenen und der nicht betroffenen Aspekte erleichtert die spätere Ursachenanalyse. Dabei sollte auch untersucht werden, warum Einheiten oder Aspekte nicht betroffen sind, die wegen ihrer Ähnlichkeit oder wegen Gemeinsamkeiten ebenfalls hätten betroffen sein können.

Was ist das Problem?
Was ist betroffen (Produkt, Prozess, Service)?	Was nicht?
Was passiert?	Was passiert nicht?
Wo tritt das Problem auf?	Wo nicht?
Wann tritt das Problem auf?	Wann nicht?
Wer löst das Problem aus?	Wer nicht?
Welche Stakeholder-Gruppen sind betroffen?	Welche nicht?

Abb.1.08: Ausführliche Problembeschreibung

 Die erste Zeile der ausführlichen Problembeschreibung entspricht der ersten Zeile der kompakten Problembeschreibung.

 Die zweite Zeile grenzt ab, welche Aspekte des Ist-Zustands betroffen sind und welche nicht. Zu den betroffenen Aspekten können z.B. Produkte, Dienstleistungen, Geschäftsprozesse, Services, IT-Systeme, Regelungen oder Daten gehören.

 „Was passiert?“ beschreibt konkreter, welche Auswirkungen das Problem nach sich zieht, und ähnelt damit der dritten Zeile der kompakten Problembeschreibung. Im Unterschied zu dieser grenzt die Frage „Was passiert nicht?“ ab, welche Konsequenzen sich nicht aus dem Problem ergeben.

 Die Frage nach dem „Wo“ bzw. „Wo nicht?“ lässt sich je nach Kontext räumlich (im Hinblick auf Standorte), technisch (bezüglich IT-Systeme) oder organisatorisch (in Hinsicht auf Organisationseinheiten) beantworten.

 „Wann?“ und „Wann nicht?“ fragen nach der Häufigkeit des Problems, nach Zeitpunkten oder Intervallen, zu denen das Problem auftritt bzw. nicht auftritt.

 „Wer?“ und „Wer nicht?“ impliziert häufig eine Schuldfrage. Die ausführliche Problembeschreibung stellt zwar auf die Personen oder Personengruppen ab, die das Problem auslösen, aber ohne diese damit automatisch als „schuldig“ anzusehen. Wichtiger ist es, sich über den beteiligten Personenkreis klar zu werden, um durch die Lösungsansätze (vgl. Kapitel 1.4) sinnvolle Wege für eine Verbesserung zu finden.

 „Welche Stakeholder-Gruppen sind betroffen?“ entspricht der zweiten Zeile der kompakten Problembeschreibung. Hier gelten die Ausführungen hinsichtlich Stakeholder-Analyse und Fokussierung auf die drei Stakeholder-Gruppen Kunden, Management und Mitarbeiter, die dort getroffen wurden.

Die ausführliche Problembeschreibung grenzt zusätzlich ab, welche Stakeholder-Gruppen nicht betroffen sind.

1.2.3 Linear-kausale Ursachenanalyse

„Echtes Wissen ist die Ursachen kennen.“

Sir Francis von Verulam Bacon

Die Techniken der linear-kausalen Ursachenanalyse eignen sich für Untersuchungen, wenn eine oder mehrere Ursachen eines Problems erforscht werden sollen. Im Unterschied zur kompakten Problembeschreibung und zur ausführlichen Problembeschreibung liegt der Fokus darauf, die Gründe für das Problem zu ermitteln.

Im Gegensatz zu den Techniken der komplexen Ursachenanalyse bieten sie per se keine Priorisierung der Ursachen, noch stellen sie Wechselwirkungen zwischen diesen dar. Die linear-kausale Ursachenanalyse bietet Business-Analysten auch nur begrenzt die Möglichkeit, Ursachen von Symptomen des Problems zu unterscheiden. Auch eine Betrachtung mehrerer Probleme gleichzeitig ist mit diesen Techniken nur bedingt möglich.

Sie zeichnen sich allerdings dadurch aus, dass sie vergleichsweise leicht zu verstehen sind bzw. Beteiligten in einem Workshop schnell erklärt werden können und übersichtliche Ergebnistypen bereitstellen.

Die folgenden Abbildungen 1.09 und 1.10 verdeutlichen die unterschiedlichen Arten der linear-kausalen Ursachenanalyse.

Bei einem einfachen Problem gibt es genau eine Ursache, die das Problem beeinflusst.

Abb. 1.09: Einfaches Problem mit einer Ursache

In vielen Fällen handelt es sich allerdings nicht um ein einfaches Problem bzw. die Annahme eines einfachen Problems verkürzt die Realität unzulässig. Bei diesen komplizierten Problemen gibt es mehr als eine Ursache, die das Problem beeinflussen.

Abb. 1.10: Kompliziertes Problem mit mehreren Ursachen

1.2.3.1 5W-Technik (5 Why)

Die 5W-Technik stellt ausgehend von einem zu untersuchenden Problem fünf Mal die Frage „Warum?“ (englisch „Why?“). Mit der Technik wird versucht, über die Zwischenstufen der Symptome zu den tatsächlichen Ursachen vorzudringen. Während Symptome nur Anzeichen sind, gilt es deren Ursachen zu ergründen und später Lösungen zu finden, um die Ursachen zu beseitigen. Der englische Begriff „root cause“ und die deutsche Redewendung „Wurzel des Übels“ bilden dies bildhaft in Sprache ab.

Problem?	Kunden bleiben aus
1. Warum?	Zu unattraktive Produkte
2. Warum?	Zu hoher Preis
3. Warum?	Mangelnde Einkaufsstärke
4. Warum?	Filialen bestellen eigenständig ihre Produkte
5. Warum?	Kein zentraler Einkauf, der Bestellungen bündelt

Abb. 1.11: 5W-Technik

Die Technik besticht durch ihre einfache Anwendung. Allerdings eignet sie sich nur bedingt im Rahmen eines Interviews. Der Interviewte, der möglicherweise mit 5 Why nicht vertraut ist, mag sich komisch vorkommen, mehrmals hintereinander „Warum?“ gefragt zu werden. Business-Analysten können diese Hürde umgehen, indem sie alternative Frageworte nutzen: „Weshalb?“, „Wieso?“, „Aus welchem Grund?“.

Ergänzend können Fragen eingestreut werden, die auch bei der ausführlichen Problembeschreibung eingesetzt werden, zum Beispiel „Wer?“, „Wann?“ und „Wo?“. Sie sollten allerdings nicht im Mittelpunkt stehen, sondern die Ursachenanalyse lediglich unterstützen.

1.2.3.2 Vorgelagerte Ursachen

Die Technik „Vorgelagerte Ursachen“ nutzt die Form einer Tabelle. In dieser Tabelle werden Probleme, deren Ursachen und diesen wiederum vorgelagerte Ursachen aufgelistet.

Gibt es mehr als eine Ursache oder mehr als eine vorgelagerte Ursache, können diese in derselben Zeile notiert werden, wenn sie inhaltlich zusammengehören. Eigenständige Ursachen sollten in einer neue Zeile notiert werden (siehe dazu das folgende Beispiel in Abb. 1.12).

Problem	Ursachen	Vorgelagerte Ursachen		Vorgelagerte Ursachen
Niedrige Gewinne	Niedrige Umsätze		Kein InternetverkaufZunehmende Konkurrenz		Keine Investition in moderne TechnikKeine eigene Wettbewerbsstrategie
	Hohe Kosten		Unterschiedliche Hardware-Ausstattung in den Filialen		Selbständige Entscheidungen der Filialen hinsichtlich technischer Ausstattung

Abb. 1.12: Vorgelagerte Ursachen

Weitere Spalten für vorgelagerte Ursachen sind möglich, um analog zur 5W-Technik ein viertes oder fünftes Mal „Warum?“ zu fragen. Damit wird eine Tabelle allerdings schnell unübersichtlich.

Im Gegensatz zu 5 Why lassen sich in der Tabelle der vorgelagerten Ursachen leichter mehrere Ursachen für ein Problem darstellen, die gleichberechtigt oder unabhängig nebeneinander stehen.

Alternativ bietet sich eine grafische Übersicht wie das Ishikawa-Diagramm an, das im Folgenden behandelt wird.

1.2.3.3 Ishikawa-Diagramm

Für eine linear-kausale Ursachenanalyse eignet sich das Ishikawa-Diagramm. Wegen seines Aussehens wird es auch Fischgräten-Diagramm oder Fishbone Diagram genannt.

Kaoru Ishikawa entwickelte ursprünglich dieses Ursache-Wirkungs-Diagramm als ein Werkzeug für Qualitätskontrollen.

Ein Ishikawa-Diagramm ist eine Darstellungstechnik in der Ursache-Wirkungs-Analyse zur Dokumentation von tiefer liegenden Problemursachen und der Kategorisierung dieser.

Abb. 1.13: Ishikawa-Diagramm

Ein Ishikawa-Diagramm kann grundsätzlich Top-Down oder Bottom-Up erstellt werden, wie in Abb. 1.14 beschrieben.

Top-Down-Vorgehen		Bottom-Up-Vorgehen
	Zu untersuchendes Problem rechts notieren (am „Kopf des Fisches“)Kategorien möglicher Ursachen zusammentragen und an den „Hauptgräten“ notierenTieferliegende Ursachen sammeln und an den „kleinen Gräten“ notieren, jeweils der geeigneten Kategorie zugeordnet		Zu untersuchendes Problem rechts notierenUrsachen (ungeordnet) zusammentragenKategorien für Ursachen bilden und benennen

Abb. 1.14: Vorgehensweisen Top-Down oder Bottom-Up zur Erstellung eines Ishikawa-Diagramms

Als Kategorien, um Ursachen zu gliedern, haben sich „8 M“ bewährt, die als Best Practice ein weites Feld möglicher Ursachen abdecken:

 Machine (Ausstattung an Werkzeugen, IT)

 Man (z.B. Motivation oder Wissen der Beteiligten)

 Management (Steuerung und Führung)

 Material (z.B. Ausstattung an Arbeitsmitteln)

 Measurement (fehlerhafte oder fehlende Messbarkeit oder Messwerte)

 Method (Art und Vorgehensweise, Prozesse)

 Milieu (Ursachen aus dem Umfeld)

 Money (finanzielle Ausstattung).

Die Kategorien lassen sich auch bei den deutschen Begriffen durchgängig mit der Alliteration M beibehalten:

 Maschine

 Mensch

 Management

 Material

 Messung/Messbarkeit

 Methode

 Milieu/Mitwelt

 Monetäres.

Als Erweiterung bieten sich noch „4P“ und „4S“ an: Place, People, Process, Policies, Suppliers, Surrounding, Systems, Skills.

Die festen Kategorien (8M, 4P, 4S) bilden einerseits einen guten Rahmen und Empfehlungen, an welche möglichen Ursachen zu denken ist. Andererseits können sie die Beteiligten hemmen, da nicht jede Kategorie selbsterklärend ist. Außerdem kann nie ausgeschlossen werden, dass weitere Ursachen vorliegen, die von dem begrifflichen Instrumentarium nicht abgedeckt werden. Business-Analysten sollten daher prüfen, ob das Bottom-Up-Vorgehen das sinnvollere ist, da bei ihm zunächst die Ursachen und noch nicht die Kategorien betrachtet werden.

Dem Ishikawa-Diagramm sehr ähnlich ist eine Mindmap. Bei einer Mindmap wird das Problem in der Mitte und die Ursachen werden um das Problem herum dokumentiert. Eine Mindmap dient dem assoziativen Vorgehen und kann daher auch als Kreativitätstechnik genutzt werden. Sie eignet sich somit auch als Technik, um Lösungsvarianten (vgl. Kapitel 1.4.3) zu entwickeln.

1.2.4 Komplexe Ursachenanalyse

Die linear-kausale-Ursachenanalyse zeichnet sich dadurch aus, dass sie vergleichsweise einfach zu erstellen ist. Sie sieht allerdings nicht vor, Wechselbeziehungen zwischen Ursachen zu untersuchen bzw. darzustellen. In der Realität finden sich eher selten linear-kausale Zusammenhänge. Typischerweise gibt es mehrere Ursachen, die einander bedingen. Auswirkungen eines Problems sind häufig Ursache für weitere Probleme. Ursachen und Probleme verstärken sich zum Teil untereinander. Tabellarische oder einfache grafische Techniken stoßen bei dieser Darstellung an ihre Grenzen. Business-Analysten wählen in diesen Fällen sinnvollerweise Techniken der komplexen Ursachenanalyse.

Die folgende Abbildung 1.15 verdeutlicht die Struktur einer komplexen Ursachenanalyse.

Abb. 1.15: Komplexe Ursachenanalyse

Grafische Netzwerke, wie das Ursache-Wirkungs-Diagramm, veranschaulichen die Zusammenhänge besser. Allerdings sind sie häufig nicht so intuitiv zu lesen, insbesondere für Personen, die bei ihrer Erstellung nicht mitgewirkt haben.

Business-Analysten können die Techniken Ursache-Wirkungs-Diagramm, Papiercomputer und Portfolio-Analyse, die im Folgenden beschrieben werden, grundsätzlich losgelöst voneinander einsetzen. Ihre größte Wirkung erzielen die drei Techniken allerdings im Zusammenspiel.

Die Inhalte des Ursache-Wirkungs-Diagramms (siehe Kapitel 1.2.4.1) lassen sich mithilfe des Papiercomputers (siehe Kapitel 1.2.4.2) übersichtlicher darstellen und weiter analysieren. Die Ergebnisse des Papiercomputers können mit der Portfolio-Analyse (siehe Kapitel 1.2.4.3) so aufbereitet werden, dass Ursachen, Probleme und Auswirkungen klarer differenziert werden können. Dadurch werden leichter Ansatzpunkte für eine sinnvolle Veränderung gefunden, die konsequent auf die Ursachen ausgerichtet ist.

1.2.4.1 Ursache-Wirkungs-Diagramm

Analog zu Ishikawa-Diagramm oder Mindmap startet das Ursache-Wirkungs-Diagramm mit einem Problem oder zu untersuchenden Sachverhalt. Auswirkungen bzw. Konsequenzen, die sich daraus ergeben, werden in einem Bubble (Blase) am Ende eines ausgehenden Pfeils notiert. Ursachen bzw. Gründe für dieses Problem oder diesen Sachverhalt werden in einem Bubble am Ende eines eingehenden Pfeils notiert. Für die hinzugefügten Bubbles gilt es, weitere Auswirkungen und Ursachen zu sammeln.

Abb. 1.16: Ursache-Wirkungs-Diagramm

Die Darstellung wird verständlicher, wenn die Bubbles so angeordnet werden, dass Auswirkungen weiter oben und Ursachen weiter unten stehen.

In einem weiteren Schritt werden die Wechselwirkungen zwischen den notierten Sachverhalten untersucht und bei Bedarf weitere Pfeile eingezeichnet, die Kausalitäten veranschaulichen. Spätestens nach diesem Schritt wird die Sortierung der Auswirkungen im oberen und Ursachen im unteren Bereich des Ursache-Wirkungs-Diagramms schwierig sein. Denn in vielen Fällen sind die notierten Sachverhalte Problem, Ursache und Auswirkung zugleich.

Die Kernursachen sind die Bubbles, die nur ausgehende Pfeile oder sehr wenige eingehende Pfeile haben. Die Hauptauswirkungen sind die Bubbles, die nur eingehende Pfeile oder sehr wenige ausgehende Pfeile haben. Symptome sind Bubbles mit mehreren eingehenden und ausgehenden Pfeilen.

Ergänzend kann an den Pfeilen noch abgetragen werden, ob es sich um eine starke, mittlere oder schwache Wirkung der Kausalität handelt (z.B. durch ein Plus, einen kleinen Kreis oder ein Minus). Da das Ursache-Wirkungs-Diagramm dadurch nicht unbedingt übersichtlicher wird, sollten die Intensitäten der Wirkung besser mithilfe des Papiercomputers dargestellt werden.

1.2.4.2 Papiercomputer

Der Papiercomputer ist eine Matrix, in der die Intensität der Wirkungen dargestellt wird. Dazu werden alle Probleme, Ursachen bzw. Wirkungen in die erste Spalte und oberste Zeile eingetragen. Die einzutragenden Sachverhalte können einer der vorher beschriebenen Techniken entnommen werden. Besonders eignen sich dazu die Ergebnisse des Ursache-Wirkungs-Diagramms.

In die Schnittfelder werden die Intensitäten auf einer Skala von 0 bis 3 notiert:

 0: keine Wirkung

 1: geringe Wirkung

 2: mittlere Wirkung

 3: starke Wirkung.

Die Abbildung 1.17 (siehe folgende Seite) zeigt ein Beispiel eines Papiercomputers.

Abb. 1.17: Papiercomputer

In der rechten Spalte wird die Aktivsumme, in der untersten Zeile die Passivsumme gebildet. Die Aktivsumme drückt aus, wie stark ein Sachverhalt (Problem) auf die anderen Sachverhalte (Probleme) wirkt. Die Passivsumme gibt an, wie stark ein Sachverhalt durch die anderen beeinflusst wird.

Probleme mit hoher Aktivsumme und niedriger Passivsumme sind grundlegende Ursachen, die es zu mildern bzw. zu beseitigen gilt. Probleme mit hoher Passivsumme und niedriger Aktivsumme sind Auswirkungen, die für die zu erstellenden Lösungsansätze (vgl. Kapitel 1.4) eine untergeordnete Rolle spielen.

Der Papiercomputer ist nicht sehr übersichtlich, falls mehrere Probleme analysiert werden. Die jeweiligen Aktiv- und Passivsummen der Probleme sind die entscheidenden Kriterien, die sich anschaulicher aus einer Portfolio-Analyse ablesen lassen.

1.2.4.3 Portfolio-Analyse

Business-Analysten werten den Papiercomputer sinnvollerweise über eine Portfolio-Analyse aus. Die Sachverhalte werden mittels ihrer Aktiv- und Passivsumme im Portfolio eingetragen.

Abb. 1.18: Portfolio-Analyse

Probleme mit hoher Aktiv- und niedriger Passivsumme (bildlich gesprochen sind dies die Bubbles des Ursache-Wirkungs-Diagramms mit vielen ausgehenden und sehr wenigen eingehenden Pfeilen) bilden die aktiven Probleme. Sie sollten mit höchster Priorität angegangen werden.

Probleme mit hoher Aktiv- und hoher Passivsumme (dies sind die Bubbles des Ursache-Wirkungs-Diagramms mit vielen ausgehenden und eingehenden Pfeilen) bilden die kritischen Probleme. Sie sind insofern „mit Vorsicht zu behandeln“, als sie starke Wechselwirkungen mit anderen Problemen aufweisen. Die Veränderung eines kritischen Problems kann sich positiv oder negativ auf verbundene Sachverhalte auswirken. Nicht immer lässt sich die Auswirkung von vornherein absehen.

Probleme mit niedriger Aktiv- und hoher Passivsumme (dies sind die Bubbles mit vielen eingehenden und sehr wenigen ausgehenden Pfeilen) bilden die passiven Probleme. Sie sind im eigentlichen Sinne die Auswirkungen und spielen eine untergeordnete Rolle. Dies gilt auch für die trägen Probleme (bildlich gesprochen sind dies die Bubbles mit wenigen eingehenden und ausgehenden Pfeilen).

1.2.4.4 Schwachstellenanalyse

Business-Analysten können die Schwachstellenanalyse nutzen, um die Ergebnisse anderer Techniken der Ursachenanalyse zusammenzufassen und weiter zu detaillieren. Die Schwachstellenanalyse kann auch als eigenständige Technik genutzt werden; allerdings fällt die Ursachenforschung mit anderen Techniken in der Regel leichter.

Die Schwachstellenanalyse ist eine Technik, mit der der Ist-Zustand hinsichtlich seiner Schwächen untersucht und systematisch nach den Ursachen der Probleme gesucht wird.

Vier Kategorien bilden die Schwachstellenanalyse:

 Problemsuche

 Problemdarstellung

 Problembewertung

 Ursachenforschung.

Abb. 1.19: Schwachstellenanalyse

Die Problemsuche kann durch die zuvor beschriebenen Techniken unterstützt werden. Jeder der dort gefundenen Sachverhalte wird in eine eigene Zeile eingetragen.

In der Problemdarstellung soll das Problem möglichst konkret abgegrenzt bzw. quantifiziert werden. Hier kann auf die Ergebnisse der ausführlichen Problembeschreibung aufgebaut werden.

 Wo treten Abweichungen auf bzw. wo werden mangelhafte Ergebnisse erzielt?

 Wann, zu welchem Zeitpunkt, in welcher Frequenz, wie lange tritt das Problem auf?

 Wie viele Einheiten (Organisationseinheiten, Produkte, Services) sind betroffen bzw. wie groß ist die Abweichung?

Für die Problembewertung können die Ergebnisse aus Papiercomputer und Portfolio-Analyse genutzt werden.

 Dringlichkeit: Gibt es Vorgaben oder Termine, bis wann das Problem zu lösen ist?

 Wichtigkeit: Wie groß sind die Tragweite, Auswirkungen, Konsequenzen des Problems?

 Priorität: Aus Dringlichkeit und Wichtigkeit abgeleitete Priorisierung der Probleme

 Machbarkeit: Gibt es erste Überlegungen, ob Ressourcen, Knowhow etc. für eine Problembeseitigung zur Verfügung stehen? Diese Aspekte werden im Schritt der Lösungsansätze aufgegriffen.

Für die Ursachenforschung können die anderen Techniken verwendet werden, z.B. Ishikawa-Diagramm, Ursache-Wirkungs-Diagramm.

1.2.5 Zusammenfassung

Der Schritt „Leistungspotenziale“ in der Business-Case-Erstellung betrachtet den Ist-Zustand. Als Grundlage für die weiteren Schritte müssen das Gesamtbild und die jeweils relevanten Zusammenhänge bekannt und verstanden sein. Die Analyse der Leistungspotenziale zeigt auf, welche Probleme bestehen, welche Ursachen es dafür gibt, d.h. welche Leistungspotenziale fehlen und welche bestehenden Leistungspotenziale genutzt, erhalten oder ausgebaut werden sollten.

1.3 Geschäftsanforderungen

„Lassen Sie uns mit den Maßnahmen anfangen; dann fallen uns die Ziele schon ein.“

Unbekannt

Abb. 1.20: Schritt Geschäftsanforderungen in der Business-Case-Erstellung

1.3.1 Überblick

Der zweite Schritt der Business-Case-Erstellung fokussiert auf den Soll-Zustand. Welche Geschäftsanforderungen sind bereits bekannt? Welche Geschäftsanforderungen gilt es auf Grundlage der fehlenden und bestehenden Leistungspotenziale zu erfüllen?

Eine Geschäftsanforderung ist eine Aussage zu Zielen und erwünschten Wirkungen. Sie beschreibt die Gründe für eine Veränderung.

Ein Ziel beschreibt einen erwünschten, angestrebten zukünftigen Zustand, eine zukünftige Wirkung oder ein zukünftiges Ereignis.

Ziele beschreiben den Soll-Zustand in einer abstrakteren Form, d.h. ohne die Wege zur Erreichung dieses Soll-Zustands vorzugeben. Sie geben Orientierung und legen fest, „was“ erreicht werden soll (das Ergebnis), ohne das „wie“ vorzugeben (das Verfahren zur Zielerreichung). Wege zum Soll-Zustand bieten die Lösungsansätze an, die im nächsten Schritt der Business-Case-Erstellung erarbeitet werden.

In der Praxis wird der Schritt der Zielfindung oft sträflich vernachlässigt. Die Beteiligten gehen von der Untersuchung des Ist-Zustands mit seinen Leistungspotenzialen nahtlos zu Lösungsansätzen oder zu einer konkreten Lösung über. Oder es wird die „Einführung des Systems XY“ als Ziel formuliert. Dies wäre jedoch eine Maßnahme bzw. Lösung und beantwortet nicht die Frage „Was soll erreicht werden?“.

Auch bei den TREND Möbelhäusern gab es sehr bald die Überlegung „Einführung eines Internet-Shops“ als Ziel auszugeben. Bis die Business-Analysten intervenierten und darauf hinwiesen, dass dies ein möglicher, wenn auch plausibler Lösungsansatz sei.

Ziele bilden eine wichtige Grundlage für weitere Schritte in der ibo-Anforderungstür^®:

 Lösungsansätze sollten anhand der Ziele bewertet werden. In welchem Ausmaß erfüllen die Lösungsansätze die Ziele? Welcher Lösungsansatz erfüllt die Ziele am besten? Vgl. Kapitel 1.5 Empfehlung als letzten Schritt im Konzept Business-Case-Erstellung.

 Jede Stakeholder-Anforderung oder zumindest Lösungsanforderung sollte sich auf ein oder mehrere Ziele zurückführen lassen und die Erfüllung dieser Ziele unterstützen, vgl. Kapitel 2.8.3 Validierung im Konzept Requirements Engineering. Dadurch lassen sich „Goldrandlösungen“ und „Wunschkonzerte“ vermeiden.

 Die Lösung sollte bei ihrer Einführung und auch danach überprüft werden, wie gut sie die vorab definierten Ziele erreicht, vgl. Kapitel 3.4.2 Lösungsbewertung und Leistungsüberprüfung im Konzept Lösungseinführung.

1.3.2 Zielformulierungsprozess

Für kleine Veränderungen können die Ziele aus den bestehenden und fehlenden Leistungspotenzialen abgeleitet werden. Dazu werden die im vorherigen Schritt analysierten Leistungspotenziale in Ziele umformuliert.

Die Business-Analysten haben als fehlende Leistungspotenziale u.a. analysiert: Sinkende Umsätze, uneinheitliche und langsame IT-Hardware, veralteter Auftritt im Internet, wenige junge Kunden. Als bestehende Leistungspotenziale wurden u.a. identifiziert: gute Beratung, Kundenfreundlichkeit, vorhandenes Filialnetz.

Daraus lassen sich folgende Geschäftsanforderungen ableiten: Umsätze steigern, IT-Hardware vereinheitlichen, performante IT-Hardware bereitstellen, Internetauftritt modernisieren, junge Kunden gewinnen, Beratungsqualität sichern, Freundlichkeit gegenüber Kunden erhalten, Filialnetz nutzen.

Diese pragmatische Herangehensweise birgt allerdings die Gefahr, Ziele zu übersehen, die sich nicht unmittelbar aus den Leistungspotenzialen ableiten lassen. Daher sollte insbesondere für mittlere und größere Veränderungen bei der Suche nach Zielen strukturiert vorgegangen werden.

Der Zielformulierungsprozess unterstützt dabei,

 die relevanten Ziele zu kennen

 Ziele zu strukturieren und dabei die Vollständigkeit der Kategorien zu überprüfen

 Ziele möglichst verständlich und eindeutig zu definieren

 Ziele zu operationalisieren, d.h. Messgrößen festzulegen, um eine Zielerreichung überprüfen zu können

 Ziele nach ihrer Bedeutung (unterschiedlich) zu gewichten

 Ziele mit Entscheidern und Beteiligten abzustimmen und festzulegen.

Folgende Schritte gehören zum Zielformulierungsprozess (in Anlehnung an SCHMIDT, Organisation und Business Analysis, 2014). Sie werden im Folgenden erläutert.

Abb. 1.21: Schritte des Zielformulierungsprozesses

1.3.2.1 Zielideen suchen

Ziele spiegeln Erwartungshaltungen von Personen oder Personengruppen wider. Diese sogenannten Zielträger haben Geschäftsanforderungen oder sie können die angedachte Veränderung beeinflussen.

Grundsätzlich wäre es möglich, aufbauend auf einer Stakeholder-Analyse (vgl. Kapitel 4.2.2), die Ziele der einzelnen Stakeholder bzw. Stakeholder-Gruppen zu ermitteln. Insbesondere zwei Gründe stehen dem entgegen: Zum einen steigert dies den Aufwand einer Business-Case-Erstellung, wenn eine große Anzahl von Stakeholdern zu befragen, mit dem Prozess der Zielfindung vertraut zu machen und untereinander abzustimmen ist. Zum anderen werden Erwartungen an eine Lösung bzw. Problemlösung geweckt, die möglicherweise nicht zu erfüllen sind (sei es, dass die Empfehlung des Business Case lautet, keine Veränderung vorzunehmen; sei es, dass es zu Konflikten zwischen den Zielen der einzelnen Stakeholder kommt, so dass nicht alle Ziele gleichzeitig oder in gleichem Maße verfolgt werden können).

So wichtig generell eine Einbeziehung und Beteiligung der von einer Veränderung Betroffenen ist, kann in den meisten Fällen auf eine direkte Mitwirkung aller Stakeholder bei der Zielfindung im Rahmen des Business Case verzichtet werden.

Die Probleme, die es zu lösen gilt, und die Leistungspotenziale, die zu verbessern sind, betreffen nahezu das gesamte Unternehmen. Dennoch wurde die Idee, möglichst viele Mitarbeiterinnen und Mitarbeiter nach ihren Zielen zu befragen, nicht weiterverfolgt.

Bei der Auswahl der Zielträger hat es sich bewährt, auf die „3 Tenöre“ zu hören, da sie die Interessen vieler Beteiligter meistens sehr gut abdecken:

 Voice of the Business (VoB): Ziele der Geschäftsführung bzw. des Managements

 Voice of the Customer (VoC): Ziele des Kunden (dies kann ein externer oder interner Kunde sein)

 Voice of the Employee (VoE): Ziele der Mitarbeiterinnen und Mitarbeiter, insbesondere derjenigen, die in der Ist-Situation arbeiten und mit einer möglichen Lösung umgehen müssten.

Typische Ziele dieser drei Zielträger sind in der Abbildung 1.22 zusammengefasst.

Voice of the Business		Voice of the Customer	Voice of the Employee
	Geringer Ressourcen- verbrauchNiedrige KostenSteigender UmsatzGutes ImageGeschäftsprozesseoptimieren Schnelle Umsetzung der VeränderungStandards einhalten oder mehr StandardisierungHöhere AutomatisierungEinhaltung von Richtlinien, Compliance, GesetzenHohe Kundenbindung	Schnelle Durchlaufzeit von GeschäftsprozessenQualitativ gute und freundliche Kundenberatung, guter ServiceHohe ProduktqualitätHohe ErreichbarkeitGutes Preis-Leistungs-VerhältnisEindeutige AnsprechpartnerHohe FlexibilitätHohe QualitätGeringer PreisEinfache Bedienbarkeit	Gute KommunikationBeteiligung an der VeränderungGleichmäßiger Arbeitsanfall(Technische) UnterstützungQualifizierung Klare ZuständigkeitenInteressante oder standardisierte Aufgaben und Abläufe

Abb. 1.22: Typische Ziele der drei Zielträger (Voice of the Business, Voice of the Customer, Voice of the Employee)

Die Business-Analysten erarbeiteten mit einigen Beteiligten die Ziele, um sie anschließend mit den Entscheidern abzustimmen. Dabei wurde auf die 3 Tenöre gehört, indem sich die Arbeitsgruppe in deren Lage versetzte und Ziele dokumentierte, die der Arbeitsgruppe plausibel erschienen.

Die Ziele wurden bereits um Mehrfachnennungen bereinigt. Ziele, die mehr als einer Zielträgergruppe zugeordnet werden können, wurden – willkürlich – nur bei einer Zielträgergruppe genannt.

Inhaber, Management		Externe Kunden		Mitarbeiter aus Filialen, Marketing, IT
	Niedrige (Personal-) KostenFlexibilität der LösungWenig Abhängigkeit von DrittenSchnelles Ergebnis		Leichte Verständlichkeit der LösungUmfassende InformationenAttraktive AufbereitungSchneller Zugriff		Zukunftssichere LösungSchnelle Einarbeitung möglichUmfassende Informationen über das ProjektAusfallsicherheitEinfache Pflege der Lösung

Abb. 1.23: Ziele der Zielträger der TREND Möbelhäuser

1.3.2.2 Ziele analysieren und Zielstruktur aufbauen

Zu diesem Schritt gehören:

 Lösungen durch Ziele ersetzen

 Muss-Ziele von Kann-Zielen trennen

 Bezug zur Veränderung prüfen

 Redundanzen eliminieren

 Zielwidersprüche beseitigen

 Geeignete Oberbegriffe suchen und Ziele vervollständigen

 Ziele operationalisieren.

1.3.2.2.1 Lösungen durch Ziele ersetzen

Die folgenden Definitionen bieten Anhaltspunkte, um Ziele und Lösungen zu unterscheiden:

Eine Lösung ist die Summe der Veränderungen des Ist-Zustands eines Unternehmens, um einen Bedarf zu decken und/oder Ziele zu erreichen.

Ein Ziel beschreibt einen erwünschten, angestrebten zukünftigen Zustand, eine zukünftige Wirkung oder ein zukünftiges Ereignis.

Eine saubere Trennung von Lösungen und Zielen ist sinnvoll, aber nicht immer möglich.

Je konkreter ein Ziel formuliert ist, desto näher rückt es an eine Lösung. Konkrete Wege zur Veränderung sollten Business-Analysten sinnvollerweise bei den Lösungsansätzen (vgl. Kapitel 1.4) erarbeiten. Ein Vergleich von Lösungsansätzen und Zielen und damit eine Bewertung der Lösungsansätze findet im Schritt Empfehlung (vgl. Kapitel 1.5) statt.

Formulierungen wie „Einführung von …“, „Zentralisation von Standorten“, „Einsatz des Systems XY“ deuten auf Lösungen hin. Selbst die Formulierung „Optimierung von …“ kann durch Ziele wie z.B. „Senkung von Kosten“, „Bessere Kundenbetreuung“ besser beschrieben werden.

Die Frage nach dem „Warum“ verhindert ein (zu frühes) lösungsorientiertes Denken und macht häufig die wahren Beweggründe, d.h. die Ziele, transparent.

Wie erwähnt lehnten die Business-Analysten das Ziel „Einführung eines Internet-Shops“ ab und wiesen darauf hin, dass dies ein möglicher Lösungsansatz sei.

1.3.2.2.2 Muss-Ziele von Kann-Zielen trennen

Muss-Ziele sind „K.O.“-Kriterien, d.h. ihre Verletzung schließt eine Lösungsvariante von weiteren Untersuchungen aus. Typische Muss-Ziele sind Einhaltung einer Budget-Obergrenze, Einhaltung von Richtlinien, Compliance, Gesetzen oder die Einhaltung von Terminvorgaben/Fristen.

Kann-Ziele sind Wunsch-Ziele, die durch Lösungsansätze möglichst gut erreichen werden sollen.

Bei den TREND Möbelhäusern haben sich Inhaber und Management bewusst gegen das Kann-Ziel „Weniger Mitarbeiterkapazitäten“ entschieden; auch wenn die Hoffnung besteht, dass die noch zu definierenden Lösungsansätze die Effizienz steigern werden.

Als Muss-Ziel wurde bewusst „Keine Entlassungen“ festgelegt, als deutliches Signal an die Belegschaft, dass die familiäre Kultur beibehalten werden soll.

Einige Ziele lassen sich in Muss-Ziel und Kann-Ziel aufteilen. Die Einhaltung eines festen Budgets kann als Muss-Ziel definiert werden. Jeder Lösungsansatz, der das Budget überschreitet, wird nicht weiterverfolgt. Als Kann-Ziel kann „Niedrige Kosten“ definiert werden; der Lösungsansatz mit den geringsten Kosten schneidet entsprechend bei diesem Ziel am besten ab.

Beide Zielarten sind wichtig. Ihre Definition bildet die Grundlage für die weitere Business-Analyse. Die Muss-Ziele sind allerdings separat zu betrachten. Die Kann-Ziele fließen in die Zielstruktur (vgl. Kapitel 1.3.2.2.6) ein.

1.3.2.2.3 Bezug zur Veränderung prüfen

„Ceterum censeo Carthaginem esse delendam. Im Übrigen bin ich der Meinung, dass Karthago zerstört werden muss.“

Cato der Ältere

Der Ausspruch, der dem römischen Staatsmann Cato zugeschrieben wird, soll am Ende vieler seiner Reden gestanden haben, unabhängig vom eigentlichen Thema der Rede. Ein gänzlich fehlender Bezug kann in einer Business-Analyse nicht sinnvoll sein, deswegen sollten Ziele eliminiert werden, die in keinem Zusammenhang mit der Veränderung stehen.

Bei TREND gab es Überlegungen, dass die Mitarbeiterinnen und Mitarbeiter Ziele haben könnten wie „positive Work-Life-Balance“ oder „hohe Vergütung“. Diese Ziele wurden für eine weitere Betrachtung gestrichen, da sie nur mittelbar mit der geplanten Veränderung zu tun haben.

Gleiches gilt für das Ziel „Niedriger Preis der Produkte“, das für externe Kunden plausibel, aber durch die anstehende Veränderung bestenfalls indirekt (z.B. über Kostensenkungen) zu erreichen ist.

1.3.2.2.4 Redundanzen eliminieren

Es kommt häufig vor, dass mehrere Zielträger gleiche Ziele verfolgen. Ein und dasselbe Ziel sollte allerdings nur einmal in die Zielstruktur einfließen. Es gibt Ziele, die offensichtlich redundant sind. Schwieriger sind Redundanzen zu erkennen, wenn sich hinter unterschiedlichen Begriffen das gleiche Ziel verbirgt. Der Schritt „Ziele operationalisieren“ (vgl. Kapitel 1.3.2.2.7) deckt diese Übereinstimmung in der Regel auf.

Die Business-Analysten identifizierten die folgenden Ziele, die – abhängig von ihrer Operationalisierung – wahrscheinlich redundant sind: „Automatisierung“ und „Optimierung von Arbeitsabläufen“, „Hohe Qualität“ und „Guter Kundenservice“, „Anwenderfreundliche Lösung“ und „Einfache Bedienbarkeit“.

1.3.2.2.5 Zielwidersprüche beseitigen

Ziele, die sich widersprechen, können sinnvollerweise nicht gleichzeitig verfolgt werden. Nur ein Ziel kann in die Zielstruktur einfließen. Sich widersprechende Ziele sind zu streichen.

Die Ziele „Flexible Lösung“ und „Hohe Standardisierung“ wurden durch die Business-Analysten auf einen Widerspruch untersucht.

1.3.2.2.6 Geeignete Oberbegriffe suchen und vervollständigen

Bei mehreren Zielen ist es sinnvoll, diese in einer Zielstruktur zu gliedern. Zwar wäre es möglich, die 3 Tenöre als Kategorien zu belassen. Aber zum einen gibt es Ziele, die von mehr als einer Zielträgergruppe verfolgt werden. Zum anderen besteht die Herausforderung, dass bei der Gewichtung den Zielen der Mitarbeiter möglicherweise weniger Bedeutung beigemessen wird und diese daher geringer gewichtet werden (im Vergleich zu den Zielen des Managements und der Kunden) oder sogar entfallen sollen.

Daher hat es sich bewährt, die Ziele wie folgt zu unterteilen:

 Systemziele: Ziele, die mit der Lösung angestrebt werden. Sie dienen als Kriterien zur Beurteilung von Lösungen (vgl. Kapitel 1.5). Zu ihnen gehören die drei Zielklassen wirtschaftliche Ziele, Leistungsziele, kulturelle Ziele.- Wirtschaftliche Ziele (Kostenziele) beziehen sich typischerweise auf einmalige Kosten und Aufwände, die durch die Planung, Umsetzung und Einführung einer Lösung entstehen, sowie auf laufende Kosten und Aufwände, die der Betrieb einer Lösung verursacht.- Leistungsziele beschreiben, welche erwünschten Ergebnisse und Zustände durch eine Lösung erreicht werden sollen bzw. was eine Lösung leisten soll. Darunter können auch (grobe) Funktionalitäten der Lösung fallen; allerdings ist zu beachten, dass hier keine Lösungsanforderungen vorweggenommen werden.- Kulturelle Ziele (Mitarbeiter-, Anwenderziele, personale Ziele) beziehen die zwischenmenschlichen Aspekte ein. Sie treffen z.B. Aussagen hinsichtlich Information, Kommunikation oder Zusammenarbeit.

 Vorgehensziele: Sie sind nur während der Laufzeit der Veränderung gültig und eignen sich nur bedingt zur Auswahl einer Lösung. Das wahrscheinlich gebräuchlichste Vorgehensziel ist es, die Veränderung möglichst schnell herbeizuführen.

Durch die Zielklassen ergeben sich u. U. weitere Ziele, wenn die Vollständigkeit einer Zielklasse überprüft wird. Daher sollten diese, soweit mit den Zielen der 3 Tenöre verträglich, ergänzt und die Zielstruktur dadurch vervollständigt werden.

Eine Obergrenze von 15-20 Zielen bei größeren Veränderungen sollte allerdings beachtet werden, um die Ziele für die weiteren Schritte und die Empfehlung in einem sinnvollen und übersichtlichen Umfang zu halten. Für mittlere und kleinere Veränderungen können es entsprechend weniger Ziele sein.

In die Zielstruktur wurden nur solche Ziele aufgenommen, die auch für die Bewertung von Lösungsansätzen herangezogen werden können. Das Vorgehensziel „Umfassende Information über die Veränderung“ wurde daher eliminiert. Außerdem wurden Ziele ergänzt, die sich aus den Oberbegriffen ableiten lassen, in der ersten Sammlung jedoch nicht enthalten waren („Betroffene beteiligen“).

Wirtschaftliche Ziele		Leistungsziele		Kulturelle Ziele		Vorgehensziele
	Niedrige Investitionskosten für InfrastrukturNiedrige Investitionskosten für SchulungNiedrige laufende PersonalkostenNiedrige laufende für Fremd-Kostenleistungen		Unabhängigkeit von DrittenLeichte VerständlichkeitUmfassende InformationenAttraktive AufbereitungZukunftssichere LösungSchneller ZugriffAusfallsicherheitEinfache Pflege der neuen Lösung		Betroffene beteiligen		Schnelles Ergebnis

Abb. 1.24: Zielstruktur der TREND Möbelhäuser

Die Ziele „Umsätze steigern“ und „Marktanteile steigern“ wurden nicht berücksichtigt, da schwierig abzusehen und zu messen ist, wie eine Lösung jeweils dazu beiträgt. Sollte zum Beispiel ein Lösungsansatz „Internet-Shop“ sein, so könnten Umsatzsteigerungen dort zu Umsatzrückgängen in den Filialen beitragen.

1.3.2.2.7 Ziele operationalisieren

„Miss es oder vergiss es.“

Unbekannt

Business-Analysten sollten Ziele eindeutig formulieren. Maßstäbe bzw. Kriterien für Ziele festzulegen wird auch als Operationalisierung von Zielen bezeichnet.

Zum Ziel „Eindeutige Ansprechpartner“ gab es unterschiedliche Vorstellungen. Einige Beteiligte brachten dieses Ziel mit der zu erstellenden Lösung zusammen und sortierten es entsprechend in der Zielklasse „Leistungsziele“ ein. Andere verstanden darunter, dass eindeutige Ansprechpartner für den Zeitraum der Veränderung notwendig seien und sahen es daher als „Vorgehensziel“ an. Ein gemeinsamer Austausch und eine Operationalisierung des Ziels klärten diese unterschiedlichen Verständnisse.

Ein pragmatischer Weg ist, die Ziele näher zu beschreiben und damit Anhaltspunkte zu liefern, was unter dem jeweiligen Ziel zu verstehen ist. Dies eignet sich insbesondere für kleinere Veränderungen.

Dabei gibt es grundsätzlich keine „richtigen“ oder „falschen“ Maßstäbe. Vielmehr wird durch die Operationalisierung ersichtlich, in welche Richtung ein Ziel interpretiert wird. Unterschiedliche Personen können bei gleichen Zielen unterschiedliche Vorstellungen entwickeln, wie diese Ziele „gemeint“ sind. Insofern dient die Operationalisierung auch einer besseren Verständigung aller Beteiligten.

Ziele	Maßstäbe
Niedrige Investitionskosten für Infrastruktur	Investitionskosten für Hard- und Software sowie Erstinstallation von Technik
Niedrige Investitionskosten für Schulung	Aufwand für die Schulung aller betroffenen Mitarbeiter zur Nutzung der Hard- und Software, die mit der neuen Lösung eingeführt werden
Niedrige laufende Kosten für Personal bzw. Fremdleistungen	Personalkosten für alle Leistungen, die zentral oder dezentral, intern oder extern für die Unterstützung anfallen
Unabhängigkeit von Dritten	Anteil der Aufgaben, die durch interne Mitarbeiter bewältigt werden können
Leichte Verständlichkeit, schnelle Einarbeitung möglich	Zeit für Schulung bis zur selbständigen Benutzung
Umfassende Informationen	Bereitgestellte Informationen im Verhältnis zu den benötigten Informationen
Attraktive Aufbereitung	Ansprechendes Design, ansprechender Mix aus Text, Bildern und Grafiken
Flexibilität, zukunftssichere Lösung	Eignung der Lösung bei Zunahme der Zugriffe und/oder Produkte (Aufwand bei Erweiterungen)
Schneller Zugriff	Dauer vom Aufrufen der jeweiligen Internetseite oder Information bis zu ihrer Bereitstellung
Ausfallsicherheit	Sicherstellen, dass die Lösung rund um die Uhr zur Verfügung steht
Gute/einfache Pflege der neuen Lösung	Anteil der Aufgaben, die durch interne Mitarbeiter ohne unnötig lange Vorbereitung oder Einarbeitung bewältigt werden können
Schnelles Ergebnis	Zeitdauer vom Anstoß der Veränderung bis zum Beginn der Nutzung der neuen Lösung

Abb. 1.25 : Operationalisierung der Ziele

Für mittlere oder große Veränderungen sind diese Maßstäbe häufig zu wenig. Eindeutige Kriterien präzisieren Ziele. Bewährt haben sich die SMART-Kriterien:

 Specific: Spezifisch

 Measureable: Messbar

 Achievable/Attainable: Erreichbar

 Realistic/Relevant: Realistisch/Relevant

 Timeable/Timely: Termingerecht.

Spezifisch bedeutet, unmissverständlich und konkret zu benennen, worum es geht. Allgemeine Formulierungen, die allen Beteiligten recht sind, aber unklar bleiben, gilt es zu vermeiden.

Messbar bedeutet, Ziele so zu formulieren, dass später objektiv zu erkennen (idealerweise zu messen) ist, ob das Ziel erreicht wurde, in welchem Ausmaß es erreicht wurde oder ob es verfehlt wurde.

Erreichbar meint, die Motivation zu nutzen, die in Zielbildern steckt. Ein beabsichtigter Endzustand, so durch ein Ziel beschrieben, als ob er bereits eingetreten oder erreicht wurde, motiviert die Beteiligten. Werden konkrete Werte genannt, sollten diese ambitioniert sein, aber nicht überzogen; häufig wird hier eine Obergrenze dessen definiert, was angestrebt wird.

Realistisch/Relevant bedeutet, dass die Ziele und insbesondere deren Erreichung aktiv durch die Beteiligten beeinflusst werden kann. Bei konkreten Werten bilden diese häufig die Untergrenze dessen, was angestrebt wird.

Termingerecht meint, dass ein Zeitpunkt festgelegt wird, bis (spätestens) wann ein Ziel erreicht werden soll bzw. wann eine Zielerreichung gemessen werden soll.

Die Business-Analysten haben zusammen mit der Arbeitsgruppe einige Ziele mithilfe der SMART-Kriterien operationalisiert.

	Umsätze steigern	Modernisierung der IT- Hardware	Jüngere Kunden gewinnen
Spezifisch	Umsätze aller Möbelprodukte (ausgenommen Bistroumsätze)	Anschaffungszeitpunkt <3 Jahre	Kunden im Alter von 18-35 Jahren
Messbar	Gewinn- und Verlustrechnung	Inventarliste	Altersabfrage oder -schätzung an den Kassen
Attraktiv	+ 10 %	90 %	+ 20 % mehr jüngere Kunden als aktuell
Realistisch	+ 5 %	75 %	+ 10 %
Terminiert	31.12. des Folgejahres	30.06. des Folgejahres	in den nächsten 3 Monaten

Abb. 1.26: Ziele mit SMART-Kriterien

1.3.2.3 Ziele gewichten

Muss-Ziele sind als K.O.-Kriterien gesetzt (vgl. 1.3.2.2.2). Kann-Ziele allerdings haben in der Regel unterschiedliche Bedeutung. Diese Bedeutung schlägt sich in ihrer Gewichtung nieder. Die Gewichtung der Ziele kann an dieser Stelle der Business-Case-Erstellung erfolgen oder im Schritt „Empfehlung“ (vgl. Kapitel 1.5), in dem die Ziele den Lösungsansätzen gegenübergestellt werden.

Eine Gewichtung der Ziele in diesem Schritt Geschäftsanforderungen bringt den Vorteil mit sich, dass die Ziele unbeeinflusst von Lösungsansätzen gewichtet werden. Erfolgt die Gewichtung im Schritt Empfehlung, besteht die Gefahr, dass die Gewichtung mit den Lösungsansätzen „im Hinterkopf“ eventuell so ausfällt, dass ein favorisierter Lösungsansatz übervorteilt wird.

Zwei Techniken unterstützen dabei, Ziele zu gewichten:

 Stufenweise Gewichtung

 Präferenzmatrix.

Stufenweise Gewichtung

Eher intuitiv und damit sehr gebräuchlich ist es, ein Gesamtgewicht von 100 Punkten zu vergeben. Da dies 100 % entspricht, ist dies für die meisten Beteiligten leicht nachzuvollziehen.

Diese 100 Punkte werden dann auf die Kann-Ziele verteilt. In einem Top-Down-Vorgehen werden im ersten Schritt zunächst die Zielklassen gewichtet. Eine typische Verteilung ist: Wirtschaftliche Ziele 30 %, Leistungsziele 50 %, Kulturelle Ziele 20 %. Situativ können aber auch ganz andere Gewichtungen „richtig“ sein.

In einem zweiten Schritt werden die Punkte der Zielklasse auf die Ziele in der Zielklasse verteilt.

Wirtschaftliche Ziele: 45 %		Leistungsziele: 50 %		Kulturelle Ziele: 2 %		Vorgehensziele: 3 %
	Niedrige Investitionskosten für Infrastruktur: 15 %Niedrige Investitionskosten für Schulung: 5 %		Unabhängigkeit von Dritten: 2 %Leichte Verständlichkeit: 5 %Umfassende Informationen: 15 %		Betroffene beteiligen: 2 %		Schnelles Ergebnis: 3 %
	Niedrige laufende Personalkosten: 15 %Niedrige laufende Kosten für Fremdleistungen: 10 %		Attraktive Aufbereitung: 10 %Zukunftssichere Lösung: 5 %Schneller Zugriff: 5 %Ausfallsicherheit: 3 %Einfache Pflege der neuen Lösung: 5 %

Abb. 1.27: Zielstruktur mit gewichteten Zielen

Präferenzmatrix

Die Präferenzmatrix ist eine Technik, mit der jede Anforderung (oder jedes Ziel) mit jeder anderen Anforderung (oder mit jedem anderen Ziel) verglichen wird. Je öfter eine Anforderung „gewinnt“, desto wichtiger ist sie relativ zu anderen Anforderungen.

Durch paarweise Vergleiche werden die Ziele höher gewichtet, die häufiger als andere Ziele den jeweiligen Vergleich für sich entscheiden.

Die Erstellung und Auswertung der Präferenzmatrix erfolgt mit folgenden Schritten.

1. Detaillierungsebene wählen: Sinnvollerweise wenden Business-Analysten die Präferenzmatrix nicht auf der Ebene der drei oder vier Zielklassen an, sondern für die Ziele in den Zielklassen.

2. Ziele eintragen: Ziele aus der Zielstruktur in die Präferenzmatrix übernehmen. Je größer die Zahl der Ziele, desto umfangreicher wird die Präferenzmatrix. Von A aufsteigende Buchstaben dienen der platzsparenden Dokumentation und repräsentieren jeweils die Ziele in den folgenden Schritten.

3. Miteinander vergleichen und „Gewinner“ eintragen: Das präferierte der beiden Ziele bzw. das Ziel mit der höheren Bedeutung wird mit seinem Buchstaben eingetragen.

4. „Gewinner“ auszählen: Durch Zählen der Buchstaben wird die jeweilige Zahl der Nennungen ermittelt.

5. Prozentualen Anteil der gewonnenen Vergleiche ermitteln: Zahl der Nennungen durch die Gesamtzahl dividieren. Die Gesamtzahl der Vergleiche folgt dabei der Formel n*(n-1)/2.

6. Ggf. Gewichtung „glätten“: Da es bei jedem Vergleich nur einen Sieger gibt, kann die Gewichtung modifiziert werden. Zum einen ist eine Glättung sinnvoll, d.h. Nachkommastellen können gerundet werden. Zum anderen sind Abstufen von 5, 10, 15, 20 leichter für weitere Schritte zu nutzen als z.B. 4, 8, 13. Die Rangfolge der Ziele sollte von einer Glättung allerdings unbeeinflusst bleiben.

Abb. 1.28: Präferenzmatrix

Der paarweise Vergleich in der Präferenzmatrix aller 14 Zielen benötigt 91 Entscheidungen. 12 dieser Vergleiche kann das Ziel „Niedrige Infrastrukturkosten“ (repräsentiert durch den Buchstaben „a“) für sich entscheiden. Dies entspricht 13,2 % aller Entscheidungen. Dieser Wert wird auf 15 % modifiziert. Für 91 Vergleiche benötigen Business-Analysten einige Zeit. Bei 10 Zielen wären es nur 45 Paarvergleiche.

Die Präferenzmatrix kann auch als Technik zur Anforderungspriorisierung (vgl. Kapitel 2.4) im Konzept „Requirements Engineering“ dienen.

1.3.2.4 Zielstruktur entscheiden und im Business Case dokumentieren

Analog zum vorhergehenden Schritt Leistungspotenziale werden auch die Ergebnisse des Schritts Geschäftsanforderungen in den Business Case übernommen. Entweder direkt oder spätestens im Zusammenhang mit dem Schritt Empfehlung (vgl. Kapitel 1.5) sollte die Zielstruktur mit Muss-Zielen und gewichteten Kann-Zielen durch die Entscheider abgenommen werden, um Input für die weiteren Schritte liefern zu können.

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.

Systemkontext		Grauzone		Irrelevante Umgebung
	LogistikWarenwirtschaftssystemBestehendes ProduktsortimentPreiseGeschäftsprozesse in den FilialenInhaberDienstleister, Lieferanten		MarketingAGBFiliallagerRatenkauf der Möbel mit einer PartnerbankStammdatenmanagement		ImbissNeues ProduktsortimentRenovierung der FilialenGebäudemanagement

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.

Supplier	Input	Process	Output	Customer
Kunde	Kaufwunsch	Möbel bestellen	Bestellformular	Verkäufer
Zentraler Einkauf	Bedarfsmeldung	Bestellvorschlag erstellen	Bestellung	Lieferant
Lieferant	Auftragsbestätigung	Auftragsbestätigung klären	Auftragsbestätigung	Filiallager, Buchhaltung
Lieferant	Auftragsbestätigung	Liefertermin bestätigen	Liefertermin	Kunde, Verkäufer
Lieferant	Ware	Wareneingang prüfen	Wareneingang	Verkäufer
Lieferant	Rechnung	Rechnung bezahlen	Geld	Lieferant
Kunde	Abholschein	Möbel abholen und bezahlen	Möbel, Rechnung	Kunde

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