Clean core: Was wirklich gesteuert werden muss.

Das Prinzip passt in einen Satz. In einem sauberen System bleibt der Kern konform zum Standard des Herstellers; alles, was das Unternehmen hinzufügt, lebt daneben, auf einer dafür vorgesehenen Erweiterungsplattform, hinter dokumentierten Schnittstellen. SAP hat daraus die offizielle Doktrin von SAP S/4HANA und RISE with SAP gemacht, und man täte unrecht, darin nur ein Verkaufsargument zu sehen: Das Versprechen regelmäßiger Updates hält nur, wenn niemand den Kern von innen verschweißt hat. Aber der wahre Grund, sich dafür zu interessieren, liegt nicht beim Hersteller. Er liegt in Ihren Büchern.

Jede Eigenentwicklung ist eine Schuld

Eine kundenspezifische Entwicklung entsteht immer aus guter Absicht. Ein Prozess, der hakt, ein gesetzlicher Bericht, den der Standard nicht so ausgibt, eine Anforderung des Fachbereichs, die man schnell erfüllen will: ein paar Tage Entwicklung, und das Thema ist erledigt. Im Moment der Programmierung wirkt eine Eigenentwicklung fast kostenlos. Erst danach beginnt sie zu kosten.

Sie kostet bei jedem Versionswechsel: Alles, was den Kern berührt, muss analysiert, angepasst und erneut getestet werden, und die Rechnung wiederholt sich, solange der Code lebt. In einer RISE-with-SAP-Welt, in der der Hersteller seine Updates in seinem Rhythmus ausrollt, hört diese Last auf, ein Ereignis alle fünf Jahre zu sein, und wird zur wiederkehrenden Maut. Sie kostet Innovation: Die Fähigkeiten, die SAP liefert, allen voran die eingebettete KI, stützen sich auf die Standardprozesse und Standarddatenstrukturen; ein mit Ausnahmen gespickter Kern sieht sie vorbeiziehen. Sie kostet schließlich Abhängigkeit: Im Laufe der Jahre konzentriert sich das Wissen über eine Eigenentwicklung in zwei oder drei Köpfen, und an dem Tag, an dem sie gehen, entdeckt das Unternehmen, dass es sein eigenes System nicht mehr erklären kann. In einem Markt, in dem SAP-Kompetenzen knapp sind, wiegt dieser letzte Kostenpunkt am schwersten.

Keiner dieser Kosten stand in der Kalkulation der ursprünglichen Entwicklung. Das ist die ganze Schwierigkeit des Themas: Die Ausgabe ist sichtbar und bescheiden, die Schuld ist unsichtbar und langlebig. Eine Geschäftsleitung, die sie ignoriert, zahlt sie trotzdem.

Der Sonderfall der Lokalisierung

Im OHADA-Raum ist ein Teil der Eigenentwicklungen keine Laune des Fachbereichs. Die Abschlüsse des revidierten SYSCOHADA, die Mehrwertsteuer und die Erklärungen jedes Staates der UEMOA-Zone, die Gehaltsabrechnungen und die nationalen Sozialabgaben: All das muss aus dem System kommen, und der Standard des Herstellers deckt nicht immer jedes Detail jedes Landes ab. Diese Entwicklungen sind legitim. Die Frage ist nicht, sie zu verbieten, sondern zu entscheiden, wo sie leben.

Unsere Position ist klar: Die Lokalisierung wird als Erweiterung gebaut, auf SAP BTP, mit dokumentierten Schnittstellen, und nicht durch Änderungen im Kern. Ein außerhalb entwickelter SYSCOHADA-Bericht überlebt die Versionswechsel und wird von einem lokalen Team gewartet. Derselbe Bericht, im Kern des Systems programmiert, muss bei jedem Update erneut validiert werden, von den wenigen Personen, die ihn noch verstehen. Der Kostenunterschied über zehn Jahre ist erheblich, und er entscheidet sich am ersten Tag.

Der Test: ein nachgewiesenes Differenzierungsmerkmal, sonst der Standard

