SH

Sascha Hess xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

 

	Strategische Wissens-Roadmap 2026
	ERP Customizing
	Die teuerste Entscheidung im ERP-Projekt — richtig treffen

WAS SIE IN DIESEM KIT ERHALTEN:

1

10 Customizing-Fallen Die häufigsten Fehler bei ERP-Anpassungen — mit Gegenstrategien

 

2

Entscheidungsmatrix Standard vs. Customizing vs. Prozessanpassung — wann was sinnvoll ist

 

3

TCO-Vollkostenrechner Was Customizing wirklich kostet — über 5 und 10 Jahre

 

4

Upgrade-Fähigkeit sichern Wie Sie anpassen, ohne sich in der nächsten Version zu blockieren

 

5

30-Tage-Entscheidungsplan Von der Anforderung zur fundierten Make-or-Adapt-Entscheidung

 

 

 

Alle Empfehlungen, Methoden und Kalkulationsmodelle wurden sorgfältig auf Basis langjähriger praktischer ERP-Projekterfahrung erstellt. Da jede ERP-Umgebung, jedes Unternehmen und jede Vertragsgestaltung individuell ist, übernimmt der Autor keinerlei Haftung für Folgen aus der Anwendung der beschriebenen Methoden oder Entscheidungen. Ziehen Sie für verbindliche Entscheidungen stets interne und externe Experten hinzu.

 

 

Genannte Kostenangaben und Aufwandsschätzungen (z. B. Upgradekosten, TCO-Faktoren) sind Erfahrungswerte aus realen KMU-Projekten und keine verbindliche Zusicherung. Tatsächliche Kosten hängen von Systemkomplexität, Anbieter, Vertragsgestaltung und internen Ressourcen ab.

 

 

Die Inhalte beziehen sich auf den Stand März 2026. ERP-Produkte, Lizenzmodelle und Migrationspfade der genannten Hersteller (SAP, Microsoft, MACH, APplus u. a.) werden regelmäßig aktualisiert. Holen Sie vor Entscheidungen stets aktuelle Herstellerinformationen ein.

 

 

Dieses Dokument ist für den persönlichen oder betriebsinternen Gebrauch des Käufers lizenziert. Weiterverkauf, Weitergabe an Dritte und öffentliche Veröffentlichung sind ohne schriftliche Genehmigung nicht gestattet.

 

 

SAP und SAP S/4HANA sind eingetragene Marken der SAP SE. Microsoft Dynamics 365 ist eine eingetragene Marke der Microsoft Corporation. MACH ist eine eingetragene Marke der MACH AG. APplus ist eine eingetragene Marke der Asseco Solutions AG. proALPHA ist eine eingetragene Marke der proALPHA Group. Alle anderen genannten Produkt- und Unternehmensnamen sind Eigentum ihrer jeweiligen Inhaber.

 

Eine ausführliche Version dieses Haftungsausschlusses befindet sich am Ende dieses Dokuments.

 

 

 

01  Einleitung

Warum die Customizing-Entscheidung über Projekterfolg entscheidet

02  Die 10 Customizing-Fallen

Häufigste Fehler — und wie man sie vermeidet

03  Entscheidungsrahmen

Standard, Customizing oder Prozessanpassung — wann was?

04  Die drei Customizing-Ebenen

Konfiguration, Extension, Modifikation — Risiko und Aufwand

05  TCO-Vollkostenrechner

Was Customizing wirklich kostet — über 5 und 10 Jahre

06  Upgrade-Fähigkeit bewahren

Wie Sie anpassen, ohne sich in der nächsten Version zu blockieren

07  Prozessanpassung als dritter Weg

Wann das Unternehmen sich anpassen sollte — nicht das System

08  Customizing-Governance

Wie Sie das Wachstum von Anpassungen dauerhaft kontrollieren

09  Migrations- und Exit-Szenarien

Was passiert beim Versionsupgrade oder ERP-Wechsel?

10  30-Tage-Entscheidungsplan

Von der Anforderung zur fundierten Make-or-Adapt-Entscheidung

 

 

Einleitung

 

 

Kein ERP-Projekt beginnt mit der Absicht, ein schwer wartbares, upgrade-feindliches Sondersystem zu bauen. Und doch endet ein erheblicher Teil mittelständischer ERP-Einführungen genau dort: mit einem System, das so stark an betriebliche Sonderwünsche angepasst wurde, dass jedes Versionsupdate zum Risikoprojekt wird, kein externer Berater ohne wochenlange Einarbeitung helfen kann, und der ursprüngliche Hersteller-Support faktisch nicht mehr greift.

 

Die Customizing-Entscheidung ist die teuerste Einzelentscheidung im ERP-Projekt. Sie wird in den meisten KMU zu früh, zu schnell und zu selten hinterfragt.

 

Dabei liegt das Problem selten in bösem Willen oder Inkompetenz. Es liegt in drei strukturellen Mustern, die sich in fast jedem ERP-Projekt wiederholen:

 

→  Der Status-quo-Reflex: "Wir haben das immer so gemacht." Bestehende Prozesse werden nicht hinterfragt, sondern ins neue System übertragen — inklusive aller historisch gewachsenen Sonderlösungen, Ausnahmen und Workarounds.

 

→  Die Anforderungs-Inflation: Jede Abteilung nennt ihre Wunschliste. Anforderungen werden selten priorisiert oder in "Must-have" und "Nice-to-have" getrennt. Am Ende ist ein Drittel der Anpassungen auf eine Handvoll Personen zurückzuführen, die selten oder nie mit dem System arbeiten.

 

→  Die unterschätzte Folgekosten-Rechnung: Die Erstkosten einer Anpassung sind sichtbar — Entwicklerstunden, Testzeitraum, Abnahme. Die Folgekosten sind unsichtbar: Wartung, Re-Test bei Updates, Dokumentation, Know-how-Abhängigkeit vom Erstentwickler, erschwerter Hersteller-Support.

 

Dieses Kit ist kein Plädoyer gegen jedes Customizing. Manche Anpassungen sind sinnvoll, notwendig und wirtschaftlich. Es ist ein Plädoyer für eine strukturierte, faktenbasierte Entscheidung — mit vollständiger Kostentransparenz, klaren Kriterien und einer Governance, die das unkontrollierte Wachstum von Anpassungen verhindert.

 

