Was kostet eine SAP S/4HANA Migration in der Schweiz?

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 SAP S/4HANA Migration in der Schweiz lässt sich nicht seriös mit einer pauschalen Zahl beziffern. Das erforderliche Budget hängt unter anderem von der bestehenden SAP-Landschaft, der gewählten Migrationsstrategie, der Datenmenge und -qualität, dem Umfang von Custom Code und Schnittstellen sowie dem gewünschten Betriebsmodell ab.

Für die Budgetplanung ist deshalb entscheidend, welcher Transformationsumfang tatsächlich umgesetzt werden soll. Eine technische System Conversion kann einen deutlich anderen Aufwand verursachen als eine umfassende Neugestaltung von Geschäftsprozessen im Rahmen eines Greenfield-Ansatzes. Auch die Anzahl betroffener Gesellschaften, Länder und angebundener Systeme kann das Projektbudget wesentlich beeinflussen.

Grundsätzlich sollte ein SAP-Projektbudget nicht nur externe Beratung und technische Migration berücksichtigen. Auch Datenbereinigung, Integration, Testing, Change Management, Schulung, interne Ressourcen, Cutover und die Stabilisierung nach dem Go-live gehören in die Betrachtung.

 Die Frage «Was kostet eine SAP S/4HANA Migration in der Schweiz?» sollte deshalb nicht mit einer einzelnen CHF-Zahl beantwortet werden. Für ein belastbares SAP-Projektbudget müssen zunächst Systemlandschaft, Transformationsumfang und die wichtigsten Aufwandstreiber bewertet werden.

Im nächsten Schritt lohnt sich daher der Blick auf die Faktoren, die die SAP S/4HANA Migration Kosten am stärksten beeinflussen.

Welche Faktoren bestimmen die SAP S/4HANA Migration Kosten? 

Die SAP S/4HANA Migration Kosten werden weniger durch einen einzelnen technischen Arbeitsschritt bestimmt als durch die Komplexität der bestehenden Systemlandschaft und den Umfang der geplanten Transformation. Besonders relevant sind Daten, Eigenentwicklungen, Schnittstellen, Prozesse und die gewählte Migrationsstrategie.

Für eine erste Budgeteinschätzung sollten Unternehmen deshalb mindestens die folgenden Faktoren analysieren.

Bestehende SAP-Landschaft

Je komplexer die Ausgangslage, desto höher ist in der Regel der Analyse- und Migrationsaufwand. Relevant sind unter anderem die Anzahl der SAP-Systeme, Mandanten, Gesellschaften und Länder sowie die eingesetzten SAP-Module und Add-ons.

Auch historisch gewachsene Systemlandschaften können die Kosten erhöhen. Unterschiedliche Systemstände, individuelle Lösungen oder Abhängigkeiten zwischen Gesellschaften erschweren eine standardisierte Migration.

Für die Budgetplanung gilt: Zuerst muss klar sein, was tatsächlich migriert wird und welche Systeme künftig noch benötigt werden.

Migrationsstrategie

Ob ein Unternehmen auf Brownfield, Greenfield oder Selective Data Transition setzt, hat einen wesentlichen Einfluss auf Aufwand und Budget.

Bei einem Brownfield-Ansatz wird das bestehende SAP-System weitgehend weiterentwickelt und auf S/4HANA überführt. Ein Greenfield-Ansatz beginnt stärker mit einem neuen Zielsystem und einer Neugestaltung der Prozesse. Selective Data Transition liegt dazwischen und ermöglicht eine gezielte Übernahme von Daten und Strukturen.

Die günstigste Variante lässt sich daraus jedoch nicht pauschal ableiten. Ein technisch schlanker Migrationsweg kann beispielsweise durch umfangreichen Custom Code oder komplexe Datenbereinigung aufwendig werden. Umgekehrt kann ein höherer initialer Transformationsaufwand langfristig Vorteile für Standardisierung und Betrieb bringen.

Custom Code und Eigenentwicklungen

Viele SAP-Systeme enthalten über Jahre gewachsene Eigenentwicklungen. Diese müssen vor der Migration analysiert werden: Welche Anwendungen werden weiterhin benötigt? Welche können durch SAP-Standard ersetzt werden? Welche müssen angepasst oder neu entwickelt werden?

Die Kosten hängen daher nicht nur von der Anzahl der Eigenentwicklungen ab, sondern vor allem von ihrer technischen und fachlichen Relevanz.

Ein hoher Anteil an Custom Code kann beispielsweise zusätzlichen Aufwand für Analyse, Anpassung, Tests und Dokumentation verursachen. Deshalb sollte die Bereinigung und Bewertung von Eigenentwicklungen möglichst früh im Projekt erfolgen.

Datenmigration und Datenqualität

