[{"data":1,"prerenderedAt":96},["ShallowReactive",2],{"content:blog:abnahmekriterien-statt-zusagen":3,"content:blog":33},{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":12,"toc":16,"body":32},"abnahmekriterien-statt-zusagen","Abnahmekriterien statt Zusagen: wie aus „bauen Sie uns etwas“ ein prüfbarer Satz wird","Welche drei Fragen wir stellen, was davon ins Angebot kommt – und wo wir uns selbst geschadet haben","2026-08-14","Prüfbare Kriterien statt Zusagen: so entsteht ein Angebot","Wie aus einem vagen Wunsch ein Abnahmekriterium wird, das vor dem Start im Angebot steht: drei Fragen, drei Beispiele aus Projekten und unsere eigenen Fehler.","„Bauen Sie uns ein System für die Bestellungen“ ist ein Wunsch, kein Auftrag. Wir beschreiben, mit welchen drei Fragen daraus ein Satz wird, den beide Seiten am Ende gegen die Wirklichkeit halten können, was davon vor dem Start im Angebot steht – und welche unserer eigenen Formulierungen uns später Diskussionen eingebracht haben.",4,[13,14,15],"Arbeitsweise","Werkvertrag","Projektpraxis",[17,20,23,26,29],{"id":18,"text":19},"wunsch","Warum „bauen Sie uns ein System“ kein Auftrag ist",{"id":21,"text":22},"fragen","Abnahmekriterien entstehen aus drei Fragen",{"id":24,"text":25},"angebot","Abnahmekriterien gehören ins Angebot, nicht ins Protokoll",{"id":27,"text":28},"beispiele","Drei Sätze aus echten Projekten",{"id":30,"text":31},"fehler","Wo wir uns selbst geschadet haben","\u003Cp>Abnahmekriterien sind der Teil eines Angebots, an dem sich später entscheidet, ob ein Vorhaben abgenommen wird oder in eine Diskussion läuft. Wir schreiben sie vor dem Start hinein, nicht nach der Lieferung ins Protokoll. Wie aus einem Satz wie „bauen Sie uns ein System für die Bestellungen“ ein prüfbarer Satz wird, steht hier.\u003C\u002Fp>\n\n\u003Ch2 id=\"wunsch\">Warum „bauen Sie uns ein System“ kein Auftrag ist\u003C\u002Fh2>\n\u003Cp>Der Satz ist ehrlich gemeint und beschreibt trotzdem nichts. Er nennt kein Ergebnis, keine Daten, keinen Zustand, an dem jemand ablesen könnte, ob das Ziel erreicht ist. Zwei Seiten unterschreiben ihn in bestem Einvernehmen und meinen dabei zwei verschiedene Dinge: Die eine denkt an eine Übersicht, die andere an eine Anbindung an die Warenwirtschaft.\u003C\u002Fp>\n\u003Cp>Auffällig wird das erst bei der Lieferung. Dann steht Aussage gegen Aussage, und die Frage „ist das fertig?“ hat keine Antwort außer Verhandlungsgeschick. Genau an dieser Stelle verlieren beide: Der Auftraggeber bekommt etwas, das er anders erwartet hatte, und der Auftragnehmer arbeitet Wochen nach, die niemand geplant hat.\u003C\u002Fp>\n\u003Cp>Ein prüfbares Kriterium ist deshalb kein juristischer Formalismus, sondern ein Werkzeug gegen Missverständnisse. Es beantwortet vor dem Start eine einzige Frage: Woran sehen wir gemeinsam, dass die Arbeit erledigt ist?\u003C\u002Fp>\n\n\u003Ch2 id=\"fragen\">Abnahmekriterien entstehen aus drei Fragen\u003C\u002Fh2>\n\u003Cp>Wir kommen von einem vagen Wunsch mit drei Fragen zu einem Satz, den man prüfen kann. Sie klingen simpel und dauern trotzdem ein ganzes Gespräch.\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Woran sehen Sie, dass es funktioniert?\u003C\u002Fstrong> Nicht „was soll es können“, sondern: Welchen Bildschirm öffnen Sie, welche Zahl schauen Sie an, welchen Vorgang spielen Sie durch? Die Antwort verschiebt die Diskussion von der Funktion zum Nachweis.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>An welchen Daten prüfen wir das?\u003C\u002Fstrong> Ein Kriterium ohne Datensatz ist keins. Wir benennen den konkreten Bestand, an dem geprüft wird – ein Monat echter Belege, ein bestimmter Mandant, eine Liste von Fällen, die vorher feststeht.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Wer stellt das fest, und was passiert bei Abweichung?\u003C\u002Fstrong> Eine benannte Person auf Kundenseite, ein Termin, ein Vorgehen für den Fall, dass ein Punkt nicht erfüllt ist. Ohne diesen dritten Teil wandert die Abnahme in die E-Mail-Ablage.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Aus den Antworten wird ein Satz im Muster: \u003Cstrong>Zustand + Datenbasis + messbare Grenze.\u003C\u002Fstrong> „Die Erkennung ist gut“ wird zu „für die Belege eines vollen Monats entsteht zu jeder Position ein Datensatz mit Lieferant, Datum und Betrag, und jede Zeile verweist auf ihr Belegbild“. Der zweite Satz ist länger, unromantischer und im Streitfall die ganze Miete.\u003C\u002Fp>\n\n\u003Ch2 id=\"angebot\">Abnahmekriterien gehören ins Angebot, nicht ins Protokoll\u003C\u002Fh2>\n\u003Cp>Was abgenommen wird, steht vor dem Start im Angebot – nicht danach im Protokoll. Konkret enthält unser Angebot deshalb immer vier Dinge: die Leistungsbeschreibung in der Sprache des Auftraggebers; je Lieferung die Kriterien, an denen sie geprüft wird; die Vertragsform, also Werk mit Abnahme oder Beratung nach Tagen; und die Feststellung, dass Code, Dokumentation und Zugänge dem Auftraggeber vom ersten Tag an offenstehen und die Nutzungsrechte am eigens für ihn erstellten Code mit vollständiger Bezahlung auf ihn übergehen. Der Zeitrahmen steht ebenfalls im Angebot und nicht auf dieser Seite, weil er zu jedem Vorhaben anders aussieht.\u003C\u002Fp>\n\u003Cp>Zwei Dinge stehen bewusst nicht drin. Erstens Personentage als Ergebnis: Wer Tage kauft, kauft Anwesenheit, und Anwesenheit lässt sich nicht abnehmen. Zweitens Formulierungen, die Zufriedenheit versprechen. Zufriedenheit ist keine Größe, die man prüfen kann; die Abgrenzung zwischen einem geschuldeten Ergebnis und einer geschuldeten Tätigkeit erklärt der Artikel \u003Ca href=\"\u002Flexikon\u002Fwerkvertrag\">Werkvertrag\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Die Weisung an unsere Entwickler läuft dabei über unsere Projektleitung. Das ist kein Detail der Höflichkeit: Wer ein Ergebnis schuldet, muss den Weg dorthin selbst verantworten können.\u003C\u002Fp>\n\n\u003Ch2 id=\"beispiele\">Drei Sätze aus echten Projekten\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Lieferantenverzeichnis aus Belegfotos.\u003C\u002Fstrong> Geprüft wurde nicht „die Erkennung läuft“, sondern: Aus 3 579 Rechnungspositionen entsteht ein Verzeichnis mit 24 Lieferanten, und 100 % der Zeilen zeigen das Belegbild, aus dem sie stammen. Der Nachweis war ein Klick pro Stichprobe.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Fünf Jahre Bestellhistorie in ein CRM.\u003C\u002Fstrong> Der Satz lautete: 19 686 Bestellungen stehen im System, keine einzige Dublette, keine automatische Reaktion an Altkunden. Alle drei Teile sind nach dem Lauf in der Datenbank ablesbar – der dritte war dem Kunden der wichtigste.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Fünfte Sprache für eine Oberfläche.\u003C\u002Fstrong> Kein fehlender Schlüssel, alle Platzhalter unverändert, kein Begriff aus dem Glossar übersetzt. Diese drei Punkte prüft eine Automatik bei jedem Build, nicht ein Mensch nach Gefühl.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Auffällig ist, was diese Sätze gemeinsam haben: Sie sind langweilig. Ein gutes Kriterium liest sich wie eine Buchhaltungszeile, nicht wie ein Versprechen.\u003C\u002Fp>\n\n\u003Ch2 id=\"fehler\">Wo wir uns selbst geschadet haben\u003C\u002Fh2>\n\u003Cp>Wir haben das nicht immer so gemacht. In einem frühen Vorhaben stand im Angebot „die Oberfläche reagiert zügig“ – ohne Gerät, ohne Datenmenge, ohne Grenze. Bei der Abnahme war der Bildschirm auf einem alten Rechner mit dem größten Mandanten spürbar träge, und wir hatten kein Argument, sondern nur eine Meinung. Nachgearbeitet haben wir auf eigene Kosten, und das war richtig – der unklare Satz war unserer.\u003C\u002Fp>\n\u003Cp>Der zweite Fehler war subtiler: eine Prüfung an einer zufälligen Stichprobe statt an den Fällen, die täglich benutzt werden. Formal war alles erfüllt, im Alltag fiel dem Kunden trotzdem etwas auf. Seitdem legen wir die Stichprobe vorher fest und gewichten sie nach Nutzung, statt sie dem Zufall zu überlassen.\u003C\u002Fp>\n\u003Cp>Beide Male galt dieselbe Lehre: Ein Kriterium, das wir selbst nicht messen können, ist eine Zusage – und Zusagen sind genau das, was wir ersetzen wollten. Wie wir daraus ein Vorhaben aufsetzen, vom ersten Gespräch bis zur letzten Lieferung, steht unter \u003Ca href=\"\u002Fleistungen\u002Fsoftwareentwicklung\">Softwareentwicklung für den Mittelstand\u003C\u002Fa>.\u003C\u002Fp>",[34,61,88],{"slug":35,"title":36,"subtitle":37,"date":38,"metaTitle":39,"metaDescription":40,"excerpt":41,"readingMinutes":11,"tags":42,"toc":45},"ki-first-was-das-im-alltag-heisst","KI im Unternehmen: was KI-First im Alltag eines Entwicklers heißt","Drei Ebenen, eine Infrastruktur und eine Grenze, die wir nicht überschreiben","2026-09-03","KI-First im Alltag: drei Ebenen, Gateway, Wissensbasis","KI-First konkret: Pflichtschritte im Entwicklungsprozess, eine Agenten-Farm, ein Gateway mit Kostengrenze – und wo KI in Unternehmen nicht beschleunigt.","„AI-powered“ steht auf jeder zweiten Website. Wir beschreiben, was ein Entwickler bei uns an einem normalen Vormittag anders macht: erster Entwurf und erstes Review vom Modell, Agenten, die Aufgaben bis zum Pull Request ausführen, ein Gateway mit harter Kostengrenze – und ehrlich, wo das alles nicht hilft.",[43,13,44],"KI-First","KI-Agenten",[46,49,52,55,58],{"id":47,"text":48},"begriff","KI im Unternehmen: ein Wort, das jeder auf der Website hat",{"id":50,"text":51},"ebene-1","Ebene 1: das Werkzeug des Entwicklers",{"id":53,"text":54},"ebene-2","Ebene 2: Agenten, die Aufgaben ausführen",{"id":56,"text":57},"ebene-3","Ebene 3: KI im Unternehmen des Kunden",{"id":59,"text":60},"grenze","Wo die Beschleunigung aufhört",{"slug":62,"title":63,"subtitle":64,"date":65,"metaTitle":66,"metaDescription":67,"excerpt":68,"readingMinutes":11,"tags":69,"toc":73},"8677-ui-strings-in-einer-stunde","8 677 UI-Strings in einer Stunde: KI-Automatisierung mit Prüfschritten","Was das Modell übernommen hat, was der Mensch – und wo die Fehler saßen","2026-08-20","8 677 UI-Strings in einer Stunde übersetzt: der Ablauf","Eine Anwendung bekommt eine fünfte Sprache: parallele Blöcke, ein Glossar, harte Prüf-Gates und ein zweites Review – Automatisierung mit KI und ihre Grenzen.","Ein Kunde brauchte sein Panel auf Türkisch. 8 677 Übersetzungsschlüssel, parallele Blöcke, ein Glossar, drei automatische Prüfungen und ein unabhängiges Review: Der Kern der Arbeit dauerte etwa eine Stunde, der ehrliche Aufwand einen Arbeitstag.",[70,71,72],"Lokalisierung","LLM","Praxisbericht",[74,77,80,83,85],{"id":75,"text":76},"ausgangslage","Ausgangslage: vier Sprachen, ein neuer Kollege",{"id":78,"text":79},"aufteilung","KI-Automatisierung heißt Arbeitsteilung, nicht Ersatz",{"id":81,"text":82},"pipeline","Die Pipeline: Blöcke, Glossar, harte Gates",{"id":30,"text":84},"Wo es hakte",{"id":86,"text":87},"lessons","Was KI-Automatisierung nicht abkürzt",{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":89,"toc":90},[13,14,15],[91,92,93,94,95],{"id":18,"text":19},{"id":21,"text":22},{"id":24,"text":25},{"id":27,"text":28},{"id":30,"text":31},1789232596386]