Beratung für SAP-Landschaften und S/4HANA-Programme

SAP-Beratung: tragfähige Entscheidungen für eine gewachsene Systemlandschaft

SAP-Beratung arbeitet an einer einzigen, immer wiederkehrenden Frage: An welchem Ort im System wird eine betriebliche Anforderung gelöst — im Standard, in einer freigegebenen Erweiterung außerhalb des Kerns oder in eigenem Code mitten im Kern? Diese Ortswahl ist die eigentliche Entscheidung. Sie bestimmt, was das nächste Release kostet, wie schnell ein Prozess geändert werden kann und wie viel Wissen an einzelnen Personen hängt. Wichtig wird das Thema, sobald das Kernsystem älter ist als die Prozesse, die darauf laufen: wenn der Umstieg nach S/4HANA ansteht, wenn Gesellschaften zusammengeführt oder herausgelöst werden, wenn Schnittstellen und Eigenentwicklungen jede Anpassung teuer machen. Gebraucht wird dafür weniger Methodik als Erfahrung mit genau dieser Konstellation: Prozesskenntnis im jeweiligen Modul, ein Blick für die Integrationslage und die Fähigkeit, eine Architekturentscheidung so zu begründen, dass sie zwei Releases später noch trägt.

Architekturfrage klären Arbeitsgebiete ansehen

Gespräch über eine SAP-Systementscheidung in einem Bürohochhaus

Führende Unternehmen vertrauen auf unser Netzwerk

Reichweite und Zuständigkeit

Was SAP-Beratung leistet — und was nicht

Auswertung einer gewachsenen SAP-Landschaft als Grundlage der Ortswahl

SAP-Beratung übersetzt fachliche Anforderungen in Systementscheidungen und macht deren Folgekosten sichtbar, bevor sie entstehen. Der Kern der Arbeit ist die Ortswahl: Jede Anforderung wird an genau einem von drei Orten gelöst — im Standard, in einer freigegebenen Erweiterung außerhalb des Kerns oder in eigenem Code im Kern. Der Standard ist billig im Betrieb und unbequem im Detail. Die Erweiterung kostet Aufbau und bleibt beim Release unangetastet. Eigener Code im Kern passt sofort und wird bei jedem Upgrade erneut bezahlt. Wer diese Wahl nicht bewusst trifft, trifft sie trotzdem — nur später und teurer.

Dazu gehört die Bestandsaufnahme dessen, was tatsächlich läuft: welche Module im Einsatz sind, welche Eigenentwicklungen noch benutzt werden, welche Schnittstellen ohne Dokumentation Daten transportieren. Und die Einordnung des Zielbilds: Welcher Umstiegspfad passt zu einer Landschaft, in der drei Gesellschaften unterschiedliche Kontenpläne führen? Was muss vor dem Umstieg entschieden sein, was kann danach kommen?

Was sie nicht leistet. Sie beantwortet nicht die Frage, ob SAP die richtige Software für Ihr Geschäftsmodell ist — das ist eine Frage vor der SAP-Beratung, nicht in ihr. Sie ersetzt keine eigene Systemverantwortung: Wer die Zielarchitektur nicht im Haus vertreten kann, verliert sie beim ersten Zielkonflikt zwischen Fachbereich und Budget. Und sie liefert keine Garantie auf Termine, die von Datenqualität, Testkapazität und Entscheidungsgeschwindigkeit im Unternehmen abhängen.

Auslöser

Wann externe SAP-Unterstützung den Aufwand wert ist

Nicht jede SAP-Aufgabe braucht Hilfe von außen. Läuft das System stabil, ist das Modulwissen im Team verteilt und der Änderungsstau überschaubar, ist der interne Weg der bessere. In den folgenden Auslösern kippt die Rechnung — aus einem strukturellen Grund: Ein internes SAP-Team erlebt einen Releasewechsel oder einen Umstieg einmal, während jemand mit zwanzig Projekten im Rücken die Sackgassen schon kennt. Externe Erfahrung ersetzt hier keine Kapazität, sondern verkürzt Entscheidungswege.