Die Übernahme von Daten ist ein weiterer wesentlicher Kostentreiber. Entscheidend ist nicht nur das Datenvolumen, sondern insbesondere die Qualität und Struktur der vorhandenen Daten.

Typische Aufgaben sind:

• Bereinigung und Konsolidierung von Stammdaten
• Definition von Mapping-Regeln
• Prüfung historischer Daten
• Vorbereitung von Migrationsobjekten
• Testmigrationen
• Validierung und Abstimmung der übernommenen Daten

Je stärker Daten über Jahre gewachsen oder auf mehrere Systeme verteilt sind, desto höher kann der Aufwand ausfallen. Datenbereinigung sollte deshalb nicht als rein technischer Schritt betrachtet werden, sondern als eigener Bestandteil des Transformationsbudgets.

Schnittstellen und Integrationen

Eine SAP-Migration betrifft häufig nicht nur das ERP-System selbst. CRM-, Produktions-, Logistik-, Banking-, Reporting- oder Drittanbietersysteme können über zahlreiche Schnittstellen angebunden sein.

Jede Integration muss auf ihre technische Funktionsfähigkeit und fachliche Bedeutung geprüft werden. Änderungen am Datenmodell oder an Prozessen können Anpassungen auf beiden Seiten einer Schnittstelle erforderlich machen.

Für das Budget sind daher insbesondere Anzahl, Kritikalität und Komplexität der Integrationen relevant. Eine detaillierte System- und Schnittstellenübersicht ist eine wichtige Grundlage für eine belastbare Kostenschätzung.

Prozessharmonisierung

Eine S/4HANA-Migration kann rein technisch durchgeführt werden oder mit einer umfassenden Optimierung der Geschäftsprozesse verbunden sein. Je mehr Prozesse vereinheitlicht, standardisiert oder neu gestaltet werden, desto grösser wird der Transformationsumfang.

Besonders relevant ist dies bei Unternehmen mit mehreren Gesellschaften oder internationalen SAP-Templates. Lokale Prozesse können sich vom globalen Standard unterscheiden und zusätzlichen Abstimmungs- und Umsetzungsaufwand verursachen.

Damit wird die Frage «Migration oder Transformation?» zu einem zentralen Budgetthema: Je stärker Prozesse verändert werden, desto weniger lässt sich das Projekt als reine technische Migration planen.

Testing, Cutover und Hypercare

Auch die Produktivsetzung selbst verursacht Aufwand. Vor dem Go-live müssen Geschäftsprozesse, Integrationen und Daten ausreichend getestet werden. Je nach Projekt können mehrere Testzyklen erforderlich sein.

Zum Budget gehören deshalb unter anderem:

• Testplanung und Testdurchführung
• Integrations- und Regressionstests
• User Acceptance Tests
• Fehlerbehebung und Nachtests
• Cutover-Planung und Produktivsetzung
• Unterstützung während des Go-live
• Hypercare und Stabilisierung

Insbesondere bei geschäftskritischen SAP-Systemen sollte der Aufwand für die Produktivsetzung nicht unterschätzt werden. Ein sorgfältig geplanter Cutover reduziert nicht nur operative Risiken, sondern schafft auch eine realistischere Grundlage für die Budgetplanung.

Interne Ressourcen und Change Management

Nicht alle SAP-Projektkosten entstehen beim externen Implementierungspartner. Fachbereiche, IT, Key User und Projektleitung müssen während der gesamten Transformation Zeit bereitstellen.

Dazu kommen Kommunikation, Schulungen und organisatorische Veränderungen. Diese Aufwände werden in frühen Budgetschätzungen häufig nicht vollständig berücksichtigt, obwohl sie für den Projekterfolg relevant sind.

Für ein vollständiges SAP-Projektbudget sollten Unternehmen deshalb zwischen externen Projektkosten und internen Aufwänden unterscheiden. Erst zusammen ergeben beide Perspektiven ein realistisches Bild der gesamten Transformationskosten.

Die wichtigsten Kostentreiber einer S/4HANA-Migration sind nicht allein Systemgrösse oder Datenvolumen. Entscheidend ist das Zusammenspiel aus Ausgangslage, Migrationsstrategie, Custom Code, Daten, Integrationen, Prozessen, Testing und verfügbaren Ressourcen. Diese Faktoren bilden die Grundlage für die nächste Frage: Welcher Migrationsansatz passt zur Ausgangslage – und wie wirkt sich die Wahl auf das Budget aus?

Brownfield, Greenfield oder Selective Data Transition – was beeinflusst das Budget?

Die Wahl der Migrationsstrategie gehört zu den wichtigsten Entscheidungen für das SAP-Projektbudget. Brownfield, Greenfield und Selective Data Transition verfolgen unterschiedliche Ziele und führen deshalb zu unterschiedlichen Aufwandsprofilen.

