Learn about how AI operates inside SAP S/4HANA, from clean core and data quality to embedded use cases, real-time decisions, and secure, transparent execution.
Eine erfolgreiche SAP S/4HANA Migration beginnt mit der Analyse der bestehenden SAP-Landschaft und nicht mit der technischen Systemkonvertierung. Erst auf Basis von Prozessen, Daten, Eigenentwicklungen, Integrationen und Geschäftszielen lässt sich die passende Transformationsstrategie bestimmen.
Warum Schweizer Unternehmen jetzt ihre SAP-ECC-Strategie prüfen sollten
Für viele Schweizer Unternehmen ist SAP ECC weiterhin ein zentraler Bestandteil der Geschäftsprozesse. Gleichzeitig verändert sich die strategische Ausgangslage: Die Wartungszeiträume der SAP Business Suite 7 nähern sich ihrem Ende, während SAP S/4HANA neue Möglichkeiten für standardisierte Prozesse, Cloud-Betriebsmodelle, Automatisierung und moderne Integrationen eröffnet.
Eine SAP S/4HANA Migration in der Schweiz sollte deshalb nicht als reines technisches Upgrade verstanden werden. Sie ist eine Entscheidung über die zukünftige ERP-Architektur und darüber, welche Geschäftsprozesse, Daten, Eigenentwicklungen und Integrationen langfristig erhalten, angepasst oder ersetzt werden sollen.
Was bedeutet das Ende der SAP-ECC-Ära für Unternehmen?
Eine SAP-Beratung unterstützt Unternehmen bei der Planung, Implementierung, Migration, Integration und Weiterentwicklung ihrer SAP-Landschaft. Je nach Projekt kann dies auch Datenmanagement, SAP BTP, Cloud-Transformation und SAP Application Management Services umfassen. Am Anfang eines SAP-Projekts steht nicht zwingend die Technologie. Zunächst sollte geklärt werden, welche Geschäftsziele mit der SAP-Transformation erreicht werden sollen.
SAP hat für die zentralen Anwendungen der Business Suite 7 eine Mainstream Maintenance bis Ende 2027 vorgesehen; für bestimmte Szenarien besteht darüber hinaus eine optionale Extended Maintenance bis Ende 2030. Das schafft einen klaren zeitlichen Rahmen für die ERP-Planung.
Für Unternehmen bedeutet das jedoch nicht, dass eine Migration möglichst schnell durchgeführt werden sollte. Entscheidend ist vielmehr, früh genug eine belastbare Ausgangsanalyse und Roadmap zu erstellen. Je nach Systemlandschaft kann die Vorbereitung von Datenbereinigung und Custom-Code-Analyse über Prozessharmonisierung und Integrationsdesign bis zur Planung von Tests und Cutover reichen.
Eine S/4HANA-Migration ist eine Geschäftsentscheidung
Bei einer SAP ECC Migration Schweiz sollten mindestens fünf Dimensionen gemeinsam betrachtet werden:
- Geschäftsprozesse: Welche Prozesse sollen unverändert bleiben, welche sollen standardisiert oder neu gestaltet werden?
- Daten: Welche Stamm- und Bewegungsdaten müssen übernommen werden, und welche können archiviert oder bereinigt werden?
- Custom Code: Welche Eigenentwicklungen sind geschäftskritisch und welche können durch S/4HANA-Standardfunktionen ersetzt werden?
- Integration: Welche Systeme, Schnittstellen und externen Anwendungen hängen vom heutigen ECC-System ab?
- Zielarchitektur: Soll das zukünftige ERP On-Premise, in der Private Cloud oder in der Public Cloud betrieben werden?
Kurz gesagt: Die richtige S/4HANA-Strategie ergibt sich aus der Kombination von Geschäftszielen, bestehender SAP-Landschaft und gewünschtem Veränderungsgrad. Eine technische System Conversion ist nur eine von mehreren möglichen Transformationswegen.
Für Schweizer Unternehmen kommt eine weitere Frage hinzu: Wie lassen sich lokale Anforderungen mit globalen Konzernstandards, internationalen SAP-Templates und gegebenenfalls Cloud- oder grenzüberschreitenden Datenflüssen verbinden?
Deshalb sollte die Ablösung von SAP ECC nicht erst mit der eigentlichen Migration beginnen. Der erste Schritt ist eine strukturierte Bewertung der bestehenden Landschaft und des gewünschten Zielbilds.
Möchten Sie direkt mit uns sprechen?
SAP ECC zu S/4HANA – was ändert sich tatsächlich?
Eine SAP S/4HANA Migration verändert mehr als die technische ERP-Plattform. Datenstrukturen, Geschäftsprozesse, Eigenentwicklungen, Integrationen und die Benutzerinteraktion können betroffen sein. Für Unternehmen ist deshalb entscheidend, früh zu verstehen, welche Teile der bestehenden SAP-Landschaft übernommen, angepasst oder neu gestaltet werden müssen.
ERP-Kern und Datenmodell
SAP S/4HANA basiert auf der SAP-HANA-Datenbank und verwendet ein vereinfachtes Datenmodell. Dadurch können bestimmte redundante Strukturen aus älteren SAP-ERP-Versionen entfallen oder anders verarbeitet werden.
Für eine SAP ECC Migration bedeutet das: Bestehende Prozesse und Daten können nicht pauschal 1:1 übernommen werden. Vor der Migration muss geprüft werden, welche Datenstrukturen, Funktionen und Prozesse im Zielsystem weiterhin benötigt werden und wie sie in S/4HANA abgebildet werden.
Gerade bei historisch gewachsenen SAP-Landschaften ist diese Analyse wichtig. Über Jahre entstandene Datenbestände, kundenspezifische Erweiterungen und individuelle Prozessvarianten können die Komplexität einer Migration deutlich erhöhen.
Prozesse und Benutzererfahrung
Mit SAP S/4HANA steht nicht nur ein neuer technischer ERP-Kern zur Verfügung. Auch die Art, wie Anwender mit dem System arbeiten, kann sich verändern.
SAP Fiori bietet rollenbasierte Benutzeroberflächen und ermöglicht einen stärker auf einzelne Aufgaben und Geschäftsprozesse ausgerichteten Zugriff. Unternehmen sollten deshalb frühzeitig prüfen, welche bestehenden Transaktionen und Arbeitsabläufe übernommen werden können und wo eine Neugestaltung sinnvoll ist.
Dabei sollte die Migration nicht allein aus IT-Sicht betrachtet werden. Veränderungen bei Finance, Einkauf, Produktion, Logistik oder Asset Management wirken sich direkt auf die täglichen Arbeitsabläufe aus. Fachbereiche sollten deshalb bereits während der Konzeption eingebunden werden.
Custom Code und Erweiterungen
Ein häufig unterschätzter Teil einer SAP S/4HANA Transformation ist der bestehende Custom Code. Eigenentwicklungen können über Jahre entstanden sein, um Lücken im damaligen SAP-Standard zu schliessen oder unternehmensspezifische Prozesse abzubilden.
Bei der Migration sollte daher nicht einfach jede Eigenentwicklung technisch weitergeführt werden. Stattdessen empfiehlt sich eine Bewertung nach dem Prinzip:
Behalten – anpassen – durch Standard ersetzen – stilllegen.
Dabei stellt sich für jede relevante Entwicklung die Frage:
- Wird die Funktion im Unternehmen weiterhin benötigt?
- Gibt es inzwischen eine geeignete S/4HANA-Standardfunktion?
- Ist die Eigenentwicklung mit dem Zielsystem kompatibel?
- Verursacht sie zusätzliche Wartungs- oder Upgrade-Aufwände?
- Sollte die Funktion künftig ausserhalb des ERP-Kerns umgesetzt werden?
Dieser Ansatz unterstützt zugleich eine Clean-Core-Strategie, bei der individuelle Erweiterungen möglichst so gestaltet werden, dass der stabile ERP-Kern nicht unnötig verändert wird.
Schnittstellen und Integrationen
Eine Migration betrifft selten nur das ERP-System selbst. In einer typischen SAP-Landschaft bestehen Abhängigkeiten zu beispielsweise:
- Lager- und Logistiksystemen
- Produktionssystemen
- E-Commerce-Plattformen
- Banken und Zahlungsdienstleistern
- Steuer- und Reportinglösungen
- CRM-Systemen
- Lieferanten- und Beschaffungsplattformen
- Data-Warehouse- und Analytics-Systemen
Jede dieser Verbindungen kann von einer S/4HANA Migration betroffen sein.
Deshalb sollte vor der technischen Umsetzung ein vollständiges Integrationsinventar erstellt werden. Dabei sind nicht nur bekannte Schnittstellen zu erfassen. Auch individuelle Datenflüsse, Batch-Prozesse, Middleware-Komponenten und Abhängigkeiten zwischen Anwendungen sollten dokumentiert und bewertet werden.
Auswirkungen auf die Fachbereiche
Die Auswirkungen einer S/4HANA Migration hängen stark von der gewählten Transformationsstrategie ab.
Bei einer eher technisch orientierten System Conversion können bestehende Prozesse weitgehend erhalten bleiben. Bei einer Greenfield-Transformation hingegen werden Prozesse häufig stärker standardisiert und neu gestaltet.
Für die Fachbereiche können daraus Veränderungen entstehen, etwa bei:
- Buchungs- und Abschlussprozessen in Finance
- Einkaufs- und Freigabeprozessen
- Produktionsplanung
- Lager- und Transportprozessen
- Stammdatenpflege
- Reporting und Analysen
- Benutzerrollen und Verantwortlichkeiten
Die zentrale Frage lautet deshalb nicht nur «Wie migrieren wir unser SAP-System?», sondern «Welche Geschäftsprozesse soll unser zukünftiges ERP-System unterstützen?»
Je früher diese Frage beantwortet wird, desto besser lassen sich Migrationsumfang, Aufwand und Veränderungsbedarf einschätzen.
Welche S/4HANA-Migrationsstrategie passt zu Schweizer Unternehmen?
Es gibt keine universell beste Strategie für die SAP S/4HANA Migration. Entscheidend ist, wie stark ein Unternehmen seine bestehenden Prozesse übernehmen möchte, wie viel historisches Datenmaterial benötigt wird und wie komplex die bestehende SAP-Landschaft ist.
Grundsätzlich stehen drei Ansätze im Mittelpunkt: Brownfield bzw. System Conversion, Greenfield bzw. Neuimplementierung und Selective Data Transition. Die Wahl sollte nicht allein aus technischer Sicht erfolgen, sondern gemeinsam mit Fachbereichen, IT, Finance und Management.
Brownfield: Bestehendes SAP-System weiterentwickeln
Beim Brownfield-Ansatz wird das bestehende SAP-ECC-System in Richtung S/4HANA transformiert. Bestehende Strukturen, Prozesse und Daten können dabei in grossem Umfang als Ausgangspunkt dienen.
Dieser Ansatz eignet sich insbesondere für Unternehmen, die ihre etablierten Geschäftsprozesse grundsätzlich beibehalten möchten und gleichzeitig die S/4HANA-Plattform nutzen wollen.
Typische Vorteile:
- Kontinuität bei etablierten Geschäftsprozessen
- weniger grundlegende Prozessneugestaltung
- vorhandene Daten und Strukturen können weitgehend als Ausgangspunkt dienen
- geeignet für schrittweise Modernisierung und Clean-Core-Ansätze
Brownfield bedeutet jedoch nicht, dass das bestehende ECC-System unverändert übernommen wird. Simplification Items, Custom Code, Add-ons, Datenstrukturen, Schnittstellen und betroffene Geschäftsprozesse müssen vor der Conversion systematisch geprüft und angepasst werden.
Greenfield: S/4HANA neu aufbauen
Beim Greenfield-Ansatz wird S/4HANA als neues ERP-System implementiert. Statt bestehende Strukturen möglichst weitgehend zu übernehmen, werden Prozesse anhand des zukünftigen Geschäftsmodells neu gestaltet und möglichst am SAP-Standard ausgerichtet.
Das kann besonders sinnvoll sein, wenn ein Unternehmen stark individualisierte Prozesse, umfangreichen Custom Code oder eine historisch gewachsene Systemlandschaft hat.
Typische Vorteile:
- konsequente Prozessharmonisierung
- stärkerer Fokus auf SAP-Standard und Clean Core
- Gelegenheit, veraltete Prozesse und Individualentwicklungen abzulösen
- gute Grundlage für eine umfassende ERP-Transformation
Der Preis dafür ist ein grösserer organisatorischer Veränderungsaufwand. Fachbereiche müssen sich aktiv mit neuen Prozessen, Rollen und Arbeitsweisen auseinandersetzen.
Selective Data Transition: Bestehendes gezielt transformieren
Selective Data Transition verbindet Elemente aus beiden Ansätzen. Nicht die gesamte bestehende ERP-Landschaft wird unverändert übernommen und auch nicht alles neu aufgebaut. Stattdessen werden relevante Daten, Prozesse oder Systembestandteile gezielt in die neue S/4HANA-Umgebung überführt.
Dieser Ansatz kann interessant sein, wenn mehrere SAP-Systeme konsolidiert werden sollen, unterschiedliche Länderorganisationen betroffen sind oder nur bestimmte historische Daten und Geschäftsprozesse benötigt werden.
Welche Strategie ist wann sinnvoll?
| Kriterium | Brownfield | Greenfield | Selective Data Transition |
|---|---|---|---|
| Bestehende Prozesse | weitgehend beibehalten | neu gestalten | gezielt auswählen |
| Prozessharmonisierung | mittel | hoch | hoch |
| Custom Code | analysieren und reduzieren | weitgehend neu bewerten | selektiv übernehmen |
| Historische Daten | stärkerer Erhalt möglich | gezielte Migration | selektive Übernahme |
| Veränderungsgrad | eher geringer | hoch | mittel bis hoch |
| Geeignet für | stabile, etablierte Prozesse | grundlegende Transformation | komplexe oder heterogene Landschaften |
Die Entscheidung sollte auf einer strukturierten Bewertung basieren. Auch SAP-Partner und Beratungen unterscheiden zwischen diesen Szenarien, wobei Faktoren wie gewünschter Veränderungsgrad, Nutzen, Risiken und organisatorische Bereitschaft entscheidend sind.
Fünf Fragen für die richtige Migrationsstrategie
Vor der Entscheidung sollten Schweizer Unternehmen insbesondere fünf Fragen beantworten:
1. Wie stark sollen die bestehenden Geschäftsprozesse verändert werden?
Je grösser der gewünschte Prozessumbau, desto eher spricht dies für einen Greenfield- oder Selective-Data-Transition-Ansatz.
2. Welche historischen Daten müssen im neuen ERP verfügbar sein?
Nicht jedes historische Datenobjekt muss zwingend vollständig in S/4HANA übernommen werden. Anforderungen an Reporting, Audit, Compliance und operative Prozesse sollten gemeinsam betrachtet werden.
3. Wie viel Custom Code und technische Altlasten bestehen?
Ein hoher Anteil individueller Entwicklungen kann eine gute Gelegenheit für Standardisierung sein. Gleichzeitig muss geprüft werden, welche Erweiterungen geschäftskritisch sind.
4. Wie komplex ist die bestehende System- und Integrationslandschaft?
Mehrere ERP-Systeme, lokale Lösungen, Drittanwendungen und zahlreiche Schnittstellen erhöhen die Anforderungen an die Transformationsstrategie.
5. Wie stark müssen Prozesse über Länder und Gesellschaften harmonisiert werden?
Für Schweizer Unternehmen mit internationalen Organisationen ist die Frage besonders relevant, ob ein globales Template übernommen, erweitert oder grundlegend neu gestaltet werden soll.
Die wichtigste Erkenntnis: Die richtige S/4HANA-Migrationsstrategie ist nicht automatisch die technisch einfachste. Sie sollte den gewünschten Geschäftszustand, die bestehende Systemlandschaft und die Veränderungsfähigkeit des Unternehmens gemeinsam berücksichtigen.
Sie planen eine SAP-Transformation in der Schweiz?
S/4HANA Cloud oder On-Premise – welche Option passt?
Die Entscheidung für S/4HANA ist eng mit der Frage verbunden, wie das ERP künftig betrieben werden soll. Schweizer Unternehmen müssen dabei nicht nur zwischen Cloud und On-Premise unterscheiden. Relevant sind auch der gewünschte Grad an Standardisierung, die Anforderungen an Individualisierung, die bestehende IT-Landschaft und der Umgang mit Daten und Integrationen.
Grundsätzlich kommen S/4HANA Cloud Public Edition, S/4HANA Cloud Private Edition und On-Premise als unterschiedliche Betriebsmodelle infrage.
S/4HANA Cloud Public Edition
Die Public Edition ist stark auf standardisierte Prozesse und ein standardisiertes Betriebsmodell ausgerichtet. Sie eignet sich vor allem für Unternehmen, die ihre ERP-Prozesse stärker am SAP-Standard ausrichten möchten und möglichst wenig eigene technische Betriebsverantwortung übernehmen wollen.
Der Ansatz passt insbesondere zu Unternehmen, die:
- Prozesse standardisieren und harmonisieren möchten
- einen hohen Cloud-Anteil anstreben
- den Eigenbetrieb der ERP-Infrastruktur reduzieren möchten
- neue SAP-Funktionen regelmässig nutzen wollen
- einen konsequenten Fit-to-Standard-Ansatz verfolgen
Für stark individualisierte Prozesse kann die Umstellung auf den Standard allerdings eine grössere fachliche und organisatorische Veränderung bedeuten.
S/4HANA Cloud Private Edition
Die Private Edition bietet mehr Spielraum für individuelle Anforderungen und komplexere bestehende SAP-Landschaften. Sie kann daher für Unternehmen interessant sein, die Cloud-Vorteile mit einem höheren Grad an Flexibilität verbinden möchten.
Gerade bei einer SAP ECC Migration Schweiz kann dieses Modell relevant sein, wenn bestehende Prozesse, Integrationen oder Organisationsstrukturen nicht vollständig auf ein stark standardisiertes Modell umgestellt werden können oder sollen.
Dabei sollte jedoch vermieden werden, bestehende technische Altlasten lediglich in eine neue Umgebung zu übertragen. Eine Migration ist eine Gelegenheit, Custom Code, Schnittstellen und Prozesse gezielt zu vereinfachen und den Clean-Core-Ansatz umzusetzen.
On-Premise: Maximale Kontrolle, höhere Eigenverantwortung
Bei einer On-Premise-Implementierung verbleibt ein grösserer Teil der technischen Verantwortung beim Unternehmen beziehungsweise dessen IT- und Betriebspartnern. Das kann sinnvoll sein, wenn spezifische Anforderungen an Infrastruktur, Integration, Individualisierung oder bestehende Betriebsmodelle bestehen.
Dem stehen höhere Anforderungen an Betrieb, Wartung, Sicherheit, Upgrades und interne Ressourcen gegenüber.
Welche Option passt zu welchem Unternehmen?
| Kriterium | Public Edition | Private Edition | On-Premise |
|---|---|---|---|
| Standardisierung | sehr hoch | hoch | flexibel |
| Individualisierung | begrenzter | höher | sehr hoch |
| Eigenbetrieb | gering | gering bis mittel | hoch |
| Komplexe SAP-Landschaft | eher begrenzt | gut geeignet | gut geeignet |
| Transformationsgrad | hoch | mittel bis hoch | variabel |
| Fit-to-Standard | zentral | wichtig | optional stärker individualisierbar |
Die Wahl des Betriebsmodells sollte deshalb nicht isoliert von der Migrationsstrategie getroffen werden. Ein Unternehmen mit stark individualisiertem ECC-System benötigt möglicherweise einen anderen Übergang als ein Unternehmen, das seine Prozesse ohnehin grundlegend harmonisieren möchte.
Schweizer Anforderungen früh berücksichtigen
Für Schweizer Unternehmen kommt eine zusätzliche Dimension hinzu: Datenhaltung, Datenschutz, Compliance und grenzüberschreitende Datenflüsse müssen bereits bei der Zielarchitektur berücksichtigt werden.
Das revidierte Schweizer Datenschutzgesetz ist seit dem 1. September 2023 in Kraft. Bei Cloud-Szenarien sollten deshalb unter anderem Verantwortlichkeiten, Auftragsbearbeitung, Unterauftragsverarbeiter, Sicherheitsmassnahmen und mögliche grenzüberschreitende Datenübermittlungen frühzeitig geprüft werden.
Auch die Schweizer Lokalisierung von SAP-Prozessen und Funktionen sollte Teil der Architekturentscheidung sein. Dazu gehören beispielsweise Anforderungen an Finance, Steuern, Reporting und elektronische Dokumente. SAP stellt hierfür landesspezifische Funktionen für die Schweiz bereit.
Die wichtigste Erkenntnis: Cloud oder On-Premise sollte nicht als reine IT-Infrastrukturentscheidung betrachtet werden. Das Betriebsmodell muss zur gewünschten Prozessstandardisierung, zur Unternehmensstrategie, zur Systemlandschaft und zu den Schweizer Compliance-Anforderungen passen.
So läuft eine SAP S/4HANA Migration typischerweise ab
Eine SAP S/4HANA Migration besteht nicht aus einem einzelnen technischen Schritt. Sie ist ein strukturiertes Transformationsprogramm, bei dem ERP-Prozesse, Daten, Eigenentwicklungen, Schnittstellen und die zukünftige Betriebsarchitektur zusammengeführt werden.
Die konkrete Reihenfolge variiert je nach Ausgangslage und gewählter Migrationsstrategie. In der Praxis lassen sich jedoch neun zentrale Phasen unterscheiden.
1. Assessment und Readiness Check
Am Anfang steht eine detaillierte Bestandsaufnahme des bestehenden SAP-ECC-Systems.
Dabei werden unter anderem analysiert:
- verwendete SAP-Module und Funktionen
- Geschäftsprozesse und Transaktionen
- Datenvolumen und Datenqualität
- Custom Code und Eigenentwicklungen
- Add-ons und Erweiterungen
- Schnittstellen und angebundene Systeme
- technische Abhängigkeiten
- bestehende Integrations- und Reporting-Lösungen
Ein Readiness Assessment hilft dabei, frühzeitig technische und funktionale Anpassungsbedarfe zu erkennen. Das Ergebnis sollte kein rein technischer Bericht sein, sondern eine belastbare Grundlage für die Migrationsstrategie und Projektplanung.
2. Zielbild und Migrations-Roadmap
Auf Basis des Assessments wird das zukünftige ERP-Zielbild definiert.
Dazu gehören unter anderem:
- Migrationsstrategie
- Ziel-Betriebsmodell
- zukünftige SAP-Architektur
- Prozessharmonisierung
- Datenstrategie
- Integrationsarchitektur
- Umgang mit Custom Code
- Rollen und Verantwortlichkeiten
- Projektphasen und Meilensteine
Gerade bei internationalen Schweizer Unternehmen sollte hier auch geklärt werden, wie lokale Anforderungen mit einem globalen SAP-Template zusammenspielen.
3. Prozessdesign und Fit-to-Standard
Anschliessend wird festgelegt, wie die Geschäftsprozesse künftig in S/4HANA funktionieren sollen.
Dabei sollte nicht automatisch jede bestehende ECC-Funktion übernommen werden. Stattdessen wird für jeden wesentlichen Prozess geprüft:
Was soll beibehalten, vereinfacht, standardisiert oder vollständig neu gestaltet werden?
Finance, Einkauf, Supply Chain, Produktion, Lager, Vertrieb und Reporting sollten gemeinsam mit den jeweiligen Fachbereichen betrachtet werden.
4. Datenmigration und Datenqualität
Datenmigration gehört zu den kritischsten Bestandteilen einer S/4HANA Transformation. Nicht nur die technische Übertragung zählt, sondern auch die Qualität und Struktur der Daten.
Besonders relevant sind:
- Stammdaten
- Geschäftspartner
- Materialstammdaten
- Finanzdaten
- offene Geschäftsvorfälle
- historische Daten
- Datenbereinigung und Dubletten
- Datenarchivierung
Die zentrale Frage lautet dabei nicht nur „Welche Daten können migriert werden?“, sondern „Welche Daten werden im zukünftigen ERP tatsächlich benötigt?“
5. Custom Code und Clean Core
Vorhandene Eigenentwicklungen werden systematisch klassifiziert.
Für jede relevante Entwicklung sollte eine Entscheidung getroffen werden:
Behalten – anpassen – durch SAP-Standard ersetzen – stilllegen.
Ziel ist eine möglichst wartbare S/4HANA-Landschaft mit weniger unnötigen Modifikationen und klar definierten Erweiterungen. Besonders bei einer Greenfield-Transformation bietet sich die Möglichkeit, historische technische Altlasten nicht in das neue ERP zu übertragen.
6. Schnittstellen und Integration
S/4HANA ist selten ein isoliertes System. Deshalb müssen alle relevanten Integrationen frühzeitig erfasst und für die Zielarchitektur bewertet werden.
Dazu können beispielsweise gehören:
- Banken und Zahlungsverkehr
- E-Commerce und Webplattformen
- CRM-Systeme
- Lager- und Logistiklösungen
- Produktionssysteme
- Lieferanten- und Kundenportale
- Steuer- und Reporting-Systeme
- Data-Warehouse- und Analytics-Plattformen
- SAP BTP und weitere Cloud-Anwendungen
Eine vollständige Integrationsübersicht reduziert das Risiko, dass kritische Abhängigkeiten erst kurz vor dem Go-live sichtbar werden.
7. Testing und Business Validation
Tests sollten nicht erst am Ende des Projekts beginnen. Neben technischen Tests müssen insbesondere durchgängige Geschäftsprozesse validiert werden.
Beispiele sind:
Bestellung → Wareneingang → Rechnung → Zahlung
oder
Kundenauftrag → Lieferung → Fakturierung → Zahlungseingang
Für Schweizer Unternehmen kommen je nach Geschäftsmodell zusätzlich lokale Finance-, Steuer-, Reporting- und Compliance-Szenarien hinzu.
8. Cutover und Go-live
Vor dem Go-live wird der Übergang vom bestehenden ECC-System auf S/4HANA detailliert geplant.
Der Cutover-Plan definiert unter anderem:
- Systemstillstand und Freeze-Phasen
- finale Datenmigration
- technische und fachliche Prüfungen
- Schnittstellenaktivierung
- Benutzer- und Berechtigungskonzepte
- Go-live-Entscheidung
- Fallback- und Notfallverfahren
Je besser diese Aktivitäten vorbereitet und mehrfach getestet wurden, desto kontrollierbarer wird der eigentliche Systemwechsel.
9. Hypercare und laufender Betrieb
Mit dem Go-live endet die Migration nicht. In der Hypercare-Phase werden Prozesse, Daten, Schnittstellen und Benutzerfeedback besonders eng überwacht.
Anschliessend geht das System in den regulären Betrieb über. Dazu gehören beispielsweise:
- Application Management Services
- Monitoring
- Incident- und Problem-Management
- Release- und Change-Management
- kontinuierliche Prozessoptimierung
- weitere Automatisierung und Innovation
Gerade bei einer langfristigen S/4HANA-Transformation sollte bereits vor dem Go-live geklärt sein, wie das System nach der Implementierung betrieben und weiterentwickelt wird.
Der entscheidende Erfolgsfaktor
Eine erfolgreiche SAP Migration Schweiz ist deshalb weniger eine Frage der reinen Conversion-Geschwindigkeit als der Vorbereitung.
Je früher Unternehmen Abhängigkeiten bei Daten, Custom Code, Schnittstellen, Prozessen und Fachbereichen sichtbar machen, desto besser können sie Aufwand, Risiken und Business Impact steuern.
Kurz gesagt: Assessment → Zielbild → Prozesse → Daten → Custom Code → Integration → Testing → Go-live → Hypercare.
Diese Abfolge schafft eine belastbare Grundlage, um eine SAP ECC Migration planbar durchzuführen und gleichzeitig die Voraussetzungen für eine moderne S/4HANA-Plattform zu schaffen.
Welche Schweizer Anforderungen müssen bei der Migration berücksichtigt werden?
Eine SAP S/4HANA Migration in der Schweiz muss neben technischen und fachlichen Anforderungen auch lokale regulatorische und organisatorische Rahmenbedingungen berücksichtigen. Besonders relevant sind Finance und Steuern, Datenschutz, internationale Datenflüsse sowie die Frage, wie Schweizer Gesellschaften in globale SAP-Strukturen eingebunden sind.
Schweizer Lokalisierung und Finance
Ein S/4HANA-System muss die relevanten Schweizer Geschäfts- und Finanzprozesse korrekt abbilden. Dazu gehören je nach Unternehmen beispielsweise Anforderungen an:
- Schweizer Währungen und Buchungsprozesse
- Mehrwertsteuer und steuerrelevante Prozesse
- Finanzreporting und gesetzliche Berichterstattung
- elektronische Dokumente und Meldungen
- Zahlungsverkehr und Bankintegration
- lokale Anforderungen an Rechnungen und Belege
SAP stellt für die Schweiz entsprechende landesspezifische Funktionen bereit. Diese sollten bereits während der Prozess- und Lösungsplanung berücksichtigt und nicht erst kurz vor dem Go-live getestet werden.
Datenschutz und Cloud-Nutzung
Bei Cloud-basierten ERP-Modellen gewinnt der Datenschutz zusätzlich an Bedeutung. Das revidierte Schweizer Datenschutzgesetz (revDSG) ist seit dem 1. September 2023 in Kraft.
Für die S/4HANA-Zielarchitektur sollte deshalb frühzeitig geklärt werden:
- Welche personenbezogenen Daten werden verarbeitet?
- Wo werden Daten gespeichert und verarbeitet?
- Welche Auftragsbearbeiter und Unterauftragsbearbeiter sind beteiligt?
- Welche Daten verlassen die Schweiz?
- Welche technischen und organisatorischen Sicherheitsmassnahmen bestehen?
- Wie werden Zugriffe, Berechtigungen und Datenflüsse dokumentiert?
Gerade bei internationalen Cloud-Architekturen sollten mögliche grenzüberschreitende Datenübermittlungen und die entsprechenden Schutzmechanismen bereits in der Planungsphase bewertet werden.
Globale Templates und Schweizer Gesellschaften
Viele Schweizer Unternehmen sind Teil internationaler Konzerne. In solchen Fällen wird S/4HANA häufig nicht für die Schweiz isoliert eingeführt, sondern als Bestandteil eines globalen ERP-Templates.
Damit entstehen zusätzliche Fragen:
Welche Prozesse sind global standardisiert und wo benötigt die Schweiz lokale Anpassungen?
Ein erfolgreiches Template muss beispielsweise globale Vorgaben für Finance, Procurement oder Supply Chain mit Schweizer Anforderungen verbinden. Wird dieser Zielkonflikt zu spät adressiert, können lokale Workarounds, zusätzliche Schnittstellen oder spätere Prozessanpassungen entstehen.
Mehrsprachigkeit und Benutzerakzeptanz
Bei Unternehmen mit mehreren Sprachregionen sollte auch die Benutzererfahrung berücksichtigt werden. Rollen, Prozesse, Dokumente und Schulungen müssen zur tatsächlichen Organisation passen.
Dabei geht es nicht nur um die Übersetzung der Benutzeroberfläche. Entscheidend ist, dass Mitarbeitende verstehen, wie sich ihre täglichen Abläufe durch S/4HANA verändern.
Schweizer Anforderungen als Teil des Designs
Lokalisierung und Compliance sollten deshalb nicht als abschliessende Kontrollpunkte behandelt werden. Sie gehören bereits in die Definition des zukünftigen Prozess- und Systemdesigns.
Eine praktische Prüfung kann dabei vier Ebenen abdecken:
| Ebene | Zentrale Frage |
|---|---|
| Finance & Tax | Sind Schweizer Finanz-, Steuer- und Reporting-Anforderungen abgedeckt? |
| Daten & Datenschutz | Sind Datenflüsse, Speicherorte und Zugriffsrechte geklärt? |
| Integration | Funktionieren Banken, Behörden, Partner und Drittsysteme mit der Zielarchitektur? |
| Organisation | Sind globale Standards und lokale Schweizer Anforderungen sinnvoll ausbalanciert? |
Die wichtigste Erkenntnis: Eine erfolgreiche SAP ECC Migration Schweiz muss das zukünftige ERP nicht nur technisch funktionsfähig machen. Es muss auch die Schweizer Geschäftsrealität, regulatorische Anforderungen und die internationale Organisationsstruktur des Unternehmens abbilden.
Was kostet eine SAP S/4HANA Migration in der Schweiz?
Die Kosten einer SAP S/4HANA Migration in der Schweiz lassen sich nicht seriös mit einer einzigen Pauschalsumme beantworten. Der Aufwand hängt stark von der Ausgangslage, der gewählten Migrationsstrategie, der Systemlandschaft und dem gewünschten Transformationsgrad ab.
SAP nennt bei Selective-Data-Transition-Projekten unter anderem die Anzahl der Quellsysteme, die Zielarchitektur, die Anzahl der Cutover-Wellen, die eingesetzten Module und Geschäftsprozesse sowie Anforderungen an minimale Ausfallzeiten als wesentliche Einflussfaktoren.
Die wichtigsten Kostentreiber
1. Grösse und Komplexität der bestehenden SAP-Landschaft
Ein einzelnes, gut dokumentiertes ECC-System verursacht in der Regel weniger Projektaufwand als eine heterogene Landschaft mit mehreren Systemen, Mandanten, Gesellschaften und Drittanwendungen.
2. Migrationsstrategie
Brownfield, Greenfield und Selective Data Transition haben unterschiedliche Aufwandsprofile. Eine selektive Migration kann beispielsweise zusätzlichen Aufwand für Datenregeln und Tests erzeugen, während ein Greenfield-Ansatz mehr Prozessdesign und Datenmigration erfordert.
3. Custom Code und Eigenentwicklungen
Je mehr geschäftskritischer Custom Code vorhanden ist, desto grösser kann der Aufwand für Analyse, Anpassung, Tests oder Neuentwicklung werden. Eine systematische Bereinigung kann dagegen den späteren Wartungsaufwand reduzieren.
4. Datenqualität und Datenvolumen
Datenbereinigung, Mapping, Stammdatenharmonisierung und die Entscheidung über historische Daten werden häufig unterschätzt. Gleichzeitig ist nicht jede vorhandene Datenmenge für das neue ERP erforderlich.
5. Schnittstellen und Integrationen
Jede relevante Integration muss analysiert, gegebenenfalls angepasst und getestet werden. Besonders umfangreich kann dies bei Banken, Logistik, Produktion, E-Commerce, CRM, Reporting oder internationalen Systemlandschaften werden.
6. Change Management und Fachbereichsbeteiligung
Eine S/4HANA Transformation verändert häufig Rollen, Prozesse und Benutzeroberflächen. Schulungen, Prozessvalidierung und organisatorisches Change Management gehören deshalb ebenfalls in das Projektbudget.
Ein einfaches Modell für die Budgetplanung
Statt nur ein Gesamtbudget zu schätzen, empfiehlt sich eine Aufteilung in mehrere Kostenblöcke:
| Kostenblock | Typische Inhalte |
|---|---|
| Assessment & Planung | Readiness, Architektur, Migrationsstrategie |
| Prozesse & Implementierung | Fit-to-Standard, Konfiguration, Prozessharmonisierung |
| Daten | Bereinigung, Mapping, Migration, Validierung |
| Custom Code | Analyse, Anpassung, Stilllegung, Neuentwicklung |
| Integration | Schnittstellen, APIs, Drittsysteme, Tests |
| Testing | Integrationstests, User Acceptance Tests, Regression |
| Cutover & Go-live | Migration, Probeläufe, Produktivsetzung |
| Change Management | Kommunikation, Schulung, Adoption |
| Betrieb | Hypercare, Application Management, Weiterentwicklung |
Hinzu kommen – abhängig vom gewählten Betriebsmodell – Kosten für SAP-Lizenzen bzw. Subscriptions, Infrastruktur, zusätzliche Lösungen und den laufenden Betrieb.
Warum ein Assessment vor dem Angebot wichtig ist
Ein belastbares Budget entsteht idealerweise nach einer strukturierten Analyse des bestehenden Systems. Bereits ein frühes Assessment kann zeigen, wo die grössten Aufwandstreiber liegen: etwa bei Custom Code, Daten, Schnittstellen, Add-ons oder komplexen Geschäftsprozessen.
SAP empfiehlt für Conversion-Projekte unter anderem den Einsatz des Readiness Checks, um relevante Simplification Items und betroffenen Custom Code frühzeitig zu identifizieren.
Damit lässt sich die entscheidende Frage beantworten:
Was muss tatsächlich transformiert werden – und was kann standardisiert, vereinfacht oder stillgelegt werden?
Die wichtigste Erkenntnis: Bei einer SAP S/4HANA Migration sollte nicht der günstigste initiale Projektpreis das zentrale Entscheidungskriterium sein. Entscheidend sind die Gesamtkosten über Migration, Betrieb und Weiterentwicklung sowie der geschäftliche Nutzen der zukünftigen ERP-Landschaft.
Möchten Sie Ihre SAP-Landschaft kostenlos digital analysieren lassen?
Die häufigsten Risiken einer SAP S/4HANA Migration – und wie Unternehmen sie reduzieren
Eine SAP S/4HANA Migration kann technisch gut vorbereitet sein und trotzdem zu Verzögerungen oder Problemen führen. Die häufigsten Ursachen liegen nicht in der Migrationstechnologie selbst, sondern in unterschätzten Abhängigkeiten bei Daten, Custom Code, Schnittstellen, Prozessen und Testing.
SAP Readiness Check unterstützt Unternehmen bereits vor einer Conversion dabei, unter anderem Simplification Items, Custom Code, Add-ons, Geschäftsprozesse und weitere Abhängigkeiten zu analysieren.