1. Das Wartungsende rückt näher, der Zielentwurf fehlt

Die Frist für die klassische Business Suite ist gesetzt, ein Beschluss über Umstiegspfad und Umfang liegt aber nicht vor.
Ohne Zielentwurf wird der Umstieg zum Nachbau des Alten — mit neuen Lizenzkosten und ohne einen einzigen einfacheren Prozess.
Die Reihenfolge ist entscheidend: erst die Ortswahl je Anforderung, dann der technische Weg.

2. Eigenentwicklungen blockieren jedes Release

Anpassungen im Kern sind über Jahre gewachsen, ein Teil davon wird nicht mehr benutzt und niemand traut sich, sie abzuschalten.
Jeder Releasewechsel wird zum Testmarathon, weil unklar ist, welche Erweiterung von welchem Prozess abhängt.
Eine Nutzungs- und Abhängigkeitsanalyse ist Handwerk und trennt Verzichtbares von Geschäftskritischem.

3. Eine Gesellschaft kommt hinzu oder wird herausgelöst

Nach Zukauf oder Verkauf müssen Mandanten, Kontenpläne, Stammdaten und Berechtigungen zusammengeführt oder getrennt werden.
Der Termin ist von außen gesetzt, meist vertraglich, und lässt keine Lernkurve zu.
Wer eine Systemtrennung schon einmal geführt hat, kennt die Reihenfolge, in der Abhängigkeiten fallen.

4. Die Schnittstellenlandschaft ist gewachsen, niemand kennt sie vollständig

Zwischen SAP und den Umsystemen liegen historische Punkt-zu-Punkt-Verbindungen, teils ohne Fehlerbehandlung.
Störungen zeigen sich zuerst im Geschäft — als fehlende Lieferung oder als Buchung, die niemand erklären kann.
Eine belastbare Übersicht der Datenflüsse ist die Voraussetzung dafür, den Kern überhaupt anfassen zu können.

5. Das Modulwissen hängt an einer einzelnen Person

Eine Kündigung, ein Ruhestand oder eine längere Abwesenheit macht ein Modul von einem Tag auf den anderen zur Blackbox.
Der Betrieb läuft weiter, jede Änderung aber wird zum Risiko, weil die Begründung hinter den Einstellungen fehlt.
Externe Fachtiefe hält das Modul am Laufen und dokumentiert dabei, was vorher nur mündlich existierte.

6. Berechtigungen und Nachweise halten einer Prüfung nicht stand

Rollen sind über Jahre gewachsen, kritische Kombinationen entstehen unbeabsichtigt, der Nachweis fehlt.
Wirtschaftsprüfung, interne Revision oder eine Zertifizierung machen daraus einen Termin mit Frist.
Ein Berechtigungskonzept ist fachliche Arbeit an Zuständigkeiten, kein technisches Aufräumen.

Erkennen Sie einen dieser Auslöser wieder? Eine erste Einordnung braucht zwanzig Minuten: welche Frage in Ihrer Landschaft zuerst entschieden werden muss, welches Profil dafür passt — und ob es dafür überhaupt jemanden von außen braucht.

Systemstand prüfen lassen

Arbeitsgebiete

Die Arbeitsgebiete der SAP-Beratung im Überblick

Die Arbeitsgebiete greifen ineinander, werden aber selten gleichzeitig beauftragt. Meist beginnt es mit einem konkreten Anlass — einem anstehenden Umstieg, einer Störung in der Integration, einem Modul ohne Betreuung — und der Zuschnitt ergibt sich daraus, welche Entscheidungen noch offen sind. Die folgende Übersicht ordnet die Felder danach, wie weit sie vom Kern des Systems entfernt liegen.

Zielbild und Systemarchitektur

