Der Code gehört der Firma. Genau das fehlt in der Ablöserechnung.

Es gibt interne Systeme, die über lange Zeit im Alltag verschwinden, weil sie funktionieren. Sie kosten keine Lizenz, kein Abo und keine Verhandlung mit einem Hersteller über den nächsten Release-Zug. Was sie kosten, ist gelegentliche Wartung und gelegentliche Weiterentwicklung — also genau die Art von Aufwand, die in einer Folie leicht als «technisch überholt» erscheint, weil sie nicht als Produktpreis auftritt. Irgendwann hat so ein System teurer Spezialistenzeit spürbar Arbeit abgenommen, nicht als Versprechen, sondern im Betrieb. Die Prozesse sind ruhig geworden. Und genau dann, wenn das Unspektakuläre zum Betriebskapital geworden ist, kommt der Satz, man müsse ablösen: modern, Standard, zukunftssicher.

Ich halte die Vermutung für begründet, dass man mit einer gewachsenen Eigenlösung, deren Quellcode der Firma gehört, in der Regel nicht wieder so günstig fahren wird wie bisher — vorausgesetzt, jemand kann und will sie noch verantworten. Mir ist bewusst, dass solche Software nicht perfekt ist. Sie war es nie, und Perfektion ist nicht die Währung, in der sich die Entscheidung entscheidet. Die Währung ist Fit, Besitz und die Frage, ob eine Ablöse den Nutzen, den Migrationsverlust, die laufenden Lizenzen und den Verlust, künstliche Intelligenz auf eigenes Prozesskapital anzusetzen, tatsächlich übersteigt. Die Oberfläche älter aussehen zu lassen als ein Verkaufsdemo, reicht dafür nicht.

Was man wirklich besitzt

Man besitzt in so einem Fall kein generisches Paket von Modulen, das man gegen ein anderes Paket derselben Broschüre tauschen könnte. Man besitzt abgebildete Arbeit: Regeln, die sich in Masken und Speicherlogik materialisiert haben, stille Ausnahmen, die niemand mehr aufschreibt, weil sie seit langem stimmen, und eine Menge von Kantenfällen, die sich nicht in einem Lastenheft finden, sondern nur noch im laufenden System. Wer das System täglich benutzt, merkt sie nicht. Wer ein Standardprodukt einführt, merkt sie alle auf einmal, und zwar genau dann, wenn Parallelbetrieb, Schulung und Go-live-Druck bereits laufen.

Das steht in keiner Bilanz. Es ist trotzdem Vermögen, versioniert und wiederholbar, und es gehört der Firma, sofern der Quellcode ihr gehört. Ein lizenziertes Produkt liefert Funktionen und oft auch Integrationsversprechen. Es liefert nicht die geronnene Betriebsgeschichte. Die muss man nachbauen, in teuren Change-Requests verhandeln oder stillschweigend aufgeben. Aufgeben fühlt sich in der Präsentation nach Vereinfachung an. Im Betrieb fühlt es sich nach den Monaten an, die das alte System einmal eingespart hat.

KI und Eigentum am Code

An dieser Stelle ändert sich die Rechnung gegenüber der Zeit, in der «niemand kennt den Stack mehr» noch ein fast automatisch überzeugendes Ablöseargument war. Künstliche Intelligenz beschleunigt Arbeit am Code, den man lesen darf. Sie erklärt Zusammenhänge, erzeugt Testdaten, sucht Regressionen, schlägt Patches vor und verkürzt die Einarbeit einer zweiten Person, weil das Repo die Spezifikation ist und nicht das Gedächtnis eines einzelnen Einführers. Das Personenrisiko sinkt dadurch nicht auf null, aber es sinkt spürbar: Eine zweite Person steigt nicht in ein Geheimnis ein, sondern in ein Archiv, das der Firma gehört.

Ein Hersteller gibt den Kerncode in aller Regel nicht heraus. KI sieht dort höchstens Schnittstellen, Konfiguration und das, was man selbst darum herum gebaut hat. Die Fachlogik bleibt hinter einer Lizenz, Change-Requests bleiben Tickets, Angebote und Warteschlangen, und «wir nutzen jetzt auch KI» ändert daran nichts, solange das Prozesskapital nicht bei euch liegt. Das ist die Asymmetrie, die in Ablösediskussionen oft fehlt: KI arbeitet auf dem, was ihr besitzen dürft. Geschlossene Software besitzt ihr nicht.

Prozesskapital im eigenen Repository ist versioniert und wiederholbar. Im lizenzierten Produkt sitzt es beim Hersteller und in Beraterköpfen, die nach dem Projekt weiterziehen. Ein Feature oder ein Fehler ist intern ein Commit, ein Test, ein Release, das ihr steuert. Beim Vendor ist es ein Ticket mit Preis und Termin, den ihr nicht setzt. Die Einarbeit einer zweiten Person dauert am eigenen Code Monate und wird mit KI kürzer. Am eingeführten Standard dauert sie oft so lange wie das Projekt selbst, und ein Teil des Wissens geht mit dem Einführer.

