Business Analyst*in vs. Requirements Engineer
In jüngster Zeit geht es im Gespräch mit vielen potenziellen Uzanto-Kunden um Mandate als Requirements-Engineer (RE) oder Business-Analyst*in (BA). Doch was ist eigentlich der Unterschied zwischen diesen Job Descriptions?
Ich fand nicht so einfach eine Antwort auf diese Frage und stellte ein paar Recherchen an. Die Ergebnisse will ich euch nicht vorenthalten.
Definitionen Swiss ICT
Gemäss der Website “Berufe der ICT” von Swiss ICT sind die beiden Tätigkeitsfelder folgendermassen definiert.
Business Analyst:
Erheben, Analysieren sowie Identifizieren und Kommunizieren der Schwachstellen von Businessprozessen, Organisationsstrukturen, Informatik- und Sachmitteleinsätzen; Ausarbeiten von Anforderungen für das Realisieren von betrieblichen Lösungen.
Requirements Engineer:
Erfassen, Analysieren, Validieren, Konsolidieren, Dokumentieren und Kommunizieren von Anforderungen von Auftraggebenden an ICT-Lösungen.
Aus dieser Sichtweise ergibt sich auf den ersten Blick eine Gemeinsamkeit und ein klarer Unterschied. Gemein ist den beiden Berufen, dass Anforderungen definiert werden. Beim RE geschieht dies aus der Sichtweise eines nicht näher definierten Auftraggebenden. Beim BA hingegen liegt der Ursprung der Requirements in bestehenden Schwachstellen.
Heisst dies, dass Business Analysten nur Bestehendes optimieren und für alle neuen Anforderungen Requirements Engineers zuständig sind?
Definition der Berner Fachhochschule
Irgendwie finde ich dieses Ergebnis nicht zufriedenstellend. Schliesslich habe ich viel Zeit und Energie in mein Business Analyse Studium an der BFH investiert und soll jetzt “nur” für die Ausmerzung von Schwachstellen zuständig sein. Dabei bin ich doch so motiviert User und ihre Bedürfnisse zu verstehen und in gescheite Anforderungen an IT Systeme zu transformieren! Habe ich das falsche Studium gewählt?
Die Fachhochschule Bern definiert diese vier Ausbildungsziele für den Lehrgang MAS Information Technology mit Vertiefung Business Analyst:
1. Sie lernen, basierend auf einer Unternehmensstrategie Zielsetzungen und Strategien für die Unternehmens-IT zu entwickeln.
2. Sie können aktiv an der Erarbeitung und Pflege der Kernelemente des IT-Managements mitarbeiten.
3. Sie können Requirements Engineering so in Ihre Entwicklungsprojekte einbringen, dass eine wirtschaftliche und benutzergerechte Lösung entsteht.
4. Sie erwerben die fachlichen Kompetenzen und die Soft Skills, um in einem Projekt ein systematisches und situationsgerechtes Requirements Engineering zu praktizieren.
Okay, das klingt nun schon etwas anders:
Die Punkte drei und vier benennen RE direkt als Tätigkeitsfeld des BA. So scheint hier RE als eine Subkategorie von BA verstanden zu werden. Dies widerspiegelt sich auch so im Studium: Requirements Engineering war eines von vier CAS während dem MAS BA Studiengang.
By the way, liebe BFH: Worin unterscheiden sich eigentlich genau die Punkte drei und vier?
Neben der zentralen RE Tätigkeit, fallen mir im Lehrplan der BFH die Punkte Unternehmensstrategie, IT-Management und Projekt(management) auf. Die ersten beiden Punkte interpretiere ich so, dass hier nicht nur die Analyse bestehender Unternehmensprozesse- und Strukturen gelehrt wird, sondern auch deren aktive Gestaltung; vor allem in einem IT Kontext.
Der Bezug auf Projekte ist nachvollziehbar, da BA’s in der IT vor allem in diesem Kontext zum Einsatz kommen. In agilen Methoden verliert der Projektbegriff aber an Bedeutung, so dass BAs vermehrt permanente Mitglieder von Teams werden.
Fazit
Für mich machten die oben wiedergegebenen Recherchen klar, dass RE und BA nicht einheitlich definiert sind und sehr nahe beieinander liegen. Am Ende spielt es wohl auch keine grosse Rolle, welchen Titel eine Stellenbeschreibung bekommt. Dennoch lohnt es sich über solche Begrifflichkeiten nachzudenken, zumal sie unsere Wahrnehmung und unser alltägliches Verhalten massgeblich prägen.
Am Ende zählt für mich in einer zunehmend agilen IT Welt, was ein Team an Kunden-Value generieren kann. Dazu braucht es neben technischen Fähigkeiten, die systematische Definition und laufende Überprüfung von Kunden-Bedürfnissen, genauso wie das radikale Hinterfragen von Geschäftsprozessen. Ich verstehe daher RE und BA als Skillset und nicht als Stellenbeschreibung. Die RE oder BA Tätigkeiten können in einem Scrum-Team durch den PO oder eine dedizierte Person ausgeführt werden. Noch besser werden aber diese Aufgaben in einem Team aufgeteilt. So lernen alle, was der Kunde wirklich braucht und das Team ist auch beim Wegfall einzelner Mitglieder funktionsfähig.
