im Requirements Engineering werden gemeinsam angegangen, beispielsweise in Workshops. Wenn dabei Anforderungen und Interessen nicht übereinstimmen, können schnell Konflikte entstehen. Dann sind Kenntnisse im Konfliktmanagement hilfreich.
Die Stakeholder – also diejenigen, die ein eigenes Interesse an der Lösung haben – sind eine wichtige Zielgruppe, da deren Anforderungen zu ermitteln, zu priorisieren und zu genehmigen sind. Ihre Beteiligung und Einbindung in die Business-Analyse entscheidet in vielen Veränderungen über den Erfolg und die Akzeptanz der zu entwickelnden Lösung.
Alle Schritte im Konzept des Requirements Engineering schlagen sich im Ergebnistyp Anforderungsdokument nieder. Abhängig vom Lösungsumfang und Lösungsansatz und auch abhängig vom Vorgehensmodell und den Standards im Unternehmen können diese Dokumente unterschiedlich strukturiert und unterschiedlich umfangreich sein. In agilen Vorgehensmodellen entsteht möglicherweise kein Anforderungsdokument im herkömmlichen Sinne, sondern die Anforderungen sind wenig strukturiert und wenig detailliert dokumentiert, zum Beispiel in Form von physischen Boards (etwa auf Pinnwänden) oder mithilfe entsprechender Tools auf elektronischen Boards.
Eine ausführliche Beschreibung des Konzepts Requirements Engineering findet sich in Kapitel 2.
G.3.4 Lösungseinführung
Abb. G.10: Lösungseinführung
„Papier ist geduldig, der Leser nicht.“
Von Unbekannt
Mit dem Konzept Business-Case-Erstellung wird eine Veränderung vorbereitet und u.a. auf Sinnhaftigkeit und Wirtschaftlichkeit untersucht. Requirements Engineering liefert als Ergebnistyp ein Anforderungsdokument. Beide Konzepte beschäftigen sich mit dem zentralen Anliegen der Business-Analyse, Anforderungen zu ermitteln und zu dokumentieren, die eine Lösung und damit eine Veränderung der Ist-Situation beschreiben.
Die Umsetzung dieser Anforderungen ist nicht mehr Bestandteil der Business-Analyse. Abhängig von der Art der beschriebenen Lösung setzen andere Rollen diese um. In vielen Fällen entwickeln Mitarbeiterinnen und Mitarbeiter der IT-Abteilung entsprechende Applikationen, Systeme sowie Infrastruktur und sorgen dafür, dass sie bereitgestellt werden.
Business-Analysten spielen eine wichtige Rolle auf dem „Hinweg“, dem Weg der Anforderungen von den Anforderungsstellern zu den Umsetzern. Es erscheint logisch und sinnvoll, dass Business-Analysten auch den „Rückweg“ begleiten sollten, den Weg der entwickelten/umgesetzten Lösung von der IT-Abteilung zu den Anforderungsstellern bzw. Nutzern dieser Lösung.
Das Konzept der Lösungseinführung in der ibo-Anforderungstür® beschreibt Aspekte, bei denen Business-Analysten sinnvoll zum Einsatz kommen, da sie mindestens mit den Anforderungen und häufig auch mit der Lösung vertraut sind.
So sollte durch die Bewertung der Lösung untersucht werden, ob die Lösung die Verbesserungen erbringt, die über die Geschäftsanforderungen im Business Case definiert wurden. Eine anschließende bzw. fortlaufende Leistungsüberprüfung stellt sicher, dass die Lösung auch künftig einen (Mehr-)Wert erbringt.
Eine Ermittlung, Dokumentation und Umsetzung von Transitionsanforderungen, die den Übergang vom Ist- zum Soll-Zustand beschreiben, erleichtert die Einführung der Lösung. Dazu gehören insbesondere Überlegungen,
wie mit Daten im Ist (bzw. in den Altsystemen) umgegangen wird, z.B. Migration auf die neue Lösung
welche organisatorischen Veränderungen der Betroffenen und Beteiligten sinnvoll und notwendig sind, z.B. Information oder Schulungen
wie Aufgaben, Geschäftsvorfälle und Geschäftsprozesse fortgeführt werden, die im Ist (bzw. in den Altsystemen) begonnen wurden, aber vor Lösungseinführung nicht beendet wurden.
In vielen Unternehmen reichen die Umsetzungskapazitäten nicht aus, um alle Anforderungen zeitnah zu realisieren. Business-Analysten können durch eine Zuordnung von Anforderungen zu Releases dabei mitwirken, gezielt Mehrwert zu schaffen, auch wenn nicht alle Anforderungen „sofort“ umgesetzt werden können oder sollen.
Mit der Einführung der Lösung verschieben sich häufig die Verantwortlichkeiten. Personen, die für die Entwicklung der Lösung verantwortlich waren, haben ihren Beitrag geleistet. Wurde die Lösung im Rahmen eines Projekts entwickelt, so neigt sich dieses dem Ende entgegen oder wurde beendet und der Projektleiter trägt (künftig) keine Verantwortung mehr. Dennoch ist immer sicherzustellen, dass der Betrieb der Lösung technisch verantwortet und weiter begleitet wird. Dieser Übergang von „Build“ to „Run“ funktioniert in vielen IT-Bereichen gut oder ist zumindest hinreichend geregelt. Die Übernahme von Verantwortung auf fachlicher Seite ist nicht immer gleich gut geregelt. Business-Analysten unterstützen eine möglichst reibungslose Einführung und ein klares Rollenverständnis, indem sie beispielsweise Prozessverantwortliche oder Fachbereichsleiter darauf hinweisen, dass „jemand den Hut aufhaben“ sollte.
Handlungsfelder
Als berufliche Handlungskompetenz hilft Business-Analysten Change Management, um Veränderungen auch kulturell zu begleiten.
Wichtige Zielgruppe sind Beteiligte, die mit der neuen oder veränderten Lösung umgehen müssen.
Ergebnistyp dieses Konzepts ist eine Lösung, die erfolgreich eingeführt und weiter begleitet wird.
Eine ausführliche Beschreibung des Konzepts Lösungseinführung findet sich in Kapitel 3.
G.3.5 Business-Analyse-Planung und -Steuerung
Die drei Konzepte Business-Case-Erstellung, Requirements Engineering und Lösungseinführung der ibo-Anforderungstür® bilden eine sinnvolle Reihenfolge, um den Grundprinzipien „Vom Groben zum Detail“, „Von den Zielen zur Lösung“ und „Rationales Entscheiden“ zu folgen.
Abb. G.11: Business-Analyse-Planung und -Steuerung
Das Konzept Business-Analyse-Planung und -Steuerung „begleitet“ die anderen drei Konzepte und soll sicherstellen, dass die Business-Analyse selbst effektiv und effizient durchgeführt wird. Dies gilt für Business-Analysten, die alleine eine Veränderung begleiten, ebenso wie für ein Team von Business-Analysten, das zum Beispiel in einem Projekt zusammenarbeitet.
Planung ist die geistige Vorwegnahme zukünftigen Handelns. In diesem Sinne strukturieren Business-Analysten ihre künftigen Tätigkeiten und stimmen deren Umfang und Inhalt ab.
Ist-Erfassung ermittelt den Status und Fortschritt der Tätigkeiten, abhängig von der Planung hinsichtlich Leistung, Qualität und Termin.
Diagnose prüft, ob es Abweichungen zwischen Ist-Werten und Plan-Werten gibt. Bei Abweichungen suchen Business-Analysten in diesem Schritt nach Ursachen und Zusammenhängen.
Steuerung ergreift Maßnahmen, um bei einer festgestellten Abweichung mögliche Nachteile zu minimieren. Bei kritischen Abweichungen ist möglicherweise eine Eskalation an Führungskraft oder Projektleiter der Business-Analysten notwendig. In jedem Fall sollten Business-Analysten Lessons Learned betreiben, d.h. aus „der Vergangenheit lernen“, Bewährtes
