Es gibt interne Systeme, die \u00fcber lange Zeit im Alltag verschwinden, weil sie funktionieren. Sie kosten keine Lizenz, kein Abo und keine Verhandlung mit einem Hersteller \u00fcber den n\u00e4chsten Release-Zug. Was sie kosten, ist gelegentliche Wartung und gelegentliche Weiterentwicklung \u2014 also genau die Art von Aufwand, die in einer Folie leicht als \u00abtechnisch \u00fcberholt\u00bb erscheint, weil sie nicht als Produktpreis auftritt. Irgendwann hat so ein System teurer Spezialistenzeit sp\u00fcrbar Arbeit abgenommen, nicht als Versprechen, sondern im Betrieb. Die Prozesse sind ruhig geworden. Und genau dann, wenn das Unspektakul\u00e4re zum Betriebskapital geworden ist, kommt der Satz, man m\u00fcsse abl\u00f6sen: modern, Standard, zukunftssicher.<\/p>\n\n\n\n
Ich halte die Vermutung f\u00fcr begr\u00fcndet, dass man mit einer gewachsenen Eigenl\u00f6sung, deren Quellcode der Firma geh\u00f6rt, in der Regel nicht wieder so g\u00fcnstig fahren wird wie bisher \u2014 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\u00e4hrung, in der sich die Entscheidung entscheidet. Die W\u00e4hrung ist Fit, Besitz und die Frage, ob eine Abl\u00f6se den Nutzen, den Migrationsverlust, die laufenden Lizenzen und den Verlust, k\u00fcnstliche Intelligenz auf eigenes Prozesskapital anzusetzen, tats\u00e4chlich \u00fcbersteigt. Die Oberfl\u00e4che \u00e4lter aussehen zu lassen als ein Verkaufsdemo, reicht daf\u00fcr nicht.<\/p>\n\n\n\n
Man besitzt in so einem Fall kein generisches Paket von Modulen, das man gegen ein anderes Paket derselben Brosch\u00fcre tauschen k\u00f6nnte. 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\u00e4llen, die sich nicht in einem Lastenheft finden, sondern nur noch im laufenden System. Wer das System t\u00e4glich benutzt, merkt sie nicht. Wer ein Standardprodukt einf\u00fchrt, merkt sie alle auf einmal, und zwar genau dann, wenn Parallelbetrieb, Schulung und Go-live-Druck bereits laufen.<\/p>\n\n\n\n
Das steht in keiner Bilanz. Es ist trotzdem Verm\u00f6gen, versioniert und wiederholbar, und es geh\u00f6rt der Firma, sofern der Quellcode ihr geh\u00f6rt. 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\u00fchlt sich in der Pr\u00e4sentation nach Vereinfachung an. Im Betrieb f\u00fchlt es sich nach den Monaten an, die das alte System einmal eingespart hat.<\/p>\n\n\n\n
An dieser Stelle \u00e4ndert sich die Rechnung gegen\u00fcber der Zeit, in der \u00abniemand kennt den Stack mehr\u00bb noch ein fast automatisch \u00fcberzeugendes Abl\u00f6seargument war. K\u00fcnstliche Intelligenz beschleunigt Arbeit am Code, den man lesen darf. Sie erkl\u00e4rt Zusammenh\u00e4nge, erzeugt Testdaten, sucht Regressionen, schl\u00e4gt Patches vor und verk\u00fcrzt die Einarbeit einer zweiten Person, weil das Repo die Spezifikation ist und nicht das Ged\u00e4chtnis eines einzelnen Einf\u00fchrers. Das Personenrisiko sinkt dadurch nicht auf null, aber es sinkt sp\u00fcrbar: Eine zweite Person steigt nicht in ein Geheimnis ein, sondern in ein Archiv, das der Firma geh\u00f6rt.<\/p>\n\n\n\n
Ein Hersteller gibt den Kerncode in aller Regel nicht heraus. KI sieht dort h\u00f6chstens 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 \u00abwir nutzen jetzt auch KI\u00bb \u00e4ndert daran nichts, solange das Prozesskapital nicht bei euch liegt. Das ist die Asymmetrie, die in Abl\u00f6sediskussionen oft fehlt: KI arbeitet auf dem, was ihr besitzen d\u00fcrft. Geschlossene Software besitzt ihr nicht.<\/p>\n\n\n\n
Prozesskapital im eigenen Repository ist versioniert und wiederholbar. Im lizenzierten Produkt sitzt es beim Hersteller und in Beraterk\u00f6pfen, 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\u00fcrzer. Am eingef\u00fchrten Standard dauert sie oft so lange wie das Projekt selbst, und ein Teil des Wissens geht mit dem Einf\u00fchrer.<\/p>\n\n\n\n
KI ersetzt das Urteil nicht. Sie halluziniert, und ohne Review und ohne jemanden, der die Arbeit kennt, landet M\u00fcll schneller im Hauptzweig als fr\u00fcher, nicht langsamer. Sie l\u00f6scht auch nicht, dass ein gewachsener Stack un\u00fcblich sein kann. Sie macht ihn zug\u00e4nglicher. Das reicht h\u00e4ufig, um \u00abkeiner kann das mehr\u00bb als alleinigen Abl\u00f6segrund zu entkr\u00e4ften. Es reicht nicht, Verantwortung abzugeben oder den Lebenszyklus von Laufzeit, Datenbank und Clients zu ignorieren. \u00abL\u00e4uft ja\u00bb ist kein Plan. Es ist nur billiger als ein Einf\u00fchrungsprojekt, das denselben Plan trotzdem braucht, plus Lizenz, plus Migration.<\/p>\n\n\n\n
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\u00e4chsten \u00c4nderung 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\u00fcrzer als der Schriftverkehr, den ein Customizing-Angebot braucht. Prozesse, die ruhig laufen, laufen weiter, und die historische Arbeitsersparnis bleibt, solange der Fit bleibt. Engp\u00e4sse und bekannte L\u00fccken sind lokal behebbar, h\u00e4ufig g\u00fcnstiger als ein Einf\u00fchrungsprojekt, gerade weil die Fachlogik schon im Code steht und nicht erst in Workshops rekonstruiert werden muss.<\/p>\n\n\n\n
Die Gefahr des Weiterbetriebs ist real und sollte nicht kleingeredet werden. Wissen sitzt oft noch bei wenigen K\u00f6pfen. KI mildert das, ersetzt aber weder Dom\u00e4nenurteil noch eine Person, die im Zweifel nein sagt. Der Stack kann un\u00fcblich bleiben; der Markt daf\u00fcr wird nicht breiter, nur die Zug\u00e4nglichkeit des bestehenden Codes. Es fehlt h\u00e4ufig Web, Mobil und ein \u00d6kosystem aus Standardkonnektoren, das Verk\u00e4ufer von Plattformen gerne als Zukunft bezeichnen. Fachliche L\u00fccken bleiben L\u00fccken, bis jemand sie baut. Sicherheits- und Betriebssystem-Lebenszyklus m\u00fcssen bewusst geplant werden. Wer das nicht tut, hat kein g\u00fcnstiges System, sondern ein aufgeschobenes Risiko.<\/p>\n\n\n\n
Die Chance einer Abl\u00f6se ist nicht leer. Es gibt einen gr\u00f6sseren Personalmarkt f\u00fcr verbreitete Produkte, Hersteller-Updates, oft Web und Mobil, Integrationen, die man nicht selbst pflegen will. Die Abh\u00e4ngigkeit von einer einzelnen Person kann sinken, sofern das neue System wirklich Standard bleibt und nicht durch Customizing wieder zur Eigenl\u00f6sung wird, nur ohne Besitz. Politisch ist \u00abmodern\u00bb und \u00abauditierbar\u00bb leichter zu verkaufen. F\u00fcr Wachstum \u00fcber Standorte hinweg, f\u00fcr Konzernvorgaben oder f\u00fcr 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\u00f6rt; sie hilft h\u00f6chstens an den R\u00e4ndern, die ihr selbst bauen d\u00fcrft.<\/p>\n\n\n\n
Die Gefahr ist das Muster, das sich in Vorhaben dieser Art wiederholt: Lizenz plus Customizing plus Parallelbetrieb plus Schulung plus Nacharbeit \u00fcber einen Zeitraum, in dem das Kerngesch\u00e4ft nicht wartet. Der \u00abStandard\u00bb wird an die Sonderf\u00e4lle gebogen, die das alte System bereits kannte, und am Ende hat man wieder eine Eigenl\u00f6sung, 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\u00fcck, wenn das neue System denselben Fit hat \u2014 den das Angebot in der Regel unterstellt, ohne ihn bewiesen zu haben. Daten und Kantenf\u00e4lle, die im eigenen Code nachvollziehbar sind, m\u00fcssen im neuen System teuer nachgebaut oder weggelassen werden. Tempo und Preis setzt der Hersteller. KI \u00e4ndert daran nichts.<\/p>\n\n\n\n
Lizenz und Abo sind bei der Eigenl\u00f6sung im Wesentlichen das, was ohnehin f\u00fcr Datenbank und Werkzeuge anf\u00e4llt. Bei der Abl\u00f6se sind sie j\u00e4hrlich und oft steigend, unabh\u00e4ngig davon, ob der Fit schon da ist.<\/p>\n\n\n\n
Eine \u00c4nderung am Prozess ist intern Tage bis Wochen wert, mit KI am eigenen Repository h\u00e4ufig schneller, weil der Code die Spezifikation ist. Beim Vendor ist dieselbe \u00c4nderung ein Angebot und eine Warteschlange; KI sieht den Kern nicht.<\/p>\n\n\n\n
Das Risiko, dass etwas \u00abnicht geht\u00bb, ist bei der Eigenl\u00f6sung meist eine bekannte L\u00fccke, die man zeitlich und fachlich einordnen kann. Bei der Abl\u00f6se zeigt sich der Fit-Gap oft erst im Projekt, also dann, wenn bereits Kosten und Verpflichtungen laufen.<\/p>\n\n\n\n
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\u00fcr die Dauer des Vorhabens gebunden ist. Die Fachlogik sitzt danach nicht automatisch bei euch.<\/p>\n\n\n\n
Der Nutzen, den das alte System im Alltag erzeugt hat, bleibt, wenn die Anwendung bleibt. Nach einer Abl\u00f6se ist er erst wieder da, wenn das neue System denselben Fit hat. Eine Abl\u00f6se muss deshalb historischen Nutzen, Migrationsverlust, laufende Lizenzen und den Verlust \u00abKI auf eigenem Code\u00bb schlagen. Die meisten Vorhaben, die vor allem eine modernere Oberfl\u00e4che versprechen, tun das nicht. Genaue Betr\u00e4ge geh\u00f6ren in Offerten, nicht in diesen Text. Die Richtung der Rechnung reicht, um die richtige Frage zu stellen.<\/p>\n\n\n\n
Nicht nie. Nur seltener, als die Folie behauptet, und seltener, als \u00abalter Stack\u00bb allein nahelegt.<\/p>\n\n\n\n
Wenn niemand die Verantwortung will, auch nicht mit einer zweiten Person und KI am eigenen Repository, dann ist Weiterbetrieb das teurere Risiko. Un\u00fcblichkeit der Technik allein ist daf\u00fcr oft nicht mehr ausreichend, sobald der Code euch geh\u00f6rt und zug\u00e4nglich gemacht werden kann.<\/p>\n\n\n\n
Wenn die Strategie Web, Verbund oder eine Konzernvorgabe wirklich verlangt und das bestehende System das nicht werden soll, ist Abl\u00f6se oder Teilabl\u00f6se ein Strategieentscheid, kein Kostenvergleich im engeren Sinn.<\/p>\n\n\n\n
Wenn eine fachliche L\u00fccke das Gesch\u00e4ft blockiert und nicht nur den Komfort st\u00f6rt, und intern bewusst nicht gebaut werden soll, kann ein Produkt, das genau diese L\u00fccke schliesst, der k\u00fcrzere Weg sein \u2014 sofern man den Rest nicht mitabschafft, nur weil man schon \u00abin Abl\u00f6se\u00bb ist.<\/p>\n\n\n\n
Wenn die Firma verkauft oder integriert werden soll, zahlen K\u00e4ufer h\u00e4ufig f\u00fcr Standard, nicht f\u00fcr Unikat, trotz eigenem Code. Das ist ein Eigent\u00fcmerargument. Man sollte es nicht mit der Behauptung verwechseln, der Betrieb werde dadurch billiger.<\/p>\n\n\n\n
\u00abDie Oberfl\u00e4che sieht alt aus\u00bb geh\u00f6rt nicht auf diese Liste.<\/p>\n\n\n\n
Der g\u00fcnstigste Weg ist in vielen F\u00e4llen weder die grosse Abl\u00f6se noch das bewusste Nichtstun. Er besteht darin, eine zweite Person aufzubauen, k\u00fcnstliche Intelligenz am eigenen Code einzusetzen, den Lebenszyklus von Laufzeit, Datenbank und Clients zu planen und die schmerzhaften L\u00fccken gezielt zu schliessen, w\u00e4hrend der Rest so bleibt, wie er den Betrieb tr\u00e4gt. Abl\u00f6sen sollte man dort, wo ein St\u00fcck wirklich fremd ist und fremd bleiben darf. Den Kern sollte man behalten, weil der Kern euch geh\u00f6rt und weil genau dort die geronnene Arbeit liegt, die kein Hersteller mitliefert.<\/p>\n\n\n\n
Das ist unspektakul\u00e4r. 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.<\/p>\n\n\n\n
Welcher nachweisbare Nutzen schl\u00e4gt Lizenz, Projekt, vor\u00fcbergehenden Produktivit\u00e4tsverlust und den Verlust, k\u00fcnstliche Intelligenz auf euer eigenes Prozesskapital anzusetzen?<\/p>\n\n\n\n
Welche Kantenf\u00e4lle des bestehenden Betriebs sind im Angebot enthalten, schriftlich, nicht als Satz \u00abdas macht der Standard\u00bb?<\/p>\n\n\n\n
Wer besitzt nach dem Go-live den Code, in dem eure Regeln stehen \u2014 und darf eine Maschine ihn lesen, erkl\u00e4ren und ver\u00e4ndern, oder nur ein Ticket beim Hersteller?<\/p>\n\n\n\n
Wenn die Antworten d\u00fcnn sind, ist die g\u00fcnstige L\u00f6sung oft die, die bereits l\u00e4uft. Nicht weil sie perfekt ist. Weil sie der Firma geh\u00f6rt, 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\u00fclle um Regeln, die man danach teuer nachbauen muss.<\/p>\n","protected":false},"excerpt":{"rendered":"
Es gibt interne Systeme, die \u00fcber lange Zeit im Alltag verschwinden, weil sie funktionieren. Sie kosten keine Lizenz, kein Abo und keine Verhandlung mit einem Hersteller \u00fcber den n\u00e4chsten Release-Zug. Was sie kosten, ist gelegentliche Wartung und gelegentliche Weiterentwicklung \u2014 also genau die Art von Aufwand, die in einer Folie leicht als \u00abtechnisch \u00fcberholt\u00bb erscheint, […]<\/p>\n","protected":false},"author":1,"featured_media":278,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,45],"tags":[87,161],"class_list":["post-277","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software-architecture","category-technology-management","tag-german","tag-outsourcing"],"_links":{"self":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/277","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=277"}],"version-history":[{"count":1,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/277\/revisions"}],"predecessor-version":[{"id":279,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/277\/revisions\/279"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/media\/278"}],"wp:attachment":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=277"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=277"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=277"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}