WAS SIE IN DIESEM BUCH ERWARTEN DÜRFEN ■  10 Customizing-Fallen — Die häufigsten Fehler bei ERP-Anpassungen mit konkreten Gegenstrategien. ■  Entscheidungsrahmen — Wann Standard, wann Customizing, wann Prozessanpassung die richtige Antwort ist. ■  TCO-Vollkostenrechner — Was eine Anpassung über 5 und 10 Jahre wirklich kostet — inklusive aller versteckten Positionen. ■  Upgrade-Strategie — Wie Sie anpassen, ohne sich in der nächsten Hauptversion zu blockieren. ■  30-Tage-Entscheidungsplan — Von der ersten Anforderung zur dokumentierten, fundierten Make-or-Adapt-Entscheidung.

 

DIE WICHTIGSTE FAUSTREGEL Fragen Sie bei jeder Customizing-Anforderung zuerst: "Warum macht der Hersteller das nicht so?" Wenn die Antwort lautet "weil kein anderes Unternehmen das so braucht" — ist das ein starkes Signal, dass nicht das System, sondern der Prozess angepasst werden sollte.

 

 

Die 10 Customizing-Fallen

 

 

 

Die Key-User-Workshops enden mit einer Liste von 180 Anforderungen. Alle werden als "wichtig" eingestuft. Niemand hat die Autorität oder den Auftrag zu sagen: "Das machen wir nicht." Das Projektteam setzt alles um — und liefert nach 18 Monaten ein System, das an 40 Stellen angepasst wurde, von denen 30 täglich genutzt werden und 10 seit Go-live nie jemand verwendet hat.

 

LÖSUNG:

 

✓  MoSCoW-Priorisierung für jede Anforderung: Must-have, Should-have, Could-have, Won't-have.

✓  Eskalationspfad definieren: Wer entscheidet bei "Could-have" ob gebaut wird? Geschäftsführung, nicht Fachbereich.

✓  Jede Anforderung kostet Geld — machen Sie die Kosten pro Anforderung sichtbar, bevor sie genehmigt wird.

 

 

"Das ERP muss unseren Monatsabschluss-Report in genau diesem Excel-Format ausgeben." Dutzende kundenspezifische Berichte werden direkt im ERP entwickelt, abhängig von internen Datenstrukturen, die sich mit jedem Update verschieben können.

 

LÖSUNG:

 

✓  Berichte und Auswertungen gehören ins BI-Tool — nicht ins ERP. ERP liefert Daten. Power BI, DeltaMaster oder Excel formatiert.

✓  ERP-interne Reports nur für operative Sofortauswertungen (Lieferschein, Rechnung, Auftrag).

✓  Reporting-Anforderungen aus dem ERP-Projekt herauslösen und als separates BI-Projekt führen.

 

 

 

 

 

 

 

Die Anforderung lautet: "Rechnungsfreigabe muss vierstufig sein." Das ERP-Standardverfahren kennt dreistufige Freigaben. Statt zu prüfen, ob drei Stufen mit angepassten Schwellenwerten ausreichen, wird eine vierte Stufe programmiert.

 

LÖSUNG:

 

✓  Vor jeder Customizing-Entscheidung: Demo des Standardprozesses für den Key-User. "Können Sie damit leben, wenn wir X anpassen?"

✓  Gap-Analyse strukturiert durchführen: Worin genau weicht der Standard vom Bedarf ab? Ist die Abweichung wesentlich?

✓  Drei Fragen je Gap: Ist der Standard wirklich unzureichend? Kann der Prozess angepasst werden? Ist die Abweichung regulatorisch zwingend?

 

 

Einmalige Logik für die Datenmigration (Alt-Kundennummern mappen, Dubletten zusammenführen, Fehlwerte korrigieren) wird als dauerhafte ERP-Erweiterung implementiert — weil es während der Projektphase "praktisch" war.

 

LÖSUNG:

 

✓  Migrations-Code hat im ERP-System nichts verloren. Er wird nach Go-live nicht mehr gebraucht, erhöht aber dauerhaft die Systemkomplexität.

✓  Migrations-ETL extern entwickeln und dokumentieren — SSIS, Python, SQL-Skripte — und nach erfolgreicher Migration archivieren.

✓  ERP-Schnittstellen für den Einmalimport nutzen, nicht neue Programmlogik.

 

 

"Das Feld Kundengruppe wird bei uns für zwei verschiedene Zwecke genutzt — bitte das ERP so programmieren, dass es beides unterscheidet." Das zugrunde liegende Problem: die Daten sind schlecht modelliert. Die Lösung: Customizing als Pflaster, das die Datenschwäche überdeckt, aber nicht behebt.

 

LÖSUNG:

 

✓  Schlechte Datenmodellierung ist ein Governance-Problem, kein ERP-Problem. Lösen Sie es vor dem Go-live.

✓  Customizing als Patch für Datenmängel rächt sich spätestens beim nächsten Upgrade — weil sich sowohl das ERP als auch die Datenbasis verändert.

✓  Datenbereinigung als Pflichtprojekt vor der ERP-Einführung einplanen — nicht als "nach Go-live optimieren".

 

 

 

Eine aufwendige Funktion wird entwickelt — und zwei Jahre später liefert der Hersteller genau diese Funktion als Standard. Das Customizing muss abgelöst werden, weil es mit der neuen Standardfunktion kollidiert. Doppelaufwand, Mehrkosten, Verdruss.

 

LÖSUNG:

 

✓  Vor jeder größeren Customizing-Entscheidung: Herstellerkontakt und Product-Roadmap-Anfrage. "Ist diese Funktion für die nächsten zwei Releases geplant?"

✓  User Groups und Herstellerforen als Informationsquelle nutzen — oft ist "die Anforderung kommt häufig" ein Zeichen für baldige Standardisierung.

✓  Roadmap-Risiko in die TCO-Rechnung aufnehmen: Wenn der Hersteller diese Funktion in 18 Monaten liefert, amortisiert sich die Eigenentwicklung nie.

 

 

Drei Jahre nach der ERP-Einführung ist der Entwickler, der die Anpassungen implementiert hat, nicht mehr im Unternehmen. Niemand weiß genau, was geändert wurde, warum, wie es funktioniert und welche Standardfunktionen es beeinflusst.

 

LÖSUNG:

 

✓  Jede Anpassung bekommt ein Customizing-Dokument: Anforderung, Umsetzung, Testfälle, betroffene Standardobjekte, Verantwortlicher, Datum.

