Business-Analyse – einfach und effektiv E-Book

Inge Hanschke

• Herausgeber: Carl Hanser Verlag GmbH & Co. KG
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Seitenzahl: 476

Beschreibung

- Systematische und durchgängige Darstellung der Tätigkeit der Business-Analyse und der Disziplin Demand Management
- Strategische, taktische und operative Planungsebene in ihrem Zusammenspiel
- Durchgängiges Praxisbeispiel
- Sammlung von Best-Practices für die Business-Analyse und die Werkzeugunterstützung sowie organisatorische Verankerung des Demand Management
- Ausführliche Beschreibung der Ergebnistypen der Business-Analyse mit Tipps und Tricks für die Nutzung inklusive Business-Case-Betrachtung
- Schritt-für-Schritt-Anleitung für die Ableitung von Business-Services
- Ihr exklusiver Vorteil: E-Book inside beim Kauf des gedruckten Buches

Unternehmen müssen in der Lage sein, sich zu verändern und an die jeweiligen Markt- und Wirtschaftsbedingungen schnell anzupassen. Die Tätigkeit der Business-Analyse und deren organisatorische Verankerung im Demand Management sind wesentliche Erfolgsfaktoren dafür. Die erforderlichen Veränderungen werden erkannt, fachlich gestaltet und umgesetzt. Das Projektportfolio sowie die einzelnen Projekte und Wartungsmaßnahmen werden an den Geschäftserfordernissen ausgerichtet und die Produktivität bei der Umsetzung wird gesteigert. Anzahl und Umfang von Geschäftsanforderungen werden durch frühzeitige Prüfung auf Nutzen, Konsistenz und Wichtigkeit deutlich reduziert. Unnötige Doppelarbeiten und wertvernichtende Projekte werden vermieden. So entstehen Freiräume für strategische Vorhaben.

Wir stellen in diesem Buch Grundlagen und Best-Practices zur Durchführung der Business-Analyse bereit und helfen Ihnen, das Demand-Management bei klassischem und agilem Vorgehen mit Leben zu füllen.

AUS DEM INHALT //
Einleitung/Einführung in die Business-Analyse/Von der Geschäftsanforderung zum IT-Projekt/Best-Practices der Business-Analyse/Ergebnistypen der Business-Analyse/Business Capability Management & Business-Services

Leseprobe

Inge HanschkeDaniel Goetze

Business-Analyse – einfach und effektiv

Geschäftsanforderungen verstehen und in IT-Lösungen umsetzen

3., überarbeitete und erweiterte Auflage

Ihr Plus – digitale Zusatzinhalte!

Auf unserem Download-Portal finden Sie zu diesem Titel kostenloses Zusatzmaterial.

Geben Sie auf plus.hanser-fachbuch.de einfach diesen Code ein:

plus-A2e93-Kiz8m

Alle in diesem Werk enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Werk enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autor*in und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebenso wenig übernehmen Autor*in und Verlag die Gewähr dafür, dass die beschriebenen Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt also auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.Die endgültige Entscheidung über die Eignung der Informationen für die vorgesehene Verwendung in einer bestimmten Anwendung liegt in der alleinigen Verantwortung des Nutzers.

Aus Gründen der besseren Lesbarkeit wird auf die gleichzeitige Verwendung der Sprachformen männlich, weiblich und divers (m/w/d) verzichtet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Bibliografische Information der Deutschen Nationalbibliothek:Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Dieses Werk ist urheberrechtlich geschützt.Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.

© 2024 Carl Hanser Verlag München, www.hanser-fachbuch.deLektorat: Brigitte Bauer-SchiewekCopy editing: Petra Kienle, FürstenfeldbruckUmschlagdesign: Marc Müller-Bremer, www.rebranding.de, MünchenUmschlagrealisation: Max KostopoulosSatz: Eberl & Koesel Studio, Kempten

Print-ISBN:        978-3-446-47396-6E-Book-ISBN:   978-3-446-47924-1E-Pub-ISBN:     978-3-446-47970-8

Inhalt

Titelei

Impressum

Inhalt

Vorwort

1 Einleitung

2 Einführung in die Business-Analyse

2.1 Business-Analyse, was ist das?

2.2 Demand Management, was ist das?

2.2.1 Business-IT-Koordination

2.2.2 Fachliche Themenplanung (Budgetierung)

2.2.3 Aufnehmen, Gestalten und Planen

2.2.4 Fachliches Steuern der Umsetzung

2.2.4.1 Initiieren von Projekten

2.2.4.2 Fachliches Steuern innerhalb von Projekten

2.2.4.3 Fachliches Steuern bei Wartungsmaßnahmen

2.2.4.4 Fachliches Steuern bei der Störungsbehebung über Tickets

2.3 Einordnung und Abgrenzung des Demand Management

2.4 Organisatorische Verankerung

2.4.1 Angemessene Organisation

2.4.2 Schlanke Demand-Management-Prozesse

2.4.3 Systematischer und gesteuerter Einführungs- und Veränderungsprozess

3 Von der Geschäftsanforderung zum IT-Projekt

3.1 Eine neue Chance für EasyHouse

3.1.1 Welche Produkte stellt EasyHouse her?

3.1.2 Ein neues Vertriebsmodell im „O-Ton Kunde“

3.2 Der Business-Analyse-Prozess

3.2.1 Ziele

3.2.2 Stakeholder finden

3.2.3 Erste Iteration zur Strukturierung der Geschäftsanforderungen: Themenbereiche finden

3.2.4 Prozessanalyse

3.2.4.1 Geschäftsprozesse und Teil-Geschäftsprozesse

3.2.4.2 Swimlane-Diagramme

3.2.4.3 Prozessablauf-Diagramme

3.2.5 Use-Case-Analyse und Analyse der fachlichen Strukturierung

3.2.5.1 Use-Cases

3.2.5.2 Fachliches Komponentenmodell

3.2.5.3 Fachliches Klassenmodell

3.2.6 Zweite Iteration zur Strukturierung der Geschäftsanforderungen: Features und Teil-Features ableiten, priorisieren und bündeln

3.3 Bewerten und planen

3.4 Fachliches Steuern der Umsetzung

3.4.1 Umsetzungsprojekt beantragen

3.4.2 Fachliches Steuern im Rahmen der Projektabwicklung

4 Best-Practices der Business-Analyse

4.1 Detaillierungsebenen von Geschäftsanforderungen

4.2 Das Reifegradmodell für die Business-Analyse

4.3 Best-Practice-Bausteine der Business-Analyse

4.3.1 Business-IT-Koordination

4.3.1.1 Anforderungen vermitteln

4.3.1.2 Priorisierung und Planung transparent machen

4.3.1.3 Komplexität transparent machen

4.3.2 Unterstützung bei der Budgetierung

4.3.2.1 Budgetierungsverfahren

4.3.2.2 Budgetfreigabe und Budgetsteuerung

4.3.3 Ableiten strategischer Geschäftsanforderungen

4.3.4 Aufnehmen, Gestalten und Planen

4.3.4.1 Geschäftsanforderung in Detaillierungsebenen einordnen

4.3.4.2 Planungsebenen

4.3.4.3 Einordnung der Business-Analyse in die Planungsebenen

4.3.4.4 Features ableiten

4.3.4.5 Features detaillieren und zerlegen

4.3.4.6 Features bewerten und priorisieren

4.3.4.7 Zusammenspiel mit EAM

4.3.4.8 Zusammenspiel mit dem Prozessmanagement

4.3.5 Fachliches Steuern der Umsetzung

4.3.5.1 Zusammenspiel mit Projekten

4.3.5.2 Agiler Festpreis

4.3.5.3 Release-Inhalte in Modellen abbilden

4.3.6 Werkzeugunterstützung für die Business-Analyse

4.3.6.1 Werkzeuge für die Business-Analyse auswählen

4.3.7 Organisatorische Verankerung

4.3.7.1 Verankerung in der Aufbauorganisation

4.3.7.2 Integration in Entscheidungsprozesse

4.3.7.3 Das Kompetenzprofil des Business-Analysten

5 Ergebnistypen der Business-Analyse

5.1 Die Ergebnistypen im Überblick

5.1.1 Die Ergebnistypen im Kontext agiler Vorgehensweisen

5.2 Die Ergebnistypen im Detail

5.2.1 Prozesslandkarte

5.2.2 Swimlane-Diagramm

5.2.3 Prozessablauf-Diagramm

5.2.4 Fachliches Komponentenmodell

5.2.5 Use-Case

5.2.5.1 Use-Case-Beschreibung

5.2.5.2 Aktivitätsdiagramm

5.2.5.3 GUI-Mockup

5.2.6 Fachliches Klassenmodell

5.2.7 Anforderungsliste

5.2.8 Portfolio-Grafik

5.2.9 Masterplan-Grafik

5.2.10 Burndown-Chart

5.2.11 Projektantrag

6 Business Capability Management & Business-Services

6.1 Business Capabilities und Business Capability Management

6.1.1 Business Capabilities und Geschäftsanforderungen

6.1.2 Initiales Ableiten der Business Capabilities

6.2 Serviceorientierte Architekturen

6.2.1 Top-down-versus Bottom-up-Ableitung

6.2.2 Ableitung von Business-Services in Projekten

Glossar

Literatur

Vorwort

„Nichts auf der Welt ist so mächtig wie eine Idee, deren Zeit gekommen ist.“

Victor Hugo (1802 – 1885)

Unternehmen müssen in der Lage sein, sich zu verändern und an die jeweiligen Markt- und Wirtschaftsbedingungen schnell anzupassen. Damit das gelingt, müssen strategische und operative Geschäftsanforderungen identifiziert und die Organisation, Prozesse, Produkte und/oder Systeme des Unternehmens entsprechend verändert werden. Manchmal sind es nur kleine Schritte, manchmal aber auch drastische Einschnitte. Die Veränderung muss geplant und gesteuert werden. Unternehmen, die diese Prozesse vernachlässigen, können auf Dauer nicht überleben.

Die Tätigkeit der Business-Analyse und deren organisatorische Verankerung in einer oder mehreren Demand-Management-Einheiten sind hierfür wesentliche Erfolgsfaktoren. Mit ihrer Hilfe werden die erforderlichen Veränderungen erkannt, fachlich gestaltet und die Umsetzung fachlich gesteuert. Projekte und Wartungsmaßnahmen werden an den Geschäftserfordernissen ausgerichtet und die Produktivität bei der Umsetzung wird gesteigert. Die Anzahl und der Umfang von Geschäftsanforderungen werden durch frühzeitige Prüfung auf Sinn, Konsistenz und Wichtigkeit deutlich reduziert. Unnötige Doppelarbeiten und wertvernichtende Projekte werden vermieden. So werden Freiräume für strategische Vorhaben geschaffen.

Dies gilt insbesondere auch für agile Projekte und Agilität im Großen. Gerade für agile Projekte sind das schnelle und systematische Erkennen der wirklichen Anforderungen und die Gestaltung handhabbarer Umsetzungspakete erfolgsentscheidend.

