BCG Platinion Case: ERP-Strategie & S/4HANA-Migration für "DekoKonzept"

Im Folgenden werden die verschiedenen Ansätze hinsichtlich ihrer Eignung betrachtet:

Brownfield-Ansatz:
Es ist davon auszugehen, dass die aktuelle IT-Landschaft und -Prozesse die strategischen Ziele von DekoKonzept nicht gut unterstützen. Eine rein technische Migration würde diese Probleme nicht angehen und auch keine neue Grundlage schaffen, um dies zu tun. Es wäre ein entsprechendes Folgeprojekt notwendig, um die Integration des Online-Shops und die Datenhaltung zu verbessern.

Greenfield-Ansatz:
Ein vollständiger Greenfield-Ansatz gilt als teuer und langwierig. Wegen der Zeit- und Budgetbegrenzung kann dieser daher ausgeschlossen werden.

Hybrid-Ansatz:
Die strategischen Ziele liegen insbesondere im Bereich "Order-to-Cash". Ein gezieltes Überarbeiten ausgewählter Prozesse oder Module könnte daher effizienter sein. Im hybriden Ansatz können genau die relevanten Bereiche entlang des Order-to-Cash Prozesses addressiert werden, um die Datenhaltung zu verbessern und den Online-Shop stärker zu integrieren. Weitere Standardisierung, zum Beispiel im Bereich Finanzen & Controlling (FI/CO) könnte diskutiert und, abhängig von Aufwand und Budget, ggf. mit in den Scope des Projekts aufgenommen werden.

Um zukünftige Aufwände gering zu halten, sollte möglichst wenig eigenes Coding innerhalb des ERP-Systems verwendet werden (Konzept des "Clean Core"). Ob ein Prozess standardisiert werden sollte, hängt allerdings auch davon ab, um welche Art von Prozess es sich handelt:

Differenzierende Prozesse:
Hierbei handelt es sich um Prozesse, die dem Unternehmen einen Wettbewerbsvorteil verschaffen können. Eine Individualisierung ist für diese Prozesse grundsätzlich denkbar (beispielsweise über WRICEFs oder eine Side-by-Side Extension), dabei ist der Kosten und Nutzen gegeneinander abzuwägen. Zusätzlich sollten auf technischer Seite die Zukunfts- und Update-Sicherheit berücksichtigt werden. Auch die Frequentierung, also wie oft der Prozess genutzt wird, ist zu beachten - insbesondere bei sehr selten genutzten Prozessen ist der Mehrwert umso klarer hervorzuheben. Abschließend muss eine Abweichung vom Standard immer durch einen klaren Business Case und den entsprechenden Mehrwert fürs Business begründet sein.

Reguläre Prozesse:
Alle nicht-differenzierenden Prozesse, die also keine wesentlichen Geschäftsvorteile gegenüber Mitbewerbern verschaffen oder anderweitig stark differenzierend sind, sollten soweit wie möglich aus dem Standard des Herstellers übernommen werden, um den eigenen Aufwand gering zu halten. Der Ist-Zustand kann im Rahmen von "Fit/Gap"-Workshops analysiert werden, um anschließend das gewünschte Standardisierungs-Niveau zu definieren und umzusetzen.

Ausnahmen:
Ausnahmefälle für eine Abweichung vom Standard könnten gesetzliche Vorgaben / Anforderungen in der Lokalisierung oder ein z. B. branchen-spezifisches "Gap" in der Software sein. Diese Ausnahmen können auch unabhängig von einem Business Case eine Individualisierung rechtfertigen.

Die Zusammenarbeit zwischen dem ERP und anderen Systemen, die Bestände verarbeiten, kann schnell zu Situationen führen, in denen ein System nicht die letzten Bestandsdaten vorliegen hat. Gerade im Retail-Bereich kommt eine zusätzliche Komplexität durch das Vorhalten von Beständen hinzu, z. B. eine Reservierung im Warenkorb. Es fehlt daher an einer "Single Source of Truth" für die Bestandsdaten und einem entsprechenden System, das diese Aufgabe übernimmt.

Beispiel von DekoKonzept: das Point-of-Sale System (POS) und der Online-Shop greifen unabhängig voneinander direkt auf Bestände im ERP zu, aber auf völlig unterschiedliche Art und Weise. Der Online-Shop beispielsweise greift direkt Bestände ab, die aber im ERP erst in nächtlichen "Batch Jobs" aktualisiert werden. Das POS-System hingegen sammelt seine Bestellungen und sendet erst zum täglichen Geschäftsschluss ein Update an das ERP. Da die Schnittstelle durch inkonsistente Daten und andere technische Probleme auch immer wieder mal auf Fehler läuft, werden die Verkaufsdaten teilweise auch erst nach ein paar Tagen aktualisiert.