✓  Customizing-Verzeichnis zentral pflegen — idealerweise im Wiki, verlinkt aus dem ERP-Administrationssystem.

✓  Übergabepflicht: Kein Customizing geht ohne vollständige Dokumentation in Produktion.

 

 

"Das ERP muss direkt mit unserem Webshop, unserem Versanddienstleister und unserem Lohnbuchhaltungssystem sprechen." Drei individuelle Schnittstellen werden im ERP entwickelt und gewartet — direkt und eng gekoppelt.

 

LÖSUNG:

 

✓  Schnittstellen gehören in eine Middleware-Schicht (EDI, iPaaS wie Make/Zapier/Azure Integration Services) — nicht direkt ins ERP.

✓  ERP-APIs (REST, OData, SOAP) nutzen und auf einer Integrationsplattform orchestrieren — lose Kopplung statt enger Direktverbindung.

✓  Direkt-Schnittstellen im ERP: nur wenn der Hersteller einen zertifizierten, supporteten Konnektor anbietet.

 

 

 

Ein Offshore-Team entwickelt die Anpassungen nach Spezifikation — ohne direkte Kommunikation mit dem Fachbereich, ohne Kenntnis der Prozesshintergründe, ohne Möglichkeit zur schnellen Rückfrage. Ergebnis: technisch korrekte Implementierungen, die den fachlichen Bedarf verfehlen.

 

LÖSUNG:

 

✓  Customizing-Entwicklung erfordert direkten Zugang zum Key-User — nicht nur zum Projektleiter.

✓  Spezifikationen sind kein Ersatz für Kommunikation. Kurze Feedback-Schleifen (täglich oder zweimal pro Woche) sind wichtiger als perfekte Dokumente.

✓  Abnahme durch den Key-User am System — nicht durch Lesen der Spezifikation.

 

 

Zwei Wochen vor Go-live kommen neue Anforderungen. "Nur kleine Änderungen." Sie werden eingebaut — ohne ausreichenden Test, unter Zeitdruck, mit dem Risiko, bereits stabile Teile zu destabilisieren. Der Go-live gerät in Schieflage.

 

LÖSUNG:

 

✓  Customizing-Freeze sechs Wochen vor Go-live: Kein neues Customizing mehr — nur noch Bugfixes.

✓  Change-Request-Prozess für Post-Go-live: Neue Anforderungen werden gesammelt, priorisiert und in der ersten Wartungsphase (3–6 Monate nach Go-live) umgesetzt.

✓  Kommunizieren Sie den Freeze aktiv: "Was nach diesem Datum kommt, kommt in Version 2."

 

 

Entscheidungsrahmen

 

 

Die Customizing-Entscheidung ist keine Binärentscheidung zwischen "Standard nutzen" und "programmieren". Es gibt immer drei Optionen — und die dritte wird am häufigsten vergessen.

 

 

ENTSCHEIDUNGSBAUM: STANDARD vs. CUSTOMIZING vs. PROZESS ══════════════════════════════════════════════════════════════ Schritt 1: IST DIE ANFORDERUNG REGULATORISCH ZWINGEND?   → Ja (Gesetz, Steuer, Zoll, branchenspezifisch):     Prüfen ob Standardfunktion + Konfiguration ausreicht.     Wenn nicht: Customizing — keine Alternative.   → Nein: weiter zu Schritt 2.   Schritt 2: IST DIE ABWEICHUNG EIN WETTBEWERBSVORTEIL?   → Ja: Schriftlich belegen, quantifizieren (€ oder % Marge).     Wenn der Vorteil die TCO übersteigt: Customizing prüfen.   → Nein: weiter zu Schritt 3.   Schritt 3: KANN DER STANDARDPROZESS KONFIGURIERT WERDEN?   → Ja (Parametrierung, Workflow-Konfiguration, Felder):     Standard mit Konfiguration — immer bevorzugen.   → Nein: weiter zu Schritt 4.   Schritt 4: KANN DER UNTERNEHMENS-PROZESS ANGEPASST WERDEN?   → Ja: Prozessanpassung — billiger, nachhaltiger, zukunftssicher.   → Nein (nachgewiesener Grund): Customizing als letzter Ausweg. ══════════════════════════════════════════════════════════════

 

 

 

→  Die Abweichung betrifft nur eine Gewohnheit, kein Geschäftsprinzip. ("Wir haben das immer so gemacht" ist kein Argument für Customizing.)

 

→  Andere Unternehmen derselben Branche arbeiten mit dem Standard — und sind damit erfolgreich.

 

→  Der Standard wird weiterentwickelt: In 12–18 Monaten deckt er den Bedarf voraussichtlich ab.

 

→  Die Anforderung stammt von wenigen Nutzern und hat geringe Transaktionsfrequenz.

 

 

→  Gesetzliche oder regulatorische Pflicht, die der Standard nicht abbildet.

 

→  Nachgewiesener, quantifizierter Wettbewerbsvorteil, der die TCO-Gesamtkosten über 5 Jahre übersteigt.

 

→  Branchenspezifische Besonderheit, für die der Hersteller keine Roadmap hat und kein Marktstandard existiert.

 

→  Schnittstelle zu einem kritischen Drittsystem, für das weder ein zertifizierter Konnektor noch eine Middleware-Lösung verfügbar ist.

 

 

→  Der Standardprozess ist aus neutraler Sicht vernünftig — die Abweichung hat historische, keine fachliche Ursache.

 

→  Der Prozess wird nur von wenigen Personen als "zu umständlich" empfunden, ist aber funktional korrekt.

 

→  Die Abweichung entstand durch eine frühere Systemschwäche (altes ERP konnte es nicht anders) — die jetzt nicht mehr gilt.

 

→  Best-Practice-Prozess des Herstellers würde in anderen Unternehmen genutzt und hat nachgewiesene Vorteile.

 

 

Die drei Customizing-Ebenen

 

 

Nicht jede Anpassung ist gleich. Das Risiko, die Wartungsaufwände und die Upgrade-Auswirkungen unterscheiden sich je nach Ebene der Anpassung fundamental.

 

 

Konfiguration nutzt vom Hersteller vorgesehene Einstellmöglichkeiten: Workflows konfigurieren, Pflichtfelder aktivieren, Nummernkreise definieren, Rollen und Berechtigungen vergeben, optionale Module aktivieren oder deaktivieren.

 

