„Analyse ist kein Dokument, sondern ein Prozess“, sagt der Analyst über die Ermittlung von Bedürfnissen, Anwendungsfällen und wie aus Geschäftsanforderungen ein funktionales System entsteht.

Drei Welten der Analyse: Business-, Daten- und Softwareanalyse

Wie sieht eigentlich deine Arbeit als Analystin aus?

Nun, wenn ich es vereinfacht sagen soll, dann mache ich die Analyse von Softwarelösungen, oft handelt es sich um maßgeschneiderte Systeme. Der Kunde kommt mit einer bestimmten Vision oder zumindest mit einer Vorstellung davon, was er gerne hätte. Und wir verwandeln das dann in ein funktionierendes System. Es geht dabei vor allem um Kommunikation. Wir sprechen viel mit dem Kunden und versuchen zu verstehen, was er braucht, was ihm hilft.

Und dann erarbeiten wir gemeinsam mit dem Architekten und den Programmierern den Lösungsvorschlag. Während der Entwicklung stimmen wir die Dinge mit dem Kunden ab, damit das Ergebnis, also das finale Produkt, nicht nur etwas ist, das er benutzen muss, sondern etwas, das ihm wirklich hilft.

Glaubst du, dass die Leute überhaupt wissen, was du machst?

Ehrlich? Die meisten nicht. Die meisten Leute denken, dass ich einfach nur am Computer sitze und irgendetwas tippe. Selbst wenn ich jemandem sage, dass ich Analystin bin, ist die erste Reaktion oft: „Und was ist das?“ Die meisten Menschen können sich darunter nichts vorstellen.

Lassen sich Analysen irgendwie einteilen? Gibt es verschiedene Typen?

Auf jeden Fall. Es gibt mehrere Möglichkeiten der Einteilung, aber aus meiner Erfahrung begegne ich am häufigsten drei Typen: Businessanalyse, Datenanalyse und Softwareanalyse.

Bei der Businessanalyse geht man zum Kunden, schaut sich an, wie seine Prozesse funktionieren, wie sein Geschäft aufgebaut ist. Meistens gibt es bereits ein Problem, etwas funktioniert nicht, etwas muss effizienter werden. Man versucht also zu verstehen, wo der Knackpunkt liegt, und eine Lösung vorzuschlagen – sei es eine Anpassung der Prozesse oder der Entwurf eines Systems, das das Ganze unterstützt.

Dann gibt es Datenanalysten, das ist schon eine andere Liga. Ich habe selbst nie so tiefgehend mit Daten gearbeitet. Ein Datenanalyst beschäftigt sich zum Beispiel mit der Migration von Daten, muss verstehen, wie die Daten zuvor strukturiert waren, um sie korrekt in ein neues System zu übertragen.

Und das, was ich mache, ist Softwareanalyse. Ich bekomme vom Kunden bestimmte Businessanforderungen und überführe diese dann in funktionale und nicht-funktionale Anforderungen. Ich entwerfe Funktionalitäten, skizziere Bildschirme, spezifiere das Verhalten des Systems. Das ist schon technischer, näher an der eigentlichen Entwicklung.

Wenn wir also von „Business“ sprechen, meinen wir damit die Prozesse, den Betrieb und wie die Dinge tatsächlich funktionieren?

Genau. In unserem Jargon nennen wir das „Businessprozesse“, also wie ein Unternehmen seine Abläufe organisiert. Und wenn ein Problem auftaucht, lösen wir es. Entweder wird etwas angepasst oder wir entwerfen ein komplett neues System.

Vom Testen zur Analyse

Wie bist du eigentlich zur Arbeit als IT-Analystin gekommen?

Ich habe als Tester-Beraterin angefangen. Ich habe an der Universität Žilina den Studiengang Managementinformationssysteme studiert. Dort haben wir einige Entwürfe gemacht, hauptsächlich Datenbankentwürfe, aber eher nur am Rande. Insgesamt war das Studium stärker auf Verkehr und Logistik ausgerichtet, nicht direkt auf Softwareentwicklung.

