Die Probleme und Aufgabenstellungen bei einem Softwareprojekt zum Upgrade, Erneuerung oder kompletter Neuanschaffung (einem ERP-Wechsel) sind anspruchsvoll und mit hohen Risiken für ein Unternehmen verbunden. Die personellen Anforderungen an ein ERP-Projektteam bei einem ERP-Wechsel sind hoch. Die benötigten Ressourcen bei Mitarbeitern und im Rahmen des Investments sind beachtlich. Was sollten die Verantwortlichen beachten, bevor ein ERP-Wechsel eingeleitet wird?
Die Probleme und Aufgabenstellungen bei einem Softwareprojekt zum Upgrade, Erneuerung oder kompletter Neuanschaffung sind anspruchsvoll. Ein Upgrade einer ERP-Software selbst vom gleichen Hersteller (zum Beispiel der Upgrade auf eine höhere Versionsnummer wie SAP R3 auf SAP S4/Hana) ist mit einer kompletten Neueinführung zu vergleichen. Damit steigen die Risiken für ein Unternehmen die Umstellung reibungslos durchzuführen. Die personellen Anforderungen an ein ERP-Projektteam bei einem ERP-Wechsel sind ebenfalls hoch. Die benötigten Ressourcen bei Mitarbeitern und im Rahmen des Investments sind beachtlich. Was können Gründe für einen ERP-Wechsel sein? Veraltete, meist unflexible IT-Landschaften/-Systeme sind meist die hauptsächlichen Gründe für einen ERP-Wechsel. Funktionsmängel oder Features, welche die bisherige ERP-Software nicht leisten kann, lassen viele Unternehmen über einen Upgrade nachdenken. Anforderungen im Rahmen der Digitalisierung führen meist zu einem ERP-Wechsel oder ERP-Upgrade Software, die durch den Lieferanten nicht mehr unterstützt wird (meist sind es Branchenpakete) Aufgekündigte Wartungsverträge der Softwarelieferanten sind Auslöser für ERP-Wechsel. ERP-Systeme, die mit Programmiersprachen erstellt wurden, die heute nicht mehr genutzt werden, aber dennoch funktionieren.
Im Mittelstand existieren nicht wenige ERP-Systeme, die durch die eigene IT-Mannschaft oder durch einen eigenen IT-Mitarbeiter oder der eigenen IT-Abteilung programmiert und erstellt wurden. Meist sind solche ERP-Systeme schon lange Jahre erfolgreich im Einsatz. Sie erfüllen Ihre Aufgabe mit Bravour. Eigentlich kein Grund, sich für eine neue ERP-Software zu entscheiden oder einen ERP-Wechsel ins Auge zu fassen.
Der Auslöser ist meist eine anstehende neue Hardware, oder eine alternde Programmiersprache, die bei neuen, jüngeren Mitarbeitern im IT-Umfeld nicht mehr bekannt ist oder gelernt wurde. Damit ist es kaum möglich bestehende Systeme mittelfristig einzusetzen. Durch einen hohen Servicegrad und meist auch durch kurze administrative Wege Funktionen, Prozesse oder Auswertungen bei der IT-Abteilung zu adressieren, werden individuelle Anforderungen in der Regel schnell und genau nach den Anforderungen des einzelnen Auftraggebers umgesetzt. Die Unterstützung dieses USP oder spezieller Prozesse ist oft ein Grund für die von Kunden belohnte Marktleistung.
Was ist die Herausforderung beim ERP-Wechsel von eigenprogrammierten ERP-Softwarelösungen? Die Verantwortlichen im Unternehmen stehen damit vor der Herausforderung entscheiden zu müssen, ob der Weg weiter mit einer eigenerstellten, selbst programmierten ERP-Software oder mit einem am Markt vorhandenen ERP-System auf Standardbasis gegangen werden soll. Oder mit einer Hybrid-Lösung, die die Vorteile von Standard ERP-Software mit den Vorteilen der bisherigen, eigenprogrammierten Lösungen verbindet. Wobei genau dies eine große Herausforderung darstellt.
Ein ERP-Wechsel wird meist verbunden mit zusätzlichen Funktionen, Features, Auswertungen und vielem mehr. Eine wichtige, entscheidende Betrachtung ist der Blick auf das Anforderungsmanagement der Kunden, die Ihre Dienstleistung oder Ihre Produkte kaufen, weil sie sich davon einen eigenen Mehrwert versprechen. Daher ist es zunächst wichtig, sich über die Wertschöpfungsstruktur, die für den Kunden sichtbare Leistung und über die Kosten der Prozesse und Dienstleistungen im Unternehmen einen Überblick zu verschaffen. Ein Einsatz von immer mehr IT-Technologie recht nicht aus, um die Leistungsfähigkeit der Ablauforganisation im Unternehmen zu verbessern um damit wettbewerbsfähig zu bleiben.
Im Rahmen von ERP-Wechsel bei Standard ERP-System zu neuem Standardsystem ist meist der Individualisierungsgrad der bisherigen ERP-Software überschaubar. Bei viel Glück ist das System und dessen Konfiguration einigermaßen dokumentiert. Im Rahmen eines ERP-Wechsels eines individuell (eigen) erstellten ERP-Systems ist der hohe Individualisierungsgrad ein entscheidender Faktor bei der Definition der Anforderungen an ein neues ERP-System im Rahmen des Requirements und der Lastenhefterstelltung. Die Erarbeitung der Deltas von Standard ERP-Systemen zu den Features der Eigenentwicklung ist eine wichtige Aufgabe. Gleichzeitig muss entschieden werden, ob ein (individual) Prozess in der Zukunft noch wirksam ist, oder ob er durch ein Standard ERP-System unterstützt werden muss, weil der Kunden diesen Wertschöpfungsbeitrag belohnt, indem er einen Auftrag erteilt.
Zunächst gibt es aus unserer Sicht bei ERP-Projekten nicht das „Eine“ Vorgehensmodell oder ein Risikomanagement. Die Ausprägung eines Risikomanagements hängt von vielen Faktoren ab, wie zum Beispiel: der Rechtsform, dem Markt in dem sich das Unternehmen befindet, die gesetzgeberischen Vorgaben, die Art der Unternehmensführung und vieles mehr.
In Anlehnung an Vorgaben in der Literatur und der Wissenschaft (Gleißner 2008 Risikocontrolling und strategisches Risikomanagement) ist dieses Sechs-Stufen-Modell ein Ausgangspunkt für eine Einschätzung des erreichten Status oder der Ausgangsposition für weiteres Handeln. Es beginnt bei Stufe 1 mit der Ausprägung: kein Risikomanagement vorhanden und erfährt seine höchste Integration auf Stufe 6 als „Embedded Risikomanagement“. Dabei werden sämtliche strategischen und operativen Entscheidungen durch Bewertungen am risikogerechten Ertragswert oder einem Risikonutzen beurteilt und ausgerichtet. Dies erfordert ein umfangreiches und Integrales Nachdenken über den erwarteten Ertrag und das Risiko dabei. Es ermöglicht auch eine Optimierung der Planungssicherheit.
Abbildung: Entwicklungsstufen im Risikomanagement
In der Regel ist die Nutzung der Stufe 6 ein Prozess, der über viele Jahre andauert und nicht „auf die Schnelle“, vor allem nicht für die Auswahl eines ERP-Systems, aufgebaut werden kann und auch soll. Aber die Stufen 3 und 4 sind für die Beurteilung der Auswirkungen – gerade bei der Frage des Ersatzes einer Eigenprogrammierung – immer wieder ein entscheidendes Werkzeug und eine Unterstützung des Managements bei ihren Entscheidungen. Dieses Risikomanagement zu nutzen, wird bei komplexen Sachverhalten dem Management Sicherheit geben. Fragen, welche Standardsoftware kann oder soll bis zu welchem Integrationsgrad bei einem ERP-Wechsel gekauft und eingesetzt werden, können damit besser beantwortet werden. Dieser Ansatz setzt natürlich voraus, dass ein ERP-Lastenheft die notwendige Qualität für ein solches Auswahlverfahren hat. Es reicht bei weitem nicht nur Funktionsbeschreibungen in Excel-Listen für eine solche komplexe Auswahl und Entscheidungen als Basis zugrunde zu legen.
Sowohl bei einem Ersatz und bei einem ERP-Wechsel einer individualisierten ERP-Software als auch bei „in die Jahre gekommenen“ ERP-Systemen ist die Berücksichtigung des Business Modells ein weiterer, wichtiger Baustein, um ein neues ERP-System zu definieren. Bei der Identifikation von strategischen Risiken, die mit einem solchen Wechsel verbunden sind, ist ein Blick auf die Zusammenhänge der Kernbereiche eines Unternehmens sinnvoll. Welche strategischen Gesichtspunkte sind bei einem ERP-Wechsel zusätzlich zu beachten? Gesetzt der Fall, ein Unternehmen hat eine IT-Mannschaft aus Programmierern, die sich nur im Rahmen von Open-Source-Programmierungen wohlfühlen und dort als Experten einen entscheidenden Wertbeitrag für ein Unternehmenden leisten. Das Management trifft eine Entscheidung zugunsten einer Standardisierung, einer am Markt etablierten Standardsoftware, sei es SAP, Oracle, Microsoft oder eine andere Lösung zu kaufen. Damit werden Skills der Programmierer mit einem Schlag wertlos und deren Wertschöpfungsbeitrag für das Unternehmen nimmt zunächst schnell danach kontinuierlich und asymptotisch ab. Diese Mitarbeiter werden mit einer hohen Wahrscheinlichkeit das Unternehmen verlassen. Damit wird auch ein Brain Drain erfolgen. Zusätzlich stellt sich die Frage: ist das Unternehmen in der Lage in einem wettbewerbsintensiven Markt für die Engpassressourcen IT-Spezialisten attraktiv genug zu sein, um neue Mitarbeiter zu gewinnen? Anmerkung: Damit möchte ich nicht der Idee Vorschub leisten, Managemententscheidungen auf oder um Personen herum zu treffen, sondern darauf hinweisen, dass solche Auswirkungen in einem Risikomanagement bearbeitet und bewertet werden müssen.
Abbildung: Kernbereiche einer Unternehmensstrategie
Ein Business Modell stellt auf einer vereinfachten und stark aggregierten Abbildung relevante Aktivitäten eines Unternehmens dar. Darin ist zu erkennen, wie durch Wertschöpfungskomponenten eines Unternehmens vermarktungsfähige Informationen, Produkte und Dienstleistungen entstehen. Dabei werden neben der Architektur der Wertschöpfungsketten auch die strategischen Kunden- und Marktpotentiale berücksichtigt, um das übergeordnete Ziel der Generierung, Sicherung und des Ausbaus des Wettbewerbsvorteils zu realisieren. (In Anlehnung an Wirtz B.W. 2013 Business Model Management, – Erfolgsfaktoren von Geschäftsmodellen)
Jede Installation und Neueinführung einer Software kommt irgendwann an den Punkt der Migration. Es gibt verschiedene Szenarien einer Migration. Im Rahmen von Übernahmen von Daten und Prozessen aus bestehenden Systemen ist ein systematisch geplantes – im Risikomanagement bewertetes – Vorgehensmodell sinnvoll.
Abbildung: Modelldarstellung zur Migration bei einem ERP-Wechsel
Alle für eine Neucodierung notwendigen Informationen werden aus dem Altsystem übernommen (meist sind dies Anforderungen im Rahmen des Stammdatenmanagements). Die notwendigen Änderungen werden im bisherigen Ansatz übernommen, eventuell angereichert, aber der bisherige Lösungsansatz bleibt erhalten. Problem dabei ist, dass sich ein neues ERP-System dafür auch eignen muss.
Daten oder Programme werden automatisiert in die für die Zielumgebung benötigte Form transformiert. Ergänzungen und Bereinigungen, sowie die Qualitätssicherung von Daten muss davor stattfinden. Werkzeuge aus dem Reverse Engineering sind dazu am Markt, aber der Aufwand ist nicht zu unterschätzen. Notwendig dafür ist aber ein tiefes Verständnis des Altsystems, um Daten und Informationen zu transformieren. Dies ist bei eigenprogrammierten Systemen in der Regel im Unternehmen vorhanden.
Daten und das Programmsystem der alten Anwendung bleiben bestehen und werden „eingefroren“. Dies wird in einem Ansatz genutzt, um das Altsystem sozusagen als Datenquelle, bzw. Datenarchiv zu nutzen, bei dem ein neues ERP-System bei Bedarf auf die Quelle zurückgreift. Voraussetzung dafür ist natürlich, dass die alte Hardware, die Software, das komplette System in der Funktionalität noch brauchbar ist. Sollten wider Erwarten Fehler im Altsystem auftauchen, müssen diese auch dort noch korrigiert werden. Eine solche Lösung hat natürlich auch ein Verfallsdatum.
Die beschriebenen Punkte der Re-Implementierung und der Konversion beziehen sich im Ansatz stärker auf eine Neuprogrammierung einer bisherigen alt-Lösung. Dabei wird zum Beispiel eine alte Programmiersprache durch eine neue ersetzt. Die Kapselung kann auch bei einer Einführung einer neuen Standard ERP-Software genutzt werden. Diese muss, da sie für einen anonymen Markt (auch Branchenlösungen zählen dazu) sind und für anonyme Märkte entwickelt wurden, an die speziellen Bedürfnisse eines Unternehmens angepasst werden. Diese Anpassung an betriebliche Ablauf-und Aufbauorganisationen und -Prozesse wird als Customizing bezeichnet und darf nicht mit einer individuellen Anpassungsprogrammierung verwechselt werden. Die genauen Spezifikationen dafür sind in einem Lastenheft zu definieren.
Eine Migration eines bestehenden auf ein neues System erfolgt meist nicht mit einem Big Bang, sondern in Form von Teilmigrationen. Meist wird dabei auf das Altsystem im Rahmen der Kapselung parallel genutzt.
Programme bleiben zunächst unverändert bestehen. Es werden nur Daten übertragen. Die Daten können auf ein neues System oder eine neue Datenbank übertragen werden, (typischer Anwendungsfall: Ersatz von Hardware oder Datenbank). Der Anwender spürt in der Regel einen solchen Wechsel nicht, außer in Form einer verbesserten Performance.
Daten bleiben unverändert im vorhandenen Datenhaltungssystem oder in der Datenbank. Es erfolgt eine Migration der Programme. (typischer Anwendungsfall: neue Programmfunktionen lassen sich im bisherigen System nicht oder nur mit hohem Aufwand realisieren, während sich das bisherige Datenhaltungssystem noch bewährt und als nutzbar oder zukunftssicher darstellt).
Hier bleiben Daten und Programme unverändert. Ausgetauscht wird nur die Benutzeroberfläche, die sogenannte Benutzerschnittstelle UUX. Hiervon ist der User am meisten betroffen. Sinn macht diese Migration natürlich nur, wenn die darunter liegenden Systeme noch den Anforderungen der Zukunft entsprechen.
Diese Migration kommt dann zum Einsatz, wenn bisherige Systeme mit neuen ERP-Systemen kommunizieren müssen und deshalb Schnittstellen neu konzipiert werden müssen. Dies kann auch notwendig sein, um bereits migrierte Systeme anzubinden.
Die Migration von Anwendungen ist ein komplexes Thema und eine große Herausforderung im Rahmen eines ERP-Wechsels für ein Unternehmen als auch die Beteiligten. Dies betrifft sowohl das Management im Rahmen von Entscheidungen für Investitionen, als auch die Verantwortlichen im Business zur Definition der künftigen Geschäftsprozesse zur Verbesserung der Kundenwertschöpfung, als auch die Mitarbeiter im Projektteam und die User am Bildschirm und den Abteilungen um nach einem ERP-Wechsel Kundenwünsche kostengünstiger und effizienter zu bearbeiten. Neben der richtigen Strategie ist eine intensive Vorbereitung, Planung zusammen mit einem Risikomanagementansatz und den richtigen Migrationswerkzeugen für den erfolgreichen ERP-Wechsel entscheidend. Dass ein qualitativ hochwertiges Identifikations-und Auswahlverfahren zur Bestimmung eines ERP-Softwarelieferanten benötigt wird, wird vorausgesetzt.