[{"data":1,"prerenderedAt":48},["ShallowReactive",2],{"page:landing-insights:en":3},[4,21,34],{"id":5,"componentName":6,"postTexts":7,"header":16,"contentShort":17,"contentHTML":18,"files":19,"dateInserted":20,"dateChanged":20,"publishDate":20},307,"insight-ai-transformation",[8],{"id":9,"locale":10,"header":11,"contentShort":12,"slug":13,"postId":5,"languageId":14,"automaticTranslation":15},1069,"en","AI transformation is not a technology question","Many processes, architectures and roles were designed for a world in which software was expensive. Introducing AI without questioning those assumptions only automates the old.","insight-ai-transformation-not-a-technology-question",1,false,"KI-Transformation ist keine Technologiefrage","Viele Prozesse, Architekturen und Rollen wurden für eine Welt entworfen, in der Software teuer war. Wer KI nur einführt, ohne diese Annahmen zu hinterfragen, automatisiert das Alte.","\u003Cp>Die meisten KI-Initiativen beginnen mit einer Technologiefrage: Welches Modell? Welche Plattform? Welcher Anwendungsfall? Das ist verständlich – und meistens die falsche erste Frage.\u003C\u002Fp>\u003Ch2>Gebaut für teure Software\u003C\u002Fh2>\u003Cp>Viele Organisationen sind um eine Annahme herum gewachsen, die kaum jemand ausspricht: Software ist teuer, langsam und riskant zu bauen. Daraus folgt vieles. Man kauft große Standardsysteme und passt die Prozesse daran an. Man bündelt Anforderungen über Monate, weil jede Änderung ein Projekt ist. Man schiebt Abstimmungen über Excel und E-Mail hin und her, weil eine kleine Integration sich nicht lohnt. Man trennt Fachbereich und IT scharf, weil Übersetzung zwischen beiden teuer ist.\u003C\u002Fp>\u003Cp>Wenn Anwendungen, Integrationen und Automatisierung in Tagen entstehen, stimmen viele dieser Entscheidungen nicht mehr. Nicht weil sie falsch waren – sondern weil ihre Grundlage weggefallen ist.\u003C\u002Fp>\u003Ch2>Die eigentliche Hürde\u003C\u002Fh2>\u003Cp>Die größte Herausforderung ist daher selten, neue Technologie einzuführen. Sie liegt darin, bestehende Annahmen zu hinterfragen und eingefahrene Muster zu überwinden: Braucht dieser Freigabeprozess wirklich drei Stufen, oder gab es sie nur, weil Fehler früher teuer zu korrigieren waren? Muss dieses Reporting monatlich sein, oder war das nur die Taktung des Batchlaufs? Ist diese Rolle eine fachliche Notwendigkeit, oder überbrückt sie eine Lücke zwischen zwei Systemen?\u003C\u002Fp>\u003Cp>Wer KI einführt, ohne solche Fragen zu stellen, automatisiert das Alte – schneller, aber nicht besser.\u003C\u002Fp>\u003Ch2>Wie ich daran arbeite\u003C\u002Fh2>\u003Cp>Ich arbeite über Strategie, Organisation, Architektur und Umsetzung hinweg: bestehende Modelle analysieren, erkennen, wo sie vereinfacht oder grundlegend neu gestaltet werden sollten, einen pragmatischen Zielzustand festlegen und Teams helfen, die Veränderung tatsächlich umzusetzen. Wichtig ist mir dabei der Kontakt zur technischen Wirklichkeit – eine Zielarchitektur, die niemand bauen kann, ist keine Strategie, sondern eine Folie.\u003C\u002Fp>\u003Cp>\u003Cstrong>Das Modell überdenken. Die Organisation verändern. Strategie in Umsetzung verwandeln.\u003C\u002Fstrong>\u003C\u002Fp>",[],"2026-10-04T20:00:00Z",{"id":22,"componentName":23,"postTexts":24,"header":30,"contentShort":31,"contentHTML":32,"files":33,"dateInserted":20,"dateChanged":20,"publishDate":20},309,"insight-saas-in-two-days",[25],{"id":26,"locale":10,"header":27,"contentShort":28,"slug":29,"postId":22,"languageId":14,"automaticTranslation":15},1077,"Income-and-expense accounting in one week. What this means for SaaS","In one week, an income-and-expense accounting system with builders for quotes, contracts and invoices came together. The remarkable part is not the AI – it is that it was mostly assembly.","insight-income-expense-accounting-in-one-week","Eine Einnahmen-Ausgaben-Rechnung in einer Woche – was das für SaaS bedeutet","In einer Woche ist eine Einnahmen-Ausgaben-Rechnung mit Buildern für Angebote, Verträge und Rechnungen entstanden. Das Bemerkenswerte ist nicht die KI – sondern dass es vor allem Zusammensetzen war.","\u003Cp>Anfang Oktober ist auf der mahevi-Plattform in einer Woche ein Rechnungswesen entstanden: eine Einnahmen-Ausgaben-Rechnung mit Buildern für Angebote, Verträge und Rechnungen, ordnungsgemäßer Rechnungslegung mit Pflichtangaben, Nummernkreisen, E-Rechnung nach ZUGFeRD und digitaler Signatur, dazu Belege per Foto, Mahnwesen, Serienrechnungen und die UVA-Übersicht. Mandantenfähig, in Produktion.\u003C\u002Fp>\u003Cp>Das klingt nach einer Geschichte über KI. Es ist eher eine über Bausteine – und über Kosten.\u003C\u002Fp>\u003Ch2>Eine Woche Zusammensetzen\u003C\u002Fh2>\u003Cp>Ehrlich gesagt war die Woche weniger Neuentwicklung als Zusammenfügen. Mandanten, Rechte, Zwei-Faktor-Anmeldung, Dateiablage, Mailversand mit Vorlagen, PDF-Erzeugung, ein Signaturzertifikat, Bildverarbeitung und ein Seiten-Editor lagen fertig und erprobt da. Neu war die Domäne: was eine Rechnung, ein Angebot und ein Vertrag sind, welche Angaben Pflicht sind, was sich nach dem Abschluss nie mehr ändern darf und wie Cent-Beträge gerundet werden. Die KI hat die Umsetzung dazwischen beschleunigt – das Modell und die Bausteine hat sie nicht geliefert.\u003C\u002Fp>\u003Ch2>Was sich verschoben hat\u003C\u002Fh2>\u003Cp>Ein Rechnungsprogramm war lange ein klassischer Fall für „kaufen statt bauen“. Die Fachlichkeit ist überschaubar, aber die Umsetzung kostete Monate. Diese Monate waren der Grund für den Markt.\u003C\u002Fp>\u003Cp>Wenn eine Organisation über gute, wiederverwendbare Bausteine verfügt und die Umsetzung KI-gestützt in Tagen geschieht, bleibt vom Preis eines Standardprodukts vor allem eines übrig: das Wissen, was die Software können muss. Dieses Wissen ist oft im Haus – es war nur zu teuer, es in Software zu gießen.\u003C\u002Fp>\u003Ch2>Was es nicht bedeutet\u003C\u002Fh2>\u003Cp>Nicht jede Firma sollte ihre Buchhaltung selbst bauen. Betrieb, Haftung, Weiterentwicklung und gesetzliche Änderungen kosten weiter Geld. Und ohne die vorhandenen Bausteine wäre es nicht eine Woche gewesen.\u003C\u002Fp>\u003Cp>Aber die Grenze zwischen „kaufen“ und „bauen“ wird neu gezogen – und sie hängt weniger an der Programmierleistung als an zwei Fragen: Verstehst du die Domäne? Und hast du die Bausteine, aus denen sich Neues schnell zusammensetzen lässt? Wer beides hat, baut Software um die eigenen Prozesse herum, statt die Prozesse an Standardsoftware anzupassen.\u003C\u002Fp>",[],{"id":35,"componentName":36,"postTexts":37,"header":43,"contentShort":44,"contentHTML":45,"files":46,"dateInserted":47,"dateChanged":47,"publishDate":47},311,"insight-contradictions-not-extraction",[38],{"id":39,"locale":10,"header":40,"contentShort":41,"slug":42,"postId":35,"languageId":14,"automaticTranslation":15},1085,"LLM extraction isn’t the hard part – modelling the knowledge in context is","A language model reads values from documents remarkably well. The hard part is modelling what was read in context – and when two documents say different things, that is where it is decided whether the system can be trusted.","insight-modelling-knowledge-in-context","LLM-Extraktion ist nicht das Schwierige – das Wissen im Zusammenhang zu modellieren schon","Ein Sprachmodell liest Werte aus Dokumenten erstaunlich gut. Schwierig ist, das Gelesene im Zusammenhang zu modellieren – spätestens wenn zwei Dokumente Verschiedenes sagen, entscheidet sich dort, ob man dem System trauen kann.","\u003Cp>Die erste Demo einer Dokumentenextraktion mit einem Sprachmodell ist fast immer beeindruckend. Man gibt einen Vertrag hinein und bekommt Parteien, Laufzeit, Beträge und Kündigungsfristen sauber als Daten zurück. Nach einem Nachmittag wirkt das Problem gelöst.\u003C\u002Fp>\u003Cp>Es ist es nicht. Die Extraktion ist der einfache Teil. Schwierig ist, das Gelesene im Zusammenhang zu modellieren: Was gehört zusammen, was ersetzt was, was gilt ab wann – und was widerspricht sich?\u003C\u002Fp>\u003Ch2>Die echte Welt widerspricht sich\u003C\u002Fh2>\u003Cp>In echten Dokumentenbeständen sagen Dokumente Verschiedenes. Der Vertrag nennt eine Laufzeit, der Nachtrag eine andere. Die Rechnung weist einen Betrag aus, der nicht zur Bestellung passt. Ein Gutachten von 2021 und eines von 2023 kommen zu unterschiedlichen Werten. Manchmal widerspricht sich sogar ein einzelnes Dokument – im Text steht etwas anderes als in der Tabelle.\u003C\u002Fp>\u003Cp>Ein Sprachmodell löst solche Widersprüche still auf. Es wählt eine Antwort, meist eine plausible, und präsentiert sie mit derselben Sicherheit wie alles andere. Genau das ist das Risiko: nicht der offensichtliche Fehler, sondern die glaubwürdige falsche Antwort.\u003C\u002Fp>\u003Ch2>Embeddings helfen beim Finden, nicht beim Entscheiden\u003C\u002Fh2>\u003Cp>Retrieval mit Embeddings findet relevante Stellen. Ob zwei gefundene Stellen dasselbe meinen, einander ergänzen oder einander widersprechen, beantwortet es nicht. Dafür braucht es ein Modell der Domäne: Was ist ein Nachtrag, was ersetzt er, welches Dokument hat Vorrang, ab wann gilt etwas?\u003C\u002Fp>\u003Ch2>Wie ein verlässliches System damit umgeht\u003C\u002Fh2>\u003Cul>\u003Cli>\u003Cstrong>Jeder Wert mit Quellenangabe:\u003C\u002Fstrong> Seite, Abschnitt, Dokument. Ohne Fundstelle kein Wert.\u003C\u002Fli>\u003Cli>\u003Cstrong>Regeln vor Vertrauen:\u003C\u002Fstrong> deterministische Prüfungen für alles, was sich prüfen lässt – Summen, Fristen, Abhängigkeiten, Vorrang.\u003C\u002Fli>\u003Cli>\u003Cstrong>Konflikte als Objekte:\u003C\u002Fstrong> Ein Widerspruch wird nicht aufgelöst, sondern gespeichert – mit beiden Quellen.\u003C\u002Fli>\u003Cli>\u003Cstrong>Der Mensch entscheidet, das System merkt es sich:\u003C\u002Fstrong> Eine Fachperson klärt den Konflikt, und die Entscheidung wird Teil der Daten.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Das klingt nach mehr Arbeit als „Modell fragen, Antwort speichern“. Es ist der Unterschied zwischen einer Demo und einem System, auf dessen Daten man Entscheidungen bauen kann.\u003C\u002Fp>",[],"2026-08-25T14:55:00Z",1791144728544]