[{"data":1,"prerenderedAt":83},["ShallowReactive",2],{"content:blog:ki-funktion-im-bestandscode":3,"content:blog":30},{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":12,"toc":16,"body":29},"ki-funktion-im-bestandscode","KI-Funktion im Bestandscode: ein Vorgang im Repository statt eines zweiten Produkts","Warum eine Erweiterung mit Sprachmodell dieselbe Abnahme braucht wie jede andere Änderung – und woran wir sie messen","2026-09-09","KI-Funktion im Bestandscode: Abnahme statt Demo","KI-Funktion im Bestandscode: dieselbe Datenbank, dieselbe Rechtelogik, ein prüfbares Ergebnis. Zwei Beispiele aus Produktion und Handel in der DACH-Region.","Ein Pilot überzeugt im Termin, eine Erweiterung muss im Betrieb bestehen. Wir beschreiben, wie eine Aufgabe mit Sprachmodell innerhalb eines laufenden Systems geschnitten wird: Kriterium vor Code, eingefrorener Datenausschnitt, erst Vorschläge und dann Schreibrechte. Mit zwei Beispielen aus Produktion und Handel und den Fällen, in denen wir davon abraten.",5,[13,14,15],"KI","Architektur","Arbeitsweise",[17,20,23,26],{"id":18,"text":19},"aufgabe","Was eine KI-Funktion im Bestandscode von einem Piloten unterscheidet",{"id":21,"text":22},"messbar","138 Schreibweisen, 75 Lieferanten: ein prüfbares Ergebnis",{"id":24,"text":25},"grenzen","Wo ein Sprachmodell die falsche Antwort ist",{"id":27,"text":28},"abnahme","KI-Funktion im Bestandscode: so nehmen wir sie ab","\u003Cp>Eine KI-Funktion im Bestandscode ist eine gewöhnliche Entwicklungsaufgabe: dasselbe Repository, dieselbe Rechtelogik, derselbe Releasezyklus, dieselbe Abnahme. Sie wird nicht dadurch besonders, dass ein Sprachmodell darin vorkommt. Besonders ist nur die Frage, woran man ihr Ergebnis misst – und diese Frage entscheidet über den Erfolg des Vorhabens.\u003C\u002Fp>\n\n\u003Ch2 id=\"aufgabe\">Was eine KI-Funktion im Bestandscode von einem Piloten unterscheidet\u003C\u002Fh2>\n\n\u003Cp>Ein Pilot lebt neben dem System. Er bekommt einen Export, rechnet darauf, zeigt ein Ergebnis und überzeugt im Termin. Was danach fehlt, ist jedes Mal dasselbe: Rechte, Protokoll, Fehlerbehandlung, ein Weg zurück in die Fachdaten und jemand, der den Betrieb übernimmt. Der Abstand zwischen einem überzeugenden Piloten und einer benutzbaren Funktion ist deshalb kein Feinschliff, sondern der größere Teil der Arbeit.\u003C\u002Fp>\n\n\u003Cp>Innerhalb des Bestandscodes stellt sich die Sache anders: Die Erkennung oder der Vorschlag ist eine Ebene im vorhandenen System, nicht daneben. Sie liest aus derselben Datenbank, sie schreibt über dieselben Prüfungen, und wer das Ergebnis sehen oder bestätigen darf, entscheidet die Rollenverwaltung, die im Haus ohnehin gilt. Ausgeliefert wird sie im selben Zug wie jede andere Änderung – über denselben Zweig, dieselben Tests, dieselbe Freigabe.\u003C\u002Fp>\n\n\u003Cp>Damit verschiebt sich auch die Frage vor dem Start. Sie lautet nicht mehr, ob ein Modell eine Aufgabe im Prinzip lösen kann; das lässt sich an einem Nachmittag ausprobieren und beweist wenig. Sie lautet: Woran erkennen beide Seiten nach der Lieferung, dass das Ergebnis brauchbar ist? Wer diese Frage nicht beantworten kann, sollte nicht bauen, sondern zuerst die \u003Ca href=\"\u002Flexikon\u002Fabnahme\">Abnahme\u003C\u002Fa> klären.\u003C\u002Fp>\n\n\u003Ch2 id=\"messbar\">138 Schreibweisen, 75 Lieferanten: ein prüfbares Ergebnis\u003C\u002Fh2>\n\n\u003Cp>Zwei Beispiele aus Projekten in Produktion und Handel zeigen, wie so ein Kriterium aussieht. Im ersten ging es um eine Lieferantenliste, die über Jahre aus Belegen gewachsen war: derselbe Betrieb stand dort in vielen Varianten, mit Rechtsform, ohne Rechtsform, mit Tippfehler, mit Zusatz. Ergebnis der Bereinigung: 138 Schreibweisen → 75 Lieferanten; 1 922 Positionen nutzbar.\u003C\u002Fp>\n\n\u003Cp>Das Kriterium war hier nicht „das Modell erkennt Namen gut“, sondern eine Zahl, die jemand im Haus nachzählen kann: Wie viele Positionen lassen sich nach der Bereinigung einem eindeutigen Lieferanten zuordnen und in einen Monatsvergleich bringen. Ein Vorschlag, den niemand bestätigt hat, gilt in dieser Rechnung nicht als Treffer.\u003C\u002Fp>\n\n\u003Cp>Das zweite Beispiel betrifft Preisalarme. Ein Alarm bei jeder Preisänderung erzeugt schnell Blindheit – gemeldet wird alles, angesehen wird nichts. Also wurde verglichen, was vergleichbar ist: gleiche Einheit, gleiche Menge, gleicher Zeitraum. Ergebnis: 1 561 Positionen neu bewertet, unvergleichbare Sprünge herausgefiltert. Auch das ist ein Kriterium, das man prüfen kann, ohne an die Technik zu glauben.\u003C\u002Fp>\n\n\u003Cp>In beiden Fällen entscheidet nicht das Modell, sondern das System. Der Vorschlag kommt aus dem Sprachmodell, die Regel bleibt im Code: Schwellen, Einheiten, Zuordnungen und der Fall, in dem nichts entschieden wird, sondern ein Mensch gefragt wird. In Kundenprojekten prüfen zuerst unsere KI-Werkzeuge jede Änderung, danach ein Entwickler.\u003C\u002Fp>\n\n\u003Ch2 id=\"grenzen\">Wo ein Sprachmodell die falsche Antwort ist\u003C\u002Fh2>\n\n\u003Cp>Die ehrliche Einschränkung zuerst: Ein Modell ersetzt keine fehlende Datenquelle. Wenn die Information, die gebraucht wird, im Haus nirgends steht, entsteht sie auch nicht durch eine sprachliche Näherung – dann ist die richtige Aufgabe eine Anbindung und keine Erkennung. Drei weitere Fälle, in denen wir abraten:\u003C\u002Fp>\n\n\u003Cul>\n\u003Cli>\u003Cstrong>Die Regel ist aufschreibbar.\u003C\u002Fstrong> Was sich als Tabelle, Formel oder eindeutiger Abgleich formulieren lässt, gehört genau dorthin. Das Ergebnis ist reproduzierbar, im Betrieb sparsamer und ohne laufende Kosten je Aufruf.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Das Ergebnis ist nicht prüfbar.\u003C\u002Fstrong> Wo niemand sagen kann, was richtig gewesen wäre, gibt es kein Kriterium und damit keine Abnahme. Solche Vorhaben landen erfahrungsgemäß im Dauerbetrieb der Meinungen.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Die Daten dürfen nicht hinaus.\u003C\u002Fstrong> Welche Felder ein Modell überhaupt zu sehen bekommt und welche vorher entfernt werden, halten wir im Angebot fest. Verarbeiten wir personenbezogene Daten im Auftrag, schließen wir einen Auftragsverarbeitungsvertrag.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Zum Betrieb gehört außerdem eine Grenze, die vor dem Start steht: Anwendungen, die im Betrieb Sprachmodelle nutzen, rufen sie über ein eigenes Gateway auf – mit Protokoll je Aufruf und einer Kostengrenze. Ohne diese Grenze ist der Aufwand einer solchen Erweiterung im Betrieb nicht vorhersehbar, und das ist für den Auftraggeber schlechter als ein langsamerer Weg.\u003C\u002Fp>\n\n\u003Ch2 id=\"abnahme\">KI-Funktion im Bestandscode: so nehmen wir sie ab\u003C\u002Fh2>\n\n\u003Cp>Unser Vorgehen beginnt mit dem Kriterium, nicht mit dem Modell. Zuerst wird festgelegt, an welcher Zahl oder welchem Vergleich das Ergebnis gemessen wird und auf welchem Ausschnitt der echten Daten. Dieser Ausschnitt wird eingefroren, damit später nicht die Grundlage wandert. Erst danach entsteht Code – im bestehenden Zweig, mit Tests, die dieselbe Prüfung automatisch wiederholen.\u003C\u002Fp>\n\n\u003Cp>Geliefert wird in Teilen, und der erste Teil ist bewusst klein: eine Auswertung, die Vorschläge erzeugt, ohne etwas zu verändern. Erst wenn die Zahlen aus der ersten Runde stimmen, bekommt die Erweiterung Schreibrechte. Wie wir das vertraglich fassen und welche Unterlagen dazugehören, steht auf der Seite \u003Ca href=\"\u002Fleistungen\u002Fki-implementierung\">KI-Softwareentwicklung im bestehenden System\u003C\u002Fa>; die Einordnung des Begriffs selbst im Lexikon unter \u003Ca href=\"\u002Flexikon\u002Fki-funktion-in-bestandssoftware\">KI-Funktion in Bestandssoftware\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Cp>Was dabei bewusst nicht passiert: Wir bauen keine zweite Anwendung neben Ihrem System, und wir hinterlassen keine Komponente, die nur wir betreiben können. Die Erweiterung liegt im selben Repository, sie wird mit denselben Werkzeugen ausgeliefert wie der Rest, und die Dokumentation beschreibt sie in der Sprache der Fachlichkeit statt in der des Modells. Mit vollständiger Bezahlung gehen die Nutzungsrechte am eigens erstellten Code auf den Auftraggeber über.\u003C\u002Fp>",[31,38,60],{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":32,"toc":33},[13,14,15],[34,35,36,37],{"id":18,"text":19},{"id":21,"text":22},{"id":24,"text":25},{"id":27,"text":28},{"slug":39,"title":40,"subtitle":41,"date":42,"metaTitle":43,"metaDescription":44,"excerpt":45,"readingMinutes":11,"tags":46,"toc":48},"zweiter-kanal-zur-fachanwendung","Ein zweiter Kanal zur Fachanwendung statt einer zweiten Wahrheit","Was eine mobile Eingabe an der bestehenden Datenbasis ändert – und was sie bewusst nicht ändert","2026-08-31","Zweiter Kanal zur Fachanwendung: mobil, eine Datenbasis","Zweiter Kanal zur Fachanwendung: mobile Eingabe auf derselben Datenbasis und Rechtelogik statt zweiter Datenhaltung. Beispiele und Grenzen aus der DACH-Region.","Im Lager, in der Werkstatt und im Außendienst entstehen Daten dort, wo kein Rechner steht. Die teure Antwort darauf ist eine eigenständige App mit eigener Datenhaltung, die abends abgeglichen wird. Wir beschreiben den schmaleren Weg – drei bis fünf Handgriffe auf derselben Schnittstelle, dieselben Rechte, ein prüfbares Abnahmekriterium – und die drei Fälle, in denen wir davon abraten.",[14,15,47],"Automatisierung",[49,52,55,57],{"id":50,"text":51},"unterschied","Was ein zweiter Kanal zur Fachanwendung technisch bedeutet",{"id":53,"text":54},"zahlen","8 Kassen und 93 Lagerpositionen ohne manuelle Eingabe",{"id":24,"text":56},"Wo wir von einer eigenen App abraten",{"id":58,"text":59},"vorgehen","Zweiter Kanal zur Fachanwendung: wie wir vorgehen",{"slug":61,"title":62,"subtitle":63,"date":64,"metaTitle":65,"metaDescription":66,"excerpt":67,"readingMinutes":11,"tags":68,"toc":70},"warteschlange-vor-dem-eigenen-team","Die Warteschlange vor dem eigenen Team: 346 Belege, die niemand vermisst hat","Warum ein verschobenes Vorhaben keine Kosten spart, sondern welche erzeugt – und woran sich der Unterschied messen lässt","2026-08-19","Warteschlange vor dem eigenen Team: was Aufschub kostet","Warteschlange vor dem eigenen Team: warum aufgeschobene Vorhaben teurer werden – 346 fehlende Belege aus einem Projekt in der DACH-Region als Beispiel.","Aufgaben, die im eigenen Haus auf einen freien Platz warten, gelten als aufgeschoben, nicht als teuer. In einem Projekt ließ sich der Preis des Aufschubs zum ersten Mal nachrechnen: 346 Belege fehlten in einem manuellen Export, den vorher niemand angezweifelt hatte. Was daraus für die Reihenfolge von Vorhaben folgt und wo die Rechnung aufhört.",[15,47,69],"Integration",[71,74,77,80],{"id":72,"text":73},"rueckstau","Was in der Warteschlange vor dem eigenen Team liegen bleibt",{"id":75,"text":76},"belege","346 Belege, die im manuellen Export fehlten",{"id":78,"text":79},"posten","Drei Kostenarten, die der Aufschub erzeugt",{"id":81,"text":82},"verkuerzen","Warteschlange vor dem eigenen Team: wie wir sie verkürzen",1789379446597]