Eine pauschale Aussage wie «Greenfield ist teurer» oder «Brownfield ist günstiger» greift zu kurz. Entscheidend sind die Ausgangslage, der gewünschte Transformationsgrad und die Frage, wie viel der bestehenden Prozesse, Daten und Entwicklungen übernommen werden soll.

Brownfield: Bestehende Strukturen weiterentwickeln

Beim Brownfield-Ansatz steht die Weiterentwicklung der bestehenden SAP-Landschaft im Vordergrund. Bestehende Prozesse und Datenstrukturen können weitgehend erhalten bleiben, müssen jedoch auf ihre Eignung für S/4HANA geprüft und gegebenenfalls angepasst werden.

Das kann den Transformationsaufwand reduzieren, wenn die bestehende Lösung bereits gut standardisiert und dokumentiert ist. Gleichzeitig können Altlasten übernommen werden. Dazu gehören beispielsweise unnötige Eigenentwicklungen, komplexe Schnittstellen oder historisch gewachsene Prozesse.

Budgetrelevant sind deshalb vor allem:

• Umfang und Qualität des bestehenden Custom Code
• eingesetzte Add-ons
• technische und funktionale Anpassungen
• Datenmigration
• Schnittstellen
• Testaufwand

Brownfield kann insbesondere dann sinnvoll sein, wenn die bestehende SAP-Lösung fachlich weiterhin tragfähig ist und die Transformation mit begrenzten Prozessveränderungen erfolgen soll.

Greenfield: Prozesse neu gestalten

Beim Greenfield-Ansatz wird ein neues S/4HANA-Zielsystem aufgebaut. Im Mittelpunkt steht nicht die möglichst vollständige Übernahme der bestehenden Lösung, sondern die Gestaltung einer standardisierten und zukunftsfähigen System- und Prozesslandschaft.

Dadurch entsteht typischerweise mehr Aufwand für Prozessdesign, Konfiguration, Datenübernahme, Integration, Tests und Change Management. Gleichzeitig bietet der Ansatz die Möglichkeit, bestehende Komplexität bewusst zu reduzieren.

Für das Budget ist daher nicht nur der initiale Implementierungsaufwand relevant. Unternehmen sollten auch berücksichtigen, welche langfristigen Vorteile durch Standardisierung, reduzierte Eigenentwicklungen und eine vereinfachte Systemlandschaft entstehen können.

Greenfield kann insbesondere dann interessant sein, wenn die bestehende SAP-Landschaft stark individualisiert ist oder Geschäftsprozesse grundlegend harmonisiert werden sollen.

Selective Data Transition: gezielt transformieren

Selective Data Transition verbindet Elemente beider Ansätze. Unternehmen können ausgewählte Daten, Strukturen oder Geschäftsbereiche übernehmen und gleichzeitig Teile der Systemlandschaft neu gestalten.

Dieser Ansatz kann bei komplexen Unternehmensstrukturen sinnvoll sein, beispielsweise wenn bestimmte Gesellschaften, Datenbestände oder Prozesse unterschiedlich behandelt werden sollen.

Der zusätzliche Gestaltungsspielraum erhöht jedoch die Anforderungen an Planung und Datenmigration. Für das Budget sind insbesondere Datenumfang, Selektionslogik, Mapping, Systemdesign und Testaufwand relevant.

Welche Strategie ist für das Budget die richtige?

Die Entscheidung sollte nicht primär anhand des erwarteten Projektpreises getroffen werden. Sinnvoller ist eine Betrachtung des Gesamtaufwands und des langfristigen Zielbilds.

Eine vereinfachte Entscheidungslogik:

• Brownfield, wenn bestehende Prozesse weitgehend beibehalten werden sollen und die Ausgangslösung technisch sowie fachlich eine gute Basis bildet.
• Greenfield, wenn Prozesse grundlegend neu gestaltet und Altlasten möglichst vermieden werden sollen.
• Selective Data Transition, wenn eine gezielte Kombination aus Übernahme und Neugestaltung erforderlich ist.

Für die Budgetplanung sollte deshalb zunächst geklärt werden, welche Veränderungen tatsächlich notwendig sind. Erst danach lässt sich der erforderliche Aufwand für Migration, Implementierung, Daten, Integration, Testing und Change Management belastbar bewerten.

Die günstigste Migrationsstrategie ist nicht automatisch diejenige mit den niedrigsten initialen Projektkosten. Für eine fundierte Entscheidung sollten Unternehmen zusätzlich den späteren Betriebsaufwand, die Wartbarkeit der Lösung, den verbleibenden Custom Code und den erwarteten Nutzen der Transformation betrachten.