Der Systemschnitt und die Frage, wo welche Anforderung gelöst wird: ein Mandant oder mehrere, welche Prozesse im Kern bleiben, welche Erweiterungen außerhalb entstehen. Dazu die Entscheidungen, die vor jedem technischen Schritt fallen müssen — Kontenplan, Organisationsstruktur, Stammdatenverantwortung.

Umstieg nach S/4HANA

Bewertung der Umstiegswege — Neuaufbau, Konvertierung des Bestands oder ein selektiver Weg je Gesellschaft — anhand von Datenqualität, Eigenentwicklungsbestand und Terminlage. Ergebnis ist ein Pfad mit benannten Voraussetzungen, kein Werkzeugvergleich.

Prozesse in den Kernmodulen

Fachliche Arbeit in Finanzwesen und Controlling, Materialwirtschaft und Vertrieb, Produktion und Lagerlogistik: Welche Einstellung erzeugt welches Verhalten, welche Abweichung vom Standard ist begründet und welche ist nur historisch.

Integration, Schnittstellen und Datenflüsse

Die Verbindung zwischen SAP und allem daneben: Middleware und Integrationsdienste, Fehlerbehandlung und Wiederanlauf, Verantwortung für Datenhoheit. Hier entscheidet sich, ob eine Landschaft änderbar bleibt oder in Abhängigkeiten erstarrt.

Eigenentwicklung, Erweiterungen und ein schlanker Kern

Bestand an Anpassungen erheben, Nutzung messen, Ablösung planen: Was verschwindet im Standard, was wandert in eine Erweiterung außerhalb des Kerns, was bleibt bewusst als eigener Code — mit Begründung und benanntem Eigentümer.

Betrieb, Berechtigungen und Systemhygiene

Rollen- und Berechtigungskonzepte mit prüffähiger Dokumentation, Transportwesen und Freigabewege, Systemüberwachung und Performance. Der Teil, der selten ein Projekt ist und über Jahre den Unterschied zwischen ruhigem und unruhigem Betrieb macht.

Welches Arbeitsgebiet bei Ihnen zuerst zählt, hängt an der Ausgangslage — das lässt sich in einem kurzen Gespräch klären.

Zielbild schärfen

Einsatzformen

Wie externe SAP-Kompetenz in ein Systemumfeld eingebunden wird

Im SAP-Umfeld entscheidet neben der Fachtiefe vor allem die Zuständigkeit: Wer darf eine Architekturentscheidung treffen, wer setzt sie um, wer verantwortet sie danach im Betrieb? Danach richtet sich die Einsatzform. Alle vier funktionieren nur, wenn die Systemverantwortung im Haus bleibt — externe Kompetenz begründet und baut, sie entscheidet nicht an Ihrer Stelle.

Einsatzform festlegen

Zweitmeinung

Prüfung einer Architekturentscheidung

Eine erfahrene Fachperson prüft einen bereits gefassten Entwurf gegen die eigene Projekterfahrung: Ortswahl je Anforderung, Systemschnitt, Annahmen zur Datenqualität. Der Auftrag ist eng gefasst und endet mit einer begründeten Empfehlung, nicht mit einer Umsetzung.

Modultiefe

Fachliche Verstärkung in einem Teilprojekt

Eine bis wenige Fachleute arbeiten in Ihrem Projektteam an einem klar abgegrenzten Ausschnitt — ein Modul, eine Integrationsstrecke, ein Berechtigungskonzept. Die Steuerung bleibt bei Ihnen, das Wissen wandert während der Arbeit ins Team.

Vakanzüberbrückung

SAP-Verantwortung auf Zeit

Eine externe Person übernimmt Leitungs- oder Modulverantwortung, solange die Stelle unbesetzt ist oder eine Doppelbelastung sonst nicht tragbar wäre. Sie führt den laufenden Betrieb und hält offene Entscheidungen in Bewegung, statt sie zu vertagen.

Programmbegleitung

Begleitung eines mehrjährigen Umstiegs

Eine kleine Einheit über mehreren Teilprojekten und Gesellschaften: Abhängigkeiten sichtbar halten, Entscheidungen vorbereiten, Abweichungen früh melden. Sinnvoll erst ab einer Größe, in der niemand mehr alle Stränge nebenbei überblickt.

