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.
Mehrere SAP-Dienstleister können auf den ersten Blick ähnliche Leistungen anbieten. Bei genauerem Hinsehen unterscheiden sich jedoch Leistungsumfang, Projekterfahrung, eingesetzte Methoden, Teamzusammensetzung, Verantwortlichkeiten und Kosten deutlich. Für Schweizer Unternehmen wird die Auswahl dadurch schnell komplex – insbesondere bei einer SAP S/4HANA-Transformation, einer Migration in die Cloud oder einem internationalen SAP-Rollout.
Wer SAP-Dienstleister in der Schweiz vergleicht, sollte nicht allein auf Preis, Unternehmensgrösse oder SAP-Partnerstatus achten. Entscheidend sind die Passung zum konkreten Projekt, relevante SAP- und Branchenkompetenz, vergleichbare Projekterfahrung, das tatsächlich eingesetzte Projektteam, Integrations- und Datenkompetenz sowie ein klar definierter Leistungs- und Supportumfang.
Dieser Leitfaden zeigt 12 Kriterien, mit denen sich SAP-Beratungsunternehmen systematisch vergleichen lassen. Zusätzlich geht es darum, wie Unternehmen SAP-Angebote auf Scope, Aufwand, Annahmen und Risiken prüfen und welche Fragen vor dem Projektstart an den Anbieter gestellt werden sollten.
Das Ziel ist keine Rangliste von SAP-Partnern. Vielmehr soll eine belastbare Entscheidungsgrundlage entstehen, mit der sich unterschiedliche Anbieter und Angebote auf einer vergleichbaren Basis bewerten lassen.
SAP-Dienstleister vergleichen: Was sollte ein Unternehmen prüfen?
Wer SAP-Dienstleister in der Schweiz vergleichen möchte, sollte zuerst die Anforderungen des eigenen Projekts definieren und danach Anbieter anhand derselben Kriterien prüfen. So lassen sich Unterschiede bei Kompetenz, Projektteam, Leistungsumfang, Kosten und Support sichtbar machen.
Der Begriff „SAP-Dienstleister“ umfasst unterschiedliche Anbieter. Dazu gehören etwa SAP-Beratungsunternehmen, Implementierungspartner, Systemintegratoren und Managed-Service-Anbieter. SAP selbst unterscheidet unter anderem zwischen Consulting-&-Implementation-Partnern und Managed-Services-Partnern.
Für die Auswahl ist deshalb zunächst wichtig, welche Rolle der Dienstleister im eigenen SAP-Projekt übernehmen soll. Ein Unternehmen, das eine S/4HANA-Migration plant, benötigt beispielsweise andere Kompetenzen als ein Unternehmen, das primär SAP Application Management oder die Integration bestehender Systeme sucht.
Die 12 wichtigsten Vergleichskriterien auf einen Blick
| Nr. | Kriterium | Zentrale Frage |
|---|---|---|
| 1 | SAP- und Technologiekompetenz | Deckt der Anbieter die für das Projekt benötigten SAP-Technologien ab? |
| 2 | Branchen- und Prozesskompetenz | Versteht der Dienstleister die relevanten Geschäftsprozesse? |
| 3 | Vergleichbare Projekterfahrung | Gibt es nachweisbare Erfahrung mit ähnlichen Projekten? |
| 4 | Migration und Transformation | Passt der vorgeschlagene Ansatz zur Ausgangslage und Zielarchitektur? |
| 5 | Integration und Architektur | Kann der Anbieter SAP und Non-SAP-Systeme sinnvoll integrieren? |
| 6 | Datenmigration und Datenqualität | Sind Datenmigration, Bereinigung und Validierung ausreichend berücksichtigt? |
| 7 | Konkretes Projektteam | Wer setzt das Projekt tatsächlich um? |
| 8 | Projekt-Governance | Wie werden Scope, Risiken, Entscheidungen und Änderungen gesteuert? |
| 9 | Schweizer und internationale Anforderungen | Passt das Delivery-Modell zur Unternehmensstruktur und zum Standort Schweiz? |
| 10 | Cloud, Clean Core und Erweiterbarkeit | Unterstützt die vorgeschlagene Architektur die langfristige SAP-Strategie? |
| 11 | Support und Weiterentwicklung | Wie wird die SAP-Landschaft nach dem Go-live betreut? |
| 12 | Angebot, Kosten und Vertragsmodell | Sind Leistungsumfang, Aufwand und Kosten transparent und vergleichbar? |
Warum ein einheitlicher Kriterienkatalog wichtig ist
SAP-Angebote sind häufig nicht direkt miteinander vergleichbar. Ein Anbieter kann beispielsweise einen grösseren Leistungsumfang kalkulieren, während ein anderer bestimmte Aufgaben beim Kunden voraussetzt. Auch Unterschiede beim Projektteam, bei der Datenmigration, beim Testing oder beim Support können den Gesamtaufwand erheblich beeinflussen.
Deshalb sollte ein Vergleich nicht bei der Frage „Welcher Anbieter ist günstiger?“ beginnen. Sinnvoller ist:
Was wird angeboten? → Wer erbringt die Leistung? → Unter welchen Annahmen? → Welcher Aufwand entsteht beim Anbieter und beim Kunden? → Welche Leistungen sind nach dem Go-live enthalten?
Erst wenn diese Punkte vergleichbar sind, lässt sich ein SAP-Angebot sachgerecht einordnen.
Für Schweizer Unternehmen kommen je nach Projekt weitere Aspekte hinzu. Bei Cloud- oder ausgelagerten Datenverarbeitungsmodellen können beispielsweise Datenschutz, Auftragsbearbeitung, internationale Datenflüsse und die Auswahl von Unterauftragnehmern relevant sein. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte weist darauf hin, dass Unternehmen auch bei ausgelagerter Datenbearbeitung entsprechende Verantwortlichkeiten und Prüfpflichten berücksichtigen müssen.
Praxis-Tipp: Erstellen Sie vor der Anbieterbewertung einen einheitlichen Fragen- und Anforderungskatalog. Bitten Sie alle SAP-Dienstleister, Scope, Projektteam, Annahmen, Aufwand, Meilensteine und Supportleistungen nach derselben Struktur darzustellen. Dadurch werden Unterschiede sichtbar, die in einer klassischen Angebotspräsentation leicht untergehen.
Kriterium 1: SAP- und Technologiekompetenz
Ein SAP-Dienstleister sollte nicht nur allgemeine SAP-Erfahrung vorweisen, sondern genau die Technologien und Lösungen beherrschen, die für das geplante Projekt relevant sind. Entscheidend ist die Passung zwischen den Kompetenzen des Anbieters und der geplanten SAP-Zielarchitektur.
Bei einer S/4HANA-Transformation können beispielsweise Kenntnisse in SAP S/4HANA, SAP Cloud ERP, Datenmigration und Integration erforderlich sein. Je nach Projekt kommen weitere Technologien wie SAP BTP, SAP Integration Suite, SAP EWM, SAP TM oder SAP Business AI hinzu.
Was sollte man prüfen?
Beginnen Sie mit den Anforderungen des eigenen Projekts und gleichen Sie diese mit den nachweisbaren Kompetenzen des SAP-Beratungsunternehmens ab:
- Welche SAP-Produkte und -Lösungen werden im Projekt benötigt?
- Verfügt der Anbieter über relevante Erfahrung mit der vorgesehenen Zielarchitektur?
- Welche Rollen und Fachbereiche kann er abdecken?
- Sind Integration und Datenmanagement Teil der angebotenen Leistungen?
- Wie aktuell ist die technologische Expertise des Projektteams?
- Welche Aufgaben werden selbst übernommen und welche an andere Partner oder Subunternehmer vergeben?
Dabei sollte zwischen Unternehmenskompetenz und konkreter Projektkompetenz unterschieden werden. Ein Dienstleister kann ein breites SAP-Portfolio anbieten, ohne dass jede Technologie automatisch im vorgesehenen Projektteam verfügbar ist.
SAP-Partnerstatus und Zertifizierungen richtig einordnen
SAP-Partnerstatus und Zertifizierungen können Hinweise auf vorhandene Kompetenzen geben. Sie ersetzen jedoch nicht die Prüfung, ob der Anbieter bereits vergleichbare Projekte umgesetzt hat und welche Experten tatsächlich für das eigene Vorhaben vorgesehen sind.
Für die Bewertung sollten deshalb mehrere Nachweise kombiniert werden:
| Nachweis | Was er zeigt | Was zusätzlich geprüft werden sollte |
|---|---|---|
| SAP-Partnerstatus | Beziehung und Rolle im SAP-Ökosystem | Relevanz für das konkrete Projekt |
| Zertifizierungen | Fachkenntnisse einzelner Personen | Projekterfahrung und aktuelle Rolle |
| Referenzprojekte | Praktische Erfahrung | Vergleichbarkeit mit dem eigenen Vorhaben |
| Projektteam | Verfügbare Kompetenzen | Wer tatsächlich eingesetzt wird |
| Architekturbeispiele | Technisches Vorgehen | Übertragbarkeit auf die eigene Landschaft |
Praxis-Tipp: Fordern Sie nicht nur eine Liste der SAP-Kompetenzen an. Bitten Sie den Anbieter, die für Ihr Projekt relevanten Technologien direkt den vorgesehenen Rollen und Referenzprojekten zuzuordnen. So wird sichtbar, ob die präsentierte Expertise tatsächlich für das geplante Vorhaben verfügbar ist.
Für Schweizer Unternehmen mit internationalen SAP-Landschaften ist zudem relevant, ob der Dienstleister lokale Anforderungen mit einer globalen SAP-Architektur verbinden kann. Gerade bei Rollouts oder der Integration einer Schweizer Gesellschaft in ein bestehendes globales Template kann diese Fähigkeit wichtiger sein als eine möglichst lange Liste einzelner SAP-Produkte.
Kriterium 2: Branchen- und Prozesskompetenz
SAP-Projekte verändern Geschäftsprozesse, nicht nur IT-Systeme. Deshalb reicht es nicht aus, dass ein SAP-Dienstleister die eingesetzte Technologie kennt. Er sollte auch verstehen, wie die relevanten Prozesse im Unternehmen funktionieren und welche Anforderungen sich daraus für die SAP-Lösung ergeben.
Das ist besonders wichtig bei komplexen oder stark integrierten Abläufen, etwa in Produktion, Beschaffung, Lager und Logistik, Finance oder Asset Management. Ein Anbieter kann beispielsweise Erfahrung mit SAP S/4HANA haben, aber dennoch wenig Erfahrung mit den konkreten Prozessen eines produzierenden Unternehmens besitzen.
Welche Prozesskompetenz ist relevant?
Das hängt vom Projekt ab. Mögliche Bereiche sind:
- Finance und Controlling
- Einkauf und Procurement
- Produktion
- Supply Chain Management
- Lager und Logistik
- Transport
- Asset Management
- Vertrieb
- Stammdatenmanagement
- Qualitätsmanagement
Auch branchenspezifische Anforderungen können eine Rolle spielen, beispielsweise in Manufacturing, Life Sciences, Consumer Products, Retail oder Distribution.
Technologiekompetenz und Prozesskompetenz getrennt prüfen
Bei der Auswahl eines SAP-Beratungsunternehmens lohnt sich eine einfache Unterscheidung:
| Kompetenz | Frage an den Anbieter |
|---|---|
| SAP-Technologie | Beherrscht das Team die benötigte SAP-Lösung? |
| Prozesskompetenz | Versteht das Team die betroffenen Geschäftsprozesse? |
| Branchenkompetenz | Kennt es typische Anforderungen und Rahmenbedingungen der Branche? |
| Transformation | Kann es bestehende Prozesse sinnvoll analysieren und weiterentwickeln? |
| Change Management | Kann es die Auswirkungen auf Fachbereiche und Anwender berücksichtigen? |
Besonders aussagekräftig sind Referenzen, bei denen Technologie, Branche und Prozesslandschaft ähnlich waren wie im eigenen Projekt.
Ein Unternehmen sollte deshalb nicht nur fragen: „Haben Sie SAP S/4HANA implementiert?“ Besser ist eine konkrete Frage wie: „Welche vergleichbaren S/4HANA-Projekte haben Sie in unserer Branche und mit einer ähnlichen Prozesslandschaft umgesetzt?“
Worauf sollte man bei Referenzen achten?
Eine relevante Referenz sollte möglichst mehrere Dimensionen abdecken:
- ähnliche Branche oder Geschäftsmodell
- vergleichbare Unternehmensgrösse
- ähnliche SAP-Ausgangslage
- vergleichbare Anzahl und Komplexität von Schnittstellen
- ähnliche internationale Struktur
- vergleichbarer Transformationsumfang
- ähnliche betroffene Geschäftsprozesse
Dabei muss eine Referenz nicht in jedem Punkt identisch sein. Entscheidend ist, dass der Anbieter nachvollziehbar erklären kann, welche Erfahrungen auf das eigene Projekt übertragbar sind und wo Unterschiede bestehen.
Lassen Sie sich nicht nur Kundenlogos oder allgemeine Fallstudien zeigen. Fragen Sie nach konkreten Projektaufgaben: Welche Prozesse wurden verändert? Welche SAP-Komponenten wurden eingesetzt? Welche Integrationen waren erforderlich? Welche Herausforderungen traten bei Migration, Testing oder Go-live auf?
So lässt sich besser beurteilen, ob ein SAP-Dienstleister nicht nur SAP-Technologie kennt, sondern die geschäftlichen Anforderungen hinter dem Projekt versteht.
Kriterium 3: Erfahrung mit vergleichbaren SAP-Projekten
Referenzen sind besonders aussagekräftig, wenn sie tatsächlich mit dem eigenen Vorhaben vergleichbar sind. Eine lange Liste bekannter Kunden oder abgeschlossener SAP-Projekte sagt allein wenig darüber aus, ob ein Dienstleister die spezifischen Herausforderungen Ihres Projekts beherrscht.
Beim Vergleich von SAP-Dienstleistern sollte deshalb nicht nur gefragt werden, ob Erfahrung vorhanden ist, sondern welche Art von Erfahrung konkret vorliegt.
Worauf sollte man bei Referenzprojekten achten?
- Ähnliche Ausgangslage: Zum Beispiel SAP ECC, eine bestehende S/4HANA-Landschaft oder eine heterogene Systemlandschaft.
- Ähnlicher Projektumfang: Migration, Neueinführung, System Conversion, Rollout oder schrittweise Transformation.
- Vergleichbare Unternehmensgrösse: Ein Projekt für einen internationalen Konzern stellt andere Anforderungen als eine SAP-Einführung bei einem mittelständischen Unternehmen.
- Ähnliche Prozesse: Beispielsweise Produktion, Einkauf, Supply Chain, Finance oder Asset Management.
- Vergleichbare Integrationen: Anzahl und Komplexität der Schnittstellen zu Non-SAP-Systemen, Plattformen oder lokalen Anwendungen.
- Ähnliche internationale Anforderungen: Etwa mehrere Länder, Gesellschaften, Sprachen, Währungen oder ein globales Template.
- Nachweisbare Ergebnisse: Nicht nur der Projektumfang, sondern auch erreichte Meilensteine, Go-live, Prozessverbesserungen oder technische Ergebnisse sollten nachvollziehbar sein.
Referenzen richtig einordnen
Eine Referenz wird besonders relevant, wenn mehrere Dimensionen mit dem eigenen Projekt übereinstimmen:
| Vergleichspunkt | Frage an den SAP-Dienstleister |
|---|---|
| Branche | Wurde ein vergleichbares Geschäftsmodell umgesetzt? |
| Unternehmensgrösse | War die Organisation ähnlich komplex? |
| SAP-Ausgangslage | Welche Systeme und Versionen waren vorhanden? |
| Zielbild | Welche SAP-Lösung und Architektur wurde eingeführt? |
| Projektumfang | Welche Bereiche und Gesellschaften waren beteiligt? |
| Integration | Welche SAP- und Non-SAP-Systeme mussten angebunden werden? |
| Migration | Welche Datenmengen und Migrationsanforderungen bestanden? |
| Projektteam | Welche Rollen und Kompetenzen wurden tatsächlich eingesetzt? |
| Ergebnis | Was wurde konkret umgesetzt und wie wurde der Erfolg gemessen? |
Besonders wichtig ist dabei die Übertragbarkeit. Ein Dienstleister kann viele SAP-Projekte durchgeführt haben, ohne dass diese für das eigene Vorhaben besonders aussagekräftig sind. Umgekehrt kann eine kleinere Zahl sehr ähnlicher Projekte eine bessere Grundlage für die Beurteilung sein.
Wichtig: Bitten Sie Anbieter um zwei bis drei Referenzprojekte, die Ihrem Vorhaben möglichst nahekommen. Lassen Sie sich dabei nicht nur Branche und Unternehmensname nennen, sondern Ausgangslage, Projektumfang, SAP-Lösungen, Integrationen, Projektteam und die wichtigsten Herausforderungen erläutern. So wird aus einer allgemeinen Referenz eine tatsächlich vergleichbare Projektbasis.
Kriterium 4: Kompetenz für Migration und Transformation
Bei einer SAP-Migration oder ERP-Transformation reicht technische Implementierungserfahrung allein nicht aus. Der SAP-Dienstleister sollte nachvollziehbar zeigen können, wie die bestehende SAP-Landschaft analysiert, das Zielbild definiert und die Transformation schrittweise umgesetzt wird.
Das gilt insbesondere bei der Migration auf SAP S/4HANA oder SAP Cloud ERP. Je nach Ausgangslage kommen unterschiedliche Transformationsansätze infrage. Entscheidend ist deshalb nicht, ob ein Anbieter einen bestimmten Ansatz bevorzugt, sondern ob er begründen kann, welcher Weg zur bestehenden Systemlandschaft, zu den Geschäftsprozessen und zu den strategischen Zielen des Unternehmens passt.
Diese Punkte sollten Sie prüfen:
- Ausgangslage: Wie werden bestehende Systeme, Eigenentwicklungen, Schnittstellen und Prozesse analysiert?
- Transformationsansatz: Wie wird zwischen Neuimplementierung, System Conversion oder einer selektiven Transformation entschieden?
- Zielarchitektur: Ist klar beschrieben, wie die künftige SAP-Landschaft aufgebaut sein soll?
- Datenmigration: Welche Daten werden übernommen, bereinigt, transformiert und validiert?
- Custom Code: Wie werden Eigenentwicklungen analysiert und im Zielbild behandelt?
- Prozessharmonisierung: Welche Prozesse sollen standardisiert, optimiert oder neu gestaltet werden?
- Teststrategie: Wie werden Migration, Integrationen und Geschäftsprozesse vor dem Go-live getestet?
- Cutover und Go-live: Wie werden die Umstellung und die Risiken rund um den Produktivstart geplant?
- Roadmap: Gibt es eine realistische Abfolge für Migration, Rollouts und weitere Optimierungen?
Ein gutes Transformationskonzept sollte ausserdem zwischen technischer Migration und organisatorischer Veränderung unterscheiden. Neue SAP-Prozesse können Auswirkungen auf Rollen, Verantwortlichkeiten, Arbeitsweisen und Schulungsbedarf haben. Deshalb sollte auch Change Management Teil der Gesamtplanung sein, wenn die Veränderung dies erfordert.
Nicht nur die Methode, sondern ihre Begründung prüfen
Im Anbieter-Vergleich lohnt sich eine einfache Gegenüberstellung:
| Prüffrage | Was sollte nachvollziehbar sein? |
|---|---|
| Warum dieser Transformationsansatz? | Bezug zur konkreten Ausgangslage |
| Was wird übernommen? | Systeme, Daten, Prozesse und Eigenentwicklungen |
| Was wird verändert? | Prozesse, Architektur und Erweiterungen |
| Welche Risiken bestehen? | Technische, fachliche und organisatorische Risiken |
| Wie wird getestet? | Teststufen, Verantwortlichkeiten und Abnahmekriterien |
| Wie erfolgt der Go-live? | Cutover-Planung, Fallback und Verantwortlichkeiten |
| Was passiert nach dem Go-live? | Stabilisierung, Support und weitere Optimierung |
Praxis-Tipp: Lassen Sie sich vom SAP-Dienstleister anhand Ihrer Ausgangslage erklären, welche Transformationsoptionen er sieht und welche Annahmen dahinterstehen. So erkennen Sie schneller, ob der vorgeschlagene Ansatz auf einer konkreten Analyse basiert oder lediglich ein standardisiertes Vorgehensmodell darstellt.
Klären Sie, welche Kompetenzen, Projektrollen und Leistungen für Ihr Vorhaben relevant sind
Kriterium 5: Integration und Systemarchitektur
Ein SAP-Dienstleister sollte nicht nur einzelne SAP-Lösungen implementieren können, sondern auch verstehen, wie diese in die bestehende IT-Landschaft integriert werden. Gerade bei modernen SAP-Architekturen entstehen Abhängigkeiten zwischen SAP-Systemen, Non-SAP-Anwendungen, Datenplattformen und Cloud-Services.
Für die Auswahl eines Dienstleisters ist deshalb relevant, ob er sowohl die bestehende Systemlandschaft als auch die geplante Zielarchitektur berücksichtigen kann.
Diese Punkte sollten Sie prüfen:
- Systemlandschaft: Welche SAP- und Non-SAP-Systeme müssen berücksichtigt werden?
- Schnittstellen: Wie werden bestehende und neue Integrationen geplant, dokumentiert und betrieben?
- Integrationsarchitektur: Welche Integrationsplattformen und Technologien sind vorgesehen?
- SAP BTP: Welche Rolle spielt die Business Technology Platform in der geplanten Architektur?
- Datenflüsse: Welche Daten werden zwischen Systemen ausgetauscht und wo liegen die führenden Datenquellen?
- Abhängigkeiten: Welche Systeme, Schnittstellen oder Prozesse können den Projektfortschritt beeinflussen?
- Betrieb: Wer ist nach dem Go-live für Monitoring, Fehleranalyse und Weiterentwicklung der Integrationen verantwortlich?
Besonders wichtig ist die Abgrenzung zwischen SAP-Implementierung und Gesamtarchitektur. Ein Dienstleister kann eine SAP-Lösung fachlich korrekt konfigurieren, ohne gleichzeitig für die gesamte Integrationslandschaft verantwortlich zu sein. Im Angebot sollte deshalb klar erkennbar sein, welche Architektur- und Integrationsleistungen enthalten sind und wo Verantwortlichkeiten beim Kunden oder bei anderen Partnern liegen.
Architektur nicht nur auf das aktuelle Projekt ausrichten
Die Zielarchitektur sollte nicht ausschliesslich den aktuellen Implementierungsumfang abbilden. Unternehmen sollten auch berücksichtigen, welche weiteren Systeme, Cloud-Services oder SAP-Lösungen künftig integriert werden könnten.
Dabei können unter anderem SAP BTP, SAP Integration Suite, APIs und ereignisbasierte Integrationen relevant sein. Entscheidend ist jedoch nicht der Einsatz möglichst vieler Technologien, sondern eine nachvollziehbare Architektur, die zu den Geschäftsanforderungen und zur langfristigen IT-Strategie passt.
| Prüffrage | Was sollte der Anbieter zeigen? |
|---|---|
| Welche Systeme werden integriert? | Vollständige Übersicht der relevanten Anwendungen |
| Wie werden Daten ausgetauscht? | Schnittstellen, APIs und Integrationsmuster |
| Wo liegen Verantwortlichkeiten? | Klare Zuordnung zwischen Anbieter und Kunde |
| Wie wird die Architektur dokumentiert? | Zielbild, Abhängigkeiten und technische Standards |
| Wie wird der Betrieb sichergestellt? | Monitoring, Support und Fehlerbehebung |
| Wie bleibt die Architektur erweiterbar? | Berücksichtigung künftiger Anforderungen |
Praxis-Tipp: Fordern Sie im SAP-Angebot ein vereinfachtes Architekturdiagramm mit den wichtigsten Systemen, Schnittstellen und Verantwortlichkeiten an. So lassen sich unterschiedliche Anbieter nicht nur anhand ihrer Produktkenntnisse, sondern auch anhand ihres Architekturverständnisses vergleichen.
Kriterium 6: Datenmigration und Datenqualität
Bei SAP-Transformationen gehört die Datenmigration zu den Bereichen mit besonders vielen Abhängigkeiten. Stammdaten, Bewegungsdaten, historische Informationen und kundenspezifische Daten müssen analysiert, bereinigt, transformiert und kontrolliert in die Zielumgebung überführt werden.
Ein SAP-Dienstleister sollte deshalb nicht nur die technische Migration beschreiben, sondern auch zeigen, wie Datenqualität und fachliche Verantwortlichkeit im Projekt sichergestellt werden.
Diese Punkte sollten Sie prüfen:
- Datenumfang: Welche Daten werden migriert und welche bleiben im Altsystem oder Archiv?
- Datenqualität: Wie werden Dubletten, fehlende Werte, inkonsistente Stammdaten und veraltete Datensätze behandelt?
- Mapping: Wie werden Quell- und Zielfelder sowie unterschiedliche Datenstrukturen aufeinander abgebildet?
- Transformation: Welche Daten müssen vor der Übernahme konvertiert oder fachlich angepasst werden?
- Verantwortlichkeiten: Wer ist für Datenbereinigung, Freigabe und fachliche Validierung zuständig?
- Migrationstests: Wie werden Testmigrationen durchgeführt und die Ergebnisse geprüft?
- Abstimmung: Wie wird sichergestellt, dass migrierte Daten fachlich und technisch vollständig sind?
- Cutover: Wie wird die finale Migration vorbereitet und kontrolliert?
Datenmigration ist auch eine fachliche Aufgabe
Ein häufiger Fehler besteht darin, Datenmigration als rein technische Aktivität zu behandeln. Ob ein Kunde, Materialstamm oder Finanzdatensatz korrekt migriert wurde, lässt sich oft nur anhand fachlicher Regeln beurteilen.
Deshalb sollte bereits im Angebot klar sein, welche Aufgaben der SAP-Dienstleister übernimmt und welche beim Unternehmen liegen. Dazu gehören beispielsweise Datenbereinigung, Definition von Mapping-Regeln, fachliche Freigaben und Validierung.
| Prüffrage | Was sollte im Angebot erkennbar sein? |
|---|---|
| Welche Daten werden migriert? | Umfang, Datenobjekte und Abgrenzungen |
| Wie wird die Datenqualität bewertet? | Prüfregeln und Bereinigungsmassnahmen |
| Wer bereinigt die Daten? | Klare Rollen und Verantwortlichkeiten |
| Wie wird migriert? | Vorgehen, Werkzeuge und Testzyklen |
| Wie wird validiert? | Fachliche und technische Prüfungen |
| Was passiert bei Abweichungen? | Fehlerbehandlung und Nachmigration |
Praxis-Tipp: Bitten Sie jeden SAP-Dienstleister um eine konkrete Darstellung des Migrationsvorgehens für die wichtigsten Datenobjekte. Vergleichen Sie dabei nicht nur den technischen Ansatz, sondern auch den eingeplanten Aufwand für Datenbereinigung, Tests und fachliche Validierung. So werden Unterschiede im Leistungsumfang früh sichtbar.
Kriterium 7: Das konkrete Projektteam
Beim Vergleich von SAP-Dienstleistern sollte nicht nur das Unternehmen als Ganzes betrachtet werden. Entscheidend ist, welche Personen das Projekt tatsächlich durchführen. Ein Anbieter kann über viele SAP-Experten verfügen, ohne dass diese automatisch für Ihr Projekt eingeplant sind.
Deshalb sollte das angebotene Projektteam bereits in der Auswahlphase möglichst konkret beschrieben werden.
Diese Punkte sollten Sie prüfen:
- Rollen: Welche Rollen sind vorgesehen, etwa Projektleitung, Solution Architect, SAP Consultants, Entwickler, Daten- oder Integrationsexperten?
- Erfahrung: Welche Projekterfahrung haben die vorgesehenen Personen mit vergleichbaren Vorhaben?
- Verfügbarkeit: Sind die genannten Experten für die geplante Projektlaufzeit tatsächlich eingeplant?
- Standort und Delivery-Modell: Welche Aufgaben werden lokal, remote oder aus internationalen Delivery-Centern erbracht?
- Seniorität: Welche Aufgaben übernehmen erfahrene Spezialisten und welche werden an weniger erfahrene Ressourcen delegiert?
- Kontinuität: Wie wird sichergestellt, dass Schlüsselpersonen während des Projekts verfügbar bleiben?
- Vertretung: Was passiert bei Ausfall oder Wechsel einer wichtigen Projektperson?
- Zusammenarbeit: Wie wird das externe Team mit internen Fachbereichen und IT-Verantwortlichen abgestimmt?
Namen und Rollen im Angebot konkretisieren
Eine reine Rollenbeschreibung wie „SAP Consultant“ reicht für einen belastbaren Vergleich oft nicht aus. Lassen Sie sich für die wichtigsten Positionen zumindest Qualifikation, relevante Projekterfahrung, Verantwortungsbereich und geplante Verfügbarkeit nennen.
Besonders bei komplexen SAP-Projekten lohnt sich auch ein Blick auf die Balance zwischen Fach-, Prozess- und Technologiekompetenz. Ein Team sollte nicht nur technische Aufgaben abdecken, sondern auch die fachlichen Entscheidungen und Integrationsfragen des Projekts unterstützen können.
| Prüffrage | Was sollte der Anbieter zeigen? |
|---|---|
| Wer leitet das Projekt? | Name, Rolle und relevante Erfahrung |
| Wer verantwortet die Architektur? | Architekturkompetenz und Projekterfahrung |
| Wer implementiert die Lösung? | Fachliche und technische Rollen |
| Wer verantwortet Daten und Integration? | Konkrete Spezialisten und Aufgaben |
| Wo arbeitet das Team? | Lokales, internationales oder hybrides Delivery-Modell |
| Wie hoch ist die Verfügbarkeit? | Geplante Kapazitäten und Einsatzzeiten |
| Was passiert bei Personalwechsel? | Vertretungs- und Übergaberegelung |
Praxis-Tipp: Bitten Sie den SAP-Dienstleister, das tatsächlich vorgesehene Kernteam im Angebot auszuweisen. Vergleichen Sie anschliessend nicht nur die Anzahl der Personen, sondern deren Rollen, Erfahrung, Verfügbarkeit und Anteil am Gesamtprojekt. Wenn sich das Team nach Vertragsabschluss wesentlich ändern kann, sollte auch geregelt sein, unter welchen Bedingungen ein Austausch erfolgt.
Sie möchten prüfen, welche SAP-Kompetenzen und Projektrollen für Ihr Vorhaben benötigt werden?
Kriterium 8: Vorgehensmodell und Projekt-Governance
Ein SAP-Projekt braucht nicht nur fachliche und technische Kompetenz, sondern auch klare Regeln für Planung, Entscheidungen, Änderungen und Eskalationen. Gerade bei komplexen Transformationen können sich Anforderungen während des Projekts verändern. Ohne klare Governance werden daraus schnell Verzögerungen, zusätzliche Aufwände oder unklare Verantwortlichkeiten.
Beim Vergleich von SAP-Dienstleistern sollte deshalb nachvollziehbar sein, wie der Anbieter das Projekt steuert und welche Verantwortung beim Kunden liegt.
Diese Punkte sollten Sie prüfen:
- Vorgehensmodell: Wie wird das Projekt strukturiert und welche Phasen sind vorgesehen?
- Meilensteine: Welche Ergebnisse müssen zu welchen Zeitpunkten erreicht werden?
- Rollen und Verantwortlichkeiten: Wer entscheidet über Fachlichkeit, Architektur, Scope und Prioritäten?
- Scope Management: Wie werden Anforderungen dokumentiert und Änderungen behandelt?
- Risikomanagement: Wie werden Projektrisiken identifiziert, bewertet und eskaliert?
- Qualitätssicherung: Welche Reviews, Tests und Freigaben sind vorgesehen?
- Kommunikation: Welche Meetings, Reports und Entscheidungswege gibt es?
- Eskalationen: Wie werden Blockaden oder Zielabweichungen adressiert?
Governance im Angebot konkret beschreiben
Ein Anbieter sollte nicht nur eine Projektmethodik nennen. Entscheidend ist, wie diese Methodik auf das konkrete SAP-Projekt angewendet werden soll.
Dazu gehören beispielsweise die Verantwortlichkeiten von Projektleitung, Steering Committee, Fachbereichen, IT und externem SAP-Dienstleister. Auch die Frage, wer Entscheidungen treffen darf und wie Änderungen am Scope freigegeben werden, sollte früh geklärt sein.
| Prüffrage | Was sollte im Angebot stehen? |
|---|---|
| Wie wird das Projekt gesteuert? | Vorgehensmodell und Projektphasen |
| Wer entscheidet? | Rollen, Gremien und Eskalationswege |
| Wie werden Änderungen behandelt? | Change-Request-Prozess |
| Wie wird Qualität kontrolliert? | Reviews, Tests und Abnahmen |
| Wie werden Risiken gesteuert? | Risiko-Log und Eskalationsprozess |
| Wie wird Fortschritt gemessen? | Meilensteine, Statusberichte und KPIs |
| Was wird vom Kunden erwartet? | Konkrete Mitwirkungspflichten |
Praxis-Tipp: Vergleichen Sie bei mehreren SAP-Angeboten nicht nur die geplante Projektdauer. Prüfen Sie auch, welche Meilensteine, Entscheidungsprozesse, Kundeneinsatzzeiten und Abnahmen eingeplant sind. Ein scheinbar günstigeres Angebot kann beispielsweise einen grösseren Teil der Projektarbeit auf interne Ressourcen verlagern.
Kriterium 9: Schweizer Anforderungen und internationales Delivery-Modell
Für Schweizer Unternehmen ist die Frage relevant, wie lokale Anforderungen und internationale SAP-Strukturen zusammenspielen. Das gilt besonders für Unternehmen mit mehreren Schweizer Gesellschaften, internationalen Standorten oder einem globalen SAP-Template.
Ein SAP-Dienstleister sollte deshalb sowohl die Anforderungen des Schweizer Standorts als auch die übergeordnete System- und Prozesslandschaft verstehen.
Diese Punkte sollten Sie prüfen:
- Schweizer Anforderungen: Welche lokalen fachlichen, organisatorischen und regulatorischen Anforderungen werden berücksichtigt?
- Internationale Strukturen: Wie werden globale Templates und lokale Anforderungen miteinander verbunden?
- Sprache und Kommunikation: Kann der Dienstleister die relevanten Fachbereiche und Stakeholder in den benötigten Sprachen unterstützen?
- Delivery-Modell: Welche Leistungen werden in der Schweiz, remote oder über internationale Teams erbracht?
- Zeitzonen: Sind Erreichbarkeit und Zusammenarbeit mit internationalen Teams praktikabel?
- Datenschutz und Datenverarbeitung: Ist transparent, wo Daten verarbeitet werden und welche externen Dienstleister oder Subunternehmer beteiligt sind?
- Support: Wie ist die Unterstützung während Projekt, Go-live und laufendem Betrieb organisiert?
Lokal, international oder kombiniert?
Ein internationales Delivery-Modell ist nicht automatisch besser oder schlechter als ein lokales Modell. Entscheidend ist, ob die Aufteilung zum Projekt passt und Verantwortlichkeiten, Kommunikation und Qualität klar geregelt sind.
Bei einem globalen SAP-Rollout kann beispielsweise ein internationales Team für Template, Architektur und zentrale Prozesse zuständig sein, während lokale Experten die Anforderungen der Schweizer Gesellschaften unterstützen. Bei einem rein nationalen Projekt können dagegen andere Strukturen sinnvoll sein.
| Prüffrage | Was sollte geklärt sein? |
|---|---|
| Wo sitzen die Projektteams? | Standorte und Delivery-Center |
| Wer ist Ansprechpartner? | Verantwortliche Projekt- und Servicekontakte |
| Wie werden lokale Anforderungen berücksichtigt? | Lokale Expertise und Entscheidungswege |
| Wo werden Daten verarbeitet? | Verarbeitungsorte und beteiligte Dienstleister |
| Wie funktioniert der Support? | Servicezeiten, Sprachen und Eskalationswege |
| Wie wird global zusammengearbeitet? | Governance zwischen lokalen und internationalen Teams |
Praxis-Tipp: Lassen Sie sich im Angebot konkret darstellen, welche Aufgaben durch welches Team erbracht werden. Prüfen Sie insbesondere bei internationalen Projekten, wer für Schweizer Anforderungen, lokale Abstimmungen und den laufenden Support verantwortlich ist. So wird sichtbar, ob das Delivery-Modell tatsächlich zur Organisation passt.
Kriterium 10: Cloud, Clean Core und Erweiterbarkeit
Bei der Auswahl eines SAP-Dienstleisters sollte nicht nur die aktuelle Implementierung betrachtet werden. Entscheidend ist auch, wie die vorgeschlagene SAP-Architektur langfristig weiterentwickelt werden kann. Das betrifft insbesondere Unternehmen, die auf SAP Cloud ERP oder andere Cloud-basierte SAP-Lösungen setzen.
Ein wichtiger Aspekt ist dabei der Clean-Core-Ansatz: Anpassungen sollten möglichst so umgesetzt werden, dass der SAP-Kern langfristig wartbar und updatefähig bleibt. Erweiterungen können je nach Anforderung beispielsweise über geeignete SAP-Services und die SAP Business Technology Platform umgesetzt werden.
Diese Punkte sollten Sie prüfen:
- Cloud-Strategie: Passt die vorgeschlagene Lösung zur langfristigen IT- und ERP-Strategie?
- Clean Core: Welche Erweiterungen und Anpassungen sind im SAP-Kern vorgesehen?
- Extensions: Wie werden individuelle Anforderungen umgesetzt, ohne unnötige Abhängigkeiten vom Kernsystem zu schaffen?
- Upgrade-Fähigkeit: Wie wirkt sich die gewählte Architektur auf künftige Updates und Releases aus?
- BTP-Nutzung: Wo kann SAP BTP für Erweiterungen, Integration oder Daten genutzt werden?
- Standards: Welche Anforderungen lassen sich mit SAP-Standardfunktionen abdecken?
- Betrieb: Welche Auswirkungen hat die Architektur auf Monitoring, Support und laufende Weiterentwicklung?
Nicht jede Individualisierung ist problematisch
Clean Core bedeutet nicht, dass Unternehmen vollständig auf individuelle Anforderungen verzichten müssen. Vielmehr sollte für jede Abweichung vom Standard nachvollziehbar sein, warum sie erforderlich ist und wie sie technisch umgesetzt werden soll.
Beim Angebotsvergleich lohnt sich deshalb eine konkrete Aufstellung der geplanten Erweiterungen:
| Prüffrage | Was sollte der Anbieter erläutern? |
|---|---|
| Was bleibt im SAP-Standard? | Standardprozesse und Funktionen |
| Wo sind Erweiterungen notwendig? | Fachliche Begründung und Umfang |
| Wie werden Extensions umgesetzt? | Technischer Ansatz und verwendete Services |
| Welche Rolle spielt BTP? | Integration, Erweiterungen oder Datenservices |
| Welche Auswirkungen gibt es auf Updates? | Wartbarkeit und künftige Releases |
| Wie wird die Architektur weiterentwickelt? | Roadmap und Governance |
Praxis-Tipp: Lassen Sie sich für wesentliche Individualisierungen jeweils den fachlichen Grund, den technischen Ansatz und die langfristigen Auswirkungen erläutern. So können Sie Angebote besser danach vergleichen, ob sie eine wartbare und erweiterbare SAP-Landschaft unterstützen – statt nur den kurzfristigen Projektumfang zu betrachten.
Kriterium 11: Support, AMS und Weiterentwicklung
Mit dem Go-live endet ein SAP-Projekt nicht. Nach der Einführung müssen Prozesse stabilisiert, Fehler behoben, Anwender unterstützt und die SAP-Landschaft kontinuierlich weiterentwickelt werden. Deshalb sollte bereits bei der Auswahl eines SAP-Dienstleisters geklärt werden, wie der Betrieb nach dem Projekt organisiert werden kann.
Dabei können Managed Services oder Application Management Services (AMS) eine Option sein. Unternehmen sollten jedoch prüfen, welche Leistungen tatsächlich benötigt werden und welche davon im Angebot enthalten sind.
Diese Punkte sollten Sie prüfen:
- Supportumfang: Welche SAP-Module, Anwendungen und Schnittstellen werden unterstützt?
- Servicezeiten: Wann ist der Dienstleister erreichbar und welche Leistungen gelten ausserhalb der Geschäftszeiten?
- SLA: Welche Reaktions- und Lösungszeiten werden für unterschiedliche Prioritäten vereinbart?
- Incident Management: Wie werden Störungen aufgenommen, priorisiert und eskaliert?
- Problem Management: Wie werden wiederkehrende Fehler analysiert und nachhaltig behoben?
- Monitoring: Welche Systeme und Integrationen werden überwacht?
- Change Requests: Wie werden kleinere Anpassungen und Weiterentwicklungen abgewickelt?
- Release Management: Wie werden Updates, neue SAP-Funktionen und technische Änderungen geplant?
- Wissensübergabe: Wie wird sichergestellt, dass Wissen über die SAP-Landschaft langfristig verfügbar bleibt?
Support nicht nur nach dem Preis vergleichen
Zwei Angebote können bei ähnlichen monatlichen Kosten einen sehr unterschiedlichen Leistungsumfang enthalten. Deshalb sollten Supportangebote anhand derselben Leistungsbausteine verglichen werden.
| Prüffrage | Was sollte im Angebot geklärt sein? |
|---|---|
| Was wird unterstützt? | SAP-Lösungen, Schnittstellen und angrenzende Systeme |
| Wann ist Support verfügbar? | Servicezeiten und Bereitschaft |
| Wie schnell wird reagiert? | SLA nach Priorität |
| Wer bearbeitet Störungen? | Rollen, Teams und Eskalationswege |
| Was kostet Weiterentwicklung? | Inklusivleistungen und zusätzliche Aufwände |
| Wie werden Änderungen umgesetzt? | Change- und Release-Prozess |
| Wie erfolgt die Übergabe? | Dokumentation und Knowledge Transfer |
Praxis-Tipp: Lassen Sie sich bereits im Projektangebot ein konkretes Supportmodell darstellen. Vergleichen Sie nicht nur monatliche Gebühren, sondern auch SLA, Servicezeiten, enthaltene Leistungen, zusätzliche Kosten und die geplante Zusammensetzung des Supportteams. So wird sichtbar, welche Total Cost of Ownership nach dem Go-live tatsächlich entstehen können.
Kriterium 12: Angebot, Kosten und Vertragsmodell
Der Preis eines SAP-Dienstleisters lässt sich nur sinnvoll vergleichen, wenn die zugrunde liegenden Leistungen vergleichbar sind. Ein günstigeres Angebot kann beispielsweise einen kleineren Scope, geringere Projektkapazitäten oder mehr Eigenleistungen auf Kundenseite voraussetzen.
Beim Vergleich von SAP-Angeboten sollte deshalb zunächst der Leistungsumfang und erst danach der Preis betrachtet werden.
Diese Punkte sollten Sie prüfen:
- Scope: Welche Leistungen und SAP-Bereiche sind enthalten?
- Deliverables: Welche konkreten Ergebnisse werden geliefert?
- Annahmen: Welche Voraussetzungen muss der Kunde erfüllen?
- Kundeneigenleistungen: Welche Aufgaben übernimmt das interne Team?
- Aufwand: Wie viele Beratertage oder Stunden sind für die einzelnen Phasen vorgesehen?
- Zeitplan: Welche Meilensteine und Abhängigkeiten liegen der Kalkulation zugrunde?
- Change Requests: Wie werden zusätzliche Anforderungen abgerechnet?
- Reisekosten: Welche Spesen und Reisekosten sind enthalten oder werden separat verrechnet?
- Support: Welche Leistungen nach dem Go-live sind im Angebot enthalten?
- Vertragsmodell: Wie werden Leistung, Aufwand, Risiken und Zahlungen vertraglich geregelt?
Festpreis, Time & Material oder Mischmodell?
Das Vertragsmodell beeinflusst, wie Projektrisiken zwischen Kunde und Dienstleister verteilt werden. Bei Time & Material werden Leistungen typischerweise nach tatsächlich geleistetem Aufwand abgerechnet. Ein Festpreis definiert dagegen einen vereinbarten Leistungsumfang zu einem festgelegten Preis. Mischmodelle können einzelne Projektphasen unterschiedlich behandeln.
Keine dieser Varianten ist grundsätzlich für jedes SAP-Projekt geeignet. Entscheidend ist, ob das Modell zum Reifegrad der Anforderungen, zur Projektdynamik und zum vereinbarten Scope passt.
| Vergleichspunkt | Was sollte geklärt sein? |
|---|---|
| Leistungsumfang | Was ist ausdrücklich enthalten? |
| Aufwand | Welche Ressourcen und Kapazitäten sind kalkuliert? |
| Annahmen | Welche Voraussetzungen liegen der Kalkulation zugrunde? |
| Kundeneinsatz | Welche internen Ressourcen werden benötigt? |
| Änderungen | Wie werden Scope-Erweiterungen behandelt? |
| Risiken | Welche Risiken liegen beim Anbieter und welche beim Kunden? |
| Zahlungsmodell | Welche Meilensteine oder Abrechnungsregeln gelten? |
| Nachprojektphase | Welche Kosten entstehen für Support und Weiterentwicklung? |
Nicht nur den Projektpreis betrachten
Für eine belastbare Entscheidung sollte neben den einmaligen Implementierungskosten auch der erwartete Total Cost of Ownership (TCO) betrachtet werden. Dazu können beispielsweise Lizenzen, Cloud-Kosten, Integration, Datenmigration, Support, Weiterentwicklung und interne Ressourcen gehören.
Praxis-Tipp: Geben Sie allen SAP-Dienstleistern möglichst denselben Anforderungskatalog und bitten Sie um eine strukturierte Kalkulation. Vergleichen Sie anschliessend Scope, Annahmen, Kundeneigenleistungen, Aufwand, Risiken und Folgekosten gemeinsam mit dem Angebotspreis. So wird erkennbar, ob die Angebote tatsächlich auf einer vergleichbaren Basis kalkuliert wurden.
SAP-Dienstleister ganzheitlich vergleichen
Der Vergleich von SAP-Dienstleistern sollte nicht bei Unternehmensgrösse, Partnerstatus oder Projektpreis enden. Aussagekräftig wird die Auswahl erst, wenn Technologiekompetenz, Branchenwissen, vergleichbare Projekterfahrung, Transformationskompetenz und das konkrete Projektteam gemeinsam betrachtet werden.
Ebenso wichtig sind die Rahmenbedingungen des Projekts: Integration, Datenmigration, Governance, Schweizer und internationale Anforderungen, langfristige Architektur sowie Support nach dem Go-live.
Bei den Angeboten sollten Unternehmen schliesslich darauf achten, dass Scope, Annahmen, Kundeneigenleistungen, Aufwand, Risiken und Folgekosten transparent dargestellt sind. Erst auf dieser Grundlage lässt sich beurteilen, ob mehrere SAP-Angebote tatsächlich miteinander vergleichbar sind.
Die zentrale Frage lautet daher nicht: Welcher SAP-Dienstleister ist am günstigsten? Sondern: Welcher Anbieter passt mit Kompetenz, Team, Vorgehen und Leistungsumfang am besten zu den konkreten Anforderungen des Projekts?