Meine erste berufliche Position war eben Tester-Beraterin. Dort habe ich begonnen, all die grundlegenden Dinge zu lernen – wie man Anwendungen testet, wie man Benutzerhandbücher schreibt und Ähnliches. Es war ein guter Einstieg. Und dort hatte ich einen Kollegen, der mich nach und nach in Richtung Analyse gezogen hat. Zuerst habe ich ihm bei Projekten als Junior-Analystin geholfen, später hatte ich schon eigene.

Also hat es dich quasi selbst „hineingezogen“ in die Welt der Analyse?

Genau. Es war nicht so, dass ich mir ausdrücklich gesagt hätte: „Ich will Analystin werden.“ Es hat sich ganz natürlich ergeben. Aber ich habe mich dem nicht widersetzt, ganz im Gegenteil. Es hat mir Spaß gemacht. Ich mag den Moment, wenn ein Projekt beginnt. Dadurch, dass wir maßgeschneiderte Systeme entwickeln, ist jeder Auftrag völlig anders, es ist immer eine neue Welt, ein neues Thema. Man lernt ständig etwas Neues. Und dieses Gefühl am Ende, wenn man das Ergebnis sieht, wenn das, was wir geschaffen haben, jemandem wirklich hilft – das ist es, was mir daran wirklich gefällt.

Wie verlief diese Transformation vom Tester zur Analystin?

Zuerst habe ich bei verschiedenen Outputs geholfen, die der Hauptanalyst brauchte – Dokumentationen, Workshop-Ergebnisse, Spezifikationen. Schritt für Schritt hat er mir mehr Verantwortung gegeben. Und als dann das erste Projekt kam, bei dem er sagte: „Versuch, das selbst zu leiten“, bin ich hineingegangen. Ich habe angefangen, selbst Aufgaben für die Programmierer vorzubereiten, mit dem Kunden zu konsultieren, Entwürfe mit den Entwicklern zu besprechen … und plötzlich habe ich gemerkt, dass ich mich dabei ganz natürlich fühle. Ich hatte kein Problem damit, zu kommunizieren, Fragen zu stellen, Zusammenhänge zu erkennen. Und so hat sich das Ganze nach und nach entwickelt.

Hast du irgendwelche Fähigkeiten aus dem Testen in die analytische Arbeit mitgenommen?

Auf jeden Fall. Auch wenn es manchmal eher umgekehrt ist – wenn ich später als Analystin bestimmte Teile des Systems getestet habe, konnte ich mich nicht immer vollständig davon lösen. Ich wusste bereits, wie es funktionieren sollte, und habe es dadurch vielleicht nicht ganz mit einem frischen Blick getestet. Aber auf der anderen Seite braucht auch ein Tester einen gewissen analytischen Ansatz. Wenn ein Problem auftaucht, muss er es zerlegen, verstehen, wo es entsteht, was passiert. Er muss sich im System auskennen, wissen, wie die einzelnen Teile funktionieren, und das dann auch dem Programmierer erklären können – idealerweise so, dass dieser schon eine Vorstellung hat, wo er nach dem Fehler suchen oder was er beheben soll.

Arbeitest du also eng mit Programmierern zusammen?

Ich arbeite mit allen zusammen. Im Grunde mit dem gesamten Team – vom Projektmanager, mit dem wir zu Beginn das Angebot, die Aufwandsschätzung und den Arbeitsumfang vorbereiten, bis hin zu Testern und Beratern, die sich am Ende des Projekts um die Ergebnisse kümmern. Wichtig ist auch der Softwarearchitekt, also der „Designer“, wie wir ihn nennen. Wenn ich einen Lösungsvorschlag habe, bespreche ich ihn mit ihm. Er sagt mir, ob das technisch umsetzbar ist, ob es irgendwelche Einschränkungen gibt oder schlägt gegebenenfalls einen besseren Weg vor. Das läuft während des Projekts, aber wir stehen als Team ständig in Kontakt.

Dann kommuniziere ich natürlich auch mit Testern und Beratern. Wenn sie während des Testens ein Problem finden, klären wir, ob es sich um einen Fehler handelt oder um ein Missverständnis der Funktionalität und ob etwas angepasst werden muss. Und wenn in den Unterlagen etwas unklar ist, können wir das sofort besprechen. Und nicht zuletzt: der Kunde. Den haben wir während des gesamten Projekts im Blick. Und die Programmierer? Da geht es um klare Aufgabenstellungen. Wenn etwas gut vorbereitet ist, läuft auch die Entwicklung reibungsloser.

