Die besten SAP-Einführungsstrategien, um teure Fehler zu vermeiden

Die beste SAP-Einführungsstrategie ist die, die zu Ihrem Unternehmen passt und die Ihr Team durchhalten kann. Sie läuft auf drei Entscheidungen hinaus. Welches Bereitstellungsmodell: S/4HANA Cloud Public Edition (meist über GROW with SAP), Private Edition (meist über RISE with SAP) oder On-Premise. Welcher Migrationspfad: Greenfield, Brownfield oder Bluefield. Und welches Rollout-Muster: Big Bang, phasenweise oder hybrid. Dieser Leitfaden richtet sich an CIOs, Programmleiter und Sponsoren, die einen Ansatz für S/4HANA wählen. Beantworten Sie die fünf Fragen unten, treffen Sie zuerst die Entscheidung zum Bereitstellungsmodell und klären Sie dann die beiden anderen mit der Vergleichstabelle und dem Entscheidungsbaum.

In den 21 Programmen, an denen ich gearbeitet habe, zeigen sich immer dieselben Muster. Die Wahl der Strategie ist real, aber sie ist die kleinere Hälfte der Entscheidung. Die größere Hälfte ist, ob das Team die Disziplin über 14 Monate Umsetzung hält, nachdem die Tabelle mit den Optionen längst abgelegt ist.

Das Ziel ist nicht die schnellste oder billigste Option. Es ist der Ansatz, der zum Unternehmen passt: zu seiner Struktur, Kultur, Geschwindigkeit, seinem regulatorischen Profil und seinen langfristigen Zielen.

Fünf Fragen, die Sie zuerst beantworten sollten

1. Wie komplex ist Ihre Struktur: eine Gesellschaft, mehrere Gesellschaften, mehrere Länder?
2. Brauchen Ihre Teams Zeit, um sich umzustellen, oder sind sie jetzt bereit für Veränderung?
3. Kommen Sie von mehreren Altsystemen, von einem ERP oder von einem leeren Blatt?
4. Haben Sie internes SAP-Know-how, oder werden Sie von Partnern abhängen?
5. Wie viel Störung können Sie beim Go-live verkraften?

Eine universelle Antwort gibt es nicht. Ihre Strategie sollte Ihre Realität widerspiegeln, nicht die Erfolgsgeschichte eines anderen.

Was sich zwischen 2023 und 2026 geändert hat

RISE und GROW wurden zum Standardweg, S/4HANA in der Cloud zu kaufen. RISE with SAP bündelt die Software (meist Private Edition), die von SAP betriebene Infrastruktur und den technischen Betrieb sowie BTP-Guthaben in einem Abonnement. GROW with SAP schnürt die Public Edition für mittelgroße Unternehmen mit Standardprozessen. Das klassische Modell, erst die Lizenz und dann die Einführung, gibt es für On-Premise weiterhin, aber die meisten neuen Gespräche beginnen mit RISE oder GROW.

Clean Core wurde vom Ratschlag zur Architektur. In der Public Edition können Sie den Kern nicht modifizieren: Erweiterungen nutzen freigegebene APIs, entweder On-Stack mit ABAP Cloud oder Side-by-Side auf SAP BTP. In der Private Edition und On-Premise geht es noch, aber SAP behandelt Modifikationen als letztes Mittel, weil jede einzelne zusätzlichen Upgrade-Aufwand bedeutet. Partner ohne Clean-Core-Erfahrung erzeugen technische Schulden ab der ersten Woche.

AI ist in den Werkzeugen für die Umsetzung angekommen. SAP Joule for Consultants (seit Mai 2025 allgemein verfügbar) beantwortet Konfigurationsfragen auf Basis der SAP-eigenen Inhalte. SAP Cloud ALM kann aus den Protokollen von Fit-to-Standard-Workshops Anforderungen entwerfen. SAP Build Code (seit März 2024 allgemein verfügbar) nutzt Joule, um Java- und JavaScript-Erweiterungen zu generieren, und Joule für Entwickler hat ab Ende 2024 die Generierung und Erklärung von ABAP-Code ergänzt. Nichts davon ändert die strategische Wahl. Es ändert Kosten und Zeit innerhalb der Wahl, die Sie treffen.

Wo Strategien gelingen oder scheitern