Risiko 1: Die bestehende Systemlandschaft wird unterschätzt
Ein ECC-System besteht selten nur aus dem ERP-Kern. Über Jahre entstehen Eigenentwicklungen, Schnittstellen, Add-ons, Reports und Abhängigkeiten zu externen Anwendungen.
Gegenmassnahme:
Vor Projektbeginn eine vollständige System- und Integrationsanalyse durchführen. Dabei sollten nicht nur aktive SAP-Komponenten, sondern auch tatsächlich genutzte Prozesse und Schnittstellen betrachtet werden.
Risiko 2: Custom Code wird zu spät analysiert
Individuelle Entwicklungen können durch Änderungen am Datenmodell und an der S/4HANA-Architektur Anpassungen benötigen. SAP stellt dafür unter anderem Custom-Code-Analysen innerhalb des Readiness-Check-Ansatzes bereit.
Gegenmassnahme:
Eigenentwicklungen früh klassifizieren:
weiterverwenden – anpassen – durch Standard ersetzen – stilllegen.
Dabei sollte auch geprüft werden, welche Entwicklungen tatsächlich noch geschäftskritisch und in Gebrauch sind.
Risiko 3: Daten werden nur technisch betrachtet
Eine erfolgreiche Datenmigration bedeutet nicht lediglich, dass Daten im Zielsystem vorhanden sind. Stammdaten können Dubletten, veraltete Einträge oder inkonsistente Strukturen enthalten.
Gegenmassnahme:
Datenqualität bereits vor der Migration bewerten und klare Regeln für Bereinigung, Mapping, Archivierung und Übernahme definieren. Kritische Datenmigrationen sollten mehrfach getestet und fachlich validiert werden.
Risiko 4: Schnittstellen funktionieren nach dem Go-live nicht wie erwartet
Änderungen an Prozessen und technischen Strukturen können Auswirkungen auf bestehende Integrationen haben. SAP Readiness Check kann unter anderem potenziell betroffene Schnittstellen analysieren.
Gegenmassnahme:
Ein vollständiges Interface Inventory erstellen und jede geschäftskritische Schnittstelle einem Verantwortlichen, einem Testfall und einem Go-live-Szenario zuordnen.
Risiko 5: Fachbereiche werden zu spät eingebunden
Wenn eine Migration hauptsächlich als IT-Projekt geführt wird, werden Prozessänderungen häufig erst während der Tests oder Schulungen sichtbar.
Gegenmassnahme:
Key User und Prozessexperten früh einbinden. Fachbereiche sollten nicht nur Anforderungen liefern, sondern auch bei Prozessdesign, Datenvalidierung, Testing und Go-live-Entscheidungen beteiligt sein.
Risiko 6: Testing wird auf die letzte Projektphase verschoben
Ein erfolgreicher technischer Systemstart garantiert keinen funktionierenden Geschäftsprozess. Gerade bei komplexen ERP-Landschaften müssen End-to-End-Prozesse getestet werden.
Gegenmassnahme:
Frühzeitig eine mehrstufige Teststrategie aufbauen – von technischen Tests über Integrationstests bis zu User Acceptance Tests und produktionsnahen Cutover-Probeläufen.
Risiko 7: Security und Controls werden unterschätzt
Mit einer neuen S/4HANA-Architektur können sich auch Berechtigungen, technische Kontrollen, Schnittstellen und Prozesse verändern. Diese Aspekte sollten deshalb nicht erst nach dem Go-live überprüft werden.
Gegenmassnahme:
Security, Rollen, Berechtigungen und relevante interne Kontrollen als festen Bestandteil der Migration behandeln und frühzeitig mit IT, Finance, Compliance und gegebenenfalls Audit abstimmen.
Risiko 8: Hypercare wird zu kurz geplant
Der Go-live ist ein Meilenstein, aber nicht das Ende der Transformation. In den ersten Wochen können Probleme bei Daten, Rollen, Schnittstellen oder Geschäftsprozessen sichtbar werden.
Gegenmassnahme:
Eine definierte Hypercare-Phase mit klaren Verantwortlichkeiten, Monitoring, Priorisierung kritischer Incidents und schnellen Entscheidungswegen einplanen.
Die wichtigsten Risiken auf einen Blick
| Risiko | Typische Folge | Prävention |
|---|---|---|
| Unvollständige Systemanalyse | Überraschungen im Projekt | Frühes Assessment |
| Viel Custom Code | Hoher Anpassungsaufwand | Code-Analyse und Bereinigung |
| Schlechte Datenqualität | Fehler im Tagesgeschäft | Data Cleansing und Validierung |
| Unklare Schnittstellen | Prozessunterbrechungen | Interface Inventory und End-to-End-Tests |
| Späte Fachbereichsbeteiligung | Geringe Akzeptanz | Key-User-Einbindung |
| Unzureichendes Testing | Fehler nach Go-live | Mehrstufige Teststrategie |
| Fehlende Security-Prüfung | Kontroll- und Compliance-Risiken | Frühzeitige Security-Analyse |
| Zu kurze Hypercare | Langsame Stabilisierung | Strukturierter Support nach Go-live |
Die wichtigste Erkenntnis: Risiken sollten nicht erst während der Migration behandelt werden. Je früher Unternehmen Systemabhängigkeiten, Daten, Custom Code, Integrationen und Geschäftsprozesse transparent machen, desto besser können sie Aufwand und Projektrisiken steuern.
Wie finden Schweizer Unternehmen den richtigen SAP-Migrationspartner?
Eine SAP S/4HANA Migration betrifft weit mehr als die technische Umstellung des ERP-Systems. Der richtige Partner sollte deshalb nicht nur Conversion-Know-how mitbringen, sondern Business-Prozesse, Daten, Integration, Architektur und Change Management zusammenführen können.
Für Schweizer Unternehmen kommen zusätzlich lokale Anforderungen und häufig internationale Konzernstrukturen hinzu. Entsprechend sollte die Partnerauswahl auf messbaren Kriterien basieren.
1. Erfahrung mit unterschiedlichen Migrationsszenarien
Ein geeigneter Partner sollte nicht von vornherein eine bestimmte Methode verkaufen. Entscheidend ist, dass er Brownfield, Greenfield und Selective Data Transition bewerten und anhand der konkreten Ausgangslage empfehlen kann.
Die erste Frage im Auswahlprozess sollte deshalb nicht lauten:
„Welche Migration bieten Sie an?“
Sondern:
„Wie bestimmen Sie, welcher Migrationsansatz für unser Unternehmen geeignet ist?“
2. Technische und fachliche Kompetenz verbinden
Eine S/4HANA Migration betrifft Finance ebenso wie Supply Chain, Produktion, Einkauf, Logistik und Reporting. Gleichzeitig müssen Datenmodelle, Custom Code und Schnittstellen technisch angepasst werden.
Ein leistungsfähiger Partner sollte deshalb beide Perspektiven abdecken:
Business: Prozesse, Organisation, Governance und Change
IT: Architektur, Daten, Integration, Custom Code, Security und Betrieb
3. Datenmigration als eigenes Kompetenzfeld
Daten gehören zu den häufigsten kritischen Punkten einer ERP-Transformation. Der Partner sollte deshalb nachvollziehbar erklären können, wie Daten analysiert, bereinigt, transformiert, migriert und validiert werden.
Besonders wichtig sind dabei klare Verantwortlichkeiten zwischen IT und Fachbereichen. Denn die technische Migration eines Datensatzes bedeutet nicht automatisch, dass dieser fachlich korrekt oder vollständig ist.
4. Integration und Zielarchitektur berücksichtigen
S/4HANA ist Teil eines grösseren digitalen Ökosystems. Deshalb sollte ein Partner auch die angrenzenden Systeme und zukünftige Architektur berücksichtigen können.
Dazu gehören beispielsweise SAP BTP, Warehouse- und Transportlösungen, CRM, E-Commerce, Produktionssysteme, Analytics sowie externe Partner- und Banksysteme.
5. Schweizer Anforderungen verstehen
Für Schweizer Unternehmen sollte der Partner mit den relevanten lokalen Anforderungen und typischen Herausforderungen internationaler Schweizer Organisationen vertraut sein.
Dazu gehören insbesondere:
- Schweizer Finance- und Steuerprozesse
- lokale SAP-Funktionalitäten
- Datenschutz und Cloud-Fragen
- internationale Datenflüsse
- globale SAP-Templates
- mehrsprachige Organisationen
6. Unterstützung über den Go-live hinaus
Eine Migration ist kein Projekt, das mit dem ersten produktiven Buchungstag abgeschlossen ist. Nach dem Go-live müssen Prozesse stabilisiert, Benutzer unterstützt und die neue Plattform kontinuierlich weiterentwickelt werden.
Deshalb sollte bereits bei der Ausschreibung geklärt werden, welche Leistungen nach der Implementierung verfügbar sind – beispielsweise Hypercare, Application Management Services, Monitoring und kontinuierliche Optimierung.
Checkliste für die Partnerauswahl
| Kriterium | Was sollte geprüft werden? |
|---|---|
| Migrationserfahrung | Nachweisbare S/4HANA-Projekte und unterschiedliche Migrationsansätze |
| Branchenkenntnis | Erfahrung mit vergleichbaren Geschäftsprozessen |
| Datenkompetenz | Datenanalyse, Bereinigung, Migration und Validierung |
| Integration | Erfahrung mit SAP BTP und Drittanwendungen |
| Schweiz | Lokalisierung, Compliance und lokale Geschäftsanforderungen |
| Projektmethodik | Klare Governance, Meilensteine und Quality Gates |
| Change Management | Einbindung von Fachbereichen und Benutzerakzeptanz |
| Betrieb | Hypercare, AMS und langfristige Weiterentwicklung |
Ein guter Auswahlprozess sollte zudem bereits vor der Beauftragung Transparenz schaffen: Welche Annahmen liegen der Aufwandsschätzung zugrunde? Welche Risiken wurden identifiziert? Welche Leistungen sind enthalten? Und welche Abhängigkeiten liegen beim Kunden?
LeverX beschreibt für die Schweiz einen End-to-End-Ansatz von der Analyse und Migrationsplanung über Datenmigration und Implementierung bis zum langfristigen SAP-Betrieb. Das Portfolio umfasst dabei unter anderem Greenfield-, Brownfield- und selektive Transformationsszenarien.
Die wichtigste Erkenntnis: Der beste SAP-Migrationspartner ist nicht zwingend der Anbieter mit dem grössten Leistungsportfolio. Entscheidend ist, ob er die konkrete Ausgangslage versteht, Risiken früh sichtbar macht und eine realistische Verbindung zwischen Business-Zielen, SAP-Technologie und Schweizer Anforderungen herstellen kann.
S/4HANA Migration mit LeverX
Eine SAP S/4HANA Migration erfordert die Verbindung von Strategie, SAP-Know-how, Daten, Integration und Geschäftsprozessen. LeverX unterstützt Schweizer Unternehmen entlang dieses gesamten Transformationsprozesses – von der Analyse der bestehenden SAP-Landschaft über die Migration und Implementierung bis zum Betrieb und zur Weiterentwicklung.
Von der Ausgangslage zur passenden Migrationsstrategie
Der erste Schritt ist die Bewertung der bestehenden Umgebung. LeverX unterstützt Unternehmen dabei, ihre SAP-Landschaft zu analysieren, den Transformationsbedarf zu bestimmen und den geeigneten Migrationsansatz auszuwählen.
Dabei können unterschiedliche Szenarien berücksichtigt werden:
- Brownfield / System Conversion
- Greenfield / Neuimplementierung
- Selective Data Transition
- Konsolidierung mehrerer SAP-Landschaften
Welche Variante sinnvoll ist, hängt von Prozessen, Daten, Custom Code, Integrationen und den strategischen Zielen des Unternehmens ab.
Daten, Integration und Prozesse zusammenführen
Bei einer S/4HANA Transformation müssen nicht nur ERP-Funktionen migriert werden. Datenqualität, Schnittstellen und angrenzende Anwendungen sind häufig ebenso entscheidend.
LeverX verbindet seine S/4HANA-Kompetenz deshalb mit Leistungen in den Bereichen Datenmanagement, Integration und SAP BTP. Dadurch können auch komplexere SAP- und Non-SAP-Landschaften in die Zielarchitektur einbezogen werden.
Für Unternehmen mit umfangreichen Supply-Chain-Prozessen können beispielsweise Lösungen wie SAP EWM, SAP TM, SAP IBP oder SAP Digital Manufacturing Teil der zukünftigen Architektur sein.
Clean Core und moderne Erweiterungen
Eine Migration bietet die Möglichkeit, bestehende Eigenentwicklungen und technische Altlasten neu zu bewerten. Ziel sollte nicht sein, jede historische Anpassung unverändert in die neue Umgebung zu übertragen.
LeverX unterstützt Unternehmen bei der Modernisierung kundenspezifischer Entwicklungen und bei Erweiterungsszenarien mit SAP BTP, einschliesslich Clean-Core- und Side-by-Side-Ansätzen.
Unterstützung bis über den Go-live hinaus
Die Zusammenarbeit endet nicht zwingend mit der Produktivsetzung. LeverX bietet neben Beratung, Implementierung und Migration auch SAP Application Management Services (AMS) für Support, Wartung und kontinuierliche Optimierung an.
Damit kann die Unterstützung je nach Projektmodell von der ersten Analyse über die Migration bis zum laufenden SAP-Betrieb reichen.
SAP-Kompetenz mit internationaler Ausrichtung
LeverX positioniert sich als globaler Systemintegrator und SAP Gold Partner. Das Unternehmen gibt mehr als 20 Jahre SAP-Erfahrung, über 1.500 abgeschlossene Projekte und mehr als 500 zertifizierte SAP-Experten an.
Für Schweizer Unternehmen mit internationalen Gesellschaften kann diese internationale Ausrichtung insbesondere bei globalen Templates, länderübergreifenden Prozessen und komplexen SAP-Landschaften relevant sein. Kontaktieren Sie uns. Gemeinsam mit einem SAP-Experten können Sie Ihre Ausgangslage, Ihr Zielbild und die nächsten Schritte für Ihre S/4HANA-Transformation bewerten.