Systemumfelder

SAP in verschiedenen Branchen: wo das Kernsystem den Takt vorgibt

Eine SAP-Landschaft lässt sich nicht branchenneutral bewerten, weil die Branche entscheidet, welcher Prozess im Kern liegen muss und welcher daneben liegen darf. In einer Serienfertigung ist die Planung das Herzstück und jede Abweichung im Materialfluss schlägt binnen Stunden auf die Linie durch. Im Projektgeschäft trägt die Kalkulation über Jahre und muss Nachträge, Teilabrechnungen und Gewährleistung abbilden. In der Prozessindustrie sind Chargenverfolgung und Rückverfolgbarkeit keine Zusatzfunktion, sondern Zulassungsvoraussetzung. Im Handel bestimmen Sortimentswechsel und Aktionslogik das Tempo, im Logistikgeschäft die Lagersteuerung und in der Versorgungswirtschaft die regulierte Abrechnung mit ihren eigenen Fristen.

Deshalb besetzen wir nach Branchenerfahrung und nicht nur nach Modulkenntnis: Wer Chargenpflicht, Nachtragswesen oder Netzabrechnung schon einmal im Standard abgebildet hat, erkennt in der Anforderung den Sonderfall — und weiß, wo der Standard genau dafür eine Antwort hat und wo tatsächlich eine Erweiterung nötig ist. Die folgenden sechs Umfelder fragen unsere Kunden am häufigsten an; sie sind ein Ausschnitt und keine Aufzählung dessen, was wir besetzen können.

Initiativen

SAP-Initiativen und was sie jeweils entscheiden

Was im SAP-Umfeld beauftragt wird, fällt größtenteils in wenige Muster. Sie unterscheiden sich weniger im Aufwand als in der Frage, was am Ende entschieden ist. Die folgenden vier sind Beispiele, keine abschließende Liste — und sie treten häufig hintereinander auf.

Umstieg nach S/4HANA

Ausgangslage: Die Wartungsfrist ist gesetzt, der Weg nicht. Entschieden wird der Umstiegspfad je Gesellschaft, der Umfang der Prozessarbeit und was bewusst entfällt. Woran der Erfolg hängt: dass die Ortswahl je Anforderung vor dem ersten technischen Schritt steht.

Ablösung von Eigenentwicklungen

Ausgangslage: Angepasster Code im Kern verteuert jedes Release, ein Teil davon wird nicht mehr benutzt. Entschieden wird je Anpassung: Standard, Erweiterung außerhalb des Kerns oder bewusster Verbleib. Woran der Erfolg hängt: an einer Nutzungsmessung, die niemand mehr bestreitet.

Trennung oder Zusammenführung von Gesellschaften

Ausgangslage: Ein Zukauf oder Verkauf setzt einen vertraglichen Termin. Entschieden wird die Mandantenstruktur, die Behandlung von Stammdaten und Historie sowie der Schnitt der Berechtigungen. Woran der Erfolg hängt: an einer Reihenfolge, die die Abhängigkeiten kennt.

Erneuerung der Integrationsschicht

Ausgangslage: Historische Punkt-zu-Punkt-Verbindungen ohne Fehlerbehandlung, Störungen fallen im Geschäft auf. Entschieden wird, welche Datenflüsse über einen Integrationsdienst laufen und wer die Datenhoheit trägt. Woran der Erfolg hängt: an Wiederanlauf und Überwachung, nicht am Werkzeug.

Die Stationen eines SAP-Programms

Umfang und Reihenfolge unterscheiden sich je nach Ausgangslage, Zahl der Gesellschaften und Eigenentwicklungsbestand. Die Stationen selbst wiederholen sich jedoch; wer eine davon überspringt, holt sie später unter Termindruck nach.

Systeminventar und Schnittstellen werden für eine SAP-Bestandsaufnahme zusammengeführt