Was eine Analyse enthält

Schreibst du auch diese „analytischen Wälzer“ mit mehreren hundert Seiten?

Klar. Das ist schon so eine klassische Sache.

Und wie viel Text hast du schon produziert? Das müssen Tausende Seiten sein.

Uff, seit 2006 habe ich an wirklich vielen Projekten gearbeitet. Ich kann gar nicht sagen, wie viele es waren, aber Hunderte ganz sicher. Bei den größeren Aufträgen ist das wirklich eine enorme Menge an Dokumentation. 400 Seiten? Völlig normal. Aber alles hängt von der Größe des Projekts ab. Wenn es sich um ein kleines Projekt handelt, produziert man natürlich keine zweihundert Seiten Dokumentation. Manchmal geht es nur um eine kleinere Änderung im System, etwas Kleines, das ergänzt werden muss. Aber wenn es eine große Lösung oder ein System für ein großes Unternehmen ist, dann ja – da geht es auch in den Bereich von mehreren hundert Seiten.

Und was ist mit Benutzerhandbüchern? Schreibst du die auch?

Ja, auch Benutzerhandbücher. Und auch die können ziemlich umfangreich sein – es hängt davon ab, wie robust das System ist. Manchmal ist es nur ein einfaches Portal, in dem etwas gesucht oder erfasst wird. Ein anderes Mal hat man ein umfangreiches System mit vielen Funktionalitäten, einem internen und einem öffentlichen Bereich, und dann wächst die Dokumentation wirklich stark an.

Wie würdest du die Projekte nach ihrem Schwierigkeitsgrad einteilen?

Es gibt so drei Kategorien. Die erste sind ganz kleine Änderungen – das System existiert bereits und es wird nur etwas Kleines angepasst. Dann gibt es kleinere Projekte, wie einfache Erfassungssysteme oder Portale, die etwas anzeigen, suchen oder gegebenenfalls speichern. Und dann gibt es die großen, robusten Systeme, oft für große Unternehmen.

Gibt es überhaupt so etwas wie einen typischen Arbeitstag eines Analysten?

Nein, wahrscheinlich nicht. Es hängt wirklich sehr davon ab, in welcher Phase des Projekts ich mich gerade befinde.

Wie entsteht eine gute Analyse

Und wie sieht so ein Anfang aus, die ersten Treffen mit dem Kunden?

Entweder haben wir bereits einige Eingangsinformationen zur Verfügung, also Dokumentation, eine Bestellung oder zumindest eine Beschreibung dessen, was der Kunde braucht – oder wir erarbeiten das erst. Meistens beginnt es mit einem Gespräch. Wir stellen Fragen, versuchen, die Dinge zu verstehen, das Projekt in kleinere Teile zu zerlegen, je nachdem, wie robust das System sein wird. Und der Kunde erzählt uns, was er braucht, wie es bei ihm funktioniert.

Und wer kommuniziert in der Regel auf Kundenseite?

Das sollte jemand sein, der den Prozess gut kennt – also ein „Business Owner“ oder jemand aus dem operativen Bereich. Manchmal ist es eine Person, manchmal mehrere, je nach Umfang. Zum Beispiel bei einem Projekt hat eine Person das Ganze koordiniert und konnte es auch den anderen Kollegen intern in ihrer „Sprache“ erklären. In solchen Fällen ist die Kommunikation deutlich einfacher.

Kommt es vor, dass während der Analyse Dinge ans Licht kommen, die dem Kunden vorher selbst nicht bewusst waren?

Auf jeden Fall. Manchmal stoßen wir während der Analyse auf „Engpässe“, derer sie sich selbst gar nicht bewusst waren. Zum Beispiel haben wir bei der Migration von Messgeräten festgestellt, dass ihr internes System überlastet ist, wenn eine große Anzahl von Anfragen auf einmal gesendet wird. Also haben wir das auf unserer Seite angepasst, die Art der Übermittlung der Anfragen geändert, damit es nicht zu einer Überlastung kommt. Sie mussten ihren gesamten Prozess nicht ändern, es hat gereicht, dass wir es bei uns anpassen konnten.

