Was macht eigentlich ein Analytiker in einem IT-Projekt? Während die Aufgaben anderer Rollen in IT-Projekten (Entwickler, Projektmanager, Tester) sehr klar definiert sind, bleibt die Beschreibung der Tätigkeiten der IT-Analyse relativ vage. Dabei handelt es sich keineswegs um ein neues Aufgabenfeld. Seit es Software gibt, wird analysiert, bevor zu programmieren begonnen wird. Vor ca. 35 Jahren hat man die Tätigkeit folgendermaßen beschrieben[1]:
Das Berufsbild des Systemanalytikers – so hat man diese Rolle damals genannt – ist für folgende Tätigkeiten zuständig:
- Ermittlung des Bedarfs nach neuen Informationssystemen oder nach Änderungen bestehender Informationssysteme
- Analyse des Ist-Zustandes bestehender Systems
- Entwicklung von Lösungsvorschlägen und von Soll-Konzepten für neue Informationssysteme.
Anforderungen erheben und dokumentieren …
Heute spricht man eher selten von „Systemanalyse“. In weiten Bereichen hat sich die Berufsbezeichnung „Requirements Engineer“ durchgesetzt. Auf die Frage nach dessen Aufgaben wird man zumeist etwa folgende Antwort bekommen: Erhebung und Dokumentation von Anforderungen.
Ein oberflächlicher Blick in die Dokumente, die den Quasi-Standard der Profession des Requirements Engineers definieren, scheint diese Aussage zu bestätigen:
Das International Requirements Engineering Board (IREB) definiert in seinem Lehrplan zur Zertifizierungsprüfung für den CPRE (Certified Professional for Requirements Engineering) folgende Haupttätigkeiten des Requirements Engineers[2]:
- Anforderungen ermitteln
- Dokumentation von Anforderungen
- Anforderungen prüfen und abstimmen
- Anforderungen verwalten.
Der zweite maßgebliche Standard für die IT Analyse ist der „Business Analysis Body of Knowledge“ (BABOK) des International Institute of Business Analysis (IIBA)[3]. Dieser ist in so genannte Knowledge Areas gegliedert. Von den sechs Knowledge Areas beschäftigen sich drei mit der Erfassung und der Verwaltung von Anforderungen.
Erheben und sauberes Aufschreiben von Anforderungen – so lässt sich nach diesen Quellen die Arbeit des IT-Analytikers zusammenfassen.
… oder Lösungen gestalten
Ein wesentlich differenzierteres Bild zeigt sich, wenn man die Arbeit eines Analytikers in der Praxis betrachtet: Es geht wesentlich über das Erfragen und Aufschreiben von Anforderungen hinaus. Da wird viel nachgedacht. Es werden Modelle entworfen, Datenmodelle auf der einen Seite, Prozessmodelle auf der anderen. Es wird über Schnittstellen geredet – vor allem jene zum Benutzer – die erforderlichen Bildschirmmasken, auf denen Daten eingegeben und angezeigt werden. Alle diese Tätigkeiten lassen sich kaum mit „Verwaltung von Anforderungen“ zusammenfassen. Es ist vielmehr ziemlich genau das, was durch die eingangs erwähnte Teilaufgabe „Entwicklung von Lösungsvorschlägen und von Soll-Konzepten für neue Informationssysteme“ beschrieben ist. Eine Definition, die diese Aktivitäten wesentlich besser trifft als „Anforderungverwaltung“, ist „Gestaltung von Lösungen“.
Das deckt sich auch gut mit dem Modell, das die Bitkom, der Digitalverband Deutschlands, auf der Website www.erlebe-it.de beschreibt. Es werden dort all die vielen Berufsbilder, die es im IT-Umfeld gibt, zu drei Gruppen zusammengefasst:
- Software-Ingenieur: das sind diejenigen, die die Technik kennen und können; etwa jene, die die Programmiersprache beherrschen, sowie alle anderen Werkzeuge, die benötigt werden, um ein IT-System zu entwickeln.
- Software-Gestalter: legen fest, was die Bedürfnisse des Nutzers erfüllt und ihnen eine effektive Arbeit ermöglicht. Sie sind die kreativen Köpfe aus der realen Welt, die die zukünftige Software planen und gestalten.
- Software-Manager: auch ein IT-Projekt muss mit beschränkten Ressourcen auskommen. Die Manager sorgen dafür, dass mit den zur Verfügung stehenden Ressourcen (Zeit, Budget) effizient umgegangen wird.
Es liegt auf der Hand, in welche Gruppe die IT-Analyse einzuordnen ist: die Software-Gestaltung. Ohne diese Tätigkeit wird ein IT-System niemals seine Aufgabe – oder anders gesagt: die Anforderungen – erfüllen können.
Zwei Paradigmen
„Anforderungsverwaltung“ und „Lösungsgestaltung“ sind also zwei Sichten auf die IT-Analyse, wie sie einerseits in der Theorie formuliert werden – und wie wir sie andererseits in der Praxis vorfinden. Aber: Auch hier ist ein Schwarz-Weiß-Denken nicht angebracht: es handelt sich dabei nicht um völlig voneinander getrennte Ansätze. Trotz der Betonung der Anforderungserhebung und -dokumentation enthält auch der CPRE-Lehrplan viele der Methoden und Werkzeuge, die für die Lösungsgestaltung erforderlich sind. Das gleiche gilt für den BABOK, in dessen Kapitel „Techniken“ ebenfalls viele dieser Methoden und Werkzeuge angeführt sind. Beispiele dafür sind:
- Datenmodellierung
- Prozessmodellierung
- Prototyping
- usw.
Alle diese Methoden sind nicht durch „Erheben und Dokumentieren“ von Anforderungen zu beschreiben. Da muss man nachdenken, experimentieren, da und dort auch scheitern, neu beginnen, kreativ sein – kurz alles das, was Analyse eigentlich ausmacht. Umgekehrt darf natürlich auch bei einer Vorgehensweise, bei der Lösungsgestaltung im Vordergrund steht, der tatsächliche Bedarf der Fachbereiche nicht außer Acht gelassen werden. Man spricht hier vielleicht weniger von „Anforderungen“ und legt weniger Wert auf deren „Traceability“ und auf deren „Verwaltung“. Der fachliche Bedarf fließt unmittelbarer in das Lösungsdesign ein – die Lösung steht im Vordergrund. „Anforderungsverwaltung“ oder „Lösungsgestaltung“ – letztlich sind die Unterschiede gar nicht so groß.
Das Bild nach außen
Unter all den vielfältigen Aufgaben, die ein IT-Analytiker in der Praxis ausführt, wird ein kleiner Ausschnitt hervorgehoben: die Erhebung und Dokumentation von Anforderungen. Die anderen Tätigkeiten werden dieser Sicht untergeordnet: Womit die IT-Analyse identifiziert wird, ist „Erhebung und Dokumentieren von Anforderungen“ – wie es eben die „vier Haupttätigkeiten des Requirements Engineering“, aber auch die „Knowledge Areas“ des BABOK suggerieren.
Das führt dazu, dass wir in der Praxis wesentlich komplexere und qualifiziertere Tätigkeiten ausführen, als wir selbst von uns sagen. Gestaltung von fachlichen Datenmodellen, die Analyse und Neuorganisation von Prozessen, die Definition von Schnittstellen – zum Anwender oder zu anderen Systemen. Das ist alles wesentlich anspruchsvoller, als es die Beschreibung „Erhebung und Dokumentation von Anforderungen“ vermuten ließe. Mit anderen Worten: Wir verkaufen uns schlecht. Für manchen Nicht-Insider ist der IT-Analytiker nichts weiter als eine bessere Schreibkraft: Wir fragen jemanden, was er braucht, und schreiben es auf. That’s it.
Schlecht für die IT-Analytiker …
Wie oben beschrieben, ist das eine verkürzte Sicht der Dinge. Aber das ist genau das Bild, das ein außenstehender Beobachter vom „Requirements Engineering“ bekommt. Das ist natürlich zunächst einmal schlecht für die IT-Analytiker selbst. Wer führt schon gerne qualifizierte Arbeit aus, wie es die Gestaltung von Softwaresystemen ist – und erhält dafür nicht die entsprechende Anerkennung, sondern wird mit einer wesentlich weniger qualifizierten Arbeit identifiziert. „Dokumentieren von Anforderungen“ – es ist nicht so abwegig, dass ein Verantwortlicher für Kosten auf die Idee kommt, diesen Job einzusparen – und die Aufgaben direkt den Stakeholdern zu übertragen. Die müssen ja wissen, was sie wollen – und: Anforderungen zu dokumentieren, kann ja schließlich nicht so schwer sein.
… aber auch schlecht für die Projekte
Es geht nicht um die Befindlichkeit der Analytiker. Wenn eine Tätigkeit nicht (mehr) benötigt wird, dann ist das eben so. Das ist in der Vergangenheit schon vielen Berufsgruppen passiert und wird in der Zukunft manch anderer widerfahren. Damit muss man leben.
Das Problem ist aber, dass die Aufgabe der Lösungsgestaltung in einem IT-Projekt erforderlich ist. Und wenn diese nicht von der IT-Analyse wahrgenommen wird, dann ist häufig niemand da, der sich dafür zuständig fühlt. Den „Solution Engineer“, der gelegentlich als verantwortlich dafür bezeichnet wird und aus Anforderungen Lösungen baut, gibt es in den wenigsten Projekten. Und wenn es ihn gäbe, dann wäre eine Arbeitsteilung zwischen Anforderungserhebung und Lösungsentwurf nicht zweckmäßig. Die meisten Anforderungen lassen sich sinnvoll nur in einem Lösungskontext verstehen. Anforderungen und Lösungen – sie müssen gleichzeitig und aufeinander bezogen entworfen werden.
Die Entwickler auf der anderen Seite sind zumeist mit den technischen Aspekten einer IT-Lösung völlig ausgelastet – und haben nicht die Kapazität, die fachliche Lösungsgestaltung zu übernehmen und die dafür erforderlichen Abstimmungen und manchmal auch Auseinandersetzungen zu führen. Die Zurückdrängung des IT-Analytikers in die Rolle des Protokollanten der Anforderungen führt zu einer Lücke in den IT-Projekten. Zum Glück nehmen viele IT-Analytiker die Rolle als Lösungsgestalter wahr, obwohl sie ihnen von der Theorie eigentlich nicht zugestanden wird. Anforderungserhebung ohne Lösungsgestaltung kann nicht erfolgreich sein.
Zusammenfassung und Appell
„Anforderungen sammeln und dokumentieren“ – das ist oft das verkürzte Bild nach außen der Analyse in IT-Projekten. Diese Definition lässt aber die eigentliche Arbeit vieler Analytiker unbeachtet – und diese eigentliche Arbeit ist die Gestaltung von Lösungen. Die Beschäftigung mit Anforderungen ist ein Teil davon, nicht mehr und nicht weniger. Die eigentliche Qualifikation des Analytikers liegt aber im kreativen Finden und in der Modellierung der Lösung. Lassen wir uns nicht länger auf die Tätigkeit als Protokollant beschränken – sondern reden wir darüber, was wir wirklich tun. Es ist zu unserem eigenen Wohl – und auch zum Wohl unserer Projekte.
[1] H. R. Hansen: Wirtschaftsinformatik I, Stuttgart 1983
[2] https://www.ireb.org/de/cpre/
[3] International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge, Toronto 2015