Als Business Analyst ermittle ich zusammen mit Ansprechpartnern aus Ihren Fachbereichen die fachlichen Anforderungen, die eine zu entwickelnde Lösung erfüllen soll.

Analyse-Methoden

Die Anforderungsermittlung kann im Rahmen von Briefings, Fachbereich-Teams, Workshops oder einer kompletten Wertstromanalyse bzw. einer Mischung aus den 4 Methoden erfolgen. Bei der Wertstromanalyse wird der Ist-Zustand einem über die strategischen Anforderungen beschriebenen Soll-Zustand gegenübergestellt und daraus Wertströme mit enthaltener Lösung entwickelt. Diese neu entwickelten Wertströme werden dann in einer oder mehreren Workshop-Runden angepasst und abgenommen. Der Vorteil bei der Zusammenarbeit mit Fachbereich-Teams ist, dass die Anforderungen sehr schnell und umfassend ermittelt werden. Nachteil ist, dass diese überwiegend hochkarätigen Personal-Ressourcen in Form von Key-Usern und Fachbereichsverantwortlichen in der Zeit der Anforderungsermittlung nicht für die eigentlichen operativen Aufgaben zur Verfügung stehen. Ich würde trotzdem immer die Zusammenarbeit mit Fachbereich-Teams bevorzugen, auch weil nur dabei ein Wissenstransfer in andere Unternehmensbereiche möglich ist.

Herausforderung

Ich verfüge sowohl über das methodische Wissen, als auch die Erfahrung aus zahlreichen Projekten, um die Anforderungen effizient und vollständig zu erfassen. Eine immer wieder große Herausforderung ist dabei das gegenseitige “Einschießen” von Fachbereich-Teams, dem Product Owner und dem Entwicklungsteam, zwischen denen der Business Analyst wie eine Flipper-Kugel interagiert. Dabei verringert sich der Abstimmungsaufwand im Projektverlauf erfahrungsgemäß deutlich.

Umsetzung

Als Business Analyst führe ich ein Fachbereichsteam “effizient” durch die Anforderungsermittlung – idealerweise anhand einer Basis- oder Ausgangslösung, die es zu weiterzuentwickeln gilt. Um die Effizienz zu steigern, arbeite ich mit Break Outs und Concept Sprints – wo sinnvoll auch mit Parallelisierung und Time-Boxing. Ich dokumentiere live in einem geeigneten und gemeinsam genutzten Tool, um Doppelarbeit zu vermeiden und Transparenz zu ermöglichen.

Ein zweiter Aufgabenbereich ist die Beratung auf Basis von Erfahrungen aus parallelen oder vorgelagerten Anforderungsermittlungen und der Wissens- und Erfahrungstransfer zwischen den Fachbereich-Teams sowie zwischen den Entwicklungsteams. Diese Transferleistung ist die Basis für eine möglichst umfangreiche Vereinheitlichung von Arbeitsprozessen, welche sowohl Projekt- als auch laufende Kosten erheblich senken.

Bedarf

Der Business Analyst ist immer dann unverzichtbar, wenn der Fachbereich nicht über das zur Umsetzung einer Lösung notwendige Fach- oder Methoden-Wissen verfügt. Ein Business Analyst kann vor allem in Großunternehmen intern gestellt werden, wenn das Unternehmen eigene Abteilungen mit dem notwendigen Wissen zur Umsetzung der Lösung unterhält – und externe Dienstleister dann höchstens zur Ergänzung von fachunkritischer Arbeitskraft einsetzt. Verfügt ein Unternehmen nicht über das methodische und fachliche Wissen zur Umsetzung einer Lösung und kauft sich deshalb die Leistung über einen Dienstleister ein, dann ist der Einsatz eines Business Analysten “vom Dienstleister” unverzichtbar, weil der über das notwendige Wissen zur Lösungsrealisierung verfügen “muss”. Das ist vor allem dann immer der Fall, wenn bestehende Standard-Lösungen eines Lieferanten implementiert werden sollen. Ein Kunde solch einer Lösung verfügt in den seltensten Fällen über ausreichend kompetente interne Ressourcen.

Was passiert also, wenn ein Unternehmen auf den Einsatz eines Business Analysten mit dem notwendigen Wissen verzichtet?

• Die Fachbereiche kennen die Methodik für eine effiziente Anforderungsermittlung nicht
• Anforderungen
  • werden nicht korrekt und vollständig erfasst
  • widersprechen sich
  • beschreiben ein vermeintliches “wie” und nicht “was” gefordert wird
  • werden nicht in der notwendigen Reihenfolge erfasst und das Entwicklerteam kann deshalb nicht frühzeitig mit der Lösungsumsetzung starten
• Das Unternehmen erfährt keine Beratung über
  • Good-Practices
  • Lösungsoptionen
• Das Entwicklerteam kann wenig bis nichts mit den Anforderungen anfangen
• Der Product Owner wird aufgrund von gegenseitigem Unverständnis zwischen Fachbereichen und Entwicklerteam verheizt
• Die Fachbereich-Teams sind ratlos und verlieren ihre Mitwirkungsbereitschaft
• Das Entwicklerteam scharrt mit den Hufen, kann aber nichts umsetzen, da Anforderungen in der notwendigen Qualität fehlen
• Das Programm und das Projekt als Ganzes verfehlen fachliche, zeitliche und monetäre Ziele
• Das Projekt scheitert, der personelle und finanzielle Einsatz müssen ohne Mehrwert abgeschrieben werden

Der Business Analyst wird aus Budgetgründen immer wieder gestrichen. Genauso oft scheitern Projekte, weil mit dem Verzicht dieser wichtigen Schnittstellen-Rolle ein unnötiges und oft unlösbares Spannungsfeld erzeugt wird.

Fazit ist, dass der Business Analyst immer vom Entwickler der Lösung gestellt werden sollte, so dass sich der Kunde oder Fachbereich ganz auf seine Stärken konzentrieren kann und möglichst wenig mit Aufgaben penetriert wird, die für die einzelnen Mitarbeiter kaum lösbar sind. Das hört sich im ersten Moment zwar teurer an, spart in der Praxis jedoch eine Menge Geld und Nerven und verringert das Projektrisiko erheblich.