6 Modellgestützte fachliche Konzeption individueller IT-Systeme (S. 117-118)

6.1 Fragen, die dieses Kapitel beantwortet

- Warum sollte die IT in der Regel den Geschäftsprozessen folgen und nicht umgekehrt?
- Welche Vorteile bringt eine strukturierte Anforderungserhebung auf Basis eines durchgängigen Fachprozesses?
- Wie nehme ich am besten Fachprozesse im Rahmen einer Fachkonzepterstellung auf?
- Wie stelle ich Fachprozesse, Systemverhalten und statische Systemkomponenten im Modell dar?
- Welche Teile eines Fachkonzepts sollte ich im Modell darstellen und welche nicht?
- Wie funktioniert eine modellgestützte Fachkonzeption mit der Oracle BPA Suite?

6.2 Die Bedeutung fachlicher Anforderungen

Es existieren zahlreiche Studien zu den Gründen des Scheiterns von IT-Projekten. Dabei kann mit dem Begriff „Scheitern“ sowohl gemeint sein, dass ein IT-Projekt abgebrochen wird, als auch, dass der Projektzeitplan nicht eingehalten oder das finanzielle Budget überzogen worden ist. Auch die Realisierung eines Systems, das sich anschließend in der Praxis als untauglich herausstellt, muss als gescheitertes IT-Projekt angesehen werden. Die große Anzahl solcher Studien lässt bereits vermuten, dass das Scheitern von IT-Projekten ein häufiges Problem in Unternehmen darstellt. Dies wiederum ist für den Business-Analysten eine große Chance, Unternehmen einen Mehrwert anzubieten, indem ein Vorgehen entwickelt wird, das dem Scheitern von IT-Projekten entgegenwirkt.

Ein solches Vorgehen zur fachlichen Konzeption individueller IT-Systeme wird in diesem Kapitel vorgestellt. Nicht nur die Anzahl der Studien, auch ihr Inhalt bietet eine interessante Erkenntnis: Als wichtigster Grund für das Scheitern von IT-Projekten wird fast durchgehend die unklare Definition bzw. das unzureichende Verständnis der fachlichen Anforderungen identifiziert. Dies wiederum resultiert aus der in Kapitel 2 beschriebenen Problematik der unterschiedlichen Sichten, die die verschiedenen an einem IT-Projekt beteiligten Personenkreise haben. Das in diesem Kapitel vorgestellte Vorgehen sieht diese fachlichen Anforderungen als Basis für die Konzeption eines IT-Systems und hilft bei deren Identifikation, Beschreibung und Kommunikation zwischen allen an einem IT-Projekt Beteiligten.

Unternehmen haben über die letzten Jahre hinweg gelernt, dass ihre Geschäftsprozesse und deren Qualität entscheidenden Einfluss auf den Unternehmenserfolg haben. Die eigentlich logische Konsequenz aus dieser Erkenntnis, auch die IT nach den Geschäftsprozessen auszurichten, ist dagegen noch nicht sehr verbreitet. Besonders in der Vergangenheit wurde häufig der Fehler gemacht, Systeme einzuführen, die bestimmte Arbeitsabläufe (Fachprozesse) vorgeben. An dieser Stelle sei zunächst gesagt, dass ein solches Vorgehen nicht immer falsch sein muss. Je standardisierter die Prozesse sind, um die es geht, desto sinnvoller kann die Einführung einer Standardsoftware sein. Für Standardprozesse wie Rechnungsprüfung oder Finanzbuchhaltung wird es in den wenigsten Fällen sinnvoll sein, eine vollständige Individuallösung zu entwickeln. In solchen Fällen ist der Aufwand, der bei der Einführung einer Standardsoftware anfällt, sicherlich geringer als der Entwicklungsaufwand einer neuen Lösung.

Dennoch ist es wichtig zu wissen, dass eine Softwareeinführung, durch die neue Fachprozesse vorgegeben werden, bestimmte Konsequenzen für alle am Projekt Beteiligten und darüber hinaus mit sich bringt: Ein solches Vorgehen hat zur Folge, dass die Mitarbeiter in der Fachabteilung ihre ggf. seit Jahren praktizierten und bis ins kleinste Detail beherrschten Abläufe aufgrund einer neuen Standardsoftware grundlegend ändern müssen. Dies erhöht nicht gerade die Akzeptanz der neuen Lösung. Tatsächlich unterschätzen Unternehmen den enormen Aufwand einer solchen organisatorischen Veränderung. Organisatorische Veränderungen stellen in sich eigene Change-Management- Projekte dar, deren Umsetzung über die technischen Aspekte einer Systemeinführung weit hinausgeht.