Die Umsetzung zählt mehr als die Wahl. Vier Muster des Scheiterns tauchen auf, egal welcher Ansatz gewählt wurde.

1. Engagement der Geschäftsleitung, das verschwindet. Bei einer S/4HANA-Einführung für eine Bank kam der CEO zu jedem wichtigen Termin, stellte gute Fragen und stärkte dem Team den Rücken. Das Projekt endete pünktlich und unter Budget. Bei einer Ladenkette gab die Geschäftsleitung nach dem Kick-off alles ab. Das Projekt stand monatelang still, weil niemand Entscheidungen treffen konnte.
2. Datenmigration als IT-Aufgabe behandelt. Ein Kunde bestand darauf, seine Materialstammdaten seien „sauber genug“. Am ersten Tag erhielt sein Lager Aufträge für Produkte, die drei Jahre zuvor ausgelaufen waren. Die Bereinigung dauerte Wochen und kostete ihn einen wichtigen Kunden. Datenmigration braucht Verantwortung im Fachbereich.
3. Schulung ausgelassen oder überhastet. Ich besuchte ein Büro zwei Wochen nach dem SAP-Start. Das Buchhaltungsteam hatte überall Haftnotizen mit Erinnerungen für einfache Aufgaben an den Monitoren kleben; es hatte einen Tag Schulung bekommen. Die Vorgesetzte sagte mir: „Wir versuchen einfach zu überleben.“ Dieses Unternehmen gab im ersten Jahr zusätzlich 200.000 US-Dollar für Support aus.
4. Menschen, die am System vorbeiarbeiten. Ich habe mit einer Fabrik gearbeitet, die glaubte, Schulung reiche aus. Die Mitarbeitenden trauten dem neuen System nicht und kehrten zu ihren Tabellen zurück. Das nach dem Go-live zu beheben, war teuer. Change Management heißt Kommunikation, Beteiligung und Fürsprecher im Unternehmen, und Schulung ist nur ein Teil davon.

Die zwei wichtigsten Rollout-Muster

Big Bang

1. 01Alles live in einer einzigen Umstellung
2. 02Schnellster Weg zu standardisierten Prozessen
3. 03Geringere Anfangskosten, höheres Risiko am ersten Tag
4. 04Verlangt gründliche Generalproben und saubere Daten

Phasenweise

1. 01Live in Wellen nach Modul, Region oder Funktion
2. 02Mehr Raum für Kurskorrekturen zwischen den Wellen
3. 03Längere Supportkosten, mehr Integration zu pflegen
4. 04Verlangt dauerhafte Disziplin und Governance

Big Bang

Ich war einmal an einem SAP-Go-live eines Fertigungsunternehmens beteiligt, bei dem alles an einem einzigen Wochenende umgestellt wurde. Finanzwesen, Einkauf, Vertrieb und Fertigung gingen am Montagmorgen gemeinsam live. Es war intensiv, aber die Klarheit war enorm. Alle bewegten sich gemeinsam, ohne Verwirrung darüber, welchem System oder welchen Daten man trauen sollte.

Was es zum Erfolg machte: Das Team probte die Umstellung mehrfach, bereinigte die Daten Wochen im Voraus und schulte die Anwender an echten Testfällen. Der Vorteil sind schnellere Abstimmung und schnellerer Nutzen. Der Nachteil: Es gibt keinen Spielraum für Fehler. Als am ersten Tag ein Preisproblem die Kundenaufträge traf, traf es jede Region.

Funktioniert, wenn: die Prozesse standardisiert sind, die Teams vorbereitet sind und die Führung beim Umfang hart bleibt.

Phasenweise

In einem anderen Projekt, bei einer Einzelhandelskette, gingen wir phasenweise vor: zuerst Finanzwesen, Personal und Einkauf, dann Logistik und Kassensysteme. Es dauerte über ein Jahr, aber es verschaffte den Teams Luft. Das Personalteam verbrachte seinen ersten Monat damit, die Abläufe auszuarbeiten, bevor es alle anderen schulte. In einem Big Bang wäre das nicht möglich gewesen.

Der Preis dafür ist eine längere Supportphase, und Daten, die zwischen bereits produktiven und noch nicht produktiven Systemen fließen, brauchen besondere Sorgfalt.