KI ersetzt das Urteil nicht. Sie halluziniert, und ohne Review und ohne jemanden, der die Arbeit kennt, landet Müll schneller im Hauptzweig als früher, nicht langsamer. Sie löscht auch nicht, dass ein gewachsener Stack unüblich sein kann. Sie macht ihn zugänglicher. Das reicht häufig, um «keiner kann das mehr» als alleinigen Ablösegrund zu entkräften. Es reicht nicht, Verantwortung abzugeben oder den Lebenszyklus von Laufzeit, Datenbank und Clients zu ignorieren. «Läuft ja» ist kein Plan. Es ist nur billiger als ein Einführungsprojekt, das denselben Plan trotzdem braucht, plus Lizenz, plus Migration.

Behalten und weiterbauen

Die Chance des Weiterbetriebs liegt in den Grenzkosten. Sie bleiben Wartung plus gezielte Features. Es gibt kein Vendor-Lock-in in dem Sinn, dass ein Hersteller Tempo und Preis der nächsten Änderung diktiert, und es gibt kein Jahresabo, das steigt, weil die Preisliste steigt. Anpassungen dauern Tage bis wenige Wochen, mit KI am eigenen Repository oft kürzer als der Schriftverkehr, den ein Customizing-Angebot braucht. Prozesse, die ruhig laufen, laufen weiter, und die historische Arbeitsersparnis bleibt, solange der Fit bleibt. Engpässe und bekannte Lücken sind lokal behebbar, häufig günstiger als ein Einführungsprojekt, gerade weil die Fachlogik schon im Code steht und nicht erst in Workshops rekonstruiert werden muss.

Die Gefahr des Weiterbetriebs ist real und sollte nicht kleingeredet werden. Wissen sitzt oft noch bei wenigen Köpfen. KI mildert das, ersetzt aber weder Domänenurteil noch eine Person, die im Zweifel nein sagt. Der Stack kann unüblich bleiben; der Markt dafür wird nicht breiter, nur die Zugänglichkeit des bestehenden Codes. Es fehlt häufig Web, Mobil und ein Ökosystem aus Standardkonnektoren, das Verkäufer von Plattformen gerne als Zukunft bezeichnen. Fachliche Lücken bleiben Lücken, bis jemand sie baut. Sicherheits- und Betriebssystem-Lebenszyklus müssen bewusst geplant werden. Wer das nicht tut, hat kein günstiges System, sondern ein aufgeschobenes Risiko.

Ablöse durch Standardsoftware

Die Chance einer Ablöse ist nicht leer. Es gibt einen grösseren Personalmarkt für verbreitete Produkte, Hersteller-Updates, oft Web und Mobil, Integrationen, die man nicht selbst pflegen will. Die Abhängigkeit von einer einzelnen Person kann sinken, sofern das neue System wirklich Standard bleibt und nicht durch Customizing wieder zur Eigenlösung wird, nur ohne Besitz. Politisch ist «modern» und «auditierbar» leichter zu verkaufen. Für Wachstum über Standorte hinweg, für Konzernvorgaben oder für einen Verkauf der Firma kann Standardsoftware ein Argument sein, das mit Betriebskosten wenig zu tun hat und trotzdem entscheidet. KI hilft am ERP-Kern in diesem Szenario kaum, weil der Code nicht euch gehört; sie hilft höchstens an den Rändern, die ihr selbst bauen dürft.

Die Gefahr ist das Muster, das sich in Vorhaben dieser Art wiederholt: Lizenz plus Customizing plus Parallelbetrieb plus Schulung plus Nacharbeit über einen Zeitraum, in dem das Kerngeschäft nicht wartet. Der «Standard» wird an die Sonderfälle gebogen, die das alte System bereits kannte, und am Ende hat man wieder eine Eigenlösung, nur teurer, mit laufendem Abo, und der Kerncode liegt beim Vendor. Stabile Prozesse brechen in der Transition, auch wenn die Folie das Gegenteil behauptet. Die historische Ersparnis kann in genau dieser Phase verloren gehen und kehrt erst zurück, wenn das neue System denselben Fit hat — den das Angebot in der Regel unterstellt, ohne ihn bewiesen zu haben. Daten und Kantenfälle, die im eigenen Code nachvollziehbar sind, müssen im neuen System teuer nachgebaut oder weggelassen werden. Tempo und Preis setzt der Hersteller. KI ändert daran nichts.

Kostenlogik, ohne Zahlen zu erfinden

Lizenz und Abo sind bei der Eigenlösung im Wesentlichen das, was ohnehin für Datenbank und Werkzeuge anfällt. Bei der Ablöse sind sie jährlich und oft steigend, unabhängig davon, ob der Fit schon da ist.