Dies hört sich in der Theorie einfach an. In der Praxis fristet aber die Business-Analyse in vielen Unternehmen noch ein Mauerblümchen-Dasein. Die Gründe für die stiefmütterliche Behandlung sind vielfältig. Das sind einige davon:

       Fehlendes Bewusstsein für die Relevanz der Business-Analyse im UnternehmenDurch eine professionelle Business-Analyse können enorme Einsparungen erzielt und das Unternehmen zielgerichtet weiterentwickelt werden. Viele Fehlentscheidungen und unnötige Investitionen werden vermieden, wenn die wirklichen Geschäftsanforderungen frühzeitig erkannt und entsprechend der Geschäftserfordernisse umgesetzt werden. Dieser Mehrwert muss im Unternehmen erst erkannt werden, um die Business-Analyse über einen nachhaltigen Veränderungsprozess im Unternehmen schrittweise zu verankern.

       Unzureichende Skills oder fehlende Akzeptanz der Business-AnalystenDie Anforderungen an die Hauptakteure der Business-Analyse, die Business-Analysten, sind sehr hoch. Neben fundiertem Fach- und Branchenwissen, einem soliden IT-Background und Modellierungsexpertise benötigen sie viel Kommunikations- und Organisationsgeschick, ausgeprägte soziale Fähigkeiten, umfangreiche analytische Kenntnisse sowie ein hohes Maß an Kreativität.

Ein Business-Analyst muss einerseits verstehen, was der Kunde (das Business) wirklich braucht. Andererseits muss er Lösungsvorschläge unterbreiten, die technisch auch umsetzbar sind. Dafür muss er sowohl mit dem Business als auch mit der IT in eine intensive Kommunikation treten und die Geschäftsanforderungen so formulieren können, dass alle Beteiligten sie verstehen. Wegen der Fülle und Komplexität von Geschäftsanforderungen und aufgrund der unterschiedlichen Sichten der Beteiligten gestaltet sich das oft nicht ganz einfach. Das Wesentliche muss vom Business-Analysten identifiziert und in prägnanten Business- oder/und IT-Modellen als Grundlage für Diskussionen sowie Budget- oder Projektentscheidungen dokumentiert werden.

Die Business-Analysten haben zudem häufig damit zu kämpfen, dass es keine klare Rollenbeschreibung für ihr Aufgabengebiet gibt. Ist ihr Verantwortungs- und Entscheidungsbereich nicht klar geregelt, können sie ihre Aufgaben nicht zielführend wahrnehmen.

       Papierberge und Formalien anstelle prägnanter ModelleAnforderungsdokumente sind häufig sehr umfangreich und werden daher vom Fachbereich und den Umsetzungseinheiten nicht oder nur teilweise gelesen. So wird die Abnahme zu einem sinnlosen formalen Akt. Man glaubt, sich mit Papierbergen abzusichern, doch der Anforderungssteller weiß häufig nicht wirklich, was er „beauftragt“. Wesentliche Annahmen, Randbedingungen und Geschäftsanforderungen sowie deren Abhängigkeiten und Auswirkungen sind in den Papierbergen nicht erkennbar. Das Nachvollziehen von Veränderungen und deren Auswirkungen ist nahezu unmöglich.

       Für klassische Organisationen: nicht vorhandenes oder verbesserungswürdiges Demand ManagementIn vielen Unternehmen ist inzwischen klar, dass die Business-Analyse wichtig ist, um die Ziele zu erreichen. Eine separate Demand-Management-Disziplin, Organisationseinheit oder Stabstelle gibt es aber nicht immer. Und selbst wenn ein Demand Management aufgesetzt ist, sind dessen Aufgaben, Zusammenspiel mit und Abgrenzung zu anderen Disziplinen, wie z.B. das Prozess-, Projektportfolio- oder Anforderungsmanagement in Projekten, häufig nicht klar geregelt. Wenn die Business-Analysten nur unzureichend in die Prozesse und Organisation integriert sind, haben sie keinen oder zu wenig Einfluss auf die Planungs-, Abwicklungs- und Entscheidungsprozesse.

       Für agile Organisationen: unzureichende Nutzung von Business-Analyse-Best-Practices in der Inkrementplanung oder im Backlog GroomingEin Beispiel hierfür ist das agile Planen. Agiles Planen und die Beschränkung auf eine handhabbare Dokumentation der Geschäftsanforderungen in der für den jeweiligen Planungshorizont angemessenen Granularität ist häufig entweder auf der Product-Owner- oder aber der Scrum-Team-Seite noch nicht präsent. Dies führt zu erheblichen Aufwänden wie in klassischen Wasserfallprojekten

       Kein systematisches Vorgehen für die Identifikation und das Management von GeschäftsanforderungenWenn geeignete Methoden und Werkzeuge nicht zur Verfügung stehen, kann der Business-Analyst seine Aufgaben nicht oder nur unzureichend wahrnehmen. Insbesondere Anforderungsmanagement-Methoden werden dann in jedem Projekt immer wieder „neu erfunden“. Hier hat man zwar ein projektspezifisches quasi-systematisches Vorgehen. Anforderungen sind aber nicht projektübergreifend sinnvoll nutzbar und konsolidierbar.

Diese und manch andere Gründe führen dazu, dass die Ausgangslage für die Business-Analyse nicht optimal ist. Zudem fehlen direkt nutzbare Hilfestellungen. In der Literatur findet man zwar umfangreiche Informationen zum Anforderungsmanagement in Projekten. Die Schnittstelle zwischen dem Business und der IT und die Business-Analyse im Vorfeld von Projekten sind jedoch nur spärlich repräsentiert. Eine wirkliche Unterstützung für die Business-Analysten wird nicht gegeben.

Diese Lücke möchten wir mit diesem Buch schließen. Wir möchten ein einfaches und effektives Instrumentarium für die Business-Analyse bereitstellen und Ihnen helfen, die Demand-Management-Disziplin mit Leben zu füllen.

Einfachheit ist uns deshalb so wichtig, weil sie in der Business-Analyse unabdingbar ist, einerseits wegen der Fülle und Komplexität von Geschäftsanforderungen, andererseits aufgrund der Vielzahl von Beteiligten. Die wesentlichen Aussagen müssen klar, übersichtlich und prägnant in Business- oder/und IT-Modellen, zugeschnitten auf die Bedürfnisse der jeweiligen Beteiligten, dokumentiert werden. Prägnante Modelle sind eine wesentliche Grundlage für Abstimmungen und Budget- oder Projektentscheidungen. Unnötiger Ballast muss abgeworfen werden, da komplexe und überladene Darstellungen regelrecht kontraproduktiv wirken. Mehrdeutige oder unklare Aussagen führen häufig zu völlig unbeabsichtigten Schlussfolgerungen, was letztendlich verheerende Fehlentscheidungen bewirken kann. Papierberge zu erstellen, kostet zudem eine Menge Geld und Zeit; ein Großteil ist häufig verschwendet und dient nur der Absicherungskultur. Mit Einfachheit geht in der Regel also auch Effizienz einher.

Einfachheit alleine genügt aber nicht, Effektivität ist genauso wichtig: Es kommt ganz wesentlich darauf an, die richtigen Dinge zu tun. Die Herausforderungen des Marktes und die relevanten operativen und strategischen Geschäftsanforderungen müssen erkannt und die richtigen Schritte eingeleitet werden. Lücken, Redundanzen und Synergien müssen identifiziert und die Prozesse, die Organisation, die Produkte und die IT-Systeme des Unternehmens durch z.B. Automatisierung, Individualisierung, End-to-end-Prozesse oder Standardisierung optimiert oder strategisch neu ausgerichtet werden.

In diesem Buch stellen wir die Methode GAME2 vor, mit der Sie einfach und effektiv Geschäftsanforderungen analysieren und managen können. Wir wollen damit einen Beitrag dazu leisten, dass Business-Analysten den hohen Anforderungen gerecht werden können, die an sie gestellt werden. Ein wesentlicher Bestandteil der Methode ist eine Sammlung von Best-Practices mit Nutzungshinweisen und Schritt-für-Schritt-Anleitungen von der Identifikation, Aufnahme und Bündelung bis zur fachlichen Planung, Bewertung und Steuerung der Umsetzung der Geschäftsanforderungen. Die Best-Practices wurden aus unseren Erfahrungen in der Business-Analyse und den Erkenntnissen aus dem intensiven Austausch mit einer großen Zahl von Experten sowohl aus Anwenderunternehmen und Beratungshäusern als auch aus der Wissenschaft konsolidiert. Darüber hinaus geben wir Ihnen Hilfestellungen, Ihre Business-Analyse aus den Best-Practice-Bausteinen zu einem stimmigen und gleichzeitig überschaubaren großen Ganzen zusammenzusetzen. So können Sie einfach und effektiv in die Business-Analyse einsteigen und Ihr spezifisches Demand Management ableiten.

Neu in der dritten Auflage

Neu in der dritten Auflage sind die Agilität im Großen und die Unterstützung der strategischen und taktischen IT-Planung.

Der digitale Wandel und die Zeiten des Umbruchs mit u.a. Energiekrise erfordern eine agile Business-Analyse mit aktiver Gestaltung und Treiben des digitalen Wandels und schnellen Antworten für dringende strategische, taktische oder operative fachliche Entscheidungsbedarfe. Verzahnt mit der Geschäftsmodellentwicklung und dem strategischen Enterprise Architecture Management dienen fachliche Ziel-Bilder, High-Level-Designs und Roadmaps zur Umsetzung als Vision und Leitplanken für die taktische und operative Umsetzung.

Eingebettet in der Agilität im Großen oder aber in klassischen Organisationen müssen schnell die wirklichen Anforderungen erkannt, fachliche Lösungen gestaltet und für die nächsten Umsetzungsinkremente oder Iterationen die Anforderungen konfektioniert werden.

Danksagung

Vielen Dank an die Diskussionspartner und Reviewer aus unterschiedlichen Unternehmen für den intensiven Austausch und die vielen Feedbacks.

Bedanken möchten wir uns auch beim Hanser Verlag, insbesondere bei Brigitte Bauer-Schiewek und Kristin Rothe, für ihr wertvolles Feedback und die vielen wichtigen Hinweise sowie bei den anderen Kolleginnen für die schnelle und sehr gute Unterstützung bei der Gestaltung.

Nichts ist kostbarer als die Zeit, die wir mit geliebten Menschen verbringen. Ein ganz besonderer Dank gilt daher diesen Menschen: unseren Familien und Freunden, die uns den Rücken freigehalten und uns durch Feedback tatkräftig unterstützt haben.

München, im Februar 2024

Inge Hanschke und Daniel Goetze

1Einleitung

„Wenn ich meine Kunden nach ihren Wünschen gefragt hätte, dann hätten sie mir gesagt,dass sie gern stärkere Pferde für ihre Kutschen hätten.“

Henry Ford (1863 – 1947)

Der Digitale Wandel, die Pandemie, die Energiekrise, zunehmender Wettbewerb von neuen Marktteilnehmern, steigende Vernetzung, immense regulatorische Vorgaben und kürzer werdende Innovations- und Time-to-Market-Zyklen stellen hohe Anforderungen an die Effizienz und die Agilität der Unternehmen. Um auf Dauer wettbewerbsfähig zu bleiben, müssen sie in der Lage sein, die relevanten Geschäftsanforderungen zu identifizieren und dann schnell und zuverlässig zu überschaubaren Kosten umzusetzen.

Dies hört sich in der Theorie sehr einfach an. In der Praxis sehen Sie sich jedoch insbesondere mit folgenden Fragen konfrontiert:

       Wie erkennen Sie die wirklichen Geschäftsanforderungen?

       Wie finden Sie angemessene Lösungsvorschläge und was müssen Sie dabei berücksichtigen?

       Wie können Sie die richtigen Schritte zu deren Umsetzung anstoßen?

       Wie stellen Sie sicher, dass die Umsetzung auch wie gewünscht erfolgt?