→  Risiko: Minimal. Konfigurationen sind vollständig durch den Hersteller getestet.

 

→  Upgrade-Sicherheit: Sehr hoch. Konfigurationen werden bei Upgrades in der Regel übernommen oder mit Migrationsskripten behandelt.

 

→  Empfehlung: Immer bevorzugen. Erschöpfen Sie alle Konfigurationsmöglichkeiten, bevor Sie die nächste Ebene in Betracht ziehen.

 

BEISPIELE FÜR KONFIGURATION (keine Programmierung): ────────────────────────────────────────────────────────────── ■ Genehmigungsworkflow: 2-stufig → 3-stufig, Schwellenwerte ■ Pflichtfelder aktivieren: Kostenstelle bei Bestellung ■ Nummernkreise: Rechnungen starten ab 2026-00001 ■ Benutzerrollen: Lagerarbeiter darf nur Wareneingang buchen ■ Formularlayout: Logo, Adressfeld, Zahlungsbedingungen ■ E-Mail-Benachrichtigungen: Wer wird bei Auftragseingang informiert? ──────────────────────────────────────────────────────────────

 

 

 

Extensions nutzen vom Hersteller vorgesehene Erweiterungspunkte: Zusatzfelder (Custom Fields), User-Exits, BAdIs (SAP), Custom APIs, eigene Reports auf Standard-Datenbankstrukturen, Plug-ins und Add-ons aus dem Hersteller-Marktplatz.

 

→  Risiko: Mittel. Erweiterungspunkte sind herstellerseitig stabil gehalten — aber nicht identisch mit Konfiguration.

 

→  Upgrade-Sicherheit: Gut, wenn ausschließlich offizielle Erweiterungspunkte genutzt werden. Sinkt deutlich bei Direktzugriff auf interne Tabellen oder APIs.

 

→  Empfehlung: Akzeptabel für echte Geschäftsanforderungen. Dokumentation und Testabdeckung sind Pflicht.

 

BEISPIELE FÜR EXTENSION: ────────────────────────────────────────────────────────────── ■ Zusatzfeld "Projektnummer" am Kundenauftrag (Custom Field) ■ Eigener Report auf Standard-Datenbankviews (keine Eingriffe) ■ Webhook-Empfänger für externe Ereignisse ■ App aus dem Hersteller-Marktplatz (zertifiziertes Add-on) ■ SAP BAdI für kundenspezifische Buchungslogik ■ Power Platform (Dynamics 365): Custom Pages, PCF-Controls ──────────────────────────────────────────────────────────────

 

 

 

Modifikation ändert direkt den Kerncode des ERP-Systems: Tabellen erweitern (nicht über Custom Fields), Standard-Prozesse überschreiben, interne Datenbankstrukturen direkt lesen oder schreiben, Kernel-Modifikationen.

 

→  Risiko: Hoch bis sehr hoch. Modifikationen können bei Updates brechen, Standardfunktionen korrumpieren und den Hersteller-Support einschränken.

 

→  Upgrade-Sicherheit: Gering. Jedes Major-Update erfordert Überprüfung und oft Neuentwicklung der Modifikation.

 

→  Empfehlung: Nur wenn kein anderer Weg existiert. Vollständige Dokumentation, maximale Testabdeckung, explizite Genehmigung durch Entscheider-Ebene.

 

Ebene	Upgrade-Sicherheit	Wartungsaufwand	Empfehlung
Konfiguration	★★★★★	Minimal	Immer bevorzugen
Extension	★★★★	Moderat	Bei echtem Bedarf
Modifikation	★★	Hoch bis sehr hoch	Letzter Ausweg

 

 

TCO-Vollkostenrechner

 

 

Die häufigste Fehlkalkulation bei Customizing-Entscheidungen: Es werden nur die Erstkosten betrachtet. Die Folgekosten über den gesamten Lebenszyklus werden systematisch unterschätzt oder ignoriert.

 

 

TCO-RECHNER: EINE EINZELNE CUSTOMIZING-ANFORDERUNG ══════════════════════════════════════════════════════════════ EINMALKOSTEN (direkt sichtbar):   Analyse & Konzeption:         [A] Stunden × Tagessatz   Entwicklung & Test:           [B] Stunden × Tagessatz   Abnahme & Dokumentation:      [C] Stunden × Tagessatz   Go-live-Begleitung:           [D] Stunden × Tagessatz   ───────────────────────────────────────────────   Summe Erstkosten:             [A+B+C+D]   JÄHRLICHE FOLGEKOSTEN (oft nicht einkalkuliert):   Wartung & Fehlerbehebung:     ca. 15–20 % der Erstkosten/Jahr   Re-Test bei Minor Updates:    0,5–2 Tage × Tagessatz / Update   Re-Entwicklung bei Major:     10–50 % der Erstkosten / Version   Interne Testzeit (Key-User):  2–8 Stunden je Update   Dokumentationspflege:         0,5–2 Stunden / Jahr   Know-how-Risiko (Abhängigkeit): schwer monetarisierbar   ───────────────────────────────────────────────   Jährliche Folgekosten:        [E] geschätzt   5-JAHRES-TCO:                   [A+B+C+D] + 5 × [E] 10-JAHRES-TCO:                  [A+B+C+D] + 10 × [E] ══════════════════════════════════════════════════════════════

 

Anpassungstyp	Erstkosten	Jährl. Folgekosten	5-Jahres-TCO	10-Jahres-TCO
Zusatzfeld + Logik (Extension)	3.000 €	600 €	6.000 €	9.000 €
Kundenspezifischer Report (Modifikation)	8.000 €	2.000 €	18.000 €	28.000 €
Erweiterter Genehmigungsworkflow	15.000 €	4.000 €	35.000 €	55.000 €
Individuelle ERP-Schnittstelle	25.000 €	6.000 €	55.000 €	85.000 €
Branchenspezifisches Kernmodul	80.000 €	20.000 €	180.000 €	280.000 €

 

→  Upgrade-Blocker-Kosten: Ein Major-Update wird verzögert, weil Customizing geprüft und angepasst werden muss. Kosten: 2–12 Monate verzögerter Zugang zu neuen Standardfunktionen, Sicherheitspatches und Compliance-Updates.

 

→  Berater-Onboarding-Kosten: Jeder externe Berater, der das System nicht kennt, braucht 1–5 Tage Einarbeitung allein in das Customizing. Bei durchschnittlich zwei externen Einsätzen pro Jahr und 50 Anpassungen summiert sich das.

 

