Abstrakte Anforderungsanalyse als Methodik der Business Analyse

Mir war es heute mal gar nicht nach KAGB, AIFMD und irgendwelchen Key figures. Heute möchte ich mich einem Thema aus der täglichen Praxis der Business Analyse widmen.

Ein wichtiger Aufgabenteil bei der Analyse von Anforderungen für die mögliche IT-technische Umsetzung ist es, die von den Fachabteilungen mehr oder weniger freiwillig bereitgestellten Informationen in eine für den Informatiker verständlich Form zu bringen. Es sind nicht immer neue Systeme, die es einzuführen gilt, oftmals sind es auch „nur“ Anpassungen die anstehen.

Hierbei konkurrieren in den Organisationen – meist historisch begründet – Systeme, die bisher parallel nebeneinander her laufen. Sie konkurieren um die Gunst der Anwender und stehen so einer einheitlichen zentralen Datenhaltung im Wege. Hat der Anwender, die aus seiner Sicht vermeintlich beste Lösung gefunden – dies kann auch eine neue Lösung sein,  so sieht er meist nur das von ihm favorisierte System und orientiert sich bei seinen Anforderungen an seinem eigenen Mikrokosmos.

In der täglichen Analysepraxis ist daher zu beobachten, dass   Fachanwender allzu gerne mit einer vorgefertigten Meinung zur technischen Umsetzung auf die IT zukommen. Diese bereits vor Aufnahme der konkreten Anforderungen stattgefundene Fokussierung hemmt aber den aktiven Meinungsaustausch zwischen Fachbereich und Analysten und lässt eine breitere Sicht auf die Dinge erst gar nicht zu. Dabei bewegen sich die Gesprächspartner während der Zusammenarbeit vielfach auf unterschiedlichen Ebenen, ohne es überhaupt zu bemerken.

Ein Ansatz dem entgegenzuwirken und die Verantwortlichen auf ihre Kernkompetenz zu fokusieren ist es, mit der Analyse ohne die Einbeziehung bereits existierender Lösungen zu starten. Ganz nüchtern sollen zunächst die konkreten Anforderungen/ Problemstellungen geschildert und aufgenommen werden. Dieser theoretisch ganz nett klingende Ansatz birgt aber einige Tücken in sich. Das wirst Du spätestens dann merken, wenn der viel beschäftigte und gestresste Fachanwender ins Spiel kommt, welcher mal wieder über Nacht ein dringendes Problem gelöst wissen möchte.

Aus Sicht des Analysten treten hier Verhaltensweisen an den Tag, die an einen Tanzbären erinnern, den man seit Geburt im engen Käfig an der Kette gehalten hatte und dann urplötzlich auf die Strasse lässt. Was meinst Du, was der Bär in solch einer Situation wohl macht? Ja richtig, er dreht sich nach wie vor im Kreis oder tappst zurück in seinen Käfig, weil er die Freiheit gar nicht kennt.

Übertragen auf die Situation in der abstrakten Anforderungsanalyse bedeutet dies, dass der Anwender eigentlich gar nicht bereit ist seine Gedanken zu öffnen. Er verweist auf das Existierende und man hört nur: „Mach mal, ist doch einfach und klar! Alles ganz easy!“.

Stell Dir jetzt mal vor, Du sollst die Anforderungen dieses „Hans Dampf in allen Sackgassen“ per abstrakter Anforderungsanalyse aufnehmen. Viel Spaß, dass wird eine große Herausforderung! Du tauchst also im Workshop ohne Screenshots oder existierende Reports auf, der Monitor bleibt aus und die Unterlagen Deines Gesprächspartners interessieren Dich nicht. Entweder eskaliert das Gespräch und wird an anderer Front weitergeführt oder Du schaffst es, mit viel Mühe und Schweiß, Dein Gegenüber von Deinem Vorgehen zu überzeugen. Eventuell startest Du auch erst im zweiten Termin, wenn man sich auf die Zurückverlegung der Front geeinigt hat. Bist Du dann soweit, wirst Du mehr als erstaunt sein, welche Perspektiven sich auf einmal öffnen.

Der Fachanwender ist nämlich auf einmal gefordert, seine Wünsche detailliert zu formulieren und seine Gedanken zum Ablaufprozess offen zulegen. Dadurch können Gedanken ausgelöst werden, die bisher nicht entfacht wurden, weil ein einfacher simpler Verweis auf die existierende Lösung genug war. Was dahinter stand wurde gar nicht mehr diskutiert, die Gedankengänge waren einfach blockiert. Die Abstrahierung kann also dazu beitragen bisher festgesetzte Verfahren neu zu überdenken und so eventuell neue, optimierte Lösungen zu finden. Die Beschreibung des Lösungsansatzes ist wieder gefragt und Multiple Choice ist out.

Für beide Seiten ist der Weg weniger komfortabel. Der Anwender muss seinen ‚Grips‘ mehr anstrengen und die Dinge und Prozesse verbal, bis ins Detail, erläutern. Dies hat den gewünschten Effekt, dass ihm die Ungereimtheiten im Ablauf selbst auffallen oder sie im gemeinsamen Gespräch mit dem Analysten auffallen und diskutiert werden können. Es bedarf mit Sicherheit mehrerer Anläufe, bis der Anwender soweit ist. Natürlich hat auch der Analyst wesentlich mehr Arbeit, denn er muss mehr dokumentieren, aufbereiten, analysieren und in geeigneter Form in Lösungsansätze gießen. Das Analyseverfahren ist aufwendiger, weil es natürlich auch bisher unentdeckte Dinge ans Tageslicht bringt.

Ja, ich weiß, wir haben keine Zeit. Aber vielleicht auch nur deshalb weil wir uns permanent um die eigene Achse drehen. Erreichen wir es in durch eine hochwertige Analyse die Substanz zu erhöhen, dann bleiben uns eventuell permanente, zeitraubende und kostenintensive Anpassungen an unseren Softwarelösungen erspart. Qualität gibt es nicht umsonst.

_{Abschließend noch ein Hinweis: Ich setze die Artikel im Blog bewusst nicht als Fachartikel auf. Die manchmal saloppe Schilderung ist bewusst gewählt, um den Text etwas zu lockern. Natürlich handelt es sich auch um Teilbereiche zu einem Thema, die wenn man tiefer einsteigen möchte mit Sicherheit ergänzender Beratung oder Literatur bedürfen. Betrachte den Beitrag einfach als Denkanstoss.}