Damit wird aus der reinen Kostenfrage eine Business-Case-Frage: Welcher Ansatz ermöglicht das gewünschte Zielbild mit einem vertretbaren Transformationsaufwand und einem nachhaltigen Betriebsmodell?

SAP-Projektbudget richtig planen

Ein belastbares SAP-Projektbudget sollte alle relevanten Aufwände entlang des gesamten Transformationszyklus abbilden. Entscheidend ist dabei, nicht nur die eigentliche Migration zu kalkulieren. Analyse, Daten, Integrationen, Tests, Schulungen und die Produktivsetzung können einen wesentlichen Teil des Gesamtaufwands ausmachen.

Für die erste Budgetplanung hat sich eine Aufteilung in acht Kostenblöcke bewährt:

Externe und interne Kosten getrennt betrachten

Ein häufiger Fehler bei der Budgetplanung ist die ausschliessliche Betrachtung des externen Projektbudgets. Ein SAP-Projekt bindet jedoch auch interne Mitarbeitende aus IT und Fachbereichen.

Dazu gehören beispielsweise:

• Projektleitung und interne IT-Ressourcen
• Fachbereichsexperten und Key User
• Mitarbeit bei Datenbereinigung und Validierung
• Durchführung und Bewertung von Tests
• Schulungen und Change-Aktivitäten
• Vorbereitung und Durchführung des Cutovers

Diese Aufwände sollten separat ausgewiesen werden. Dadurch wird sichtbar, wie hoch die tatsächlichen SAP-Transformationskosten für das Unternehmen sind und welche internen Kapazitäten während des Projekts benötigt werden.

Nicht nur das Projektbudget, sondern auch das Betriebsmodell planen

Neben den einmaligen Transformationskosten sollten Unternehmen die Auswirkungen auf die späteren laufenden Kosten betrachten. Dazu gehören je nach Zielarchitektur beispielsweise Software- oder Subscription-Kosten, Infrastruktur, Betrieb, Support, Weiterentwicklung und Integrationen.

Gerade beim Vergleich von SAP S/4HANA Cloud und On-Premise sollte deshalb nicht nur der initiale Projektaufwand betrachtet werden. Relevant ist die gesamte Kostenstruktur über den geplanten Betrachtungszeitraum.

Risikoreserve nachvollziehbar begründen

Bei einer frühen Kostenschätzung sind nicht alle Aufwände bekannt. Deshalb sollte das Budget einen angemessenen Puffer für identifizierte Projektrisiken enthalten.

Dieser sollte jedoch nicht als pauschaler Prozentsatz festgelegt werden, ohne die zugrunde liegenden Risiken zu analysieren. Sinnvoller ist eine risikobasierte Betrachtung: Welche Unsicherheiten bestehen bei Daten, Custom Code, Schnittstellen, Scope, internen Ressourcen oder Testing – und welche finanziellen Auswirkungen könnten daraus entstehen?

So wird aus einer groben Budgetzahl ein nachvollziehbares Transformationsbudget mit klar dokumentierten Annahmen.

Von der Kostenschätzung zum Business Case

Ein SAP-Projektbudget beantwortet zunächst die Frage, was die Transformation voraussichtlich kostet. Für eine Investitionsentscheidung reicht das allein nicht aus.

Zusätzlich sollten Unternehmen betrachten:

• Welche Prozesse werden verbessert oder standardisiert?
• Welche bestehenden Systeme und Eigenentwicklungen können entfallen?
• Welche Betriebs- und Wartungsaufwände verändern sich?
• Welche strategischen Anforderungen werden mit S/4HANA unterstützt?
• Welche Risiken entstehen, wenn die bestehende SAP-Landschaft unverändert bleibt?

Damit lassen sich Kosten, Nutzen und Risiken gemeinsam bewerten. Das schafft eine wesentlich bessere Entscheidungsgrundlage als ein isolierter Vergleich einzelner Anbieterangebote.

 Erstellen Sie zunächst ein Budgetmodell auf Basis der acht Kostenblöcke und dokumentieren Sie für jeden Block die zugrunde liegenden Annahmen. Sobald Systemlandschaft, Scope und Migrationsstrategie konkreter werden, können diese Werte schrittweise durch belastbarere Aufwandsschätzungen ersetzt werden.

Welche SAP-Kosten werden häufig unterschätzt?

Bei einer SAP S/4HANA Migration werden die offensichtlichen Kosten meist früh berücksichtigt: Implementierung, technische Migration und externe Beratung. Schwieriger sind Aufwände, die erst im Projektverlauf sichtbar werden oder deren Umfang zu Beginn nur unvollständig bekannt ist.

Besonders häufig unterschätzt werden folgende Bereiche:

Datenbereinigung