→  Know-how-Abhängigkeit: Wenn der interne oder externe Entwickler nicht mehr verfügbar ist, steigen Risiko und Kosten für jede spätere Änderung exponentiell.

 

→  Test-Aufwand bei Updates: Jede Anpassung, die getestet werden muss, multipliziert die Test-Aufwände bei Updates. 50 Anpassungen × 2 Stunden Test je Update × 4 Updates pro Jahr = 400 Stunden/Jahr nur für Regressionstest von Customizing.

 

→  Opportunity Cost: Ressourcen, die in Customizing-Wartung fließen, fehlen bei Innovation und Weiterentwicklung.

 

DIE 3-JAHRES-SCHWELLE In der Praxis amortisiert sich Customizing mit mittlerem Aufwand selten innerhalb von 3 Jahren, wenn alle Folgekosten eingerechnet werden. Verwenden Sie den TCO-Rechner und legen Sie den 5-Jahres-Wert offen — bevor eine Entscheidung getroffen wird.

 

 

Upgrade-Fähigkeit bewahren

 

 

Das Hauptrisiko von Customizing ist nicht der Erstaufwand — es ist der Verlust der Upgrade-Fähigkeit. Ein System, das nicht mehr regulär aktualisiert werden kann, verliert schrittweise Sicherheitspatches, Compliance-Updates und neue Funktionen. Im schlimmsten Fall endet es im Extended Support oder im Abkündigungsrisiko.

 

 

Regel 1 — Niemals Standardtabellen direkt ändern

 

Jede direkte Änderung an vom Hersteller verwalteten Tabellen (Spalten hinzufügen, Datentypen ändern) bricht bei Updates garantiert. Nutzen Sie ausschließlich vom Hersteller vorgesehene Erweiterungsmechanismen: Custom Fields, Extension Tables, Satellite Tables.

 

Regel 2 — Keine Direktzugriffe auf interne APIs

 

Undokumentierte oder als "intern" markierte APIs, Funktionen und Methoden des Herstellers können ohne Ankündigung geändert oder entfernt werden. Nur öffentlich dokumentierte, versionierte APIs nutzen.

 

Regel 3 — Geschäftslogik aus dem ERP-Kern heraushalten

 

Komplexe Geschäftslogik gehört in externe Services, nicht in ERP-Trigger oder ERP-interne Skripte. Externe Services können unabhängig vom ERP-Update-Zyklus gewartet werden.

 

Regel 4 — Upgrade-Tests in der Customizing-Spezifikation verankern

 

Jede Customizing-Spezifikation enthält als Pflichtbestandteil: eine Liste der betroffenen Standardobjekte und einen Testplan für den nächsten Major-Update-Zyklus.

 

Regel 5 — Upgrade-Kompatibilität als Abnahmekriterium

 

Kein Customizing geht ohne schriftliche Bestätigung des Entwicklers in Produktion: "Diese Anpassung nutzt ausschließlich offiziell supportete Erweiterungspunkte und ist kompatibel mit der aktuellen Herstellerroadmap."

 

 

■  Nutzt die Anpassung ausschließlich offizielle, dokumentierte Erweiterungspunkte?

■  Gibt es eine Testprozedur, die bei jedem Update überprüft, ob die Anpassung noch funktioniert?

■  Ist die Anpassung vollständig dokumentiert — so dass ein bisher unbekannter Entwickler sie in 2 Jahren versteht?

■  Wurde die Herstellerroadmap auf konkurrierende Standardfunktionalität geprüft?

■  Ist die Anpassung im zentralen Customizing-Verzeichnis erfasst?

■  Hat ein Entscheider (nicht nur der Projektleiter) die Folgekosten gesehen und freigegeben?

 

 

Prozessanpassung als dritter Weg

 

 

Der dritte Weg wird in ERP-Projekten am häufigsten vergessen, weil er politisch unbequem ist: Er bedeutet, dass eine Abteilung oder eine Person ihren gewohnten Arbeitsablauf ändert — statt das neue System an den alten Ablauf anzupassen.

 

 

→  ERP-Standardprozesse sind aus jahrelanger Implementierungserfahrung mit hunderten Unternehmen entstanden. Sie sind nicht perfekt — aber sie sind oft besser als historisch gewachsene, nie hinterfragte interne Abläufe.

 

→  Ein neues ERP ist eine strategische Chance zur Prozessverbesserung. Diese Chance wird verspielt, wenn die Einführung als "altes System in neuer Software" geplant wird.

 

→  Jede Prozessanpassung, die Customizing vermeidet, ist eine Investition in Upgrade-Fähigkeit, Support-Qualität und langfristige Wartbarkeit.

 

 

Szenario 1 — "Das war historisch so"

 

Der bisherige Prozess ist nicht das Ergebnis einer bewussten Entscheidung, sondern einer früheren Systemlimitation oder einer einmaligen Ausnahme, die zur Regel wurde. Fragen Sie: "Wenn wir heute neu anfangen würden — wie würden wir das machen?"

 

Szenario 2 — "Wir sind in dieser Branche anders"

 

Oft stimmt das — für Kernprozesse. Für Randprozesse (Urlaubsgenehmigung, Eingangsrechnungsverarbeitung, Kostenstellen-Zuweisung) gibt es selten echte branchenspezifische Unterschiede. Prüfen Sie kritisch, was wirklich branchenspezifisch ist und was Gewohnheit.

 

Szenario 3 — "Unsere Kunden erwarten das so"

 

Kunden erwarten Ergebnisse — nicht Prozesse. Wenn ein Kunde eine schnelle Lieferbestätigung erwartet, ist das eine Output-Anforderung. Wie intern damit umgegangen wird, ist eine Design-Entscheidung, die den Standard-Prozess nicht zwingend ausschließt.

 

VIER FRAGEN FÜR JEDE PROZESSANPASSUNGS-ENTSCHEIDUNG: ────────────────────────────────────────────────────────────── 1. WER leidet wirklich unter dem Standardprozess?    Einzelne Person, Team, gesamte Abteilung, alle Nutzer?   2. WIE OFT ist das Problem relevant?    Täglich, wöchentlich, monatlich, selten?   3. WIE GROSS ist der Aufwand der Prozessanpassung?    Schulung, Ablaufänderung, neue Verantwortlichkeit?   4. WAS ist billiger auf 5 Jahre — Customizing oder Umgewöhnung?    TCO Customizing vs. 1–2 Schulungstage + Übergangsfrist? ────────────────────────────────────────────────────────────── Wenn Frage 4 eindeutig für Prozessanpassung spricht: → Entscheidung durch Führungsebene herbeiführen — nicht durch   Abstimmung im Fachbereich (dort gewinnt immer der Status quo). ──────────────────────────────────────────────────────────────

 

 

 