Soll man deshalb jede Eigenentwicklung außerhalb der Lokalisierung verbieten? Nein, und die Befürworter des reinen Standards irren ebenso wie die anderen. Manche Prozesse gewinnen Kunden, Margen oder Liquiditätstage genau deshalb, weil sie nicht denen des Nachbarn gleichen. Diese verdienen es, verteidigt, sauber außerhalb des Kerns entwickelt und wie Vermögenswerte gepflegt zu werden.

Alles liegt im Kriterium. Unseres ist einfach zu formulieren und unbequem anzuwenden: Eine Eigenentwicklung ist gerechtfertigt, wenn sie gesetzlich vorgeschrieben ist oder wenn der Prozess, den sie trägt, ein nachweisbares fachliches Differenzierungsmerkmal ist. Nachweisbar, nicht gefühlt: Wer kann sagen, was das Unternehmen konkret verlieren würde, wenn es zum Standard überginge? Wenn niemand antworten kann, lautet die Antwort Standard, und der Prozess passt sich an. Unsere Erfahrung mit Inventaren von Eigenentwicklungen ist in diesem Punkt konstant: Die große Mehrheit fällt beim Test durch. Sie reproduzieren eine Gewohnheit, selten einen Vorteil.

Die richtige Frage lautet nicht „Was macht diese Eigenentwicklung?“, sondern „Was wäre das Unternehmen ohne sie wert?“. Wenn die Antwort „dasselbe“ lautet, hat sie im Kern nichts verloren.

Was die Disziplin von der Governance verlangt

Ein Kriterium reicht nicht; es braucht jemanden, der es hält. Hier verlässt das Thema die technische Sphäre, denn ein Kriterium zu halten heißt, Nein zu sagen. Nein zu einem drängenden Fachbereichsleiter, Nein zu einem Projekt, das schon versprochen hat, Nein zur bequemen Lösung, die den Kern wieder öffnen würde. Eine Architekturinstanz, die sich nicht auf die Geschäftsleitung stützen kann, wird nachgeben. Höflich, und systematisch.

Die Governance, die funktioniert, beruht auf drei Praktiken. Ein Entscheidungsgremium, in dem der Fachbereich seine Anforderung vorträgt, mit dem Test des Differenzierungsmerkmals als vorab bekannter Spielregel. Sodann ein Ausnahmeregister: Jede akzeptierte Eigenentwicklung wird dort mit Eigentümer, Begründung, Ort (Kern oder Erweiterung) und Überprüfungsdatum eingetragen, denn eine Schuld lässt sich schlecht verwalten, wenn man nicht Buch darüber führt. Und schließlich eine Überprüfung bei jedem Versionswechsel: Eine Eigenentwicklung muss sich bei jedem Termin ihren Platz neu verdienen, sonst fliegt sie raus. Ohne diesen Termin kehrt die Abweichung in wenigen Jahren zurück, durch Anhäufung kleiner Ausnahmen, die einzeln alle vernünftig sind.

2027, die Bereinigung, die nicht wiederkommt

Bleibt der Kalender. Das Ende der Standardwartung von ECC, festgelegt auf Ende 2027 mit möglicher Verlängerung bis Ende 2030, zwingt jedes Unternehmen zum Übergang auf SAP S/4HANA. Eine Konvertierung ist der einzige Moment, in dem Bereinigen weniger kostet als Bewahren: Man muss ohnehin jede Entwicklung inventarisieren, analysieren und erneut testen. Bei dieser Gelegenheit zu sortieren ist ein marginaler Aufwand; alles mitzunehmen heißt, seine Schuld zusammen mit seinem System zu konvertieren und sie zehn weitere Jahre lang zurückzuzahlen.

Deshalb plädieren wir dafür, die Doktrin der Eigenentwicklungen vom Scoping an festzulegen, vor der Wahl des Szenarios und des Integrators, statt sie mitten im Programm zu entdecken, wenn jede Entscheidung einen Meilenstein verzögert. Das Unternehmen, das mit seiner Spielregel, seinem Register und seiner Bereinigungsliste in die Verhandlung geht, wählt sein Programm. Das andere erduldet es.

Zum Weiterlesen: unsere Lektüre des Termins 2027 für die Unternehmen der Subregion, unser Angebot SAP · S/4HANA & ERP und unsere individuellen Anwendungen, wo die Erweiterungen konzipiert und gebaut werden.