Eine Änderung am Prozess ist intern Tage bis Wochen wert, mit KI am eigenen Repository häufig schneller, weil der Code die Spezifikation ist. Beim Vendor ist dieselbe Änderung ein Angebot und eine Warteschlange; KI sieht den Kern nicht.

Das Risiko, dass etwas «nicht geht», ist bei der Eigenlösung meist eine bekannte Lücke, die man zeitlich und fachlich einordnen kann. Bei der Ablöse zeigt sich der Fit-Gap oft erst im Projekt, also dann, wenn bereits Kosten und Verpflichtungen laufen.

Wissen liegt im einen Fall im Repository, das die Firma besitzt; KI senkt die Einarbeit und ersetzt Review nicht. Im anderen Fall liegen Wissen und Tempo bei Beratern und einem internen Kernteam, das für die Dauer des Vorhabens gebunden ist. Die Fachlogik sitzt danach nicht automatisch bei euch.

Der Nutzen, den das alte System im Alltag erzeugt hat, bleibt, wenn die Anwendung bleibt. Nach einer Ablöse ist er erst wieder da, wenn das neue System denselben Fit hat. Eine Ablöse muss deshalb historischen Nutzen, Migrationsverlust, laufende Lizenzen und den Verlust «KI auf eigenem Code» schlagen. Die meisten Vorhaben, die vor allem eine modernere Oberfläche versprechen, tun das nicht. Genaue Beträge gehören in Offerten, nicht in diesen Text. Die Richtung der Rechnung reicht, um die richtige Frage zu stellen.

Wann Ablöse trotzdem rational ist

Nicht nie. Nur seltener, als die Folie behauptet, und seltener, als «alter Stack» allein nahelegt.

Wenn niemand die Verantwortung will, auch nicht mit einer zweiten Person und KI am eigenen Repository, dann ist Weiterbetrieb das teurere Risiko. Unüblichkeit der Technik allein ist dafür oft nicht mehr ausreichend, sobald der Code euch gehört und zugänglich gemacht werden kann.

Wenn die Strategie Web, Verbund oder eine Konzernvorgabe wirklich verlangt und das bestehende System das nicht werden soll, ist Ablöse oder Teilablöse ein Strategieentscheid, kein Kostenvergleich im engeren Sinn.

Wenn eine fachliche Lücke das Geschäft blockiert und nicht nur den Komfort stört, und intern bewusst nicht gebaut werden soll, kann ein Produkt, das genau diese Lücke schliesst, der kürzere Weg sein — sofern man den Rest nicht mitabschafft, nur weil man schon «in Ablöse» ist.

Wenn die Firma verkauft oder integriert werden soll, zahlen Käufer häufig für Standard, nicht für Unikat, trotz eigenem Code. Das ist ein Eigentümerargument. Man sollte es nicht mit der Behauptung verwechseln, der Betrieb werde dadurch billiger.

«Die Oberfläche sieht alt aus» gehört nicht auf diese Liste.

Der dritte Weg

Der günstigste Weg ist in vielen Fällen weder die grosse Ablöse noch das bewusste Nichtstun. Er besteht darin, eine zweite Person aufzubauen, künstliche Intelligenz am eigenen Code einzusetzen, den Lebenszyklus von Laufzeit, Datenbank und Clients zu planen und die schmerzhaften Lücken gezielt zu schliessen, während der Rest so bleibt, wie er den Betrieb trägt. Ablösen sollte man dort, wo ein Stück wirklich fremd ist und fremd bleiben darf. Den Kern sollte man behalten, weil der Kern euch gehört und weil genau dort die geronnene Arbeit liegt, die kein Hersteller mitliefert.

Das ist unspektakulär. Es wirft das Betriebskapital nicht weg, und es leugnet das Personenrisiko nicht. Es nutzt den einzigen Hebel, den ein lizenziertes Produkt in dieser Konstellation nicht hat: KI auf Prozesskapital, das im eigenen Repository liegt.

Was man fragen kann, bevor jemand «Ablöse» sagt

Welcher nachweisbare Nutzen schlägt Lizenz, Projekt, vorübergehenden Produktivitätsverlust und den Verlust, künstliche Intelligenz auf euer eigenes Prozesskapital anzusetzen?

Welche Kantenfälle des bestehenden Betriebs sind im Angebot enthalten, schriftlich, nicht als Satz «das macht der Standard»?

Wer besitzt nach dem Go-live den Code, in dem eure Regeln stehen — und darf eine Maschine ihn lesen, erklären und verändern, oder nur ein Ticket beim Hersteller?

Wenn die Antworten dünn sind, ist die günstige Lösung oft die, die bereits läuft. Nicht weil sie perfekt ist. Weil sie der Firma gehört, weil die Prozesse ruhig sind, und weil Besitz am Quellcode in einer Zeit, in der KI den eigenen Code beschleunigt und den fremden nicht, mehr wert ist als eine modernere Hülle um Regeln, die man danach teuer nachbauen muss.