Welche Teile der Analyse sind die wichtigsten?

Die Grundlage sind die Business-Anforderungen, also das, was das System können soll. Diese werden in funktionale und nicht-funktionale Anforderungen unterteilt. Funktionale Anforderungen bedeuten konkrete Funktionalitäten, die das System bereitstellen soll, zum Beispiel „der Benutzer kann einen Antrag erstellen“. Nicht-funktionale Anforderungen sind technischer oder betrieblicher Natur, zum Beispiel dass das System responsiv, sicher, skalierbar oder 24/7 verfügbar sein soll.

Wie wird das weiter ausgearbeitet?

Jede funktionale Anforderung sollte durch einen sogenannten „Use Case“ abgedeckt sein. Diese beschreiben, was das System tun soll, wer es nutzt und wie der Ablauf der Aktion aussieht. Danach erstellen wir Prototypen der Bildschirme, also wie die Benutzeroberfläche aussehen wird. Das sind eher technische Entwürfe für das Team – wo sich welche Elemente, Buttons und Eingabefelder befinden. Es ist noch kein finales Design für den Kunden, sondern dient als Grundlage für die weitere Kommunikation mit dem Team und mit dem Kunden.

Und was beschreibst du sonst noch alles?

Auch, wie das System einen konkreten Prozess verarbeitet, zum Beispiel wie eine Bestellung oder eine Rechnung abgewickelt wird, welche Zustände sie haben kann und wie sich diese ändern. Dazu erstellen wir auch Zustandsdiagramme, Entitäten, Domänenmodelle und anschließend bereits detaillierte Aufgabenstellungen für die Programmierer.

Aufgabenstellungen für Programmierer? Was können wir uns darunter vorstellen?

Das sind Spezifikationen darüber, was eine konkrete Funktionalität tun soll und wie sie sich verhalten soll. Damit die Entwickler wissen, was und wie sie programmieren sollen, welche Grenzen es gibt und was unbedingt einzuhalten ist. Ohne eine gut vorbereitete Aufgabenstellung würde das nicht funktionieren – sie ist im Grunde die Brücke zwischen dem, was das Business will, und dem, was die Entwicklung umsetzt.

Welcher Teil deiner Arbeit ist deiner Meinung nach am anspruchsvollsten?

Am Anfang zu verstehen, was der Kunde eigentlich will. Die Anforderungen richtig zu identifizieren. Je weniger wir einander verstehen, desto mehr Probleme können später entstehen. Und der Kunde kann oft nicht genau sagen, was er braucht – er weiß nur, welches Ergebnis er haben möchte. Meine Aufgabe ist es zu verstehen, was im System passieren muss, damit er dieses Ergebnis erreicht.

Gibt es auch einen Teil der Arbeit, den du als einfach bezeichnen würdest?

Schwer zu sagen. Meiner Meinung nach hängt es davon ab, wie man an die Sache herangeht. Wenn man sich im Voraus sagt, dass es kompliziert ist oder dass man es nicht schafft, dann wirkt es auch anstrengend. Aber wenn man es aufteilt, analysiert und sich Schritt für Schritt „durchbeißt“, dann ist es machbar. Es geht weniger darum, dass etwas völlig einfach ist, sondern eher darum, dass einem manche Dinge mehr Spaß machen.

Bist du auch nach der Implementierung noch Teil des Projekts?

Ja, bei den Projekten, an denen ich arbeite, bin ich von Anfang bis zur Einführung eingebunden. Es kann sein, dass bei größeren Projekten der Analyst nur eine Aufgabe hat – er erstellt die Analyse, übergibt sie und kommt nur dann wieder dazu, wenn es ein Problem gibt. Aber bei uns ist es so, dass wir den gesamten Weg bis zum Ende begleiten.

Analyse als lebendiger Prozess

Das heißt, die Analyse führt kein „Eigenleben“, du bist ständig dabei?

Die Analyse ist nicht nur ein Dokument, das irgendwohin geschickt und dann vergessen wird. Sie ist ein Prozess, der weitergeführt, diskutiert, angepasst und an die Realität angeglichen wird. Und der Analyst ist Teil davon, bis zu dem Moment, in dem das System tatsächlich funktioniert. Sie führt also nie ganz ein „Eigenleben“. Selbst wenn das Projekt abgeschlossen ist, kann man jederzeit darauf zurückkommen, zum Beispiel wenn eine Änderungs-, Anpassungs- oder Korrekturanforderung entsteht.

