Welche Aufgaben gibt es bei einem IT-Projekt?

Zuletzt aktualisiert: 15.02.2024

Was umfasst die Bedarfsanalyse?

Gleichgültig ob es sich um die Einführung eines neuen Informationssystems, um die Erweiterung eines bestehenden Informationssystems, um die Kopplung mehrerer vorhandener Informationssysteme oder um die Entwicklung eines neuen Informationssystems handelt, wird dabei sehr schnell deutlich, dass all diese Vorhaben im Rahmen eines eigenen Projekts durchgeführt werden müssen. Gerade die Merkmale „neuartig“ und damit „risikobehaftet“ sowie die Limitierung in Zeit, Kosten und Ressourcen sind typisch für ein Projekt.

Da die Durchführung und Umsetzung eines Projekts auch immer selbst Zeit und Geld kostet, ist die Behandlung solcher Vorhaben als ein Projekt nur dann wirtschaftlich sinnvoll, wenn damit auch eine gewisse Größenordnung verbunden ist.

Die genaue Abgrenzung des Projektbegriffs ist nicht immer eindeutig. Wir definieren hier das eigentliche Projekt vom Erhalt eines Auftrags zur Projektdurchführung bis hin zur Abnahme und Übergabe eines fertigen Produkts:

Abgrenzung des Projekts von Auftragserhalt bis Abnahme
Abgrenzung des Projekts von Auftragserhalt bis Abnahme

Dem eigentlichen Projekt geht immer voraus, dass von einem Auftraggeber eine Entscheidung getroffen wird, ein Vorhaben durchzuführen. Ist der Auftragnehmer extern, so gibt es meist eine Anfrage (z.B. in Form einer Ausschreibung). Daraufhin legen potentielle (und eingeladene) Bieter entsprechende Angebote, von denen eines (in Sonderfällen auch keines) einen Zuschlag erhält, was zu einer Auftragserteilung und damit in Folge zu einem (externen) Projekt führt.

Ist der Auftragnehmer intern, so kann es zu einem Projekt kommen, wenn es eine Projektidee oder eine Notwendigkeit, z.B. aus einer strategischen Planung oder durch eine Gesetzesänderung, gibt und innerhalb des Unternehmens ausreichend Kompetenz und Ressourcen zur Umsetzung vorhanden sind. 

In beiden Fällen kann es eine Vorprojektphase geben, in der – speziell bei unbekannten Technologien etc. – die Machbarkeit der Projektidee überprüft und ein Kostenrahmen geschätzt wird. Fällt die Entscheidung positiv aus, kommt es zum Projekt.

Ab diesem Punkt – nämlich dem Erhalt des Auftrags zur Durchführung des Projekts – beginnt das Projekt offiziell zu laufen. Das bedeutet nicht zwangsläufig, dass Teile der (künftig geplanten) Projektorganisation nicht auch schon in Vorphasen involviert waren – beispielsweise wird ein Projektmanager seine Expertise in die Planung und Kalkulation bei der Angebotslegung oder bei der Vorprojektphase einbringen. Ebenso ist es möglich, dass bei komplexen Vorstudien oder bei umfangreichen Angeboten diese selbst als eigenes Projekt aufgesetzt und durchgeführt werden.

Die Bedarfsanalyse und der sich daraus ergebende Projektauftrag sind wesentliche Voraussetzungen für die Abwicklung der Planung und für die Entwicklung von Informationssystemen. Schließlich münden die Ergebnisse der Bedarfsanalyse in konkrete, umzusetzende Ziele und geben einen Zeit- und Kostenrahmen für die Projektumsetzung vor.

Die Themen Problemanalyse, Ideen und Vorstudien etc. stehen immer zu Beginn jeglichen Vorhabens. Diese Themen werden jedoch nicht nur einmalig zu Beginn eines neuen Projekts relevant sein, sondern auch dann, wenn sich „von außen“ neue Herausforderungen ergeben und diese beispielsweise wieder in einer Durchführbarkeitsstudie auf Umsetzungsmöglichkeit überprüft werden. Gleichzeitig werden in den meisten Fällen laufend neue Anforderungen durch zusätzliche Ideen und Wünsche von Benutzern sowie Rückmeldungen für Fehlerbehebungen eintreffen.

Die Bedarfsanalyse ist somit auch eng mit dem Change Management verbunden – auch bei Änderungswünschen müssen Machbarkeit, Zeit und Kosten definiert werden und es muss eine Entscheidung zur Umsetzung getroffen werden. 

Was umfasst die Business Analyse?

Betrachtet man die Phase der Bedarfsanalyse aus Sicht der Business Analyse, so sind mehrere Schritte zu durchlaufen:

Zunächst ist zu ermitteln, was auf der Business-Ebene benötigt wird, was also die Zielsetzung aus der gesamten Unternehmenssicht ist (= Anforderungen aus der Business-Sicht).

Phase 1 der Bedarfsanalyse aus Sicht der  Unternehmen

Im nächsten Schritt sind die Stakeholder (das sind alle vom Projekt betroffenen oder im Projekt beteiligten Personen und Gruppen) zu befragen, was diese für die vorgegebene Zielsetzung benötigen und wie das Ziel umgesetzt werden könnte

