Kitabı oku: «Business-Analyse», sayfa 4
Handlungsfelder
Als berufliche Handlungskompetenz hilft Business-Analysten Change Management, um Veränderungen auch kulturell zu begleiten.
Wichtige Zielgruppe sind Beteiligte, die mit der neuen oder veränderten Lösung umgehen müssen.
Ergebnistyp dieses Konzepts ist eine Lösung, die erfolgreich eingeführt und weiter begleitet wird.
Eine ausführliche Beschreibung des Konzepts Lösungseinführung findet sich in Kapitel 3.
G.3.5 Business-Analyse-Planung und -Steuerung
Die drei Konzepte Business-Case-Erstellung, Requirements Engineering und Lösungseinführung der ibo-Anforderungstür® bilden eine sinnvolle Reihenfolge, um den Grundprinzipien „Vom Groben zum Detail“, „Von den Zielen zur Lösung“ und „Rationales Entscheiden“ zu folgen.
Abb. G.11: Business-Analyse-Planung und -Steuerung
Das Konzept Business-Analyse-Planung und -Steuerung „begleitet“ die anderen drei Konzepte und soll sicherstellen, dass die Business-Analyse selbst effektiv und effizient durchgeführt wird. Dies gilt für Business-Analysten, die alleine eine Veränderung begleiten, ebenso wie für ein Team von Business-Analysten, das zum Beispiel in einem Projekt zusammenarbeitet.
Planung ist die geistige Vorwegnahme zukünftigen Handelns. In diesem Sinne strukturieren Business-Analysten ihre künftigen Tätigkeiten und stimmen deren Umfang und Inhalt ab.
Ist-Erfassung ermittelt den Status und Fortschritt der Tätigkeiten, abhängig von der Planung hinsichtlich Leistung, Qualität und Termin.
Diagnose prüft, ob es Abweichungen zwischen Ist-Werten und Plan-Werten gibt. Bei Abweichungen suchen Business-Analysten in diesem Schritt nach Ursachen und Zusammenhängen.
Steuerung ergreift Maßnahmen, um bei einer festgestellten Abweichung mögliche Nachteile zu minimieren. Bei kritischen Abweichungen ist möglicherweise eine Eskalation an Führungskraft oder Projektleiter der Business-Analysten notwendig. In jedem Fall sollten Business-Analysten Lessons Learned betreiben, d.h. aus „der Vergangenheit lernen“, Bewährtes für weitere Business-Analysen standardisieren und begangene Fehler für die Zukunft vermeiden.
Die Planung der Business-Analyse umfasst die drei Komponenten Stakeholder-Analyse, Aufgaben und Anforderungsmanagement.
Stakeholder-Analyse
In der Stakeholder-Analyse klären Business-Analysten, wer durch eine Veränderung betroffen ist, wer auf sie Einfluss nimmt und welche Stakeholder für die Business-Analyse zu berücksichtigen sind. Die beste, technisch umgesetzte Veränderung droht an mangelnder Akzeptanz zu scheitern, wenn Personen sich übergangen fühlen, nicht ausreichend berücksichtigt wurden oder ihre Anforderungen nicht einbringen konnten.
Aufgaben
Die Planung der Aufgaben unterscheidet sich je nach dem gewählten Vorgehensmodell. In klassischen Vorgehensmodellen (z.B. Projekte nach Wasserfallprinzip) werden die künftigen Aufgaben der Business-Analyse vergleichsweise ausführlich vorab geplant, indem die Inhalte der Aufgaben beschrieben, Dauer und Termine festgelegt werden. Häufig wird die Planung formal abgenommen und später auch formal überprüft.
In agilen Vorgehensmodellen wird in der Regel lediglich die anstehende Iteration fein geplant. Weitere Iterationen werden umso gröber geplant, je weiter sie in der Zukunft liegen.
Anforderungsmanagement
Die Planung des Anforderungsmanagements umfasst unter anderem Überlegungen, in welchen Dokumenten Anforderungen hinterlegt werden und welche Software-Tools zur Verwaltung der Anforderungen genutzt werden. Sinnvollerweise planen Business-Analysten auch vorab, welche Attribute sie neben der eigentlichen Anforderung erfassen und verwalten wollen. Häufig genutzte Attribute sind eine eindeutige ID, Angaben zur Quelle der Anforderung, zum Versionsverlauf, zum Autor, zum Status der Anforderung.
Die Verfolgbarkeit (Traceability) der Anforderungen erfasst ihren Lebenszyklus, von ihrem Entstehen bis zu ihrem Ende (z.B. durch Umsetzung und Archivierung). Business-Analysten können die Verfolgbarkeit von Anforderungen unterschiedlich intensiv betreiben. Daher sollten sie vorab planen, in welcher „Ausbaustufe“ sie Traceability durchführen wollen.
Weiter ist festzulegen, wie mit Änderungen von Anforderungen umgegangen werden soll. Während agile Vorgehensmodelle eine Veränderung von vornherein vorsehen und akzeptieren, findet im Rahmen klassischer Vorgehensmodelle häufig ein explizites IT-Change-Management statt. In der Planung des IT-Change-Managements wird unter anderem festgelegt, wie über Änderungen entschieden wird und wie Anforderungen formal geändert werden (z.B. Prozess mit Change Request).
Ist-Erfassung
Die Ist-Erfassung ermittelt und dokumentiert Kennzahlen für eine effiziente und effektive Performance der Business-Analyse. Dies können z.B. Termine, Änderungshäufigkeit der Anforderungen, Anzahl benötigter Review-Zyklen für Anforderungsdokumente sein.
Diagnose
Die Diagnose vergleicht die Werte der Planung mit den Ergebnissen der Ist-Erfassung. Typische Fragen insbesondere bei Abweichungen sind:
Wie war das Vorgehen?
Wo bestehen Probleme in der Business-Analyse?
Wo liegen Chancen für Verbesserungen?
Steuerung
Die Steuerung greift in die aktuelle Business-Analyse ein, um ungewollten Abweichungen von der Planung zu begegnen. Dazu ergreifen Business-Analysten korrigierende Maßnahmen, um sicherzustellen, dass Leistung, Qualität und Termine eingehalten werden.
Vorbeugende Maßnahmen mindern bei künftigen Abweichungen deren Eintrittswahrscheinlichkeit oder deren negative Auswirkung. Schließlich wird durch eine kontinuierliche Verbesserung der Business-Analyse das Vorgehen beziehungsweise der Geschäftsprozess der Business-Analyse aktualisiert.
In der Praxis sind die Schritte Ist-Erfassung, Diagnose und Steuerung kaum voneinander zu trennen. Zudem unterstützen viele Techniken gleichzeitig alle drei Schritte. Daher werden diese drei Schritte in Kapitel 4 eng miteinander verknüpft. Dort findet sich eine ausführliche Beschreibung des Konzepts Business-Analyse-Planung und -Steuerung.
G.4 Rollen und Stellen in der Business-Analyse
In diesem einleitenden Kapitel soll ein Überblick über die verschiedenen Bezeichnungen der Personen gegeben werden, die mit Anforderungen befasst sind. Anders als zum Beispiel im Projektmanagement wurden die Rollen- und Stellenbezeichnungen in der Business-Analyse (noch) nicht vereinheitlicht.
Ein Business-Analyst ist jede Person, die Aufgaben der Business-Analyse ausführt.
Die Definition berücksichtigt,
dass Business-Analyse aus Aufgaben mit unterschiedlicher „Flughöhe“ besteht (eher strategischer, taktischer oder operativer Natur)
dass diese Aufgaben in unterschiedlichen Themenfeldern anfallen, z.B. Automatisierung oder Geschäftsprozessoptimierung
dass Business-Analyse in unterschiedlichen Kontexten stattfindet, in agilen oder klassischen Projekten, Veränderungsmaßnahmen großen oder mittleren Ausmaßes oder in kleinen Veränderungen im Tagesgeschäft.
Neben der weit verbreiteten Stellenbezeichnung „Business-Analyst“ gibt es weitere Rollen und Stellen, die verwandte Aufgaben rund um Anforderungen wahrnehmen bzw. die in eine Business-Analyse einbezogen werden. Die Abbildung nennt gebräuchliche Bezeichnungen dieser Personen.
Abb. G.12: Rollen und Stellen in der Business-Analyse
Rund um Anforderungen lassen sich zwei Personengruppen unterscheiden:
Spezialisten, die sich hauptsächlich mit Anforderungen beschäftigen. „Business-Analyst“ ist hierbei eine verbreitete Stellenbezeichnung und wird im weiteren Verlauf des Buches verwendet. Darüber hinaus gibt es noch andere Bezeichnungen für Spezialisten rund um Anforderungen (vgl. linke Spalte der Abbildung G.12).
Daneben gibt es Personen, die sich als Betroffene/Beteiligte einen Teil ihrer Arbeitszeit mit Anforderungen beschäftigen, sei es in Projekten oder im Tagesgeschäft (vgl. mittleren und rechten Teil der Abbildung G.12).
Die Aufgaben dieser Personen und ihre Verknüpfung zur Business-Analyse werden insbesondere in den Kapiteln 1 bis 4 erläutert. Die Schwerpunkte einiger Rollen werden im Folgenden skizziert.
Business-Case-Erstellung
Bei der Erstellung eines Business Case werden beispielsweise Unternehmensarchitekten oder Business-Planer tätig, die die Verträglichkeit von Lösungsansätzen und -ideen mit Architekturentscheidungen und -vorgaben des Unternehmens abgleichen. Multiprojekt- und Portfoliomanager prüfen, ob verwandte oder widersprüchliche Lösungsansätze vorhanden sind. Sie fügen nach einem erfolgreichen Business Case das Veränderungsvorhaben in das Portfolio aller Vorhaben ein, indem sie es zeitlich und inhaltlich einordnen. Produktmanager entwickeln Vorschläge, wie bestehende Produkte weiterentwickelt oder neue Produkte bzw. Dienstleistungen geschaffen werden sollen.
In plan-orientierten Vorgehensmodellen (z.B. nach Wasserfall) entscheidet ein Bewilligungsgremium oder Architektur-Board über den Business Case. In wandel-getriebenen (agilen) Vorgehensmodellen liegt diese Kompetenz z.B. beim Product Owner (als zentrale Rolle in Scrum).
Requirements Engineering
Je nach Unternehmen und Branche wird anstelle von Business-Analyst eine der anderen Bezeichnungen genutzt, wie z.B. Requirements Engineer, Anforderungsmanager, Systemanalytiker, IT-Koordinator, IT-Organisator. Unternehmen, die sich nach ITIL ausrichten, setzen häufig Demand Manager ein, die Anforderungen aufnehmen und dokumentieren.
In klassischen Projekten entscheidet ein Lenkungsausschuss oder ein Steering Committee über das Projekt im Allgemeinen und das Anforderungsdokument im Besonderen. In agilen Vorgehen bearbeitet ein Entwicklungsteam die Anforderungen und wird dabei von einem Scrum Master methodisch unterstützt.
Lösungseinführung
Bei der Lösungseinführung wird das Ergebnis des Vorhabens in die Linie bzw. in das Tagesgeschäft übergeben. Für prozessorientiert gegliederte Unternehmen spielen die Prozessverantwortlichen eine zentrale Rolle.
Sind mehrere Business-Analysten in einem Unternehmen tätig, müssen sie als Gruppe oder Team organisiert werden. Dabei können formal feste Rollen wie Senior-Business-Analyst oder Lead-Business-Analyst geschaffen werden. Es kann auch ein Business-Analyse-Center-of-Excellence oder Business-Analyse-Office eingerichtet werden, in dem die Mitarbeiter der Business-Analyse zusammengeführt werden. Ein solches Center of Excellence dient dann auch dem Informationsaustausch, dort werden Lessons Learned gezielt genutzt und es wird die Business-Analyse im Unternehmen weiterentwickelt.
Literatur zu Kapitel G
Carkenord, B. A.: Seven Steps to Mastering Business Analysis. Plantation 2009
International Institute of Business Analysis (IIBA): A Guide to the Business Analysis Body of Knowledge (Babok Guide). Version 3.0, Toronto 2015
International Institute of Business Analysis (IIBA): Business Analysis Body of Knowledge® – BABOK 2.0®. Leitfaden zur Business Analysis. 1. Aufl. in deutsch, Gießen 2012
Paul, D.; Yeates, D.; Cadle, J. (Editors): Business Analysis. 3rd Edition, London 2014
Podeswa, H.: The Business Analyst's Handbook. Boston 2008
Robertson, S.; Robertson, J.: Mastering the Requirements Process. 3rd Edition, Upper Saddle River 2012
1 Business-Case-Erstellung
1.1 Einleitung
„Wenn man in einen falschen Zug einsteigt, nützt es nichts, wenn man im Gang entgegen der Fahrtrichtung läuft.“
Dietrich Bonhoeffer
1.1.1 Startpunkte für Veränderungen
Business-Analyse beschäftigt sich mit Veränderungen. Alle Veränderungen beruhen auf Anforderungen, die von unterschiedlichen Seiten eingebracht werden können. Anforderungen tragen es in sich, dass sie den Ist-Zustand verändern sollen. Häufig sind damit Verbesserungen des Ist-Zustands verbunden.
In den Fällen, dass regulatorische oder gesetzliche Auslöser eine Veränderung anstoßen, steht in der Regel keine Verbesserung, sondern die Einhaltung der regulatorischen oder gesetzlichen Auflagen im Mittelpunkt. Auch Veränderungen, die aus einer Organisation heraus initiiert werden, bringen es oft mit sich, dass regulatorische Aspekte zu beachten sind.
Seit einiger Zeit häufen sich bei den TREND Möbelhäusern die Wünsche, dass in den Filialen die Einrichtung der Bistros modernisiert werden sollte. „Die Einrichtung ist in die Jahre gekommen“, lautet es sowohl von Kunden als auch von Mitarbeitern.
Sollten diese Anforderungen weiterverfolgt werden, sind auch gesetzliche Bestimmungen einzuhalten, wie sie zum Beispiel im Gaststättengesetz und in der Verordnung über Arbeitsstätten zu finden sind.
Veränderungen (Changes) können unterschiedliche Startpunkte haben: Top-Down, Bottom-Up, Middle Management, External Drivers (vgl. Abb. 1.01).
Abb. 1.01: Startpunkte für Veränderungen (in Anlehnung an VAHS, 2015)
Veränderungen von Top-Down entstammen häufig der strategischen Ebene, ausgelöst durch die Geschäftsführung bzw. das Management eines Unternehmens. Oft sind neue oder aktualisierte Unternehmensziele, strategische Maßnahmen, Umstrukturierungen oder der Aufbau einer neuen Produktlinie die Auslöser.
Bottom-Up-Veränderungen werden in der Regel von Mitarbeitern angestoßen und betreffen operative Probleme oder Verbesserungen in Geschäftsprozessen oder IT-Systemen. Sie kommen z.B. aus dem betrieblichen Vorschlagswesen, aus einem „Kontinuierlichen Verbesserungsprozess“ (KVP), aus Behelfslösungen (Workarounds), die beseitigt oder optimiert werden sollen, aus Mitarbeiterbefragungen oder einem Ideenmanagement.
Das Middle Management stößt Veränderungen häufig an, um beispielsweise Arbeitsabläufe zu standardisieren oder zu automatisieren, um Zuständigkeiten zu klären oder Hinweise und Auflagen aus Qualitätsmanagement, Revision oder internen Audits aufzugreifen.
External Drivers stammen vom Kunden, vom Wettbewerb, von Regulatoren. Die damit verbundenen Veränderungen haben ihren Ursprung zum Beispiel im Beschwerdemanagement, Kundenbefragungen, Benchmarking, Normen und Standards.
1.1.2 Skalierbarkeit von Business Cases
Große Veränderungen werden in vielen Unternehmen im Rahmen eines Projekts abgewickelt. Kleinere Veränderungen finden im Tagesgeschäft statt. Die meisten Organisationen halten für Veränderungen mittleren Ausmaßes sogenannte Maßnahmen oder Einzelmaßnahmen bereit, die keinen echten Projektcharakter haben, aber auch nicht in den normalen Abläufen des Tagesgeschäfts (z.B. in Geschäftsprozessen) erledigt werden.
Das Konzept der Business-Case-Erstellung in der ibo-Anforderungstür® bietet sowohl für große, mittlere als auch für kleinere Veränderungen ein strukturiertes Vorgehen, um zu einer rationalen Entscheidung zu kommen, wie die Veränderung angegangen werden sollte. Unabhängig von der Größe der Veränderung ist es sinnvoll, das „Big Picture“, also das „Große Ganze“ zu verstehen und die Gründe für eine Veränderung zu analysieren.
Ein Business Case ist eine Grundlage für eine Entscheidung, ob eine Lösung dazu beiträgt, Geschäftsanforderungen zu erreichen, und ob der Nutzen einer Lösung größer ist als die Kosten für Umsetzung und Betrieb der Lösung.
Eine Lösung ist die Summe der Veränderungen des Ist-Zustands eines Unternehmens, um einen Bedarf zu decken und/oder Ziele zu erreichen.
Mit dem Begriff Business Case wird häufig eine umfangreiche Machbarkeits- und Wirtschaftlichkeitsprüfung verbunden. Für große Veränderungen lohnt es, diese Vorüberlegungen zu treffen, bevor Anforderungen im Detail erhoben, analysiert und dokumentiert werden.
Aber auch bei kleinen Veränderungen erscheint es sinnvoll, nicht gleich loszulaufen, ohne den Weg zu kennen. In diesen Fällen sollte bei einer Realisierbarkeits- bzw. Durchführbarkeitsprüfung entsprechend weniger Aufwand betrieben werden.
Abb. 1.02: Ausprägungen und verwandte Konzepte zu einem Business Case
Die Abbildung 1.02 zeigt Synonyme bzw. verwandte Konzepte zum Business Case. Die Skala reicht von „Small“ bis „Vollversion“. Damit reicht die Spanne von kleinen Veränderungen und damit „schlanken“ und häufig informellen Dokumenten bis hin zu großen Veränderungen, die formale und umfangreiche Dokumentationen mit sich bringen.
Einige gebräuchliche Ausprägungen eines Business Case werden im Folgenden skizziert:
Auftragsklärung, Projektantrag/-idee, Projektauftrag, Vorhabenblatt: Zusammenfassung der Ausgangslage und Gründe für eine Veränderung, der angestrebten erwünschten Wirkungen und des geplanten Zeitfensters
One Pager, Vorstandsvorlage: Management Summary als Entscheidungsvorlage für eine Veränderung; häufig mit formalen Vorgaben hinsichtlich Inhalt und Struktur
Machbarkeitsprüfung, -studie: Fokussierung auf die Überprüfung der technischen, organisatorischen und fachlichen Durchführbarkeit einer Veränderung mit internen oder externen Ressourcen
Demand and Scope Management, Szenario-Analyse: Fokussierung auf die Betrachtung verschiedener Lösungsansätze oder Zukunftsszenarien und die Empfehlung, welche Maßnahmen getroffen werden sollten, um diesen bestmöglich zu begegnen
Business Case, Wirtschaftlichkeitsprüfung: Fokussierung auf die Überprüfung des Kosten-Nutzen-Verhältnisses einer Veränderung; häufig mit vorgegebener Struktur und Angaben, wann eine Veränderung „sich rechnet“; unter Einbeziehung der möglichen Risiken, die eine Veränderung mit sich bringt.
1.1.3 Vier Schritte zur Business-Case-Erstellung
Professionelle Business-Analyse zeichnet sich insbesondere durch ein systematisches, strukturiertes Vorgehen aus. Dieses sollte auch bei der Erstellung eines Business Case gelten.
Die vier Schritte zur Business-Case-Erstellung umfassen (vgl. Abb. 1.03):
Leistungspotenziale: Den Ist-Zustand im Gesamtzusammenhang verstehen, Probleme und tiefer liegende Ursachen analysieren, fehlende Leistungspotenziale aufdecken, vorhandene Leistungspotenziale einschätzen
Geschäftsanforderungen: Klären, welche Ziele mit der Veränderung verfolgt werden, dabei Lösungen durch Ziele ersetzen
Lösungsansätze: Wege zur Lösung herausfinden und dabei den Lösungsumfang definieren
Empfehlung: Business Case vervollständigen und eine Empfehlung für eine Lösung aussprechen.
Bei den verschiedenen Ausprägungen eines Business Case (vgl. oben) werden typischerweise alle vier Schritte betrachtet. Je nach Ausprägung kann allerdings der Schwerpunkt innerhalb der vier Schritte unterschiedlich gesetzt werden.
Abb. 1.03: Vier Schritte der Business-Case-Erstellung
Je nach Ausmaß der Veränderung ist es sinnvoll, Umfang und Detaillierung des Business Case anzupassen. Große Veränderungen bringen eine umfangreichere Voruntersuchung mit sich, die in einen ausführlicheren Business Case mündet. Kleine Veränderungen kommen mit einem kompakten und „abgespeckten“ Business Case aus (vgl. auch Kapitel 1.6).
Unter Beachtung des Grundprinzips Rationales Entscheiden (vgl. Kapitel G.3) sollte vermieden werden, dass eine Entscheidung bzw. Empfehlung schon vor Beginn der Business-Case-Erstellung feststeht. Andernfalls besteht die Gefahr, dass im Business Case nur Fakten zusammengetragen werden, um diese Entscheidung zu untermauern. Oder es besteht die Herausforderung, dass für die vorab getroffene Empfehlung vermeintliche Argumente gesammelt werden, die unter objektiver Betrachtung nicht stichhaltig sind.
Daher sollte ein Business Case möglichst ergebnisoffen begonnen werden, so dass im Schritt „Lösungsansätze“ Alternativen erarbeitet werden, die eine tatsächliche Verbesserung des Ist-Zustands herbeiführen können und dabei die Ziele des Schritts „Geschäftsanforderungen“ erfüllen können.
Je nach Inhalt und Kontext des Business Case können sich die jeweiligen Empfehlungen zum weiteren Vorgehen bzw. zur Weiterverfolgung der Veränderung unterscheiden. Empfehlungen werden häufig auf der Basis eines Kriteriums oder mehrerer Kriterien ausgesprochen, wie zum Beispiel:
Wirtschaftlichkeit: Günstiges Kosten-Nutzen-Verhältnis, ungünstiges, kein sinnvolles Kosten-Nutzen-Verhältnis, Wirtschaftlichkeit aus gesetzlichen oder regulatorischen Gründen unerheblich
Risiko: Veränderung zu riskant, wenig riskant, Risiken vertretbar
Zeitlich: Sofortige Umsetzung der Veränderung, zeitnahe, mittelfristige, langfristige Umsetzung der Veränderung
Fachlich, Kontext: Alleinstehend, mit anderen Themen/Veränderungen verknüpft, in kleinere Veränderungen aufteilen
Ressourcen, Know-how: Veränderung intern umsetzen, mit externer Unterstützung angehen, extern umsetzen
Vorgehensweise: Mit Hilfe einer agilen Methode (z.B. Scrum), in einem klassischen Projekt (z.B. Wasserfall)
Größe der Veränderung: Klein und damit im Tagesgeschäft möglich, mittel bis groß und damit Umsetzung im Rahmen einer Einzelmaßnahme oder eines Projekts sinnvoll, sehr groß und damit in mehreren Projekten bzw. in einem Projektportfolio oder -programm umzusetzen.