Customizing-Governance

 

 

Ohne aktive Steuerung wächst Customizing in jedem ERP-System. Jede neue Anforderung wird bewertet ("klein und machbar") — aber die kumulierte Komplexität wird nicht bewertet. Nach fünf Jahren ist ein System entstanden, das niemand mehr vollständig überblickt.

 

 

Jede Anpassung wird im zentralen Customizing-Verzeichnis erfasst — ohne Ausnahme:

 

CUSTOMIZING-VERZEICHNIS — EINTRAGSVORLAGE: ══════════════════════════════════════════════════════════════ ID:               CUS-2026-047 Bezeichnung:      Vierstufige Rechnungsfreigabe Ebene:            Extension (BAdI / Workflow-Extension) Status:           Produktiv seit 2026-03-15 ────────────────────────────────────────────────────────────── Anforderung:      Rechnungen > 50.000 € benötigen GF-Freigabe Fachlicher Owner: CFO / Buchhaltungsleitung Technischer Owner: ERP-Administrator, IT-Abteilung ────────────────────────────────────────────────────────────── Betroffene Objekte: Workflow WS20000050, Tabelle T16FS Testfälle:        TC-047-A (Normalbetrag), TC-047-B (> 50T €) Testverantwortung: Key-User Buchhaltung (nach jedem Update) ────────────────────────────────────────────────────────────── Erstkosten:       12.500 €    Jährl. Folgekosten: ca. 2.500 € 5-Jahres-TCO:     25.000 € ────────────────────────────────────────────────────────────── Letzter Test:     2026-02-10 (nach SP2025-11) Nächster Review:  2026-08-01 Abkündigung?:     Nein — keine konkurrierende Roadmap-Funktion ══════════════════════════════════════════════════════════════

 

 

 

Keine Anpassung ohne Change-Request-Prozess. Dieser hat vier Pflichtschritte:

 

→  Schritt 1 — Anforderungsaufnahme: Key-User dokumentiert den Bedarf schriftlich — inkl. Häufigkeit, betroffene Nutzer, Geschäftswert.

 

→  Schritt 2 — Standardprüfung: IT oder ERP-Berater prüft: Ist die Anforderung durch Konfiguration oder Standardprozessanpassung lösbar? Ergebnis schriftlich.

 

→  Schritt 3 — TCO-Kalkulation: Erstkosten + Folgekosten über 5 Jahre werden berechnet und dokumentiert.

 

→  Schritt 4 — Genehmigung: Entscheider (nicht Fachbereich) genehmigt oder lehnt ab — mit Begründung. Keine Anpassung ohne explizite Genehmigung durch die definierte Entscheiderebene.

 

 

Einmal pro Jahr: Durchsicht des gesamten Customizing-Verzeichnisses.

 

■  Welche Anpassungen werden noch aktiv genutzt? (Usage-Statistiken aus ERP-Logs)

■  Welche Anpassungen sind durch neue Standardfunktionen redundant geworden?

■  Welche Anpassungen haben ihren ursprünglichen Geschäftszweck verloren?

■  Welche Anpassungen sind nicht dokumentiert — und müssen nachdokumentiert werden?

 

 

Migrations- und Exit-Szenarien

 

 

Die Customizing-Entscheidung von heute ist die Migrations-Herausforderung von morgen. Wer heute unreflektiert anpasst, bezahlt beim nächsten Major-Update oder ERP-Wechsel die Rechnung — mit Zinseszins.

 

 

Risiko für Customizing: niedrig bis mittel, abhängig von der Ebene. Konfigurationen: kein Risiko. Extensions über offizielle Punkte: geringes Risiko. Direkte Modifikationen: mittleres Risiko — jede Änderung an Standardobjekten muss geprüft werden.

 

Maßnahme: Customizing-Testplan aus dem Verzeichnis ausführen. Key-User testen alle Testfälle des Verzeichnisses auf dem Update-System, bevor der Produktiveinsatz erfolgt.

 

 

Risiko für Customizing: mittel bis sehr hoch. Jedes Major Release kann Datenbankstrukturen, APIs und Verarbeitungslogiken grundlegend ändern. Direkte Modifikationen müssen oft vollständig neu entwickelt werden.

 

VORGEHENSMODELL FÜR MAJOR-UPDATE MIT CUSTOMIZING: ────────────────────────────────────────────────────────────── 6 Monate vor Update:   ■ Alle Customizing-Einträge gegen neue Release Notes prüfen   ■ Betroffene Anpassungen identifizieren   ■ Aufwandsschätzung für Anpassungsübernahme   4 Monate vor Update:   ■ Testumgebung mit neuer Version aufbauen   ■ Customizing auf Testumgebung portieren/neu entwickeln   2 Monate vor Update:   ■ Vollständigen Regressionstest aller Testfälle   ■ Key-User-Abnahme auf Testumgebung   Go-live:   ■ Produktionsupdate + sofortiger Smoke-Test aller Anpassungen ──────────────────────────────────────────────────────────────

 

 

 

ERP-Wechsel sind die härteste Prüfung für Customizing-Entscheidungen der Vergangenheit. Kein Customizing ist portierbar. Alle Anpassungen müssen im neuen System von Grund auf neu bewertet, spezifiziert und entwickelt werden — sofern sie überhaupt noch gebraucht werden.

 

→  Gute Nachricht: Ein ERP-Wechsel ist die beste Gelegenheit, Customizing-Schulden abzubauen. Viele historische Anpassungen werden beim Wechsel nicht mehr benötigt — entweder weil der neue Standard sie abdeckt oder weil sich der Prozess geändert hat.

 

→  Schlechte Nachricht: Jede undokumentierte Anpassung im Altsystem muss durch Reverse Engineering verstanden werden, bevor entschieden werden kann, ob sie übertragen wird.

 

→  Empfehlung: Starten Sie den ERP-Wechsel mit einer vollständigen Bestandsaufnahme aller bestehenden Anpassungen — und entscheiden Sie für jede explizit: Übernehmen, ablösen durch Standard, oder nicht mehr benötigt?

 

 