Nicht jede vorhandene Datenmenge sollte automatisch in das neue System übernommen werden. Veraltete, doppelte oder inkonsistente Daten müssen identifiziert, bereinigt und fachlich validiert werden.

Der Aufwand entsteht daher nicht nur durch die technische Datenübertragung. Auch die Fachbereiche müssen entscheiden, welche Daten relevant sind und welche Qualitätsanforderungen gelten.

Analyse und Bereinigung von Custom Code

Eine grosse Anzahl von Eigenentwicklungen bedeutet nicht automatisch hohe Kosten. Entscheidend ist, wie viele davon tatsächlich geschäftskritisch sind und wie stark sie an bestehende SAP-Funktionen gebunden sind.

Aufwand kann entstehen für die Analyse, Priorisierung, Anpassung, Tests oder Ablösung von Eigenentwicklungen. Frühzeitige Transparenz über den Custom Code reduziert deshalb das Risiko späterer Budgetabweichungen.

Schnittstellen und Drittanwendungen

Schnittstellen werden in frühen Planungen teilweise nur als technische Einzelposition betrachtet. Tatsächlich können Änderungen an einer SAP-Lösung Auswirkungen auf zahlreiche angebundene Systeme haben.

Neben der Anpassung selbst entstehen gegebenenfalls zusätzliche Aufwände für Abstimmung, End-to-End-Tests und Fehlerbehebung. Besonders kritisch sind Integrationen, deren technische oder fachliche Abhängigkeiten nicht vollständig dokumentiert sind.

Zusätzliche Testzyklen

Ein einzelner geplanter Testzyklus reicht in komplexen SAP-Projekten nicht zwingend aus. Fehler in Daten, Prozessen oder Integrationen können weitere Tests und Nachtests erforderlich machen.

Das Budget sollte deshalb nicht nur die Durchführung von Tests, sondern auch mögliche Korrektur- und Wiederholungsschleifen berücksichtigen.

Interne Ressourcen

Die Arbeitszeit interner Mitarbeitender erscheint häufig nicht in einem externen Implementierungsangebot. Für das Unternehmen stellt sie dennoch einen realen Ressourcenbedarf dar.

Wenn Fachbereiche und IT ihre Projektaufgaben nicht mit der erforderlichen Kapazität abdecken können, kann dies zu Verzögerungen, zusätzlichem externem Aufwand oder einer Ausweitung des Projektumfangs führen.

Change Management und Schulung

Eine technische Migration führt nicht automatisch zu einer erfolgreichen Einführung. Verändern sich Benutzeroberflächen, Rollen oder Geschäftsprozesse, müssen Mitarbeitende entsprechend vorbereitet werden.

Kommunikation, Schulungen, Dokumentation und Unterstützung der Key User sollten deshalb von Anfang an Bestandteil des Projektbudgets sein.

Cutover und Hypercare

Die Produktivsetzung erfordert häufig mehr Aufwand als nur einen definierten Go-live-Termin. Daten müssen final migriert, Schnittstellen geprüft, Verantwortlichkeiten geklärt und Abläufe koordiniert werden.

Auch die Phase unmittelbar nach dem Go-live sollte eingeplant werden. Während der Hypercare-Phase können zusätzliche Unterstützung, Fehleranalyse und Stabilisierung notwendig sein.

Parallelbetrieb und Ablösung von Altsystemen

Je nach Projekt können für eine Übergangszeit zusätzliche Betriebs- oder Lizenzkosten entstehen. Auch die spätere Stilllegung alter Systeme ist nicht automatisch kostenfrei.

Dazu können beispielsweise Datenarchivierung, technische Deaktivierung, Anpassungen an abhängigen Systemen oder die Sicherstellung gesetzlicher und geschäftlicher Anforderungen gehören.

Reporting und Analytics

Auch Berichte und Auswertungen sollten bei der Budgetplanung berücksichtigt werden. Bestehende Reports können von Datenmodellen, Prozessen oder technischen Änderungen betroffen sein und müssen gegebenenfalls angepasst oder neu aufgebaut werden.

Ein belastbares SAP-Budget sollte nicht nur die «Migration» als technische Leistung kalkulieren. Datenqualität, Custom Code, Integrationen, Tests, interne Ressourcen, Change Management, Cutover, Parallelbetrieb und Reporting können den tatsächlichen Aufwand wesentlich beeinflussen.

Je früher diese Positionen transparent gemacht werden, desto geringer ist das Risiko, dass das SAP-Projektbudget im späteren Projektverlauf durch ungeplante Zusatzaufwände erweitert werden muss.

SAP S/4HANA Cloud oder On-Premise – wie unterscheiden sich die Kosten?