Änderungen werden in der Regel auf Basis der ursprünglichen Unterlagen eingearbeitet. Das muss nicht unbedingt derselbe Analyst sein, der sie erstellt hat, aber es ist wichtig, dass die Dokumentation qualitativ hochwertig und auch für jemand anderen verständlich ist, falls der Analyst das Projekt verlässt oder das Unternehmen verlässt. Kontinuität ist entscheidend. Änderungen, die Auswirkungen auf die Funktionalität haben, müssen rückwirkend auch in der Dokumentation berücksichtigt werden. Die Analyse als solche bleibt somit während des gesamten Lebenszyklus des Projekts ein Teil davon.

Welche Fähigkeiten sind deiner Meinung nach ideal für einen guten Analysten?

Kommunikationsfähigkeit ist die Basis. Dann analytisches Denken, die Fähigkeit zu fragen, warum Dinge so funktionieren, wie sie funktionieren. Und sicherlich auch ein Gefühl für Sprache – Dinge verständlich erklären und festhalten zu können, sodass sie aussagekräftig und auch für andere übersichtlich sind.

Kommt es vor, dass sich jemand unter einer Analyse etwas Falsches vorstellt?

Manchmal ja. Wir verwenden verschiedene Standards, Sprachen und Notationen wie UML oder BPMN. Und manchmal passiert es, dass ein Diagramm für den Kunden unverständlich wirkt, wenn jemand komplexere Elemente verwendet.

Deshalb fügen wir immer auch eine textliche Beschreibung hinzu, eine Erklärung, wie der Prozess abläuft. Ziel ist es, dass der Kunde das Schema mit der Realität verknüpfen kann. Wenn er beides zusammen betrachtet – Text und Diagramm –, sollte er verstehen, worum es geht.

Also ist BPMN eine Modellierungssprache?

Ja. BPMN wird von Analysten und Softwarearchitekten zur Beschreibung von Prozessen verwendet. UML wird eher zur Beschreibung von Funktionalitäten genutzt, zum Beispiel über „Use Cases“. Diese Modelle ermöglichen es allen – Analysten, Architekten, Programmierern –, „dieselbe Sprache zu sprechen“. Auf ihrer Grundlage kann das System anschließend programmiert werden.

Gibt es deiner Meinung nach irgendwelche Mythen über die Arbeit eines Analysten?

Ich denke, dass normale Menschen oft überhaupt nicht wissen, was wir tun. Manchmal werden wir mit Datenanalysten verwechselt – man stellt sich vor, dass wir nur in Tabellen sitzen und rechnen. Oder man denkt, wir seien nur Berater, die in Meetings sitzen und etwas erzählen. Auch zwischen Unternehmen gibt es Unterschiede in der Bezeichnung – irgendwo heißt dieselbe Rolle „Business-Analyst“, anderswo „Berater“ oder „Prozessspezialist“. Wenn man also Stellenbeschreibungen in verschiedenen Unternehmen vergleicht, stellt man fest, dass es keinen einheitlichen Standard gibt.

Analytisches Denken auch außerhalb der Arbeit

Nimmst du dir Dinge manchmal auch mit nach Hause, im Kopf?

Ja, das passiert mir gelegentlich. Wenn ich etwas angefangen habe, denke ich auch zu Hause darüber nach. Ich sage mir dann: „Das muss ich morgen aufschreiben.“ Oder mir wird etwas klar, während ich etwas ganz anderes mache. Es ist aber nicht so, dass ich nonstop über die Arbeit nachdenke. Eher in den Phasen, in denen etwas anläuft, in denen ich mich orientieren, Zusammenhänge verstehen und mich auf ein Kundengespräch vorbereiten muss. Dann „rattert“ es im Kopf mehr.

Und wie entspannst du dich?

Durch Schlaf. Wenn ich kann. Aber mit Kindern ist das nicht immer einfach. Kinder haben Priorität, und wenn ich mich ihnen widme, versuche ich, ganz bei ihnen zu sein, es mit der Arbeit nicht zu übertreiben und das nicht zu vermischen.