Das Zitat von Henry Ford trifft den Kern der ersten Frage. Kunden und Fachbereiche beschreiben häufig in ihren Anforderungen konkrete Lösungsansätze und nicht das Ziel, das sie erreichen wollen. Sie haben zwar die Vision vor Augen „schneller am Zielort ankommen“, drücken das aber in der Lösung „stärkere Pferde“ aus. Hätte Ford dieses Ziel verfolgt, wäre sein Lösungsraum so eingeschränkt gewesen, dass er vermutlich nie ein Auto entwickelt hätte.

Doch auch das Finden angemessener Lösungsvorschläge ist nicht einfach. Das Entwerfen einer Lösung ist ein hochgradig kreativer und kommunikativer Prozess. Lösungsszenarien sind in einer interdisziplinären Zusammenarbeit zwischen fachlichen und technischen Experten zu entwickeln und zu bewerten. Welche Lösungsszenarien identifiziert werden, hängt sehr stark von der Erfahrung, den Interessen und dem Kontext der handelnden Personen ab.

Die Forderung von Angemessenheit, d.h. ein passendes Kosten-Nutzen-Verhältnis, kompliziert das Ganze noch weiter. Jedes Lösungsszenario muss diesbezüglich zumindest grob bewertet werden. Die Lösungsszenarien bieten gegebenenfalls weitere ursprünglich nicht geforderte Anwendungsmöglichkeiten, wie z.B. „Übernachten im Auto“. Diese neuen Chancen müssen in der Bewertung mit betrachtet werden.

Hat man schließlich eine inhaltlich und wirtschaftlich sinnvolle Lösung gefunden, muss diese natürlich auch umgesetzt werden. Hierfür sind ein organisatorischer Rahmen und ein Governance-Instrumentarium erforderlich, die einen ausreichenden Einfluss auf Entscheidungen schaffen. Dies ist nur über entsprechende Rollen, Verantwortlichkeiten, Gremien und Prozesse realistisch möglich.

In diesem Buch beschreiben wir mit der Methode GAME2 – „Geschäftsanforderungen analysieren und managen – einfach und effektiv“ – unmittelbar anwendbare Hilfestellungen für die beschriebenen Fragestellungen. Wir liefern Ihnen ein leicht handhabbares Instrumentarium für die Business-Analyse, das Ihnen hilft, die Herausforderungen des Markts zu erkennen, die Geschäftsanforderungen aufzunehmen, die richtigen Maßnahmen einzuleiten und deren Umsetzung zu forcieren. Damit können Sie diese komplexen Aufgaben bewältigen. Wir stellen Ihnen prägnante Business- und/oder IT-Modelle vor, die auf die Bedürfnisse der Stakeholder zugeschnitten sind und mit deren Hilfe die Kommunikation mit den unterschiedlichen Stakeholdern und der fachliche Lösungsentwurf einfacher oder überhaupt erst möglich werden. Zudem geben wir Ihnen Best-Practices für die typischen Themenstellungen an die Hand, die Sie individuell entsprechend Ihrer Bedürfnisse wählen und kombinieren können. Darüber hinaus zeigen wir auf, wie das Demand Management mit dem Anforderungsmanagement in Projekten zusammenspielt und organisatorisch verankert werden kann.

Wegweiser durch das Buch

In Bild 1.1 finden Sie die Kapitelstruktur dieses Buchs. Sie können die Kapitel in der vorgegebenen Reihenfolge oder aber auch selektiv lesen. Sie sind inhaltlich in sich abgeschlossen.

Bild 1.1Kapitelstruktur dieses Buchs

Kapitel 2 führt in die Tätigkeit der Business-Analyse und die Disziplin Demand Management ein. Sie erhalten einen Überblick über das Instrumentarium der Business-Analyse, den Aufgabenbereich des Demand Management und dessen organisatorische Einbettung.

Kapitel 3 zeigt anhand eines Praxisbeispiels das Vorgehen in der Business-Analyse. Ausgehend von einer exemplarischen Geschäftsanforderung des fiktiven Unternehmens Easy-House werden die wesentlichen Aufgaben, die Ergebnisse und das Vorgehen von der ersten Idee bis zur Umsetzung in einem IT-Projekt erläutert.

Kapitel 4 liefert eine Sammlung von Best-Practices für die Business-Analyse und die organisatorische Verankerung des Demand Management. Sie finden Hilfestellungen für alle wesentlichen Aufgabenbereiche und Anwendungskontexte der Business-Analyse; unter anderem auch für agile Vorgehensweisen. Anhand eines Reifegradmodells und der Ausrichtung sowie der Einordnung in die Planungsebenen können Sie schnell die Anwendbarkeit einzelner Best-Practice-Bausteine für Ihren Kontext prüfen.

In Kapitel 5 werden die Ergebnistypen der Business-Analyse vorgestellt. Für jeden Ergebnistyp, wie z.B. Prozesslandkarte, fachliches Komponenten- und Klassenmodell oder Use-Case, werden dessen Inhalte, Adressaten, Zweck und weitere Aspekte sowie Tipps und Tricks für die Nutzung ausführlich beschrieben.

In Kapitel 6 finden Sie im Hinblick auf die Bedeutung vom Business Capability Management und der Serviceorientierung eine Schritt-für-Schritt-Anleitung für die Ableitung von Business-Services (Business Capabilities) mit praktischen Beispielen und Hilfestellungen für das Tailoring für Ihren Kontext.

In jedem Kapitel finden Sie zahlreiche Literaturhinweise, die Ihnen Empfehlungen zur Vertiefung des jeweiligen Themas geben. Darüber hinaus werden in einem umfangreichen Glossar alle wesentlichen Begriffe aus der Business-Analyse erläutert.

Wer sollte dieses Buch lesen?

Wir wenden uns mit diesem Buch im Wesentlichen an Business-Analysten im Demand Management sowie an Business- und IT-Verantwortliche und Stabsstellen. Sie und auch Business-Planer, Leiter Organisation, Unternehmensarchitekten, Prozessmanager, Projektportfolio-Manager, Projektleiter und -mitarbeiter sowie Controller und Compliance- oder Sicherheitsverantwortliche erhalten Antworten auf wichtige Fragen:

       Business-Analysten im Demand Management

       Wie sieht ein wirksames Instrumentarium zum Management von Geschäftsanforderungen aus? Wie werden Geschäftsanforderungen identifiziert, aufgenommen, klassifiziert, fachlich geplant, gebündelt, bewertet sowie die Umsetzung geplant und gesteuert?

       Welche Skills benötigen Business-Analysten?

       Wie kann das Demand Management zum Fliegen gebracht werden?

       Stabsstellen der Unternehmensführung (CxO)

       Wie kann die Business-Analyse bei der Unternehmensplanung, Festlegung der langfristigen Ziele und Rahmenbedingungen, der Planungs- und Kontrollsysteme sowie der Unternehmensorganisation und -steuerung unterstützen?

       Wie kann mit Hilfe des Demand Managements sichergestellt werden, dass in der Umsetzung eine Balance aus strategischen und operativen Geschäftsanforderungen erreicht wird, um einerseits einen zuverlässigen Geschäftsbetrieb zu gewährleisten und andererseits das Unternehmen strategisch weiterzuentwickeln?

       Business-Planer

       Wie kann die Business-Analyse bei der Weiterentwicklung des Geschäftsmodells sowie bei der strategischen Planung unterstützen?

       Welcher fachliche Input für die Business-Planung wird vom Demand Management bereitgestellt?

       Wie können Geschäftsanforderungen aus der Unternehmensstrategie abgeleitet werden?

       Welche Abhängigkeiten und Auswirkungen bestehen bei Veränderungen im Business?

       Leiter Organisation (Synonym: Orga-Leiter)

       Wie kann das Demand Management bei der Weiterentwicklung der Aufbau- und Ablauforganisation unterstützen?

       Welcher fachliche Input wird für die Organisationsentwicklung geliefert? Wie werden Handlungsbedarf und Optimierungspotenzial, wie z.B. organisatorische Redundanzen oder Brüche, aufgedeckt?

       Business-Verantwortliche (Fachbereichsleiter und Key-User)

       Wie können die Geschäftsanforderungen des Fachbereichs wirksam gemanagt werden?

       Wo ist das Demand Management organisatorisch angesiedelt?

       Wie kann man erkennen, welche Geschäftsanforderungen „wichtig“ oder „dringend“ sind? Welche Abhängigkeiten und Risiken bestehen?

       Welche fachlichen Alternativen gibt es bei der Umsetzung der Geschäftsanforderungen?

       Welche Auswirkungen haben Geschäftsanforderungen auf Organisation und Prozesse?

       Wie sieht die Priorisierung der Geschäftsanforderungen aus?

       Welche Geschäftsanforderungen sind budgetiert?

       Wie ist der Status der Umsetzung der Geschäftsanforderungen?

       Welche Auswirkungen haben Change Requests auf die fachlichen Ziele und die verabschiedeten Budgets?

       Unternehmensarchitekten und Prozessmanager

       Wie spielen Demand Management und EAM beziehungsweise Prozessmanagement zusammen?

       Wer ist für die fachliche Planung verantwortlich: EAM oder Demand Management? Prozessmanagement oder Demand Management?

       Welchen Input liefert das Demand Management für EAM oder das Prozessmanagement?

       Compliance- oder Sicherheitsverantwortliche

       Wie werden Dokumentationspflichten und die Ordnungsmäßigkeit der Prozesse und Systeme zur Umsetzung von Compliance- oder Sicherheitsanforderungen sichergestellt?

       Controller

       Wie können die Entscheidungsprozesse und insbesondere der Budgetierungsprozess durch das Demand Management unterstützt werden?

       Projektportfolio-Manager

       Welchen Input kann das Demand Management für die Bewertung von Projektanträgen und die Analyse von fachlichen Abhängigkeiten und Auswirkungen geben?

       Welche Geschäftsanforderungen werden in welchem Projekt umgesetzt?

       Welche fachlichen Auswirkungen haben Veränderungen im Projektportfolio?

       Werden die Budgets bestimmungsgemäß verwendet?

       IT-Verantwortliche (CIOs, Verantwortliche für „Build“- und „Run“-Einheiten und -Systeme) sowie IT-Stabsstellen

       Wie kann die Business-Analyse bei der Planung und Steuerung der IT unterstützen?

       Wie spielen das Anforderungsmanagement in Projekten und das Demand Management zusammen?

       Welchen Herausforderungen muss sich ein CIO aktuell stellen? Wie hilft das Demand Management bei der Bewältigung dieser Herausforderungen?

       Wo ist das Demand Management organisatorisch angesiedelt?

       Projektleiter und -mitarbeiter

       Welchen Input kann das Demand Management für die Projektabwicklung geben?

       Welche Geschäftsanforderungen werden in welchem Projekt umgesetzt? Welche Abhängigkeiten bestehen? Welche Auswirkungen gibt es?

       Wie spielen das Demand Management und das Anforderungsmanagement in Projekten zusammen?

       Auf welcher Basis erfolgt die fachliche Abnahme in Projekten?

       Wie werden Change Requests fachlich eingeplant? Wer kümmert sich um die erforderlichen Budgets?

Zusatzmaterial

Unter