30-Tage-Entscheidungsplan

 

 

Dieser Plan ist für zwei Szenarien geeignet: erstens für KMU mitten in einer ERP-Einführung, die strukturiert Customizing-Entscheidungen treffen wollen; zweitens für Unternehmen mit einem bestehenden ERP, das zu viel ungeplantes Customizing angesammelt hat und jetzt Ordnung schaffen möchte.

 

VOR DEM START Benennen Sie einen "Customizing-Verantwortlichen" — eine Person, die den Prozess koordiniert. In KMU ist das oft der IT-Leiter oder der ERP-Projektleiter. Diese Person hat kein Veto-Recht, aber sie moderiert den Prozess und stellt sicher, dass kein Customizing ohne vollständige Dokumentation und Genehmigung umgesetzt wird.

 

 

■ TAG 1–2: CUSTOMIZING-INVENTUR

 

■  Vollständige Liste aller bestehenden Anpassungen aus dem ERP-System exportieren (Systemprotokoll, Transportaufzeichnung oder Herstellertool)

■  Jede Anpassung in drei Kategorien einteilen: Konfiguration / Extension / Modifikation

■  Für jede Anpassung: Ersteller, Datum, fachlichen Owner identifizieren (soweit möglich)

■  Anpassungen ohne Dokumentation markieren — diese werden in Woche 2 nacherfasst

 

■ TAG 3–4: NUTZUNGSANALYSE

 

■  ERP-Nutzungsstatistiken auswerten: Welche angepassten Bereiche werden täglich genutzt, welche selten?

■  Key-User-Interviews (je 15 Minuten): "Welche Anpassungen wären für Sie nicht mehr wegzudenken? Welche vermissen Sie kaum?"

■  "Zombie-Customizing" identifizieren: Anpassungen, die seit > 12 Monaten niemand aktiv genutzt hat

■  Priorisierungsliste erstellen: Welche 20 % der Anpassungen erzeugen 80 % des Nutzens?

 

■ TAG 5–7: KOSTEN SICHTBAR MACHEN

 

■  TCO-Rechner (Kapitel 5) für die 10 aufwendigsten Anpassungen ausfüllen

■  Jährliche Gesamtfolgekosten des aktuellen Customizing-Portfolios schätzen

■  Ergebnis als 1-seitige Management-Summary aufbereiten: Was kostet das Customizing-Portfolio jährlich?

■  Erste Abkündigungskandidaten identifizieren: Anpassungen, die durch neue Standardfunktionen ersetzt werden könnten

 

 

■ TAG 8–10: CUSTOMIZING-VERZEICHNIS ANLEGEN

 

■  Verzeichnis-Vorlage (Kapitel 8) im Wiki oder SharePoint einrichten

■  Die 20 wichtigsten Anpassungen mit vollständigem Eintrag erfassen

■  Fehlende Dokumentation der übrigen Anpassungen: Verantwortliche benennen, Nacherfassungs-Termine setzen

■  Testfälle für alle dokumentierten Anpassungen festhalten — Basis für künftige Update-Tests

 

■ TAG 11–13: CHANGE-REQUEST-PROZESS EINFÜHREN

 

■  Change-Request-Vorlage (Kapitel 8, vier Pflichtschritte) erstellen und im Wiki veröffentlichen

■  Entscheiderebene definieren: Wer genehmigt welche Anpassungsklassen? (z. B. Konfiguration: IT-Leiter; Extension: IT + CFO; Modifikation: GF)

■  Kommunikation an Key-User: Ab sofort kein Customizing ohne CR-Prozess

■  Ersten Monatstermin für CR-Review einplanen: Offene CRs gemeinsam bewerten

 

■ TAG 14: ZOMBIE-CUSTOMIZING BEREINIGEN

 

■  Für jeden identifizierten Zombie-Kandidaten: Key-User-Bestätigung einholen ("Brauchen Sie das noch?")

■  Abkündigungsplan erstellen: Welche Anpassungen werden in welchem Zeitraum deaktiviert?

■  Ersten Deaktivierungstest auf Testumgebung durchführen: Verändert das Entfernen irgendein Verhalten, das noch gebraucht wird?

■  Erste Bereinigung produktiv setzen — jede entfernte Anpassung ist eine reduzierte Folgekosten-Position

 

 

■ TAG 15–17: PENDENTE CUSTOMIZING-ANFORDERUNGEN STRUKTURIEREN

 

■  Alle offenen, noch nicht umgesetzten Customizing-Wünsche aus Tickets, E-Mails und Notizen sammeln

■  Jede Anforderung durch den Entscheidungsbaum (Kapitel 3) führen: Standard / Customizing / Prozessanpassung?

■  Anforderungen mit klarer Antwort "Prozessanpassung" — Key-User informieren und Entscheidung begründen

■  Anforderungen mit klarer Antwort "Standard nach Konfiguration" — umsetzen ohne CR-Prozess

 

■ TAG 18–20: TCO-KALKULATION OFFENER ANFORDERUNGEN

 

■  Für alle verbliebenen Customizing-Anforderungen: TCO-Rechner ausfüllen

■  Anforderungen unter dem Break-even-Schwellenwert (TCO > Prozessanpassungskosten) ablehnen und begründen

■  Genehmigungspflichtige Anforderungen dem definierten Entscheider vorlegen — mit TCO-Kalkulation

■  Priorisierte Umsetzungsliste erstellen: Was wird in welcher Reihenfolge gebaut?

 

■ TAG 21: UPGRADE-STRATEGIE FESTLEGEN

 

■  Aktuelles ERP auf nächstes Major Release prüfen: Welche Anpassungen sind betroffen?

■  Upgrade-Testplan aus dem Customizing-Verzeichnis ableiten: Welche Testfälle müssen vor dem Update ausgeführt werden?

■  Upgrade-Budget reservieren: Jährliche Rückstellung für Update-bedingte Anpassungsüberprüfungen einplanen

■  Upgrade-Kompatibilität als Standardklausel in künftige Entwicklungsaufträge aufnehmen

 

 

■ TAG 22–25: PROZESSE KOMMUNIZIEREN UND SCHULEN

 

■  Change-Request-Prozess allen Key-Usern und Abteilungsleitern vorstellen (30-Minuten-Session)