Greift deine Arbeit ins Elternsein ein? Kannst du komplett „abschalten“?

Wahrscheinlich nicht ganz. Manchmal passiert es mir, dass ich bei den Hausaufgaben, vor allem bei Mathematik, anfange, die Dinge zu sehr zu analysieren. Das Kind schaut drauf und löst es einfach. Ich hingegen überlege schon, was der Autor der Aufgabe damit sagen wollte. Und das ist nicht immer ein Vorteil. Vielleicht liegt das an meiner Denkweise. Ich versuche, Dinge zu lösen, zu verstehen, warum ein Problem entstanden ist, was dahintersteckt – auch zu Hause, in alltäglichen Situationen. Dort ist es dann eher eine „emotionale Analyse“. Manchmal ist es aber besser, die Dinge einfach zu unterbrechen und sie nicht sofort bis in die Tiefe zu analysieren.

Wo findest du die größte Zufriedenheit in deiner Arbeit?

Wahrscheinlich darin, wenn alles funktioniert. Wenn sich das Team versteht, wenn die Kommunikation natürlich verläuft und keine Spannung herrscht. Das ist ein großes Plus. Manchmal sind die Dokumente lang, 300-seitige Ergebnisse, aber wenn im Team eine gute Atmosphäre herrscht, geht es leichter. Und dann ist da natürlich auch das Feedback vom Kunden, wenn er sagt, dass er zufrieden ist, dass das, was wir vorbereitet haben, für ihn Sinn ergibt. Das ist so ein kleiner „Win“. Auch wenn das Dokument noch nicht final freigegeben ist und weitere Anpassungen anstehen, ist es ein Moment, in dem man sich sagt: Gut, wir sind auf dem richtigen Weg.

Kommt die Zufriedenheit also auch schon früher als erst nach der Einführung?

Auf jeden Fall. Ich muss nicht auf die finale Unterschrift warten, um zu sagen, dass ich ein gutes Gefühl dabei habe. Zum Beispiel, wenn ich ein Dokument zusammenstelle, das klar, verständlich und in sich stimmig ist und wir es nur noch feinjustieren. Dann habe ich das Gefühl, dass es fertig ist. Auch wenn ich weiß, dass noch Anmerkungen kommen werden, ist das für mich ein wichtiger Meilenstein.

Was würdest du jemandem empfehlen, der Analyst werden möchte? Was sollte er können?

Auf jeden Fall ist es wichtig, Fachwissen zu haben, Modellierungssprachen wie UML zu kennen, Prozessdiagramme lesen und erstellen zu können. Und dann ist es sehr wichtig, Fragen zu stellen. Warum funktioniert das so? Wie funktioniert es? Und was meint der Kunde damit eigentlich?

Was motiviert dich?

Dadurch, dass ich Analysen für maßgeschneiderte Informationssysteme mache, komme ich mit unterschiedlichen Bereichen in Kontakt, jedes Projekt ist ein wenig anders. Man lernt verschiedene Welten kennen. Zum Beispiel habe ich erfahren, wie das System zur Bestellung von Zeitschriften bei der Post funktioniert oder wie diese Vitrinen verteilt werden, in denen Bücher, Spielzeug und Ähnliches liegen. Vielleicht nutze ich das im Alltag nicht, aber es macht mir Spaß – plötzlich weiß ich etwas, das ich vorher nicht wusste.

Und nutzt du analytisches Denken auch im Alltag?

Wahrscheinlich ja, aber nicht gezielt. Wenn wir zu Hause renovieren oder etwas planen, vergleiche ich ganz natürlich Preise, erstelle Listen und wäge Möglichkeiten ab. Aber das machen viele Menschen, nicht nur Analysten. In eine Datenbank trage ich es bisher noch nicht ein (lacht).

Welche Stereotype gibt es über Analysten?

Nun, sie sind nicht so ausgeprägt wie bei Programmierern mit karierten Hemden. Aber ja, manchmal sehen uns die Leute nur als diejenigen, die Tabellen machen oder Diagramme zeichnen. Aber das ist nur ein Teil dessen, was wir tun. Und vor allem: Wir sind auch Menschen.