Die Wahl zwischen SAP S/4HANA Cloud und On-Premise beeinflusst nicht nur die technische Architektur, sondern auch die Kostenstruktur eines SAP-Projekts. Ein Cloud-Modell ist dabei nicht automatisch günstiger. Entscheidend ist, wie sich einmalige Transformationskosten, laufende Betriebskosten und der benötigte interne IT-Aufwand über den gesamten Lebenszyklus verteilen.

Cloud: Andere Kostenstruktur statt automatisch niedrigere Kosten

Bei einer Cloud-Lösung verschiebt sich ein Teil der Kosten von klassischen Infrastruktur- und Betriebsaufwänden hin zu laufenden Nutzungs- oder Subscription-Kosten. Gleichzeitig können Anforderungen an Integration, Datenmigration, Security, Berechtigungen und Prozessanpassungen weiterhin einen erheblichen Projektaufwand verursachen.

Für die Budgetplanung sollte deshalb zwischen einmaligen Migrations- und Implementierungskosten und laufenden Betriebskosten unterschieden werden.

On-Premise: Mehr Kontrolle, aber eigener Betriebsaufwand

Bei On-Premise-Systemen trägt das Unternehmen einen grösseren Teil der Verantwortung für Infrastruktur und technischen Betrieb. Je nach Ausgangslage können dadurch zusätzliche Aufwände für Hardware, Hosting, Systemadministration, Betrieb, Upgrades und technische Wartung entstehen.

Gleichzeitig kann On-Premise für Unternehmen mit spezifischen Anforderungen an Architektur, Integration oder individuelle Systemkontrolle sinnvoll sein.

TCO statt nur Projektkosten vergleichen

Für eine fundierte Entscheidung empfiehlt sich eine Total-Cost-of-Ownership-Betrachtung (TCO). Dabei werden nicht nur die Kosten der Migration berücksichtigt, sondern auch die erwarteten laufenden Kosten des gewählten Betriebsmodells.

Eine solche Betrachtung sollte unter anderem folgende Positionen umfassen:

• Software- und Subscription-Kosten
• Infrastruktur und Hosting
• Implementierung und Migration
• Integration und Schnittstellen
• Betrieb und Support
• interne IT-Ressourcen
• Upgrades und Weiterentwicklung
• Security und Compliance
• Datenmanagement

Cloud und On-Premise unterscheiden sich vor allem darin, wo Kosten entstehen und wer bestimmte Betriebsleistungen übernimmt. Für eine seriöse Bewertung sollten Unternehmen deshalb nicht nur den initialen Projektpreis vergleichen, sondern die erwarteten Gesamtkosten und das gewünschte Betriebsmodell über den relevanten Betrachtungszeitraum analysieren. 

Was ist bei einer SAP-Migration in der Schweiz besonders zu beachten?

Eine SAP S/4HANA Migration in der Schweiz folgt grundsätzlich denselben technischen Prinzipien wie andere S/4HANA-Transformationen. Gleichzeitig können lokale gesetzliche, organisatorische und steuerliche Anforderungen zusätzlichen Aufwand verursachen.

Besonders relevant sind vier Bereiche: Schweizer Lokalisierung, internationale Systemlandschaften, lokale Prozessanforderungen und Datenschutz.

Schweizer SAP-Lokalisierung

Schweizer Gesellschaften benötigen Funktionen und Prozesse, die auf lokale gesetzliche und geschäftliche Anforderungen abgestimmt sind. Dazu können beispielsweise steuerliche Anforderungen, Finanzprozesse und landesspezifische Auswertungen gehören.

Bei einer Migration sollte deshalb früh geprüft werden, welche lokalen Funktionen heute genutzt werden und wie diese im künftigen S/4HANA-System abgebildet werden.

Budgetrelevant ist dabei nicht nur die technische Umsetzung. Auch fachliche Abstimmungen, Tests und die Validierung der relevanten Prozesse müssen berücksichtigt werden.

Globale SAP-Templates und lokale Abweichungen

Viele Schweizer Unternehmen sind Teil internationaler SAP-Landschaften. Ein globales Template definiert dabei zentrale Prozesse und Strukturen, während einzelne Länder oder Gesellschaften lokale Anforderungen berücksichtigen.

Für die Schweizer Gesellschaft entsteht zusätzlicher Aufwand, wenn bestehende lokale Prozesse vom globalen Standard abweichen.

Vor der Migration sollte deshalb geklärt werden:

• Welche Prozesse werden global standardisiert?
• Welche Schweizer Besonderheiten müssen erhalten bleiben?
• Welche lokalen Eigenentwicklungen können entfallen?
• Welche Schnittstellen sind für Schweizer Gesellschaften relevant?
• Welche Anforderungen müssen im Rahmen des globalen Templates neu abgestimmt werden?