https://plus.hanser-fachbuch.de/

finden Sie ein integriertes Modell mit weiteren exemplarischen Diagrammen zum Beispiel in Kapitel 3.

Geben Sie dazu folgenden Code ein:

plus-A2e93-Kiz8m

Abgrenzung und weiterführende Literatur

Der Schwerpunkt dieses Buchs liegt in der Beschreibung der wesentlichen Inhalte und Aufgaben der Tätigkeit Business-Analyse im Kontext der Disziplin Demand Management. Hier geht es vor allen Dingen um die übergreifende fachliche Analyse und Gestaltung im Vorfeld sowie zur Steuerung von Projekten. Die Schnittstelle zwischen Demand Management und Projekten wird explizit beschrieben. Das Vorgehen beim Anforderungsmanagement in Projekten und Software-Produktlinien wird hier nur gestreift. Für Details zum Anforderungsmanagement in Projekten sei auf [Ebe10], [Poh08] und [Rup09] verwiesen. Weitere Informationen zu Software-Produktlinien finden Sie in [Boe04] und [Bos00].

Da die Business-Analyse im Wesentlichen im Vorfeld und im Kontext von Projekten und Wartungsmaßnahmen stattfindet, wird im Buch nur auf die Schnittstelle zwischen dem Demand Management und dem IT-Servicemanagement im IT-Betrieb eingegangen. Weitere Informationen zu dieser Disziplin finden Sie in [Ebe08], [Buc07] und [Joh11].

Angrenzende Disziplinen, wie z.B. das Projektportfoliomanagement, das Prozessmanagement, das Enterprise Architecture Management oder die Produktentwicklung werden kurz eingeführt. Für weiterführende Informationen sei beim Projektportfoliomanagement auf [Hir11] und [Sei11], beim Prozessmanagement auf [Fis10] und [HLo21], beim Enterprise Architecture Management auf [Han22] und [Bit11] sowie bei der Produktentwicklung auf [Gau09] und [Ker08] verwiesen.

2Einführung in die Business-Analyse

„Menschen, die es verstehen, uns zu verstehen, sind Geschenke des Himmels.“

Ernst Ferstl, (*1955), österreichischer Lehrer, Dichter und Aphoristiker

Die Fülle, Änderungsrate und Komplexität der Geschäftsanforderungen nehmen infolge der schnellen Veränderungsgeschwindigkeit aufgrund von Digitalisierung, Krisen, Vernetzung zwischen Unternehmen und kürzer werdenden Innovations- und Time-to-Market-Zyklen immer weiter zu. Die Geschäftsanforderungen zu verstehen und in adäquate IT-Lösungen umzusetzen, ist nicht einfach. Kein Wunder also, dass das in vielen Unternehmen nicht optimal gelingt. Um diesen Prozess zu verbessern, müssen sowohl strategische als auch operative Geschäftsanforderungen ganzheitlich und systematisch gemanagt werden.

Vermittler zwischen den fachlichen und technischen Welten, die Business-Analysten (siehe Bild 2.1 und Abschnitt 2.4.1), und ein systematisches sowie übergreifendes Demand Management sind erforderlich. Der Business-Analyst muss einerseits verstehen, was der Kunde (sein Fachbereich) wirklich braucht, und die unterschiedlichen Sichten der Beteiligten (z.B. Unternehmensführung, Fachbereich und Controller) in Einklang bringen. Andererseits muss er fachliche Lösungsvorschläge, die technisch machbar sind, unterbreiten, sie zur Entscheidung bringen und sicherstellen, dass sie auch umgesetzt werden. Das stellt hohe Anforderungen an die Business-Analysten.

Bild 2.1Business-Analysten, die Vermittler zwischen den Welten

Um diese komplexen Aufgaben zu bewältigen, benötigt der Business-Analyst ein einfaches, handhabbares Instrumentarium von Methoden und Werkzeugen.

In diesem Kapitel erhalten Sie einen Überblick über das Instrumentarium der Business-Analyse und dessen organisatorische Einbettung im Demand Management.

In diesem Kapitel finden Sie Antworten auf folgende Fragen:

Was verstehen wir unter Business-Analyse und Demand Management?

Was sind überhaupt Geschäftsanforderungen?

Was macht die Disziplin Demand Management aus? Welche Aufgabenbereiche deckt das Demand Management ab und wie wirken diese zusammen?

Wie spielt das Demand Management mit Unternehmensplanung, Projektportfoliomanagement, Enterprise Architecture Management, Prozessmanagement und Anforderungsmanagement zusammen?

Welche Rollen, Verantwortlichkeiten und welche organisatorische Einbettung sind für ein erfolgreiches Demand Management erforderlich?

2.1Business-Analyse, was ist das?

Der Begriff „Business-Analyse“ wird aktuell in der Literatur und auch in der Praxis sehr unscharf verwendet. Wir werden im Folgenden den Begriff definieren und die wesentlichen Ziele und Ergebnisse der Business-Analyse beleuchten.

Definition

Business-Analyse ist eine Tätigkeit zur Identifikation von Geschäftsanforderungen sowie Ableitung und Herbeiführung von fachlichen Lösungen, die Unternehmen helfen, ihre Ziele zu erreichen. Eine Lösung besteht oft in der Bereitstellung von IT-Komponenten, kann aber auch Prozessverbesserungen oder organisatorische Änderungen umfassen.

Die Business-Analyse beschäftigt sich also mit der systematischen Planung und Steuerung der Weiterentwicklung der Prozesse, Produkte und deren IT-Unterstützung. Sie hilft Ihnen zu verstehen, wie Ihr Unternehmen aktuell funktioniert und was Sie tun müssen, um Ihre Unternehmensziele zu erreichen. Personen, die die Business-Analyse durchführen und verantworten, bezeichnen wir im Folgenden als Business-Analysten (siehe Abschnitt 2.4).

Ziele der Business-Analyse

Die wesentlichen Ziele der Business-Analyse sind:

       Fachliche und organisatorische Strukturen und Zusammenhänge im Unternehmen sowie Änderungsbedarf und Auswirkungen von Änderungen verstehen

       Fachliche Lösungen für strategische und operative Geschäftsanforderungen gestalten

       Die Umsetzung der fachlichen Lösung effektiv steuern

       Geschäftsanforderungen und Lösungsansätze verständlich und effektiv mit den Beteiligten kommunizieren

Wesentlich für das Erreichen der Ziele sind geeignete Modelle für das Verstehen, Gestalten, Steuern und Kommunizieren. Durch die systematische und einheitliche Darstellung der für den jeweiligen Sachverhalt wesentlichen Elemente und Aspekte wird eine Arbeitsgrundlage für die Business-Analyse geschaffen.

Im Folgenden werden die wesentlichen Ergebnistypen kurz vorgestellt und im Anschluss die Ziele der Business-Analyse anhand eines Beispiels erläutert.

Ergebnistypen der Business-Analyse im Überblick

Die Business-Analyse nutzt unterschiedliche Diagramme und Grafiken in Abhängigkeit von Zweck und Adressat. Die Ergebnistypen stammen aus unterschiedlichen Disziplinen, wie z.B. Anforderungsmanagement, Prozessmanagement, EAM oder Projektmanagement. In Tabelle 2.1 finden Sie wesentliche Diagramme und Grafiken, die sich in der Business-Analyse bewährt haben.

Tabelle 2.1 Wesentliche Ergebnistypen der Business-Analyse

Kontext Enterprise Architecture Management

Das funktionale Referenzmodell oder auch Business Capability Map (siehe [HLo21]) genannt, beschreibt die fachlichen Funktionen (oder auch Business Capabilities) des Unternehmens im Überblick. Funktionale Referenzmodelle und Prozesslandkarten (siehe unten bei Kontext Prozessmanagement) sind beides fachliche Domänenmodelle.

Bebauungsplan-Grafik, auch Matrix-Diagramm genannt, dient zur Einordnung von Bebauungselementen eines Elementtyps in einen zweidimensionalen Bezugsrahmen wie z.B. Zuordnung von Informationssystemen zu Geschäftsprozessen und Geschäftseinheiten.

Informationsfluss-Grafik wird zum Aufzeigen von Abhängigkeiten und Zusammenhängen zwischen Informationssystemen und deren fachlich logischem Informationsfluss genutzt. Siehe hierzu Abschnitt 4.3.4.7.

Kontext Prozessmanagement

Prozesslandkarte beschreibt die Geschäftsprozesse des Unternehmens im Überblick.

Swimlane-Diagramm dient zur Visualisierung von Zuständigkeiten von Teil-Geschäftsprozessen.

Ein Prozessablauf-Diagramm zeigt den Prozessablauf im Detail. Es beschreibt, welcher Auslöser einen Prozess anstößt, in welcher Reihenfolge und unter welchen Bedingungen Aktivitäten durchgeführt werden und wer eine Aktivität im Prozess ausführt.

Kontext Business-Planung und Projektmanagement

Ein Projektantrag enthält sämtliche Informationen für die Entscheidung für oder gegen die Durchführung des Projekts im Projektportfoliomanagement.

Portfolio-Grafik dient zur Visualisierung von „Wertigkeiten“ von Bebauungselementen oder Strategien für Bebauungselemente auf einen Blick.

Masterplan-Grafik visualisiert zeitliche Abhängigkeiten von z.B. Projekten.

Burndown-Chart macht Projektfortschritt und Aufwände im agilen Kontext transparent.

Kontext Anforderungsmanagement

Die Anforderungsliste ist das zentrale Instrument im Anforderungsmanagement. Die Geschäftsanforderungen werden in der für das Unternehmen festgelegten Struktur aufgenommen und bewertet. Es ist das zentrale Instrument für das systematische Management der Geschäftsanforderungen. Die Auflistung von Anforderungen im agilen Kontext wird Backlog genannt. Es gibt unterschiedliche Backlogs, wie z.B. ein Produkt- oder Sprint-Backlog (siehe [Lef11]).

Das fachliche Komponentenmodell gliedert die einzelnen, IT-technisch umgesetzten oder umzusetzenden Funktionen in fachliche Cluster, die Komponenten.

Ein Use-Case beschreibt das nach außen hin für den Nutzer eines Systems sichtbare Verhalten.

Das fachliche Klassenmodell stellt die wesentlichen Entitäten und deren Beziehungen sowie Geschäftsregeln dar.

In Abschnitt 4.3.4.7 werden die EAM-Ergebnistypen und in Kapitel 5 die restlichen Ergebnistypen der Business-Analyse im Detail erläutert. Neben diesen Ergebnistypen werden sicherlich im Unternehmenskontext noch weitere spezifische Ergebnisdarstellungen und Visualisierungen (siehe [Mat04-1] und [Mat04-2]) verwendet.

Empfehlung

Beschränken Sie sich auf die für Sie wesentlichen Ergebnistypen und legen Sie für diese Modellierungsrichtlinien fest. Nur durch eine einheitliche Verwendung der Ergebnistypen sind Modelle für andere Business-Analysten ohne großen Erklärungsaufwand verständlich. Hilfestellungen für die Auswahl und Modellierung finden Sie in Kapitel 5.

Anhand eines einfachen Beispiels möchten wir nun die Ziele und die Inhalte der Business-Analyse verdeutlichen. Das systematische Vorgehen wird in den Kapiteln 3, 4 und 5 ausführlich beschrieben.

Beispiel

