• Beim klassischen Wasserfallprinzip folgt der Anforderungsaufnahme und -analyse das Business-Konzept, die Realisierung, Test, Produktionsvorbereitung und schließlich der Produktivstart. Der Nachteil: Der Anwender befasst sich bei diesem Ansatz meist erst nach dem Produktivstart eingehend mit der Lösung, zu spät für Know-how-Transfer und Fehlerkorrekturen.

• Der zweite Ansatz ist mehr von fachlichen Anforderungen getrieben. Beim Nachfahren von Konzernabschlüssen auf Basis übernommener Altdaten sollen Zahlen für Vorperioden- und Vorjahresvergleiche in das Berichtswesen übernommen werden. Die entsprechenden Mitarbeiter sind gezwungen, sehr früh produktiv mit der neuen Lösung zu arbeiten. Auf einem vorkonfigurierten Prototyp werden jeweils nur die Funktionen weiter ausgeprägt, die für die betreffende historische Periode relevant ist. Die restlichen Funktionen werden während der Implementierung „zugeschaltet“.

• Der dritte Ansatz eignet sich insbesondere für die Umsetzung mehrerer dezentraler Konsolidierungsprozesse. Zunächst wird ein Konsolidierungstemplate aufgebaut, das als Vorlage für die Teilkonzernsysteme dient. Die Teilkonzerne prägen dieses Template gemäß ihrer spezifischen Anforderungen aus, ohne die Schnittstellen oder Grundanforderungen des Mutterkonzerns zu ändern. Bei dieser Vorgehensweise ist der Aufwand für die Zentrale begrenzt, allerdings hängt der Projekterfolg stark von den dezentralen Einheiten und der Kommunikation mit diesen ab.

Kurz & knapp

Das „Wasserfallprinzip“ ist gewissermaßen der klassische Weg und wird dem zufolge auch am häufigsten gewählt. Dem gegenüber ist der zweite Ansatz insbesondere dann zu empfehlen, wenn die Altdaten bereits während der Implementierung einer neuen Lösung in geeigneter Qualität vorliegen, etwa bei einem Releasewechsel. Der dritte Ansatz empfiehlt sich, wenn die Teilkonzerne im Rahmen der IT-Strategie des Gesamtunternehmens mit der Implementierung individuelle Anforderungen umsetzen dürfen und dadurch einen Mehrwert für sich schaffen.