■  Customizing-Verzeichnis veröffentlichen — intern zugänglich für IT und Entscheiderebene

■  FAQ-Dokument erstellen: "Was ist Customizing? Wie stelle ich einen CR? Wer entscheidet?"

■  Ersten realen Change Request gemeinsam durch den Prozess führen — als Praxisbeispiel

 

■ TAG 26–28: GOVERNANCE-KALENDER ETABLIEREN

 

■  Monatlichen CR-Review-Termin (30 Min.) als Dauerserie einplanen

■  Jährlichen Customizing-Audit (Kapitel 8) im Kalender verankern

■  Halbjährlichen Abgleich mit Hersteller-Roadmap terminieren

■  Review-Termine in alle Customizing-Verzeichnis-Einträge eintragen

 

■ TAG 29–30: ABSCHLUSS & MESSUNG

 

■  KPIs festhalten: Anzahl dokumentierter Anpassungen, Anzahl abgelehnter CRs, Anzahl deaktivierter Zombie-Anpassungen

■  Geschätzte jährliche Einsparung durch Bereinigung und Prozessverbesserungen beziffern

■  Management-Präsentation: Ergebnisse, Kosten-Transparenz, nächste Schritte

■  Backlog für die nächsten 90 Tage priorisieren: Welche Anpassungen werden als nächstes bereinigt oder neu bewertet? ■

 

ERGEBNIS NACH 30 TAGEN Ihr Ergebnis nach 30 Tagen: Ein vollständiges Customizing-Verzeichnis, ein funktionierender Change-Request-Prozess der neue Anpassungen strukturiert bewertet, eine bereinigte Liste aktiver Anpassungen ohne Zombie-Customizing, eine TCO-Transparenz über das gesamte Anpassungsportfolio — und eine Governance, die das unkontrollierte Wachstum von Customizing dauerhaft verhindert.

 

 

 

 

Die in diesem Dokument enthaltenen Empfehlungen, Methoden und Kalkulationsmodelle wurden nach bestem Wissen und Gewissen auf der Grundlage langjähriger praktischer Erfahrung in ERP-Einführungs- und Anpassungsprojekten erstellt. Dennoch kann keine Gewähr für Vollständigkeit, Richtigkeit oder universelle Anwendbarkeit übernommen werden.

 

Der Autor übernimmt ausdrücklich keinerlei Haftung für Schäden, die aus der Anwendung der beschriebenen Methoden und Entscheidungsrahmen entstehen, einschließlich, aber nicht beschränkt auf: fehlerhafte Investitionsentscheidungen, Projektverzögerungen, Systemausfälle, entgangenen Gewinn oder Kosten für Korrekturen.

 

 

Hinweise zu regulatorischen oder gesetzlichen Anforderungen stellen keine Rechtsberatung dar und ersetzen nicht die Beratung durch einen Rechtsanwalt oder Steuerberater. Regulatorische Anforderungen sind jurisdiktionsabhängig und unterliegen Änderungen.

 

 

Alle Angaben zu produktspezifischen Funktionen, Erweiterungspunkten, APIs und Roadmap-Informationen (SAP, Microsoft Dynamics, MACH, APplus u. a.) beziehen sich auf öffentlich verfügbare Informationen zum Stand März 2026. Herstellerprodukte werden regelmäßig aktualisiert. Holen Sie vor Entscheidungen stets aktuelle Herstellerinformationen ein.

 

 

Dieses Dokument und alle Inhalte sind urheberrechtlich geschützt. © 2026 Sascha Hess, xenosystems.de. Alle Rechte vorbehalten.

 

 

SAP und SAP S/4HANA sind eingetragene Marken der SAP SE. Microsoft Dynamics 365 ist eine eingetragene Marke der Microsoft Corporation. MACH ist eine eingetragene Marke der MACH AG. APplus ist eine eingetragene Marke der Asseco Solutions AG. proALPHA ist eine eingetragene Marke der proALPHA Group. Infor ist eine eingetragene Marke der Infor, Inc. Alle anderen genannten Produkt- und Unternehmensnamen sind Eigentum ihrer jeweiligen Inhaber.

 

Es gilt ausschließlich deutsches Recht. Gerichtsstand für alle Streitigkeiten ist, soweit gesetzlich zulässig, Weimar, Thüringen, Deutschland.

 

 

 

Sascha Hess ist Diplom-Biologe und IT-Professional mit über 20 Jahren Erfahrung in der Administration von ERP-, BI- und Datenbanksystemen sowie in der Beratung mittelständischer Unternehmen bei ERP-Einführungen und -Optimierungen. Er hat mehr als 15 ERP-Projekte begleitet — von der Systemauswahl über die Einführung bis zur Nachoptimierung — und dabei Customizing-Portfolios von wenigen bis zu mehreren hundert Anpassungen analysiert, bewertet und bereinigt.

 

Sein Ansatz verbindet naturwissenschaftliche Präzision mit hochgradiger IT-Spezialisierung. Schwerpunkte: SQL Server Performance-Tuning, ERP-Einführungen, Business Intelligence (Power BI, DeltaMaster), Data Governance, Prozessdigitalisierung und IT-Interim-Management.

 

Web: www.xenosystems.de | E-Mail: info@xenosystems.de | Standort: Weimar, Thüringen / Remote

 

Service	Beschreibung
Customizing-Audit	Vollständige Bestandsaufnahme und Bewertung Ihres ERP-Customizing-Portfolios — mit TCO-Kalkulation, Zombie-Analyse, Upgrade-Risikobewertung und priorisiertem Bereinigungsplan. Scope: 2–4 Tage.
ERP-Einführungsberatung	Begleitung von ERP-Projekten (MACH, Dynamics 365, APplus, proALPHA) als neutrale Instanz — Anforderungsmanagement, Customizing-Entscheidungen, Datenmigration und Go-live-Begleitung.
Change-Request-Governance	Einführung eines strukturierten Customizing-Governance-Prozesses: Verzeichnis, CR-Prozess, Entscheidermatrix, Upgrade-Strategie und jährlicher Audit-Zyklus. Scope: 3–5 Tage.
SQL Server DB Health Check	Professioneller Audit Ihres SQL Servers — Managementreport, Risikobewertung und Maßnahmenplan. Scope: 3–5 Tage.
Interim IT-Management	Übernahme der IT-Steuerung auf Zeit — Budgetplanung, Dienstleister-Management, strategische IT-Ausrichtung.