Der Außendienst meldet einen operativen Handlungsbedarf. In der Kundenkontakthistorie fehlen wesentliche Besuchsberichte. Nun gilt es die Ursachen zu finden. Die relevanten Strukturen, wie z.B. Geschäftsprozesse, Geschäftseinheiten oder Informationssysteme, müssen identifiziert und analysiert werden, um das Problem zu lokalisieren. Da der Business-Analyst selbst häufig nicht über die Informationen im Detail verfügt und diese entweder nicht dokumentiert vorliegen oder die Dokumentation veraltet ist, befragt er die wesentlichen Stakeholder in Business und IT. Er muss die richtigen Stakeholder und die richtigen Fragen identifizieren, um die wirklichen Ursachen möglichst schnell zu finden. Der Business-Analyst muss hierzu in der Organisation „verdrahtet“ sein und den fachlichen Kontext sowie dessen IT-Umsetzung zumindest im Überblick kennen.

Für die Befragung der Stakeholder nutzt er im Wesentlichen die in Tabelle 2.1 aufgeführten Ergebnistypen entsprechend der jeweiligen Fragestellungen. Wenn die Modelle noch nicht vorliegen, erstellt er sie. Durch Visualisierungen, die auf die jeweiligen Stakeholder zugeschnitten sind, wird die Kommunikation erheblich vereinfacht. So werden z.B. Organisationsbrüche über Swimlane-Diagramme und Schnittstellen zwischen IT-Systemen über Informationsfluss-Grafiken einfach ersichtlich (siehe Tabelle 2.1, Kapitel 5 und [HLo21]).

Empfehlung

Modellieren Sie den für die Befragung der Stakeholder relevanten Ausschnitt auch dann, wenn Sie nicht über alle Informationen im Detail verfügen. Im Rahmen des Gesprächs mit dem Stakeholder werden Lücken oder Fehler in den Modellen aufgedeckt, so die Qualität der Modelle verbessert und vor allen Dingen die für eine fachliche Lösung relevanten Aspekte identifiziert.

Im Beispiel war die Ursache des operativen Handlungsbedarfs eine fehlerhafte Integration des Außendienstsystems mit dem CRM-System. Die Daten des Außendienstsystems wurden nicht immer richtig synchronisiert. Diese Ursache wurde ermittelt, indem die folgenden Aktivitäten durchgeführt wurden:

1.      Fachlichen Kontext feststellen. Ermittlung der relevanten Geschäftsprozesse (Beispiel Geschäftsprozess „Service“) und deren Verantwortlichkeiten anhand der in diesem Kontext vorhandenen Ergebnistypen; in diesem Fall Prozesslandkarte, Swimlane- und zusätzlichen Kontextdiagrammen (siehe Kapitel 3 und 5)

2.      IT-Kontext ergründen. Analyse der IT-Unterstützung anhand von Bebauungsplänen und Informationsfluss-Grafiken (siehe Abschnitt 4.3.4.7), Ermittlung der relevanten IT-Systeme und Schnittstellen und der für sie Verantwortlichen

3.      Use-Cases im Kontext sammeln. Nutzung der vorhandenen Use-Case-Dokumentation soweit vorhanden

4.      Ist-Analyse zur Identifikation möglicher Ursachen. Befragung des Geschäftsprozessverantwortlichen zur Identifikation von möglichen Ursachen unter Nutzung der Modelle. Analyse der Geschäftsprozesse und Use-Cases aus dem ermittelten Kontext gemeinsam mit dem Geschäftsprozessverantwortlichen.

Im Beispiel wurden hier mehrere mögliche Ursachen gesammelt:

a)      Eingabefehler beim Außendienst

b)      Fehler beim Abspeichern im Außendienstsystem

c)      Schnittstellenfehler zwischen dem Außendienst- und dem CRM-System

d)      Anzeigefehler beim CRM-System

Der Geschäftsprozessverantwortliche hatte im Beispiel im Nachgang eine Überprüfung der Kundenkontaktdaten in Bezug auf die vorliegenden Fehlermeldungen angestoßen und so die Alternativen a), b) und d) ausgeschlossen.

5.      Befragung des Schnittstellenverantwortlichen zwischen dem Außendienst- und dem CRM-System unter Nutzung der Informationsfluss-Grafik und des Inputs vom Geschäftsprozessverantwortlichen. Der Schnittstellenverantwortliche analysierte das Logfile für die Übertragung der Kundenkontaktdaten vom Außendienst- zum CRM-System.

Nach Identifikation des Problems muss der Business-Analyst eine angemessene fachliche Lösung finden und dafür sorgen, dass diese auch wirklich umgesetzt wird. Im Beispiel war die fachliche Lösung „einfach“ die Überarbeitung der Schnittstelle zwischen den Systemen. Diese wurde über eine Wartungsanforderung beim Schnittstellenverantwortlichen beauftragt und nach Fertigstellung des nächsten Schnittstellen-Release vom Fachbereich getestet und fachlich abgenommen und schließlich in Produktion genommen.

Die Festlegung und Abstimmung der fachlichen Lösung sind nicht immer so naheliegend wie in diesem Beispiel. Hilfestellungen hierfür und auch für das fachliche Steuern der Umsetzung finden Sie in Abschnitt 4.3.5.

Was sind überhaupt Geschäftsanforderungen?

Wir haben bislang häufig den Begriff der Geschäftsanforderung benutzt, ohne ihn zu definieren. Eine Geschäftsanforderung beschreibt das, was ein Anforderungssteller zur Lösung seines Problems oder zur Erreichung seines Ziels benötigt oder was ein System oder eine Systemkomponente erfüllen muss, um Vorgaben zu genügen (siehe IEEE 1990 [IEEE90]).

Definition

Eine Geschäftsanforderung ist eine überprüfbare Aussage über eine Eigenschaft oder Leistung, die ein Produkt, ein Prozess, ein am Prozess Beteiligter oder ein IT-System erfüllen müssen. Jede Geschäftsanforderung erfüllt das Bedürfnis eines bestehenden oder potenziellen Kunden oder das anderer Stakeholder.

Geschäftsanforderungen leiten sich aus der Unternehmens- oder IT-Strategie ab oder resultieren aus Veränderungsanforderungen aus dem operativen Geschäftsbetrieb oder von externen Randbedingungen, wie z.B. gesetzliche Anforderungen. Sie beschreiben das Ergebnis der Veränderung nach der Umsetzung. Die Veränderungen können organisatorischer, prozessualer oder technischer Natur sein.

Geschäftsanforderungen können unterschiedliche Granularität, Konkretisierung, Dringlichkeit und Wichtigkeit aufweisen. Beispiele für Geschäftsanforderungen, die bei Ihnen aufschlagen können, sind:

       „Das neue Geschäftsmodell X muss ermöglicht werden.“

       „Außendienstanbindung muss verbessert werden.“

       „In Maske 4711 das Feld XYZ 5 cm nach rechts verschieben.“

       „Fehlermeldung erscheint bei Rechnungsdruck.“

Strategische Geschäftsanforderungen, wie die Unterstützung des neuen Geschäftsmodells „neuer Vertriebskanal über Partner“, werden aus der Unternehmens- oder IT-Strategie abgeleitet. Sie sind häufig eher grobgranular und noch nicht sehr konkret, haben aber eine hohe Wichtigkeit und eine niedrige bis mittlere Dringlichkeit.

Im Gegensatz hierzu kommen operative Geschäftsanforderungen, wie z.B. „Verbesserung der Antwortzeit des CRM-Systems beim Anlegen eines neuen Kunden“, aus dem laufenden Geschäftsbetrieb in Business oder IT. Beispiele hierfür sind:

       Fehler und Unzulänglichkeiten im Tagesgeschäft, wie z.B. Störungen und unzureichende Performance,

       Optimierungsanforderungen und neue Funktionalitäten („Feature Requests“), wie z.B. ein durchgängiges einheitliches Management von Kundenstammdaten.

Operative Geschäftsanforderungen sind in der Regel feingranularer und haben eine niedrigere Wichtigkeit. Die Dringlichkeit hängt stark von der Art der einzelnen Geschäftsanforderung ab. Bei produktionsverhindernden Fehlern besteht eine sehr hohe Dringlichkeit. Bei Maskenverschönerungen reicht häufig eine Behebung zum nächsten Release-Termin des betreffenden Informationssystems. Gesetzliche Anforderungen und aufsichtsrechtliche Richtlinien müssen im vorgegebenen Zeitrahmen umgesetzt werden (siehe Kapitel 4).

Neben strategischen und operativen Geschäftsanforderungen müssen in der Business-Analyse insbesondere auch gesetzliche Anforderungen und aufsichtsrechtliche Richtlinien, wie z.B. die Einhaltung von Compliance- oder Sicherheitsanforderungen, berücksichtigt werden. Diese setzen Randbedingungen, die im Rahmen der fachlichen Lösungskonzeption eingehalten werden müssen.

Wichtig

Trennen Sie klar zwischen Anforderung und Lösung. Eine Anforderung beschreibt das „Was“ und eine Lösung das „Wie“. Führen Sie erst dann Lösungsdiskussionen, wenn Sie die Anforderungen wirklich verstanden haben. Fragen Sie hierzu bis zu drei Mal nach dem „Warum“. Spätestens nach dem dritten „Warum“ sind Sie erfahrungsgemäß auf den Kern der Anforderung gestoßen.

Dies erläutern wir im Folgenden kurz. Ausführlich wird das Demand Management in Kapitel 4 beschrieben.

2.2Demand Management, was ist das?

Das Management der Geschäftsanforderungen kann entweder klassisch wasserfallmäßig oder aber agil im Kleinen oder Großen erfolgen. Agil im Kleinen im Operativen, wie z.B. mit Scrum (siehe [Glo11]), oder aber im Großen auf taktischer und operativer Ebene, wie z.B. unter Anwendung von SAFe® (siehe [Lef11]).

Im Klassischen wird das Management der Geschäftsanforderungen häufig Demand Management genannt. Hier kann das Demand Management sowohl in der IT als wichtige Disziplin in der „CIO-Organisation“ als auch im Business angesiedelt sein. Der Begriff wird jedoch ebenso wie bei der Business-Analyse-Aktivität in der Literatur unscharf und uneinheitlich benutzt. Daher definieren wir das Demand Management im Folgenden.

Definition

Das Demand Management umfasst alle Aufgaben für das Management der strategischen und operativen Geschäftsanforderungen. Es geht darum, im Zusammenspiel zwischen Business und IT die Geschäftsanforderungen möglichst angemessen, kostengünstig und trotzdem tragfähig und zeitgerecht umzusetzen. Eine wesentliche Tätigkeit im Demand Management ist die Business-Analyse, d.h. die Identifikation, Aufnahme, Bündelung, fachliche Planung, Bewertung der Geschäftsanforderungen und Einsteuerung dieser in den Umsetzungsprozess.

Im agilen Kontext beinhaltet das Demand Management neben dem eigentlichen Management der Geschäftsanforderungen die agile Planung und Umsetzung der Geschäftsanforderungen.

Die konkrete Ausgestaltung des Demand Managements muss sich am organisatorischen Kontext und an den im Unternehmen ggf. bereits gesetzten Methoden orientieren, wie z.B. V-Modell oder V-Modell XT, oder aber agil z.B. entsprechend SAFe®, um einen optimalen Fluss der Anforderungen von Anforderungstellern bis zur Umsetzung sicherzustellen.

Hinweis