Je mehr lokale Abweichungen bestehen, desto wichtiger ist eine klare Abgrenzung zwischen globalem Template und Schweizer Anforderungen.

Mehrere Sprachen und Gesellschaften

Internationale Organisationen müssen zusätzlich die Anzahl der betroffenen Gesellschaften, Standorte und Benutzergruppen berücksichtigen. Unterschiedliche Organisationsstrukturen und Sprachen können zusätzlichen Abstimmungs-, Test- und Schulungsaufwand verursachen.

Das bedeutet nicht, dass jede mehrsprachige oder internationale SAP-Landschaft automatisch teurer ist. Entscheidend ist, wie stark sich Prozesse, Daten, Rollen und Anforderungen zwischen den Einheiten unterscheiden.

Datenschutz und Cloud

Bei Cloud- und hybriden SAP-Landschaften sollte auch der Umgang mit personenbezogenen Daten frühzeitig geprüft werden. Relevant sind insbesondere Datenflüsse, Auftragsbearbeitung, Dienstleister und gegebenenfalls grenzüberschreitende Datenübermittlungen.

Für Schweizer Unternehmen bedeutet dies nicht automatisch, dass sämtliche Daten in der Schweiz gespeichert werden müssen. Entscheidend ist vielmehr, wo Daten verarbeitet werden, welche Parteien beteiligt sind und welche rechtlichen und vertraglichen Anforderungen für die jeweilige Datenverarbeitung gelten.

Datenschutz und Security sollten deshalb bereits bei der Zielarchitektur und nicht erst kurz vor dem Go-live betrachtet werden.

Schweizer Anforderungen früh in die Budgetplanung integrieren

Lokale Anforderungen sollten Bestandteil des ursprünglichen Projektumfangs sein. Werden sie erst während der Implementierung identifiziert, können zusätzliche Analyse-, Entwicklungs- und Testaufwände entstehen.

Für die Budgetplanung empfiehlt sich daher eine frühe Prüfung von:

1. Schweizer Lokalisierung und gesetzlichen Anforderungen
2. globalen Templates und lokalen Abweichungen
3. Gesellschaften, Organisationseinheiten und Benutzergruppen
4. lokalen Schnittstellen und Drittanwendungen
5. Datenflüssen sowie Datenschutz- und Security-Anforderungen

Die besonderen Herausforderungen einer SAP-Migration in der Schweiz liegen nicht allein in der Technologie. Lokalisierung, globale Templates, lokale Prozessvarianten und Datenanforderungen können den Projektumfang beeinflussen und sollten deshalb bereits in der frühen Budget- und Architekturplanung berücksichtigt werden.

Wie läuft eine SAP-Implementierung in der Schweiz ab?

Eine SAP-Implementierung in der Schweiz ist kein einzelner technischer Migrationsschritt, sondern ein mehrstufiges Transformationsprojekt. Der genaue Ablauf hängt von Ausgangslage, Scope, Migrationsstrategie und Zielarchitektur ab.

Für die Budgetplanung ist es hilfreich, die einzelnen Phasen und ihre typischen Aufwände zu kennen.

1. Assessment und Ausgangsanalyse

Zu Beginn wird die bestehende SAP-Landschaft analysiert. Dabei werden unter anderem Systeme, Prozesse, Custom Code, Daten und Schnittstellen betrachtet.

Typische Ergebnisse:

• Bewertung der Ausgangslage
• Identifikation von Abhängigkeiten und Risiken
• erste Einschätzung des Migrationsaufwands
• mögliche Migrationsstrategien
• erste Budget- und Ressourcenplanung

Diese Phase schafft die Grundlage für die weiteren Entscheidungen.

2. Strategie, Scope und Business Case

Auf Basis der Analyse wird festgelegt, welches Zielbild erreicht werden soll. Dazu gehören die Wahl der Migrationsstrategie, der gewünschte Funktionsumfang und das künftige Betriebsmodell.

Gleichzeitig sollte der Business Case konkretisiert werden. Neben den erwarteten Projektkosten sollten auch betriebliche Auswirkungen, Risiken und der erwartete Nutzen betrachtet werden.

3. Solution Design und Prozessgestaltung

Anschliessend wird definiert, wie Geschäftsprozesse und technische Architektur im S/4HANA-Zielsystem aussehen sollen.

Je nach Transformationsansatz reicht dies von der weitgehenden Übernahme bestehender Prozesse bis zur umfassenden Neugestaltung.

Besonders wichtig ist die klare Entscheidung, welche Anforderungen mit SAP-Standard abgedeckt werden und wo individuelle Erweiterungen tatsächlich notwendig sind.

4. Konfiguration und Entwicklung

