Business-Analyse. Axel-Bruno Naumann

Lösung vertraut sind.

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

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

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

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

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

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

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

      Handlungsfelder

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

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

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

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

G.3.5 Business-Analyse-Planung und -Steuerung

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

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

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

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

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

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

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

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

      Stakeholder-Analyse

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

      Aufgaben

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

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

      Anforderungsmanagement

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

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

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

      Ist-Erfassung

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

      Diagnose

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

       Wie war das Vorgehen?

       Wo bestehen Probleme in der Business-Analyse?

       Wo liegen Chancen für Verbesserungen?

      Steuerung

      Die Steuerung greift in die aktuelle Business-Analyse ein, um ungewollten Abweichungen von der Planung zu begegnen. Dazu ergreifen Business-Analysten