Einige Vorgehensmodelle sehen die Vorbereitung der Inhalte für die Umsetzung und/oder die mittelfristige Planung als „gegeben“ an. Dementsprechend werden die dafür notwendigen Aktivitäten und die dabei beteiligten Rollen nur am Rande betrachtet.

Die im Folgenden beschriebenen Aufgaben, von der Business-IT-Koordination bis hin zur fachlichen Steuerung der Umsetzung, sind notwendig, um Ihr Unternehmen erfolgreich voranzubringen. Achten Sie bei der Adaption auf „Ihr“ Vorgehensmodell darauf, dass auch diese Aspekte berücksichtigt werden.

Im Demand Management wird Business-Analyse durchgeführt. Das Demand Management stellt sicher, dass die wirklichen Geschäftsanforderungen erkannt und auch entsprechend der Geschäftserfordernisse umgesetzt werden. Die wesentlichen Aufgaben des Demand Management sind (siehe Bild 2.2):

       Business-IT-Koordination. Das Demand Management ist eine Schnittstellenfunktion zwischen Business und IT mit starker Businessorientierung und gleichzeitig IT-Sachverstand. Die Business-IT-Koordination ist daher ein wichtiger Querschnittsaspekt, der sich auch der anderen Aufgabenbereiche bedient.

       Unterstützung bei der Budgetierung durch die fachliche Themenplanung. Die Budgetierung ist ein Teil des Gesamtplanungsprozesses einer Organisation. Im Idealfall (und bei einem hohen Reifegrad des Demand Management) unterstützt das Demand Management dabei. Die Business-Analysten nehmen dann Budgetpositionen der Fachstellen auf, entwickeln und bewerten grobgranulare Lösungsszenarien sowie schätzen diese monetär im Zusammenspiel mit Lösungsarchitekten ab.

Die Business-Analysten können zudem Vorschläge für Investitionsthemen durch die Ableitung von strategischen Geschäftsanforderungen aus der Unternehmensstrategie den Fachstellen unterbreiten (siehe Abschnitt 4.3.3).

       Projektanträge und Roadmap-Planung. Auf einer taktischen Planungsebene geht es darum, inhaltlich angemessen und zeitgerecht die Vorschläge für Investitionsentscheidungen auf einer groben Ebene vorzubereiten. Ein Vorschlag kann entweder im klassischen Vorgehen ein Projektantrag oder aber eine Produkt-Roadmap sein. Die eigentlichen Investitionsentscheidungen werden dann z.B. im Projektportfoliomanagement oder im Agilen im Portfoliomanagement (siehe Abschnitt 4.2.3) oder im Produktmanagement-Board (siehe Abschnitt 4.2.3) getroffen. Abhängig von der Unternehmensorganisation und -kultur muss eine adäquate Art und Weise festgelegt werden.

       Fachliche Projekt- und Iterationsplanung. Die auf der taktischen Planungsebene festgelegten Initiativen werden im Detail geplant und so weit heruntergebrochen, dass sie in Inkremente oder Iterationen des Projekts oder aber in der agilen Produktlieferung eingeplant werden können.

       Fachliches Steuern der Umsetzung. Der Business-Analyst muss sicherstellen, dass die Geschäftsanforderungen wirklich umgesetzt werden. Er stellt Transparenz über den Grad der Umsetzung der Geschäftsanforderungen z.B. über fachliche Tests und Reviews her. Entsprechend der organisatorischen Einbettung kann dies unterschiedlich ausgestaltet sein.

Die Aufgabenbereiche werden im Folgenden im Überblick erläutert. Detaillierte Hilfestellungen, Schritt-für-Schritt Anleitungen und Templates für die unmittelbare Anwendung in Ihrem Unternehmen finden Sie in Kapitel 4.

Bild 2.2Wesentliche Aufgabenbereiche des Demand Management

2.2.1Business-IT-Koordination

Die Business-IT-Koordination ist eine wesentliche Aufgabe des Business-Analysten. Es ist eine Beratungsfunktion für die Fachabteilungen sowie eine Vermittler- und Dolmetscherfunktion zwischen den Fach- und IT-Abteilungen.

Die Fachbereiche, die Anforderungssteller, werden unter anderem bei der Beantwortung folgender Fragen unterstützt:

       Welche Budgets sind für die Umsetzung der Geschäftsanforderungen in einem Fachbereich für das nächste Kalenderjahr, Geschäftsjahr oder andere Zeitspannen notwendig?

       Welche fachlichen Lösungsalternativen gibt es, um die Geschäftsanforderung umzusetzen? Welche Alternative ist die angemessenste oder/und kostengünstigste?

       Gibt es Redundanzen oder Abhängigkeiten unter den unterschiedlichen von mehreren Seiten geäußerten Geschäftsanforderungen?

       Welche Geschäftsanforderungen sollten mit dem festgelegten Budget umgesetzt werden?

       Wann werden die Geschäftsanforderungen umgesetzt? In welchem Projekt oder welcher Wartungsmaßnahme? Von welcher IT-Einheit oder welchem externen Lieferanten?

       Wie ist der Status der Umsetzung? Welche Auswirkungen gibt es im Falle einer Verzögerung?

       Wurde die Geschäftsanforderung wirklich im Rahmen des Projekts umgesetzt oder gibt es Nachbesserungsbedarf?

In ihrer Vermittler- und Dolmetscherfunktion „übersetzen“ die Business-Analysten die fachlichen Begriffe und Geschäftsanforderungen in die Sprache der IT und sind der Ansprechpartner für fachliche Rückfragen für die IT. Sie stellen, falls sie Fragen nicht unmittelbar selbst beantworten können, den Kontakt zu den Schlüsselpersonen im Business her und dolmetschen.

Beispiele für fachliche Rückfragen:

       Was soll eigentlich umgesetzt werden? Welche Prioritäten bestehen? Was sind Muss- und was Kann-Anforderungen? Welches Budget steht zur Verfügung?

       Welche gesetzlichen oder regulatorischen Vorschriften bestehen?

       Welche Randbedingungen existieren? Welche Ziele werden verfolgt?

       Welche nichtfunktionalen Anforderungen, wie z.B. Zuverlässigkeit oder Sicherheit, bestehen?

       Welche fachlichen Abhängigkeiten bestehen zwischen den Geschäftsanforderungen?

       Welche Anwendungsfälle gibt es im jeweiligen Kontext? Welche Ausnahmen und Fehlerfälle sind zu berücksichtigen?

       Erfüllt eine technische Lösung wirklich die fachlichen Anforderungen? Kann der Fachbereich damit „leben“?

Wichtig

Die Business-Analysten haben einen Überblick über die fachlichen Zusammenhänge in ihrem Fachbereich und kennen die Schlüsselpersonen in Business und IT. Sie sorgen dafür, dass die Fachbereiche die richtigen und angemessenen Lösungen für die Umsetzung der Geschäftsanforderungen erhalten. Sie gleichen die Geschäftsanforderungen der Fachabteilungen mit den Möglichkeiten ab, die die IT bereitstellt.

Wesentlich für eine funktionierende Business-IT-Koordination sind deren organisatorische Verankerung in Prozessen und eine gute Werkzeugunterstützung (siehe Abschnitt 2.4).

Die Business-Analysten beraten die Fachbereiche sowohl im Hinblick auf die Strategieumsetzung als auch in Bezug auf die Nutzung von technischen Trends und Möglichkeiten. Für sehr viele Unternehmen ist das aber noch Zukunftsmusik, meist findet die Abstimmung zwischen Fachabteilung und IT bisher noch sehr unsystematisch und unregelmäßig statt. Häufig wird der Fehler gemacht, dass entweder technische Diskussionen zu früh geführt werden oder bereits spezifiziert wird, bevor die wirkliche Essenz der Anforderung verstanden ist. Dies führt dann dazu, dass die IT zwar die Anforderungen umsetzt, die Lösung aber nicht den wirklichen Bedürfnissen der Fachbereiche entspricht. Durch eine systematische und hinterfragende Business-Analyse lässt sich dieser unnötigen Geld- und Ressourcenverschwendung entgegenwirken (siehe Abschnitt 4.3.4.1 und [Lef11]).

Wichtig ist hier insbesondere auch die Beratung bei der Priorisierung der Geschäftsanforderungen, gerade in Zeiten knapper Budgets. Nur so kann sichergestellt werden, dass die eingeschränkten Ressourcen richtig eingesetzt werden. Die Priorisierung der Geschäftsanforderungen erfolgt häufig im Rahmen der Budgetierung.

2.2.2Fachliche Themenplanung (Budgetierung)

Unter Budgetierung wird der Prozess verstanden, der alle Aktivitäten im Rahmen der Aufstellung, Verabschiedung, Durchsetzung, Anpassung und Kontrolle von Budgets erfasst. Die Budgetierung ist Teil des Gesamtplanungsprozesses einer Organisation sowie ein wichtiges Controlling- und Steuerungsinstrument. Im agilen SAFe®-Kontext ist es Teil des Lean Portfolio Management.

Das Lean Portfolio Management schlägt die Brücke zwischen Strategie und Umsetzung. Budgetzuweisungen erfolgen im taktischen Planungshorizont flexibel, um den Wertdurchsatz zu maximieren. Durch einen transparenten Umsetzungsstand und Fortschritt (u.a. Backlog, Kanban und Demos neuer Funktionalitäten) sowie Lean-Prinzipien können die Budgetzuweisungen an die jeweiligen Erfordernisse angepasst werden. Die Geschäftschancen mit dem höchsten Wert und die dafür anzupackenden strategischen Themen werden ermittelt und im Portfolio Backlog priorisiert. Getroffene Entscheidungen und Pläne werden im taktischen Planungshorizont (häufig vierteljährlich) auf der Grundlage von neuem Feedback besprochen. Die Erkenntnisse fließen in die Budgetplanung ein.

Budgets sind letztendlich zahlenmäßige Vorgaben für Kosten oder Leistungen zum Erhalt und zur Weiterentwicklung des Unternehmens für einen festgelegten Zeitraum und Verbindlichkeitsgrad. Der Planungsprozess ist in der Regel mehrstufig. Das Management (Unternehmensführung oder Führung von Geschäftseinheiten) gibt in der Regel sowohl maximale Gesamtbudgets für Gesamtunternehmen, Geschäftseinheiten oder Produkte als auch eine Aufteilung des Budgets in z.B. gesetzliche Anforderungen, strategische Maßnahmen, Wartung und Betrieb für die verschiedenen Geschäftseinheiten vor. Die eigentlichen Budgetanforderungen werden von den einzelnen Geschäftseinheiten (oder Kostenstellen) nach einheitlichen Regeln erarbeitet und dann vom Controlling zum Gesamtbudget verdichtet (siehe [Hor12]). In einem iterativen Verfahren wird dann der Mittelbedarf mit den von der Unternehmensführung gesamthaft bereitgestellten Budgets abgeglichen. Falls der Mittelbedarf das Gesamtbudget übersteigt, werden über Priorisierung der Geschäftsanforderungen oder andere Verfahren, wie z.B. prozentuale Kürzungen, die Budgets der Verantwortungsbereiche festgelegt. Diese münden dann in einen finanziellen Gesamtplan. Insoweit ist die Budgetierung eng mit der Finanzplanung verknüpft.