In dieser Phase wird die geplante Lösung umgesetzt. Dazu gehören Konfiguration, erforderliche Entwicklungen, Anpassungen von Erweiterungen sowie die Einrichtung und Anpassung von Integrationen.

Parallel werden bestehende Eigenentwicklungen und Schnittstellen entsprechend der zuvor definierten Strategie behandelt.

5. Datenmigration und Integration

Die relevanten Daten werden bereinigt, vorbereitet, migriert und validiert. Gleichzeitig werden Schnittstellen und angebundene Systeme integriert und getestet.

Testmigrationen sind dabei besonders wertvoll: Sie zeigen früh, ob Datenqualität, Mapping und technische Prozesse wie geplant funktionieren.

6. Testing

Vor dem Go-live wird die Lösung schrittweise getestet. Dazu können unter anderem Integrations-, Regressionstests und User Acceptance Tests gehören.

Nicht nur einzelne Funktionen sollten geprüft werden. Entscheidend ist, ob die End-to-End-Geschäftsprozesse inklusive Daten und angebundener Systeme funktionieren.

7. Change Management und Schulung

Parallel zur technischen Umsetzung werden Benutzer und Fachbereiche auf die neue Lösung vorbereitet.

Dazu gehören beispielsweise:

• Kommunikation der Veränderungen
• Schulung von Key Usern und Endanwendern
• Anpassung von Arbeitsanweisungen
• Unterstützung bei neuen Prozessen und Rollen

Der Aufwand hängt stark davon ab, wie umfassend sich Arbeitsweisen und Verantwortlichkeiten verändern.

8. Cutover und Go-live

Vor der Produktivsetzung wird der Cutover detailliert geplant. Dabei werden unter anderem finale Datenmigration, technische Aktivitäten, Schnittstellen, Verantwortlichkeiten und Kommunikationswege koordiniert.

Nach erfolgreicher Vorbereitung erfolgt der Go-live.

9. Hypercare und Stabilisierung

Nach dem Go-live beginnt die Stabilisierungsphase. In der Hypercare-Phase werden auftretende Probleme priorisiert, analysiert und behoben.

Erst wenn Prozesse, Integrationen und Benutzerabläufe stabil funktionieren, kann das Projekt schrittweise in den regulären Betrieb übergehen.

Der Ablauf bestimmt auch die Kostenstruktur

Die Phasen sind nicht vollständig unabhängig voneinander. Entscheidungen in einer frühen Phase können den Aufwand späterer Phasen wesentlich beeinflussen.

Beispielsweise kann eine Entscheidung für umfassende Prozessharmonisierung zusätzlichen Aufwand in Solution Design, Konfiguration, Datenmigration, Testing und Change Management verursachen.

Deshalb sollte das SAP-Projektbudget nicht nur nach externen Leistungen, sondern entlang des gesamten Projektverlaufs geplant werden:

Assessment → Strategie → Design → Umsetzung → Migration → Testing → Change → Go-live → Hypercare

Je früher kritische Entscheidungen zu Scope, Migrationsstrategie, Daten, Custom Code und Zielarchitektur getroffen werden, desto besser lässt sich der spätere Projektaufwand kalkulieren und steuern.

SAP S/4HANA Migration mit einem belastbaren Budget planen

Die Kosten einer SAP S/4HANA Migration in der Schweiz lassen sich nicht auf einen pauschalen Betrag reduzieren. Entscheidend sind die Ausgangslage, der Transformationsumfang, die Migrationsstrategie sowie die Komplexität von Daten, Custom Code, Integrationen und Geschäftsprozessen. Hinzu kommen Testing, Change Management, interne Ressourcen und der Aufwand für Cutover und Stabilisierung.

Für Unternehmen bedeutet das: Ein belastbares SAP-Projektbudget entsteht nicht durch eine frühe Pauschalschätzung, sondern durch eine strukturierte Bewertung der bestehenden SAP-Landschaft und der geplanten Zielarchitektur. Je früher relevante Aufwandstreiber und Risiken sichtbar werden, desto besser lassen sich Budget, Zeitplan und Ressourcen planen.

LeverX unterstützt Unternehmen dabei, genau diese Transparenz zu schaffen. Von der Analyse der bestehenden SAP-Landschaft und der Bewertung von Custom Code und Daten bis zur Auswahl der passenden Migrationsstrategie und der Planung der Umsetzung begleitet LeverX SAP-Transformationen ganzheitlich. Dabei stehen nicht nur die technische Migration, sondern auch Geschäftsprozesse, Integrationen, Datenqualität und das zukünftige Betriebsmodell im Fokus.

So entsteht eine fundierte Entscheidungsgrundlage für die nächsten Schritte – mit einem SAP-Migrationsbudget, das auf der tatsächlichen Komplexität Ihres Unternehmens basiert.