Neue Systemversion muss nicht automatisch Nachfolge heißen

Der Umstieg von SAP R/3 auf S/4HANA oder auch von Microsoft Navision auf Dynamics 365 ist mehr als ein technisches Upgrade – es ist eine strategische Neuausrichtung und das nicht nur auf Seiten der Anbieter. Doch eins nach dem anderen. Zunächst schauen wir auf die technologischen Fakten.

Die beiden Produkte Dynamics NAV (ehemals Navision) und Dynamics AX (ehemals Axapta) wurden 2002 von Microsoft von einem dänischen Unternehmen übernommen. NAV war auf kleine und mittlere Unternehmen ausgerichtet, AX auf größere Unternehmen mit komplexen Prozessen. Microsoft hat im Zuge seiner Neuausrichtung beide Produkte in Dynamics 365 auf einer technologischen Plattform zusammengeführt: NAV wurde zu Business Central, AX zu Dynamics 365 Finance und Supply Chain Management.

SAP hat mit seinem neuen Produkt S/4HANA grundlegende Veränderungen im Datenmodell, Prozesslogik und Benutzerführung vorgenommen.

Viele Unternehmen haben in der Vergangenheit ihre Systeme um Eigenentwicklungen ergänzt. Mitunter in sehr großem Umfang, sodass ein Umstieg auf neue Release oft mit großen zeitlichen und finanziellen Aufwand verbunden war. Beide Anbieter bieten ihren Kunden für den Umstieg auf die neuen Produktfamilien technische Unterstützung an, um den Migrationsaufwand zu reduzieren. Dieses Vorgehen hat den Vorteil, das bestehende Eigenentwicklungen zu einem Großteil übernommen werden ohne dass das System komplett neu aufgesetzt werden muss. Allerdings sollte sich jedes Unternehmen die Frage stellen, ob man das wirklich tun sollte oder ob nicht die aktuell im Einsatz befindliche Lösung einmal kritisch hinterfragt werden sollte. Bei Vorliegen von folgenden Gründen sollte Unternehmen dies auf jeden Fall tun:

1. Die Systemlandschaft um das ERP-System herum ist in den letzten Jahren stetig gewachsen. Einige Prozesse aus dem ERP-System sind in Subsysteme ausgelagert worden. Schnittstellen sind nicht implementiert worden.
2. Sie haben eine lange Wunschliste an Funktionen die eigentlich noch im ERP-System implementiert werden müssten.
3. Sie sind unzufrieden mit dem betreuenden Systemhaus/Partner.
4. Die Mitarbeiter äußern Unzufriedenheit über das System und/oder fangen an, sich Umgehungslösungen zu bauen (siehe auch Punkt 1).
5. Ihr Geschäftsmodell hat sich in den letzten Jahren verändert oder wird sich perspektisch in den nächsten Jahren verändern.

Es muss nicht gleich ein komplettes Auswahlprojekt sein. Es kann zunächst ausreichen, die kritischen Geschäftsanforderungen an das ERP-System zu formulieren und einen Abgleich mit dem aktuellen System durchzuführen. Dabei sollten in jedem Fall die implementierten Anpassungsprogrammierungen kritsch hinterfragt werden. Auch wenn die Übernahme durch technische Tools vereinfacht werden kann, geht mit jeder Anpassungsprogrammierung bei zukünftigen Updates Aufwand für das Testen und ggf. nachziehen der Programmierungen einher. Gerade bei einem Umstieg auf die Cloud, welcher von beiden Herstellern (SAP / Microsoft) vorangetrieben wird, verkürzen sich die Updatezyklen drastisch.

Stellt sich heraus, dass größere funktionale Lücken bestehen oder die Menge der Anpassungsprogrammierungen nicht reduziert werden kann, sollte in jedem Fall ein richtiges Auswahlprojekt gestartet werden. Trotz vorliegender Gründe entscheiden sich viele Unternehmen beim Wechsel von SAP R/3 auf S/4HANA bewusst gegen ein strukturiertes ERP-Auswahlprojekt. Die Gründe dafür sind vielfältig: Häufig stehen Kosten- und Zeitdruck im Vordergrund – ein Auswahlprozess erfordert zusätzliche Ressourcen, die im laufenden Betrieb oft nicht verfügbar sind. Zudem herrscht vielfach die Vorstellung, S/4HANA sei der einzige sinnvolle Nachfolger, sodass eine umfassende Evaluierung anderer Optionen gar nicht erst in Betracht gezogen wird. Nicht zuletzt fehlt es intern oft an methodischem Know-how und Erfahrung, um ein Auswahlprojekt effizient und fundiert durchzuführen. Die Folge ist, die Probleme aus der “alten Systemwelt” werden in die Neue ERP-Welt mit übernommen. Auch wenn SAP und Microsoft technisch die Systeme auf den neuesten Stand gebracht haben, funktional hat sich zwar einiges geändert, aber im Kern sind die Abläufe und Funktionen identisch geblieben.

Stellt sich heraus, dass die Lösung weiterhin den Anforderungen gerecht wird, steht einem geordneten Releaseupdate natürlich nichts im Wege.