1. Bestand aufnehmen

Module, Mandanten, Eigenentwicklungen und Schnittstellen erheben — inklusive Messung, was davon tatsächlich benutzt wird.

Datenqualität dort prüfen, wo sie den Umstieg bremst: Stammdaten, offene Posten, Historie.

Ergebnis ist eine Bestandsliste, über die Fachbereich und IT nicht mehr streiten.

Technische Abstimmung im Team über das Zielbild einer SAP-Landschaft

2. Zielbild und Ortswahl festlegen

Je Anforderung wird der Ort bestimmt: Standard, Erweiterung außerhalb des Kerns oder eigener Code im Kern.

Organisationsstruktur, Kontenplan und Stammdatenverantwortung werden vorab entschieden, nicht im Projekt.

Was bewusst nicht mitgenommen wird, steht mit Begründung auf der Liste.

Führungsrunde entscheidet über den Umstiegspfad einer SAP-Landschaft

3. Umstiegspfad wählen

Neuaufbau, Konvertierung des Bestands oder ein selektiver Weg je Gesellschaft — bewertet an Datenlage und Terminen.

Die Umschaltreihenfolge wird an Abhängigkeiten festgemacht, nicht an Wunschterminen.

Der Pfad benennt Voraussetzungen, die vor dem Start erfüllt sein müssen.

Testlauf eines angepassten Prozesses im SAP-System

4. Umsetzen und testen

Prozesse einstellen, Erweiterungen bauen, Schnittstellen anbinden — in kleinen, abnehmbaren Schnitten.

Testen mit echten Daten und echten Mengen; Fachbereiche nehmen ab, nicht die Projektleitung.

Jede Abweichung vom Standard wird im Moment ihrer Entstehung begründet und dokumentiert.

Freigabe des Systemwechsels vor dem Produktivstart

5. In den Betrieb übergeben

Datenübernahme, Berechtigungen, Freigabewege und Notfallplan stehen vor dem Umschalten fest.

Anwenderinnen und Anwender werden an ihren eigenen Vorgängen geschult, nicht an Musterfällen.

Der Betrieb übernimmt mit benannten Zuständigkeiten je Modul und Schnittstelle.

Nachmessung der Systemleistung nach Abschluss des Umstiegs

6. Stabilisieren und messen

Störungen werden nach Ursache sortiert: Einstellung, Daten, Erweiterung oder Bedienung.

Gemessen wird gegen die vor dem Start festgehaltene Basis — Durchlaufzeiten, Abschlussdauer, Fehlerquoten.

Der Übergabepunkt steht von Anfang an fest: danach führt Ihre Organisation das System weiter.

Kostenrahmen

Was SAP-Beratung kostet: Tagessatzspannen und Budgetrahmen

Externe SAP-Kompetenz rechnen wir nach Tagessatz ab. Er bewegt sich entlang von fünf Größen: Seniorität und Zahl der begleiteten Umstiege, Modul und Spezialisierung (Architektur, Integration und Berechtigungen liegen über dem Mittel), Präsenzanteil vor Ort, Laufzeit des Mandats — längere Einsätze liegen pro Tag niedriger — und Verfügbarkeit im gesuchten Profil.

Die Spannen unseres Bestands im Fachbereich SAP & Enterprise Systems liegen aktuell zwischen 750 € und 1.650 € pro Tag. Die Kacheln darunter zeigen sie je Rolle, wie sie auch auf der jeweiligen Rollenseite ausgewiesen sind.

Freelance SAP Architect

1.050 – 1.650 € pro Tag
Freelance SAP FI/CO Consultant

960 – 1.500 € pro Tag
Freelance ServiceNow Solution Architect

950 – 1.500 € pro Tag
Freelance SAP BTP / Integration Consultant

950 – 1.500 € pro Tag
Freelance SAP Solution Architect

1.000 – 1.500 € pro Tag
Freelance SAP S/4HANA Consultant

1.000 – 1.500 € pro Tag
Freelance SAP MM/WM Berater