Funktioniert, wenn: die Organisation groß oder verteilt ist, die Prozesse sich je nach Region unterscheiden oder die Führung Raum für Kurskorrekturen will.

Hybrid

Manchmal lautet die Antwort: beides.

Ein Distributor für Unterhaltungselektronik in Großbritannien, mit dem ich gearbeitet habe, musste Finanzwesen und Einkauf schnell live bringen. Sein Lager war wegen zu vieler Abhängigkeiten nicht bereit. Also gingen Finanzwesen und Einkauf zuerst, Logistik und Lagerverwaltung folgten. Big Bang in einem Bereich, phasenweise in einem anderen.

Hybrid erzeugt zusätzlichen Koordinationsaufwand. Wenn der Einkauf in SAP ist und der Vertrieb nicht, muss der Datenabgleich zwischen beiden sorgfältig gestaltet werden, und die Governance muss die ganze Zeit wachsam bleiben.

Funktioniert, wenn: Geschäftsbereiche sich unterschiedlich schnell bewegen, einige Abteilungen schneller umstellen müssen oder saisonale Spitzen bestimmte Go-live-Termine ausschließen.

So schneiden die drei im Vergleich ab:

Kriterium	Big Bang	Phasenweise	Hybrid
Zeitplan	Am kürzesten: alles auf einmal	Länger: über Wellen verteilt	Mittel: einige Bereiche schnell, andere langsamer
Störung des Geschäfts	Hoch, wenn der Go-live Probleme hat	Geringer: Veränderung kommt schrittweise	Hoch für die erste Welle, danach geringer
Risiko	Probleme treffen das ganze Unternehmen	Probleme bleiben innerhalb einer Phase	Konzentriert in den Big-Bang-Teilen
Kosten	Anfangs geringer, Fehler sind teuer	Insgesamt höher, weniger Notfälle	Dazwischen; die Koordination ist der Unsicherheitsfaktor
Datenmigration	Ein Zeitfenster; muss vollständig sein	Aufgeteilte Ladevorgänge, weniger pro Phase	Die Schnittstellen zwischen produktiven und noch nicht produktiven Systemen sind der schwierige Teil
Akzeptanz der Anwender	Schwer: Veränderung über Nacht	Leichter: schrittweise Gewöhnung	Die erste Welle sind Pioniere; spätere Wellen lernen von ihnen
Am besten geeignet	Kleinere Organisationen, Standardprozesse, hohe Bereitschaft	Große, verteilte Unternehmen mit unterschiedlichen Prozessen	Organisationen mit mehreren Einheiten, von denen einige bereit sind und andere nicht

Decide

Welcher Migrationspfad passt zu Ihrer Situation?

→Greenfield

Altsysteme sind zersplittert und Sie wollen Prozesse neu gestalten

→Brownfield

Prozesse sind solide, ECC ist stabil, die Historie muss bleiben

→Bluefield

Mehrere Gesellschaften, teilweise Wiederverwendung und selektive Daten gewünscht

Greenfield: neu anfangen

Ich habe diesen Ansatz in einem Projekt für ein Handelsunternehmen erlebt, das durch Übernahmen schnell gewachsen war und dessen Systeme zersplittert waren. Wir starteten sauber und gestalteten einheitliche Prozesse auf S/4HANA. Teams, die an ihre eigenen Wege gewöhnt waren, wehrten sich anfangs. Das Ergebnis waren mehr Einheitlichkeit über die Regionen hinweg, saubereres Reporting und Systeme, die miteinander sprachen.

Einsetzen, wenn: die Altsysteme zu zersplittert oder zu stark angepasst sind, um sauber migriert zu werden, und das Unternehmen neu denken will, wie es arbeitet, statt alte Gewohnheiten zu digitalisieren.

Brownfield: konvertieren und upgraden

In einem meiner früheren Projekte, bei einem Fertigungsunternehmen, war Brownfield die richtige Entscheidung. Der Kunde hatte sein ECC-System stark angepasst, und ein Neuanfang erschien zu riskant. Wir konzentrierten uns auf die technische Konvertierung zu S/4HANA. Die Anwender gewöhnten sich schneller ein, und wir gingen früher live, aber wir schleppten umständliche Abläufe mit, die hätten neu gestaltet werden sollen.

Einsetzen, wenn: die bestehenden Prozesse solide und dokumentiert sind, die Bewegungshistorie für Prüfung oder Compliance zählt, Budget oder Zeit knapp sind und die Organisation sich nicht umstrukturiert.

