Kitabı oku: «Business-Analyse», sayfa 3
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.
