Zum IT-Projekt gehört nicht nur die Umsetzung der Softwareanforderungen sondern auch das Einrichten neuer Geschäftsprozesse, denn selten bleiben die Abläufe im Unternehmen gleich, wenn die verwendete Software sich ändert.
Leider werden die Verantwortlichkeiten für beides meist schon zu Projektbeginn säuberlich getrennt. In verschiedenen Teams wird nebeneinander her gearbeitet. Man tut so, als ob die Softwareanforderungen alles Wichtige über die Software sagen und dass die Geschäftsprozesse in den frühen Anforderungserhebungen bereits hinreichend dokumentiert wurden. Aber das ist ein großer Fehler, der sich spätestens dann rächt, wenn die Lösung „live“ gehen soll. Dann merkt man, dass die Software eben nicht genau zu den Prozessen passt.
Da die Änderung einer fertigen Software viel zu teuer ist, werden die Geschäftsabläufe mühsam an die Software angepasst, was aus vielen Gründen frustrierend ist und zu großen Akzeptanz-Problemen für das neue System führt.
Gibt es Alternativen? Idealerweise würde es überhaupt nur eine Dokumentation geben, in der die Geschäftsprozessänderungen genauso dargestellt werden wie die Spezifikation der Softwarelösung. Das ist leider nicht immer möglich. Wichtig ist aber eine enge Zusammenarbeit zwischen Software- und Prozess-Designern. Bei jedem Anwendungsfall muss gefragt werden: wie ändert er die Geschäftsprozesse? Und wie wirkt sich eine Änderung der Geschäftsprozesse auf die Software-Anforderung aus?
Vor längerer Zeit hatte ich schon einmal darüber geschrieben, dass die Kontextabgrenzung im IT-Projekt oft intuitiv falsch gezogen wird – man meint, das System, das sich ändert, bestehe nur aus Software. Das ist der Denkfehler: Die Geschäftsprozesse sind nicht Kontext, sie gehören zum System dazu.
Praktisch heißt das: Die Prozessverantwortlichen müssen mit den Systemdesignern ständig zusammenarbeiten, jedes Teilergebnis, jeder wichtige Vorschlag muss der anderen Seite vorgestellt und diskutiert werden. Soll mit einer geänderten Anforderung der Prozess oder die Software angepasst werden.
Das spart auch Kosten: Oft ist die Änderung eines Prozesses nur eine kleine Sache – wenn sie rechtzeitig und plausibel kommuniziert wird. Dagegen kann die Umsetzung einer Softwareanforderung entsprechend eines alten Prozesses großen Aufwand bedeuten.