Bluefield: selektiver Übergang

Bluefield (selektive Datenübernahme) überträgt bestimmte Buchungskreise, Geschäftsbereiche oder Zeiträume statt aller Daten. Es passt zu Unternehmen, die von Fusionen oder Abspaltungen geprägt sind, oder zu Systemen mit jahrelangen Daten, die niemand braucht. Sie erhalten Prozessfreiheit wie bei Greenfield und Kontinuität wie bei Brownfield für die Teile, die Sie behalten wollen. Mein Leitfaden zur Migration von ECC auf S/4HANA geht tiefer auf die drei Pfade und ihre Zeitpläne ein.

2018 waren Rollout-Muster und Migrationspfad die ganze Strategie. 2026 gibt es eine dritte Entscheidung, und sie begrenzt die beiden anderen: welche Edition von S/4HANA Sie betreiben und wie Sie sie kaufen.

1. 03Rollout-MusterBig Bang, phasenweise oder hybrid, je nachdem, wie viel Störung Sie verkraften können
2. 02MigrationspfadGreenfield, Brownfield oder Bluefield, im Rahmen dessen, was die Edition unterstützt
3. 01BereitstellungsmodellPublic Edition, Private Edition oder On-Premise. Entscheiden Sie das zuerst

S/4HANA Cloud Public Edition (meist über GROW with SAP gekauft und von SAP als SAP Cloud ERP vermarktet). Mandantenfähiges SaaS, SAP-Standardprozesse, Upgrades alle sechs Monate, keine Modifikation des Kerns. Nur Greenfield. Am schnellsten zum Nutzen, am wenigsten flexibel. Am besten für mittelgroße Unternehmen, die bereit sind, den SAP-Standard zu übernehmen. Wenn Ihre Prozesse deutlich abweichen müssen, ist es die falsche Antwort.

S/4HANA Cloud Private Edition (meist über RISE with SAP gekauft). Single-Tenant, von SAP betriebene Infrastruktur, alle zwei Jahre ein neues Release mit sieben Jahren Mainstream-Wartung und mehr Spielraum für Konfiguration und Erweiterung. Unterstützt Brownfield, Greenfield und selektive Übergänge. Der Standard für die meisten Programme in Großunternehmen.

S/4HANA On-Premise. Sie oder Ihr Hyperscaler betreiben die Infrastruktur. Die meiste Erweiterbarkeit und Kontrolle, der langsamste Upgrade-Rhythmus. Clean Core wird empfohlen, aber nicht erzwungen. Passt zu strengen Vorgaben zur Datenresidenz und zu Organisationen mit starken internen Basis-Teams. Neue SAP-Funktionen erreichen zunehmend zuerst die Cloud-Editionen.

Rollout-Muster und Migrationspfad liegen dann innerhalb der gewählten Edition. Ein Public-Edition-Projekt ist per Definition Greenfield. Ein Private-Edition-Programm, das ein stark angepasstes ECC-System konvertiert, ist meist Brownfield oder Bluefield und in großem Maßstab meist phasenweise. Zur kommerziellen Seite von RISE und GROW lesen Sie meine Seiten zu GROW with SAP und RISE with SAP.

Es war ein Donnerstagmorgen, mitten in einem Design-Workshop. Der IT-Leiter hatte gerade den SAP-Standardprozess Order-to-Cash vorgeführt. Jemand aus dem Vertrieb sagte: „Ja, aber so machen wir das nicht.“ Im Raum wurde es still. Dieser Moment kommt in fast jedem Projekt.

Fit-to-Standard

Wer beim SAP-Standard bleibt, verkürzt die Einführungszeit und senkt den langfristigen Wartungsaufwand. Upgrades können keine Eigenlogik beschädigen, die es nicht gibt. In einem Einzelhandelsprojekt, an dem ich gearbeitet habe, half Fit-to-Standard dem Kunden, in weniger als sechs Monaten live zu gehen: weniger bewegliche Teile, weniger Hin und Her, ein saubereres System für künftige Upgrades.

Faustregel: Passen Sie nur an, wenn Regulierung es verlangt oder der Prozess Ihnen einen echten Wettbewerbsvorteil verschafft. Niemals, weil „wir das schon immer so gemacht haben“.