Grundlegende Anforderungen, die notwendig sind, um die Anforderungen umzusetzen (weitere Nennungen sind möglich):

• Funktionalität: das ERP muss funktional die entsprechenden Prozesse rund um Click & Collect anbieten (im SD / O2C-Modul).
• Datenmodell: konsistentes Datenmodell über alle relevanten Applikationen hinweg (ERP, POS, etc.), sodass ein Austausch über Schnittstellen ohne Fehler möglich ist.
• Integration: Echtzeit-Datenverarbeitung über eine Middleware / einen Integration Layer, die den Austausch zwischen den Applikationen ermöglicht und der als zentrale Datenquelle für aktuelle Bestandsdaten gilt.
• Bestandsmanagement: Vorhaltung von Reservierungen, Warenkörben, etc. in einer separaten Applikation, die an das ERP angeschlossen ist (wie beispielsweise SAP CAR oder "on-the-edge" an der Middleware).

Es gibt verschiedene Herangehensweisen, den Business Case aufzubauen:

1. Top-down: grobe Abschätzung der wichtigsten Kosten- & Nutzen-Positionen mithilfe verfügbarer KPIs und Benchmarks - schnell durchführbar, aber potenziell ungenau
2. Bottom-up: detailliertere Rechnung, bei der Kosten- & Nutzen-Positionen bspw. entlang der Projektzeitleiste kalkuliert und dann aggregiert werden - grundsätzlich zeitaufwendig, für kürzere Projektzeiträume aber potenziell genauer als der Top-down Ansatz

Davon ausgehend, dass ERP-Transformationen eher längere Projektzeiträume umfassen, bietet sich oft eine Top-down Schätzung zu Beginn an, die später ausdetailliert werden kann.

Mögliche Top-down Struktur (andere oder abweichende Antworten möglich):

Kosten

• Einmalige Kosten
  • Initialkosten (Setup, Hardware, erste Schulungen, etc. ...)
  • Implementierungskosten (interne FTE, externe FTE - oder Split nach Aufgaben, z. B. PMO, Customizing, Entwicklung, Testing, ...)
  • Projektnebenkosten (Reisekosten, Projektraum / -geräte, ...)
• Laufende Kosten
  • Vertragskosten (SAP RISE etc.)
  • Ggf. zusätzliche Wartung / Support durch externen SI
  • Interne Personalkosten (z. B. Betrieb, Prozesse)

Nutzen

• Direkte Einsparungen
  • Kostenersparnisse durch Automatisierung und Prozess-Effizienzen (in eingesparten FTE)
  • Konsolidierung von IT-Systemen, Wartung und Support
• Indirekte Vorteile
  • Harmonisierung von Prozessen ermöglicht einfacheren Austausch zwischen verschiedenen Standorten / Funktionen
  • Höhere Kundenzufriedenheit (siehe die bereits erwähnten abgebrochenen Aufträge wegen falscher Bestandsdaten)
  • Strategische Vorteile durch bessere Entscheidungsfindung / Datentransparenz und modernes System als notwendige Basis für Innovation (z. B. GenAI)
  • Vereinfachte Compliance und damit schnellere Prüfung bzgl. Compliance
  • Attraktivere Prozesse und Oberflächen für die Anwerbung neuer Mitarbeiter:innen

Für eine Bottom-up Struktur könnten beispielsweise die verschiedenen Workstreams (entweder nach Funktion: O2C, P2P, ... oder nach Aktivitäten: Design, Build, Testing, ...) und ihre entsprechenden Personalbedarfe über die Zeitleiste hinweg geplant werden.

Eintrittspunkt positiver Effekte:
Da die ERP-Transformation selbst bei einem kleinen Unternehmen zwischen 1 und 3 Jahren dauern kann, und die meisten Vorteile sich erst nach dem Go-live ergeben, sollte der Business Case auch mindestens diesen Zeitraum berücksichtigen. Manche Vorteile - wie Prozesseffizienzen - ergeben sich möglicherweise auch erst später, nachdem die Mitarbeiter:innen sich an die neuen Prozesse gewöhnt haben. Eventuell gibt es auch eine Übergangsphase, in der alte und neue Prozesse noch parallel zueinander existieren, um die Stabilität zu gewährleisten. Auch die Reduzierung von Ressourcen lässt sich nur nach und nach umsetzen (je nach Unternehmensbedingungen und Arbeitsrecht).

Wichtigste Positionen:
Die größten Kostenpositionen sind typischerweise interne & externe FTE (Personalkosten) und der größte Nutzen können dementsprechend Einsparnisse bei Personalkosten durch Prozesseffizienzen sein.