950 – 1.400 € pro Tag
Freelance SAP MM / SD Consultant

900 – 1.400 € pro Tag
Freelance SAP EWM Berater

900 – 1.300 € pro Tag
Freelance SAP CPI Berater

900 – 1.300 € pro Tag
Freelance SAP Ariba Berater

900 – 1.300 € pro Tag
Freelance ServiceNow Entwickler

850 – 1.300 € pro Tag
Freelance SAP Rollout Manager

850 – 1.250 € pro Tag
Freelance SAP Basis Administrator

850 – 1.250 € pro Tag
Freelance SAP Security Berater

850 – 1.200 € pro Tag
Freelance SAP PP Berater

850 – 1.200 € pro Tag
Freelance SAP Fiori Entwickler

800 – 1.150 € pro Tag
Freelance SAP SD Berater

800 – 1.100 € pro Tag
Freelance SAP ABAP Entwickler

750 – 1.050 € pro Tag

Jede Spanne steht so auch auf der zugehörigen Rollenseite, nicht auf Anfrage.

Wie sich ein SAP-Budget aufstellen lässt. Gerechnet wird in Personentagen je Station, nicht in einer Gesamtsumme. Eine Bestandsaufnahme mit Nutzungsmessung der Eigenentwicklungen bewegt sich bei einer mittelständischen Landschaft in einem überschaubaren zweistelligen Tagevolumen. Ein Zielbild mit Ortswahl je Anforderung ist eine Frage von Entscheidungsrunden, nicht von Aufwand. Der Umstieg selbst wird je Gesellschaft und Welle gerechnet, damit nach der ersten Welle entscheidbar bleibt, ob die zweite so weitergeführt wird. Verantwortung auf Zeit rechnet anders: feste Wochentage über die Dauer der Vakanz.

Aussagekräftig ist nicht der Tagessatz, sondern sein Verhältnis zu dem, was am System hängt. Wo ein Releasewechsel wegen ungeklärter Eigenentwicklungen regelmäßig Wochen an Testaufwand bindet, ist eine Ablösungsentscheidung binnen eines Jahres bezahlt. Wo ein Modul stabil läuft und niemand es ändern will, ist externe Unterstützung kein Gewinn — diese Antwort geben wir vor dem Angebot.

Der Unterschied zu einem Systemhaus oder einer Beratungsgesellschaft. Sie beauftragen einzelne Fachleute und nicht einen Apparat: keine Projektleitungsebene, die Sie mitbezahlen, kein Partneranteil, keine Sockelkosten für Methodik. Dafür bekommen Sie keine Gesamtverantwortung aus einer Hand — die fachliche Führung bleibt bei Ihnen. Festpreise auf Systemergebnisse bilden wir nicht ab: Sie setzen den Anreiz, den Umfang klein zu halten, statt die richtige Entscheidung zu treffen.

Welches Profil passt, hängt an der offenen Frage: Eine Architekturentscheidung verlangt andere Erfahrung als die Ablösung einer Eigenentwicklung im Kern. Die vollständige Übersicht steht unter SAP & Enterprise Systems — darunter Freelance SAP Architect, Freelance SAP S/4HANA Consultant, Freelance SAP Basis Administrator und Freelance SAP Rollout Manager. Die sechs Karten oben sind ein Ausschnitt aus zwanzig Rollen dieses Fachbereichs; angrenzend liegen IT-Beratung, Business-Intelligence-Beratung und Prozessberatung.

54 %

der befragten SAP-Anwenderunternehmen arbeiten noch mit SAP ECC oder der Business Suite — 2024 waren es 68 Prozent.

DSAG-Investitionsreport 2026, 198 Teilnehmende

2030

endet die erweiterte Wartung der Business Suite 7 — die reguläre Wartung läuft Ende 2027 aus, die Verlängerung kostet zwei Prozentpunkte Aufschlag.

SAP Business Suite 7, Wartungsfristen

28 %