Häufig wird bei der Budgetierung zwischen der operativen und strategischen Budgetierung unterschieden:

       In der operativen Budgetierung werden für eine Planungsperiode (in der Regel ein Jahr) die finanziellen Planvorgaben (Budget) für die Umsetzung der Anforderungsbündel als Zielvorgabe gesetzt. Sie umfasst die Aufstellung und Kontrolle operativer Budgets in der Planungsperiode (in der Regel ein Jahr) für die verschiedenen Verantwortungsbereiche. Die Summe der operativen Budgets ist die vollständige mengen- und wertmäßige Zusammenfassung der gewünschten Entwicklung der Geschäftseinheit in der Planungsperiode. Projekte und Wartungsmaßnahmen müssen im Rahmen des zugeordneten Budgets abgewickelt werden.

       Die strategische Budgetierung (Mittelfristplanung) zielt auf die langfristige Existenzsicherung und Weiterentwicklung des Unternehmens entsprechend der Unternehmensstrategie ab. Die Ziele und die Maßnahmen beziehen sich auf einen längerfristigen Zeitraum von über drei Jahren (häufig fünf oder sogar zehn Jahre). Die Ergebnisse fließen als Input in die operative Budgetierung ein, wo sie in umsetzbare Einheiten heruntergebrochen werden.

Die Budgets sind letztendlich genau definierte Sollgrößen, wie z.B. Kosten, die es innerhalb der nächsten Planungsperiode einzuhalten gilt. Sie setzen Maßstäbe zur Leistungskontrolle. Die Verantwortlichen werden auf bestimmte Kostenziele verpflichtet.

Wichtig

Nur wenn sich die Mitarbeiter mit den Zielvorgaben identifizieren können, wird die Umsetzung bestimmungsgemäß erfolgen. Wenn nicht, werden häufig Hintertürchen gesucht und gefunden, um formal die Zielvorgaben zu erfüllen. Dies führt im Allgemeinen zu großem wirtschaftlichem Schaden für das Unternehmen, wenn z.B. wichtige Konsolidierungsmaßnahmen einfach nicht durchgeführt werden.

Erfolgsentscheidend für die Identifikation mit den Zielen ist eine partizipative Erarbeitung von realistischen Zielen. Das Budget sollte zudem als Rahmenvorgabe verstanden werden, innerhalb dessen eigenverantwortlich entschieden und gehandelt werden kann.

Das Gesamtbudget im Unternehmen setzt sich in der Regel aus den operativen Budgets der Geschäftseinheiten sowie den zumeist übergreifenden strategischen Budgets zusammen. Während die Geschäftseinheiten über ihr operatives Budget für z.B. die Umsetzung von Wartungsanforderungen selbst entscheiden können, muss bei den strategischen Budgets häufig ein Entscheiderkreis unter Führung der Unternehmensleitung wirken.

Operative Betriebsbudgets werden im Allgemeinen nicht im Detail geplant. Auf der Basis von Vorjahreswerten, Annahmen oder Erfahrungswerten der Umsetzungsverantwortlichen werden diese Budgets in der Regel top-down geschätzt und verteilt.

Die unternehmensübergreifende Gesamtverantwortung für die Steuerung des Budgetierungsprozesses liegt in der Regel beim Controlling. Die Verantwortung für die Aufstellung und Kontrolle der Budgets liegt bei den Verantwortlichen der jeweiligen Planungseinheit (z.B. Kostenstelle). Diese nutzen die ihnen zugeordnete Demand-Management-Einheit. Das Demand Management nimmt die Budgetpositionen auf, entwickelt und bewertet Lösungsszenarien und schätzt diese monetär ab. Das Demand Management liefert also die Inhalte in dem durch das Controlling gesteuerten Prozess.

Dies gilt auch für die Anpassung und Kontrolle der Budgets. Budgets werden über Projekte, Wartungsmaßnahmen oder Tickets abgerufen (siehe Abschnitt 2.2). Die Budgeteinhaltung muss regelmäßig über geeignete Kontrollmaßnahmen vom Demand Management überprüft und gegebenenfalls an den Verantwortlichen der Planungseinheit eskaliert werden. Bei Projekten erfolgt dies in der Regel über regelmäßige Projektstatusberichte und deren Erörterung und Entscheidung in den Projektsteuerkreisen. Bei Wartungsmaßnahmen und Tickets kann dies z.B. über ein IT-Koordinatoren-Gremium (siehe Abschnitt 2.4.1) oder direkte Abstimmungen mit dem Dienstleister entsprechend der formalen oder vertraglichen Festlegungen erfolgen.

Wichtig

Das Demand Management vertritt die inhaltlichen Interessen der Fachverantwortlichen. Es sammelt, bündelt und bewertet die für die Budgetierung relevanten Geschäftsanforderungen.

Die Ausgestaltung des Budgetierungsprozesses ist sehr unternehmensspezifisch. Dies gilt insbesondere für die Rolle des Demand Managements bei der Aufstellung, Anpassung und Kontrolle der Budgets. Best-Practices hierzu finden Sie in Abschnitt 4.3.2.

Ableiten von strategischen Geschäftsanforderungen

Häufig liegen strategische Geschäftsanforderungen noch nicht in einer strukturierten und aussagekräftigen Art und Weise dokumentiert vor. In diesem Fall muss der Business-Analyst die strategischen Geschäftsanforderungen erst aus der Unternehmens- oder Geschäftsbereichsstrategie ableiten. In einem nachvollziehbaren Prozess muss er die strategischen Geschäftsanforderungen strukturiert und aussagekräftig ermitteln und abstimmen.

Wichtig

Wenn die Unternehmens- oder Geschäftsbereichsstrategie nicht in schriftlicher Form vorliegt, müssen Sie Annahmen darüber treffen, diese dokumentieren und z.B. in einer Folge von Workshops mit Vertretern der Unternehmensführung abstimmen. Die explizite Dokumentation der Unternehmensziele und der gesetzten Randbedingungen ist entscheidend, da nur so eine Basis für die Ableitung der strategischen Geschäftsanforderungen besteht.

In Abschnitt 4.3.3 finden Sie eine Schritt-für-Schritt-Anleitung für die Ableitung der strategischen Geschäftsanforderungen.

2.2.3Aufnehmen, Gestalten und Planen

Eine der wesentlichen Aufgaben des Business-Analysten umfasst das Aufnehmen, Gestalten und Planen von Geschäftsanforderungen und deren fachlichen Lösungen. Dies kann auf unterschiedlichen Planungsebenen erfolgen. Die Business-Analysten können in der Planung sowohl auf strategischer, taktischer als auch operativer Ebene eingebunden werden. Die Einbindung auf strategischer Ebene haben wir im vorhergehenden Abschnitt erläutert.

In dieser taktischen Planungsebene werden Projektanträge bzw. das Projektportfolio und die Roadmap zur Umsetzung für alle Produkte inhaltlich geplant und entsprechend der sich ändernden Anforderungen und Rahmenbedingungen angepasst. Dies ist die Königsdisziplin im Demand Management, da es hier darauf ankommt, mit einem angemessenen Aufwand sicherzustellen, dass die richtigen Dinge getan werden.

Wichtig

In der Praxis werden häufig die Business-Analysten auf der taktischen Ebene noch nicht einbezogen, Die Verantwortlichkeit liegt hier dann entweder bei den Fachverantwortlichen oder aber im Projektportfoliomanagement. Die inhaltliche Planung wird gegebenenfalls vernachlässigt und so werden die falschen Schwerpunkte gesetzt. Eine Menge Potenzial des Demand Management wird dann verschenkt.

Die taktische inhaltlich fundierte Planung ist alles andere als einfach, da dies die Beherrschung des Anforderungschaos voraussetzt und aufbauend darauf die taktische Planung systematisch durchgeführt werden muss. Hierzu müssen mit vertretbarem Aufwand die relevanten Geschäftsanforderungen identifiziert und abgestimmt werden. Die strategischen Geschäftsanforderungen werden weiter heruntergebrochen und aus den gesammelten Realisierungsanforderungen und Pains über eine Bottom-up-Konsolidierung den top-down ermittelten Geschäftsanforderungen zugeordnet. Auf dieser Basis können sie zu taktischen Umsetzungspaketen gebündelt, analysiert und bewertet werden. Hierauf setzt dann die eigentliche taktische Umsetzungsplanung auf. Ergebnisse sind Projektanträge, das aus fachlicher Sicht sinnvolle Projektportfolio und/oder (Produkt-)Roadmaps für die Umsetzung der taktischen Umsetzungspakete. Die Projektanträge werden ins Projektportfoliomanagement (siehe Abschnitt 4.3.2) und die Produkt-Roadmaps ins Produktmanagement (siehe Abschnitt 4.2.3) eingesteuert. Best-Practices hierzu finden Sie in Kapitel 4.

Die auf taktischer Ebene festgelegten Initiativen werden auf der operativen Ebene im Rahmen der Projektplanung oder Iterationsplanung oder aber bei der Release-Planung feingranular geplant. Die feingranularen Anforderungen werden den Inkrementen und Iterationen des Projekts zugeordnet. Wenn sie zu grobgranular sind, müssen sie so weit heruntergebrochen werden, dass sie in die Inkremente eines Projekts, eines Release oder aber einer Iteration eingepasst werden können. Bei agilen Projekten mit Iterationen von drei oder vier Wochen müssen die Realisierungsanforderungen entsprechend klein gehalten werden. Für die Detaillierung und Zerlegung von Features gibt es eine Reihe von Best-Practices (siehe Kapitel 4). In Bild 2.3 finden Sie die verschiedenen Planungsebenen im Demand Management zusammengefasst dargestellt.

Der für einen Fachbereich zuständige Business-Analyst nimmt die Geschäftsanforderungen aus seinem Fachbereich strukturiert auf und überführt sie in machbare Umsetzungspakete. Hierzu müssen die wesentlichen Anforderungen identifiziert und dafür angemessene fachliche Lösungen gefunden werden. Jede Anforderung muss im Hinblick auf Sinn, Nutzen und Umsetzungsaufwand geprüft werden. Der Business-Analyst berät den Fachbereich bei der Priorisierung und hinterfragt die geschäftliche Notwendigkeit. So lassen sich Anzahl und Umfang von Geschäftsanforderungen erheblich reduzieren und vor allen Dingen dafür sorgen, dass die „richtigen Dinge richtig“ umgesetzt werden.

Soweit möglich, konzipiert und bündelt der Business-Analyst die Geschäftsanforderungen zu fachlichen Anforderungsbündeln, die gesamthaft umgesetzt werden sollen. Diese stimmt er in der Regel mit dem Fachbereichsverantwortlichen ab, bevor er sie in Form von Wartungsanforderungen, fachlichen Projektanträgen oder Tickets an die IT oder Organisationsabteilung zur Bewertung weiterleitet.

Bild 2.3Vom O-Ton Kunde zur Umsetzung der Geschäftsanforderung

In Bild 2.3 werden die wesentlichen Schritte vom „O-Ton Kunde“ bis zur Festlegung der Umsetzungspakete grob dargestellt:

Schritt 1: Strukturiert aufnehmen und klassifizieren