Clean Core in der Praxis

Fragen Sie jeden Partner nach Beispielen für Erweiterungen, die er auf freigegebenen APIs oder auf SAP BTP gebaut hat. Ist die Antwort vage, werten Sie das als Warnsignal. Partner, die On-Premise-Gewohnheiten in ein Cloud-Programm mitbringen, häufen ab dem ersten Sprint technische Schulden an.

Wenn Code unvermeidbar ist

Etwas Eigenentwicklung ist notwendig. AI-Werkzeuge wie SAP Build Code und Joule für Entwickler senken die Kosten, ihn zu schreiben. Sie senken nicht die Kosten, ihn zu pflegen.

Eigenlogik, die niemand dokumentiert hat, wird zu Logik, die niemand anfassen will, und das verzögert jede spätere Änderung. Kein AI-Werkzeug löst das. Dokumentationsdisziplin schon. Wenn Sie anpassen müssen, dokumentieren Sie es von Anfang an, bauen Sie es auf freigegebenen APIs oder BTP und halten Sie es vom Kern getrennt. Saubere Anpassung hat echte Kosten, die Sie wieder hereinholen können. Unsaubere Anpassung hat Kosten, die Sie immer weiter bezahlen.

Das sind die Spannen der gesamten Programmkosten, die ich 2026 für S/4HANA sehe. Unternehmensgröße und Umfang bestimmen die Zahl weit stärker als die Strategie. Nutzen Sie sie als Anker für die Budgetplanung, nicht als Angebote, und die vollständige Aufschlüsselung finden Sie in meinen Kostenspannen für SAP-Einführungen 2026.

Unternehmensgröße	Typische gesamte Programmkosten
Klein (unter 200 Beschäftigte)	80.000 bis 500.000 US-Dollar
Mittelstand (200 bis 1.000 Beschäftigte)	500.000 bis 2 Mio. US-Dollar
Großunternehmen (1.000 bis 10.000 Beschäftigte)	2 bis über 10 Mio. US-Dollar
Globaler Konzern (über 10.000 Beschäftigte)	10 bis über 50 Mio. US-Dollar

Die Strategie verschiebt Sie innerhalb einer Spanne, nicht über Spannen hinweg. Greenfield kostet anfangs mehr als Brownfield, und Big Bang tauscht geringere Anfangskosten gegen ein höheres Risiko am ersten Tag. Halten Sie zusätzlich 10 bis 20 Prozent Reserve vor und rechnen Sie damit, dass Implementierungsleistungen 35 bis 50 Prozent der Gesamtsumme ausmachen.

Das Bereitstellungsmodell ist die Kostenvariable, die am häufigsten unterschätzt wird. RISE- und GROW-Abonnements sind nicht günstiger als On-Premise-Lizenzen, sobald man die mehrjährige Bindung zusammenrechnet. Ihr Wert liegt in der verlagerten Verantwortung für die Infrastruktur, im schnelleren Nutzen und in planbaren Abonnementkosten. Das Argument für RISE oder GROW sind selten die Gesamtkosten. Es ist das Betriebsmodell.

Dieser Leitfaden gehört zu meinem Überblick zur SAP-Einführung, der alle Themen vom Business Case bis zum Go-live verlinkt.

Was ist eine SAP-Einführungsstrategie?

Es ist der Ansatz, mit dem ein Unternehmen SAP einführt: Umfang, Methode, Bereitstellungsmodell, Migrationspfad, Rollout-Muster und Zeitplan. Die wichtigsten Entscheidungen 2026 sind das Bereitstellungsmodell (Public Edition, Private Edition oder On-Premise), der Migrationspfad (Greenfield, Brownfield oder Bluefield) und das Rollout-Muster (Big Bang, phasenweise oder hybrid).

Entscheidend ist, ob die Kombination zur Bereitschaft der Organisation, zur Komplexität ihrer Prozesse, zu ihrem regulatorischen Profil und zu ihrer Toleranz für Störungen passt.

Wann funktioniert eine Big-Bang-Einführung?

Wenn die Prozesse bereits standardisiert sind, die Anwender gut geschult sind, die Daten vor der Migration bereinigt wurden und die Führung den Umfang hält. Fehlt auch nur eines davon, vor allem saubere Daten und die Bereitschaft der Anwender, ist es ein Glücksspiel.