rechnen mit einem sinkenden SAP-Budget — nach 19 Prozent in der Vorerhebung. Der Umstieg fällt damit in eine Phase engerer Mittel.

DSAG-Investitionsreport 2026, 198 Teilnehmende

SAP-Beratung unterstützt Unternehmen dabei, betriebliche Anforderungen in Systementscheidungen zu übersetzen und deren Folgekosten vorher sichtbar zu machen. Der Kern ist die Ortswahl: Jede Anforderung wird im Standard, in einer freigegebenen Erweiterung außerhalb des Kerns oder in eigenem Code im Kern gelöst. Dazu kommen Bestandsaufnahme der laufenden Landschaft, Bewertung von Umstiegswegen, fachliche Arbeit in den Modulen sowie Integration, Berechtigungen und Betrieb.

Allgemeine IT-Beratung fragt, welche Systeme ein Unternehmen braucht und wie sie zusammenspielen. SAP-Beratung setzt die Entscheidung für SAP voraus und arbeitet innerhalb dieser Landschaft: Modulverhalten, Standardumfang, Erweiterungsmodell, Releasefolgen. Wo die Systemwahl selbst noch offen ist, führt der Weg über die IT-Beratung; wo Prozesse unabhängig von der Software neu geschnitten werden, über die Prozessberatung.

Wir rechnen nach Tagessatz ab. Im Fachbereich SAP & Enterprise Systems liegen die Spannen unseres Bestands aktuell zwischen 750 € und 1.650 € pro Tag; die Kacheln im Kostenabschnitt zeigen sie je Rolle. Architektur-, Integrations- und Berechtigungsprofile liegen dabei am oberen Rand, Entwicklungsprofile darunter. Angesetzt wird in Personentagen je Station, nicht als Projektpauschale — so bleibt nach der ersten Station entscheidbar, ob die nächste den Aufwand rechtfertigt.

Von fünf Größen: Seniorität und Zahl der bereits begleiteten Umstiege; Modul und Spezialisierung, wobei Architektur, Integration und Berechtigungswesen über dem Mittel liegen; Präsenzanteil vor Ort, weil Reisezeit Verfügbarkeit kostet; Laufzeit des Mandats, da längere Einsätze pro Tag niedriger liegen; und die Verfügbarkeit im gesuchten Profil zum Zeitpunkt der Anfrage.

Für die letzten Erweiterungspakete der SAP Business Suite 7 endet die reguläre Wartung Ende 2027. Wer die erweiterte Wartung bucht, hat bis Ende 2030 Zeit und zahlt dafür zwei Prozentpunkte Aufschlag auf die Wartungsbasis. Danach bleibt kundenspezifische Wartung ohne neue rechtliche und funktionale Anpassungen. Ältere Versionsstände laufen früher aus — der maßgebliche Termin hängt also am eigenen Releasestand.

Dass Anpassungen nicht mehr im Kern des Systems liegen, sondern in Erweiterungen daneben, die über freigegebene Schnittstellen angebunden sind. Der Nutzen zeigt sich beim Releasewechsel: Was außerhalb liegt, muss nicht erneut geprüft werden. Der Preis ist Aufbauarbeit und eine Betriebsverantwortung mehr. In der Praxis geht es deshalb nicht um Reinheit, sondern um eine begründete Entscheidung je Anpassung — mit benanntem Eigentümer.

Ein Systemhaus übernimmt Gesamtverantwortung und bringt Kapazität in der Breite mit; das passt, wenn im Haus niemand die fachliche Führung übernehmen kann. Einzelne Fachleute passen, wenn die Führung intern liegt und punktuell Erfahrung fehlt — für eine Architekturentscheidung, ein Modul ohne Betreuung, eine Integrationsstrecke oder eine Vakanz. Der Unterschied liegt weniger im Tagessatz als in der Frage, wer am Ende die Entscheidung verantwortet.