Phase 2 der Bedarfsanalyse aus Sicht der Business Analyse

Daraus ergeben sich Anforderungen der Stakeholder, sogenannte Stakeholder Requirements.

Phase 3 der Bedarfsanalyse aus Sicht der Business Analyse

Die beispielhafte, noch vage formulierte Anforderung „eine Bestellung muss getätigt werden können“ wird im nächsten Schritt präzisiert, z.B. durch eine nähere Prozess- oder Ablaufbeschreibung

Phase 4 der Bedarfsanalyse aus Sicht der Business Analyse

Erst wenn die Ebenen der Geschäftssicht und die Anforderungen der Stakeholder bekannt sind, kann mit der Fragestellung „Wie sieht eine (entsprechende) Lösung aus?“

Phase 5 der Bedarfsanalyse aus Sicht der Business Analyse

Somit ergeben sich Anforderungen an eine Lösung, welche jeweils wiederum die Anforderungen an die Geschäftsziele und an die Stakeholder erfüllen müssen = Solution Requirements

Phase 6 der Bedarfsanalyse aus Sicht der Business Analyse

Erst wenn die Anforderungen an die Lösung feststehen, kann – nach Entscheidung der Umsetzung – die ausgewählte Lösung umgesetzt werden

Phase 7 der Bedarfsanalyse aus Sicht der Business Analyse

Ergebnis einer Business Analyse sind somit ein oder mehrere Lösungsvorschläge, welche stark am Unternehmensnutzen ausgerichtet sind, die Anforderungen der Unternehmensvorgaben und der betroffenen Stakeholder berücksichtigen und unter anderem auch einen Zeit- und Kostenrahmen beinhalten.

Wichtig bei der Bedarfsanalyse ist es auch, möglichst alle Stakeholder (also alle vom Projekt betroffenen Personen und Organisationen) in die Analyse einzubinden, da nur dann ein Erfolg eines Projekts sichergestellt werden kann. Werden wichtige Stakeholder mit deren Wünschen und Anforderungen nicht berücksichtigt, ist wahrscheinlich die Akzeptanz einer Lösung gering oder wird nicht selten sogar boykottiert. Das richtige und angemessene Stakeholder-Management ist somit auch ein wesentlicher Aspekt jedes Projekts.

Was bedeutet Systemkontext?

Eine der ersten und wesentlichen Aufgaben innerhalb der Bedarfs- und Anforderungsanalyse ist die Abgrenzung bzw. Festlegung des Systemkontexts. Dieser wird definiert als „jener Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen an das betrachtete System relevant ist“. 

Das ist insofern einleuchtend, weil ja der Ursprung aller Anforderungen an ein System in dessen Umgebung liegt. In diesem Sinne zählen sowohl Personen (Stakeholder oder Stakeholdergruppen), fremde Systeme (andere technische Systeme), Prozesse (technische und physikalische Prozesse) als auch Dokumente (Gesetze, Standards etc.) dazu.

Aktivitäten innerhalb der Anforderungsanalyse
Aktivitäten innerhalb der Anforderungsanalyse

Wird der Systemkontext im Rahmen der Bedarfsanalyse inkorrekt oder unvollständig berücksichtigt, hat dies unvollständige oder fehlerhafte Anforderungen zur Folge. Dies führt dazu, dass das entwickelte System auf der Grundlage unvollständiger oder fehlerhafter Annahmen arbeitet, was eine häufige Ursache für Systemversagen im Betrieb ist. 

Solche Fehler bleiben bei der Überprüfung, ob das entwickelte System den spezifizierten Anforderungen genügt, häufig unentdeckt und treten erst später im Betrieb des Systems auf, und das mit teilweise katastrophalen Konsequenzen.

Systemgrenze, Systemkontext und Kontextgrenze
Systemgrenze, Systemkontext und Kontextgrenze

Die Systemabgrenzung dient zur Festlegung der Systemgrenze. Sie legt die Aspekte fest, welche durch das (zu entwickelnde) System bzw. durch die Umgebung erbracht werden. Die Systemgrenze separiert das geplante System von seiner Umgebung. Sie grenzt den im Rahmen des Projekts gestaltbaren und veränderbaren Teil der Realität von Aspekten von der Umgebung ab, die durch das Projekt nicht verändert werden können.

Die Kontextabgrenzung stellt die Abgrenzung des Systemkontexts von der irrelevanten Umgebung dar. Die Kontextgrenze separiert den relevanten Teil der Umgebung eines geplanten Systems vom irrelevanten Teil, d.h. dem Teil der Umgebung, der keinen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen des Systems hat.

Diese Abgrenzungen sind deshalb von großer Bedeutung, weil damit festgelegt wird, was Teil des geplanten Systems ist und was nicht. Sozusagen nebenbei entstehen dadurch oft auch bereits eine Vielzahl von Anforderungen an das geplante System, weil durch die Systemgrenze klar wird, wer mit dem System interagieren wird und was daher das System leisten muss.

Was die Anforderungen an ein IT-Projekt sind erfahren Sie im dazu passenden Lexikoneintrag. Zum Eintrag IT-Projekt Anforderungen?

    👉 Dir gefällt dieser Beitrag?
    Success! Thanks for Your Request.
    Error! Please Try Again.