Der Business-Analyst muss die unterschiedlichen in Abschnitt 2.1 ausgeführten Arten von Geschäftsanforderungen der Fachbereiche aufnehmen. Mögliche Quellen sind:

       Strategieunterlagen, aus denen der Business-Analyst erst selbst strategische Anforderungen ableiten muss,

       gesetzliche und aufsichtsrechtliche Richtlinien aus entsprechenden Webseiten und Veröffentlichungen,

       Projektideen des Fachbereichs oder der IT in Form von vorausgefüllten Projektanträgen,

       Protokolle aus Abstimmungsmeetings oder Interviews mit dem Fachbereich oder der IT,

       Change Requests und Wartungsanforderungen in den im Unternehmen vorgesehenen Formularen,

       Fehlerbehebungs-Tickets im Ticketing-System.

Geschäftsanforderungen können in der unterschiedlichsten Art und Weise beim Business-Analysten landen:

       Sie können mündlich übermittelt werden. Der Business-Analyst nimmt dann die Geschäftsanforderung selbst auf und stimmt das Ergebnis mit den Anforderungsstellern in Iterationen ab.

       Sie können schriftlich in Form einer Projektidee oder aber einer Wartungsanforderung vom Anforderungssteller übergeben werden. Hierfür gibt es häufig Vorlagen (siehe [Rat08]). Der Business-Analyst überprüft, verfeinert und stimmt die Geschäftsanforderungen mit den Anforderungsstellern ab.

Der„O-Ton Kunde“, das heißt die wörtliche Formulierung der Anforderung des Anforderungsstellers, ist nicht immer allgemeinverständlich, eindeutig und nachvollziehbar. Ein Beispiel für eine Anforderung in „O-Ton Kunde“ ist „XAVIER sicher machen“. Dass hier das Online-Banking-IT-System XAVIER gemeint ist und unter „sicher machen“ die Einführung des Chip-Tan-Verfahrens verstanden wird, ist nicht unmittelbar klar. Der Business-Analyst muss die Anforderung erst verstehen, Zusammenhänge und Abhängigkeiten analysieren, gegebenenfalls den Sinn hinterfragen und dann in Abstimmung mit dem Anforderungssteller gegebenenfalls aussortieren oder umformulieren und strukturiert aufnehmen (siehe Kapitel 5). Falls die Anforderung noch unklar ist, muss diese z.B. im Rahmen eines Analyseprojekts konkretisiert werden.

Wichtig

Achten Sie darauf, dass Sie bei der Aufnahme der Einzelanforderungen auf der fachlichen Anforderungsebene (was ist zu leisten?) bleiben und diese nicht mit technischen Lösungsaspekten (wie soll es umgesetzt werden?) vermischen. Dies ist nicht immer einfach, da die Anforderungssteller häufig technische Lösungen als Anforderung benennen. Hier müssen Sie den fachlichen Kern und die Hintergründe der Geschäftsanforderung erst ermitteln. Technische Lösungsaspekte können Randbedingungen für die Umsetzung darstellen. Formulieren Sie diese explizit.

Das Strukturieren umfasst sowohl das Zerlegen in Einzelanforderungen als auch das Zusammenfassen von inhaltlich ähnlichen Einzelanforderungen mit vergleichbaren oder eng zusammenhängenden Inhalten zu neuen Einzelanforderungen. Das Strukturieren zielt darauf ab, Einzelanforderungen zu erhalten, die getrennt priorisiert und gegebenenfalls auch umgesetzt werden können. Dies führt zu einer Komplexitätsreduktion bei der Projektplanung, -steuerung und -durchführung.

Bei der Aufnahme der Einzelanforderungen müssen insbesondere auch die Wichtigkeit und Dringlichkeit sowie die Hintergründe1, die nichtfunktionalen Anforderungen und Randbedingungen hinterfragt werden. Die Klassifikation nach Wichtigkeit (z.B. Muss, Kann und nice-to-have) und Dringlichkeit (z.B. hoch, mittel und niedrig) ist insbesondere für die Priorisierung der Geschäftsanforderungen erforderlich. Durch das Hinterfragen der Hintergründe erhalten Sie ein tieferes Verständnis davon, was Anfordernde wirklich haben möchten bzw. tatsächlich benötigen. Die nichtfunktionalen Anforderungen, wie z.B. Sicherheit, und die Randbedingungen, wie z.B. „unter Nutzung der SAP-Software“, beschränken den fachlichen Lösungsraum.

Wichtig

Stellen Sie sicher, dass Sie die Ziele und Hintergründe der Anforderungssteller für die Geschäftsanforderung wirklich verstanden haben. Im Gespräch mit dem Anforderungssteller muss es Ihnen gelingen, die wirklich entscheidenden und wichtigen Aspekte der Anforderungen zu extrahieren. Dokumentieren Sie die zentralen Inhalte, fachlichen Zusammenhänge, Abhängigkeiten und Auswirkungen auf dem für die Abstimmung mit dem Anforderungssteller erforderlichen Level. Dokumentieren Sie zudem die Randbedingungen und Annahmen, die Sie getroffen haben.

Hinterfragen Sie die Notwendigkeit und Angemessenheit der Anforderung, indem Sie versuchen, den Nutzen für den Anforderungssteller zu ermitteln. Der Nutzen muss nicht zwangsläufig monetärer Natur sein, beispielsweise Kosteneinsparung. Möglicher Nutzen sind auch effizientere Geschäftsprozesse, Minimierung von Risiken oder die Verbesserung der Kundenzufriedenheit. Konkretisieren Sie den Nutzen im Dialog mit dem Anforderungssteller so weit wie möglich, wie beispielsweise „Einsparung von mindestens einem Tag Liegezeit pro Geschäftsvorfall“. So dämmen Sie pauschale Nutzenaussagen ein.

Stellen Sie, soweit zu diesem Zeitpunkt schon möglich, den erwarteten Aufwand gegenüber und konfrontieren Sie den Anforderungssteller damit. Häufig reichen grobe Aussagen über die Kosten, wie z.B. „sehr aufwendig“. Solche Aussagen können Sie häufig schon aus Ihrer Erfahrung heraus abgeben. Für den Anforderungssteller ist diese Beratung sehr wichtig. Er kann so den Wert der Geschäftsanforderung für sich besser einschätzen. So können Sie pauschal als „wichtig“ bewerteten Anforderungen frühzeitig entgegenwirken und im Dialog mit dem Anforderungssteller frühzeitig viele doch unwichtige aussortieren („die Spreu vom Weizen trennen“).

Best-Practices für das strukturierte Aufnehmen und Klassifizieren von Geschäftsanforderungen finden Sie in Kapitel 5.

Schritt 2: Konzipieren und fachliches Bündeln

Der Business-Analyst konzipiert grobe fachliche Lösungsideen und bündelt die Einzelanforderungen zu fachlichen Anforderungsbündeln, die Einheiten für die Bewertung und Inkrementbildung bei der Umsetzungsplanung. Hierzu werden entsprechend der bestehenden Randbedingungen die Einzelanforderungen in ihrem inhaltlichen Kontext, z.B. fachliche Domäne „Vertriebssteuerung“, analysiert, grobe fachliche Lösungsideen generiert und diese mit den fachlich Verantwortlichen abgestimmt. Das fachliche Bündeln ist insbesondere wichtig, um sicherzustellen, dass gleiche oder ähnliche Bedarfe ähnlicher Dringlichkeit verschiedener Fachbereiche zusammengefasst werden. So können übergreifende Synergiepotenziale erkannt und gehoben werden.

In Abhängigkeit vom organisatorischen Kontext, wie z.B. der Größe des Unternehmens oder der Komplexität oder Heterogenität des Anforderungsbündels sind hierbei gegebenenfalls mehrere Business-Analysten mit gleichem oder verschiedenem fachlichen Kontext eingebunden. Die fachliche Konzeption und Bündelung müssen dann von den verschiedenen Business-Analysten gemeinsam oder in enger Abstimmung erfolgen. Wenn die Business-Analysten verschiedenen organisatorischen Bereichen angehören, ist in der Regel eine Projektorganisation für die Abwicklung erforderlich.

Wichtig

Erstellen Sie keine aufwendigen fachlichen Lösungskonzepte. Beschränken Sie sich auf die Dokumentation der wesentlichen Annahmen, Entwurfsideen und -entscheidungen. Nutzen Sie hierzu insbesondere die Ergebnistypen (siehe Tabelle 2.1) und möglichst wenig Text, da der Aufwand für die Aktualisierung und Konsistenzsicherung des Textes in Anbetracht der noch volatilen Grobkonzepte in keinem Verhältnis zum Nutzen steht.

Nutzen Sie diese leichtgewichtige Grobkonzeption für die inhaltliche Abstimmung mit den Fachbereichen und der Umsetzungsseite. Führen Sie Entscheidungen über die wesentlichen Annahmen und Entwurfsideen herbei. So gibt es eine abgesicherte Grundlage für die fachliche Detailkonzeption in den Umsetzungsprojekten.

Die fachlichen Lösungsideen müssen konform zu den Randbedingungen und strategischen Vorgaben sein, wie z.B. einer Soll-Bebauung (siehe [Han23]), und die nichtfunktionalen Anforderungen erfüllen. Für die Einzelanforderungen beziehungsweise Anforderungsbündel können durchaus verschiedene Lösungsszenarien entwickelt werden. Der Business-Analyst muss dann die alternativen Szenarien bezüglich ihrer fachlichen Eignung charakterisieren und die fachlich Verantwortlichen bei der Entscheidungsfindung beraten. Nach der Entscheidung für mögliche Lösungsszenarien müssen diese so weit detailliert werden, dass die technische Bewertung und die Umsetzungsplanung erfolgen können (siehe Abschnitt 4.3.4 und Kapitel 3).

Für die Analyse und Gestaltung der Lösungsideen und die fachliche Bündelung werden insbesondere Informationen sowie Analyse- und Bebauungsplanungsmethoden aus dem Enterprise Architecture Management und Prozessgestaltungsfunktionalitäten aus dem Prozessmanagement genutzt (siehe Abschnitt 2.3). So werden z.B. Informationen über Geschäftsprozesse, Geschäftsobjekte, Verantwortlichkeiten und deren Zusammenspiel ermittelt und Redundanzen, Inkonsistenzen oder Optimierungspotenziale aufgedeckt sowie ideale Bebauungen gestaltet.

Bei der Bündelung werden in der Regel fachlich eng gekoppelte Einzelanforderungen so zusammengefasst, dass die verschiedenen Anforderungsbündel möglichst unabhängig voneinander sind und sich gleichzeitig klare Verantwortlichkeiten zuordnen lassen. Letzteres unterstützt den Abstimmungsprozess, da nur noch das Bündel als Ganzes mit den jeweiligen Verantwortlichen diskutiert werden muss.

Details und Hilfestellungen für die fachliche Konzeption von groben Lösungsideen und die fachliche Bündelung finden Sie in Kapitel 3.

Schritt 3: Bewerten und Planen

Auf der Basis der fachlichen Anforderungsbündel kann nun die Bewertung bezüglich Umsetzungsaufwänden und Risiken sowie die Planung der Umsetzungspakete, wie z.B. Projekte, Wartungsmaßnahmen oder Tickets, erfolgen. Diese Bewertung führt in der Regel der Umsetzungsverantwortliche aus, z.B. die interne IT- oder Organisationseinheit. Im Rahmen der Bewertung eruiert der Umsetzungsverantwortliche zumindest grob eine technische Lösungsidee und schätzt den Aufwand sowie die Risiken für die Umsetzung. Hier reichen häufig Größenordnungen, wie z.B. Aufwand zwischen „1000 – 2000 PT“ oder Risiko beziehungsweise Komplexität „niedrig“, „mittel“ oder „hoch“.