An Kennzahlen, die vor dem Start festgehalten wurden: Durchlaufzeit der betroffenen Prozesse, Dauer des Monatsabschlusses, Fehlerquote in den Schnittstellen, Testaufwand beim nächsten Releasewechsel und Zahl der noch aktiven Anpassungen im Kern. Ohne diese Basis lässt sich hinterher nur die Einhaltung des Termins belegen — und das ist die schwächste aller Aussagen über ein Systemvorhaben.

Sie können sich auf uns verlassen

Ausgezeichnet. Finden nicht nur wir selbst.

consultingheads wurde mehrfach von führenden Fachmagazinen und unabhängigen Dritten ausgezeichnet.

Auszeichnung für consultingheads: F.A.Z. Institut TOP Berater 2026

Auszeichnung für consultingheads: kununu Top Company 2025

Auszeichnung für consultingheads: kununu Top Company 2024

Auszeichnung für consultingheads: kununu Top Company 2023

Erstgespräch

Bringen wir Ordnung in die Systemfrage.

Einordnung Ihrer Systemlandschaft in zwanzig Minuten

Eine benannte erste Entscheidung statt einer Methodenübersicht

Die Tagessatzspanne je Rolle steht offen auf der Seite

Zwanzig Minuten, in denen wir Ihre Ausgangslage einordnen und benennen, welche Entscheidung bei Ihnen zuerst fällig ist.

Termin vorschlagen lassen

SAP-Beratung: tragfähige Entscheidungen für eine gewachsene Systemlandschaft

Führende Unternehmen vertrauen auf unser Netzwerk

Was SAP-Beratung leistet — und was nicht

Wann externe SAP-Unterstützung den Aufwand wert ist

1. Das Wartungsende rückt näher, der Zielentwurf fehlt

2. Eigenentwicklungen blockieren jedes Release

3. Eine Gesellschaft kommt hinzu oder wird herausgelöst

4. Die Schnittstellenlandschaft ist gewachsen, niemand kennt sie vollständig

5. Das Modulwissen hängt an einer einzelnen Person

6. Berechtigungen und Nachweise halten einer Prüfung nicht stand

Die Arbeitsgebiete der SAP-Beratung im Überblick

Zielbild und Systemarchitektur

Umstieg nach S/4HANA

Prozesse in den Kernmodulen

Integration, Schnittstellen und Datenflüsse

Eigenentwicklung, Erweiterungen und ein schlanker Kern

Betrieb, Berechtigungen und Systemhygiene

Wie externe SAP-Kompetenz in ein Systemumfeld eingebunden wird

Prüfung einer Architekturentscheidung

Fachliche Verstärkung in einem Teilprojekt

SAP-Verantwortung auf Zeit

Begleitung eines mehrjährigen Umstiegs

SAP in verschiedenen Branchen: wo das Kernsystem den Takt vorgibt

Automotive & Zulieferindustrie

Maschinen- & Anlagenbau

Chemie & Pharma

Handel & Konsumgüter

Logistik & Transport

Energie & Versorger

Automotive & Zulieferindustrie

Maschinen- & Anlagenbau

Chemie & Pharma

Handel & Konsumgüter

Logistik & Transport

Energie & Versorger

SAP-Initiativen und was sie jeweils entscheiden

Umstieg nach S/4HANA

Ablösung von Eigenentwicklungen

Trennung oder Zusammenführung von Gesellschaften

Erneuerung der Integrationsschicht

Welche Rollenprofile ein SAP-Umfeld braucht

Die Stationen eines SAP-Programms

1. Bestand aufnehmen

2. Zielbild und Ortswahl festlegen

3. Umstiegspfad wählen

4. Umsetzen und testen

5. In den Betrieb übergeben

6. Stabilisieren und messen

Was SAP-Beratung kostet: Tagessatzspannen und Budgetrahmen

Der Umstieg drängt, die Budgets wachsen langsamer

54 %

2030

28 %

Häufige Fragen zur SAP-Beratung

Ausgezeichnet. Finden nicht nur wir selbst.

Bringen wir Ordnung in die Systemfrage.