Probleme beim Go-live treffen alles auf einmal. Mit Vorbereitung ist das beherrschbar. Ohne sie ist es eine Krise.

Was ist der Unterschied zwischen einer Greenfield- und einer Brownfield-Einführung von SAP?

Greenfield beginnt mit einem neuen System, ohne übernommene Altkonfiguration. Sie gestalten die Prozesse von Grund auf rund um den SAP-Standard. Brownfield konvertiert das bestehende System und behält Bewegungshistorie und Konfiguration.

Greenfield kostet anfangs mehr und ergibt ein saubereres, zukunftsfähigeres System. Brownfield ist schneller und weniger störend, schleppt aber Workarounds und Eigencode mit. Bluefield ist der Mittelweg: die selektive Migration der Gesellschaften und Daten, die Sie auswählen.

Was ist der Unterschied zwischen RISE with SAP und GROW with SAP?

RISE with SAP ist das Abonnementangebot von SAP für Großunternehmen, meist auf Basis von S/4HANA Cloud Private Edition, mit von SAP betriebener Infrastruktur und technischem Betrieb in einem Vertrag. Ich sehe typischerweise gesamte Programme von 2 bis über 10 Mio. US-Dollar für ein Großunternehmen und von 10 bis über 50 Mio. US-Dollar für einen globalen Konzern, einschließlich Umsetzung, über 9 bis 18 Monate.

GROW with SAP richtet sich an mittelgroße Unternehmen und läuft auf S/4HANA Cloud Public Edition mit den SAP-Standardprozessen. Für ein mittelgroßes Unternehmen sehe ich typischerweise 500.000 bis 2 Mio. US-Dollar einschließlich Umsetzung, über etwa 6 bis 9 Monate.

Die Unternehmensgröße und wie weit Ihre Prozesse vom SAP-Standard abweichen müssen, entscheiden zwischen beiden.

Was bedeutet Fit-to-Standard bei SAP und warum ist es heute wichtiger?

Fit-to-Standard heißt, Ihre Prozesse an die Standardfunktionen von SAP anzupassen, statt SAP an Ihre heutige Arbeitsweise anzupassen. Das verkürzt die Einführung, senkt die Wartung und macht Upgrades sauberer.

Heute ist es wegen Clean Core wichtiger. In der Public Edition ist eine Modifikation des Kerns überhaupt nicht möglich. In der Private Edition und On-Premise bedeutet jede Modifikation zusätzlichen Upgrade-Aufwand. Die Frage lautet, ob es einen echten geschäftlichen Grund gibt, den der SAP-Standard nicht abdecken kann, und falls ja, ob Ihr Partner die Erweiterung auf freigegebenen APIs oder SAP BTP bauen kann.

Welche Phasen hat die SAP-Activate-Methodik?

SAP Activate hat sechs Phasen. Discover (das SAP-Angebot und den Business Case erkunden), dann vier Kernphasen der Umsetzung: Prepare (planen, steuern, das Team aufstellen), Explore (Fit-to-Standard-Workshops und das Backlog), Realize (konfigurieren, erweitern, in Sprints testen) und Deploy (Umstellung, Go-live und Hypercare). Run umfasst den Betrieb nach dem Go-live.

In Realize verlieren die meisten Projekte Zeit, besonders wenn Probleme mit der Datenqualität im Test auftauchen oder der Umfang der Anpassungen wächst. Eine straffe Umfangsbasis während Realize trennt Projekte, die pünktlich live gehen, von denen, die abdriften.

Warum scheitern SAP-Einführungen?

Vier Ursachen erklären die meisten Fehlschläge: ein Engagement der Geschäftsleitung, das nach dem Kick-off verschwindet, eine Datenmigration, die als IT-Aufgabe behandelt wird, ein Change Management, das sich auf Schulungshandbücher beschränkt, und Partner ohne Clean-Core-Erfahrung, die technische Schulden erzeugen, die beim ersten Upgrade sichtbar werden.

Die Technologie versagt selten. Programme scheitern, wenn Entscheidungen nicht getroffen werden, schmutzige Daten ins neue System gelangen, Anwender Workarounds finden oder Anpassungen neu gebaut werden müssen. Die Strategie zählt. Die Disziplin in der Umsetzung zählt mehr.