Hier ist einmal definiert, was „Aufwand” in diesem Vault bedeutet. Alle Zahlen in Lieferkatalog, in den Bausteinen und in den Branchennotizen benutzen genau diese Einheiten.
Anlass: Erics Frage auf Seite 20 des Berichts — „wieviel Aufwand stecken wir selbst rein für die jeweiligen Beträge? Aufwandschätzung Manuel + Eric + ‚Luft’?” → Erics Rückmeldungen
Alle Zahlen hier sind Setzungen, nicht validiert.
Es wurde noch kein einziges Projekt geliefert. Es gibt keine Ist-Daten, keine erfassten Stunden, keinen abgeschlossenen Piloten. Die Werte sind aus dem Leistungsumfang abgeleitet und plausibilisiert — mehr nicht. Sie werden ab dem ersten echten Projekt durch gemessene Zeiten ersetzt.
Die Einheiten
| Begriff | Definition |
|---|---|
| PT | Personentag = 8 produktive Stunden. Nicht Kalendertag. |
| Manuel / Eric | Immer getrennt ausgewiesen. Eric hat den Verteilungsschlüssel „auf Basis konkreter Stundenaufwände” vorgeschlagen — der funktioniert nur, wenn getrennt geschätzt und erfasst wird. |
| Erstbau | Der erste Kunde eines Bausteins. Schema, Prompt, Regeln und Feldliste entstehen neu. |
| Wiederholung | Jeder weitere Kunde desselben Bausteins. Der Kern wird wiederverwendet, angepasst werden Felder, Sprache und Zielsystem. |
| Luft | Risikozuschlag +25 % auf den Erstbau, +15 % auf die Wiederholung. Steht als eigene Zeile, wird nie stillschweigend eingerechnet. |
| Kalenderzeit | Durchlaufzeit beim Kunden, inklusive Wartezeiten. Nicht dasselbe wie Aufwand. |
Kalenderzeit ist nicht Aufwand
„3 Wochen” heisst 15 Arbeitstage Durchlaufzeit — nicht 15 PT Arbeit. Zwischen Zwischenschau, Kundenfeedback und Freigaben liegen Wartezeiten. Beim AnfrageFlow-Erstbau entfallen auf Manuel rund 6–10 PT verteilt über 15 Arbeitstage, also etwa 50–70 % Auslastung. Das ist Absicht — parallel läuft Akquise oder ein zweiter Kunde.
Grössenklassen
Zum schnellen Überfliegen im Lieferkatalog. Immer bezogen auf den Erstbau, ohne Luft, beide Personen zusammen.
| Klasse | PT | Bedeutung |
|---|---|---|
| S | 1–3 | Halber bis ganzer Prozess-Check, kleine Ergänzung an einem laufenden Ablauf |
| M | 4–8 | Ein abgegrenzter Pilot mit einem Eingang und einer Ausgabe |
| L | 9–15 | Mehrere Eingänge, echte Systemanbindung oder aufwendige Fachlogik |
| XL | > 15 | Nicht als Fixpreis-Pilot verkaufen. Nur nach einem gelieferten Piloten, als Ausbau mit eigenem Umfang |
Die neun Lieferschritte
Bei allen fünf Bausteinen gleich. Nur der Inhalt jedes Schritts ändert sich, nicht die Abfolge. Was in jedem Schritt konkret getan wird, steht in der jeweiligen Baustein-Notiz.
| # | Schritt | Wer führt |
|---|---|---|
| L0 | Interne Vorbereitung — einmalig, nicht fakturierbar | Manuel |
| L1 | Prozess-Check und Abgrenzung, Basiswert vorher messen | Eric, mit Manuel |
| L2 | Eingang anbinden — genau ein Kanal | Manuel |
| L3 | Feldschema mit der Fachperson definieren | Manuel, mit Eric |
| L4 | KI-Schritt bauen — Prompt, Structured Output, Konfidenz | Manuel |
| L5 | Validierung und Schutzregeln | Manuel |
| L6 | Review-Inbox als Freigabestufe | Manuel, mit Eric |
| L7 | Ausgabe ins Zielsystem — nur als Entwurf | Manuel |
| L8 | Test T1–T6 mit echtem Kundenmaterial | Beide |
| L9 | Übergabe — Schulung, Doku, Vorher-/Nachher-Auswertung | Beide |
| + | Begleitung und Koordination über die Laufzeit | Beide |
L1 enthält die Vorher-Messung. Eric hat das selbst hervorgehoben: „Bei jedem KI-Projekt sollten wir VOR Projektstart Ausgangslage beziffern (Anzahl h für Aufgabe X)”. Ohne diesen Wert ist jede spätere Aussage über Einsparung wertlos — und dann ist auch der Folgeauftrag schwer zu begründen.
Was KI-gestützte Entwicklung wirklich einspart
Alle Zahlen unten setzen voraus, dass KI-gestützte Entwicklung, vorhandene Schnittstellen und Low-Code-Werkzeuge konsequent genutzt werden. Das verkürzt den Bau — nicht das Projekt.
| Schritt | Kompression | Warum |
|---|---|---|
| L1 Prozess-Check | −20 % | Das Gespräch bleibt. Vorbereitung, Fragenraster und Protokoll entstehen in Minuten |
| L2 Eingang anbinden | −80 % | Standardanbindungen sind generiert, bevor man sie von Hand getippt hätte. Übrig bleiben Zugänge und Rechte beim Kunden |
| L3 Feldschema | −50 % | Der Entwurf entsteht aus 20 echten Beispielen in Minuten. Die Entscheidung, welche Felder der Betrieb wirklich braucht, bleibt fachlich |
| L4 KI-Schritt bauen | −90 % | Prompt, Schema und Aufruf sind eine Stunde Arbeit, nicht ein Tag |
| L5 Validierung | −85 % | Regeln und der dazugehörige Testsatz werden zusammen erzeugt |
| L6 Review-Inbox | −75 % | Tabelle, Spalten und Statuslogik sind vorgeneriert |
| L7 Ausgabe | −75 % | |
| L8 Test T1–T6 | −50 % | Testfälle und Stapellauf sind erzeugt. Das Urteil einer Fachperson über die Ergebnisse bleibt |
| L9 Übergabe | −30 % | Ablaufbeschreibung generiert, Schulung und Auswertung bleiben |
| Begleitung | keine | Termine, Rückfragen, Wartezeiten |
Der technische Teil wird drei- bis fünfmal schneller — das ganze Projekt rund doppelt so schnell.
Das ist kein Widerspruch. Manuels Bauanteil am AnfrageFlow sinkt von 6–10.5 auf 2–4 Personentage; was früher Tage waren, sind Stunden. Erics Anteil sinkt kaum, weil Gespräche, Feldentscheide und die fachliche Beurteilung der Testergebnisse nicht schneller werden.
Die Begrenzung ist nicht mehr der Code, sondern der Kalender des Kunden. Die 20–50 echten Fälle, die Rückmeldung der Testperson und der Schulungstermin bestimmen die Dauer — nicht das Bauen. Deshalb bleiben die drei Wochen Durchlaufzeit stehen, obwohl der Aufwand halbiert ist.
Wo die Rechnung umgekehrt läuft
Bei den Bausteinen des Musters Beobachten (SichtbarkeitsFlow, BewertungsFlow, AusschreibungsFlow) und Befähigen (RegelFlow) ist der Bau ohnehin klein — der Aufwand steckt in Auswertung, Bericht und Gespräch. Deshalb tragen sie sich viel früher. → Umsatzstart
MVP-Aufwand aller 13 Bausteine
Erster Bau je Baustein, beide Personen zusammen, ohne Luft, mit KI-gestützter Entwicklung.
| Muster | Baustein | MVP | Pro Kunde (Wdh.) | Klasse |
|---|---|---|---|---|
| Beobachten | BewertungsFlow | 1–2.5 PT | 0.5 PT | S |
| Beobachten | SichtbarkeitsFlow | 1.5–3 PT | 0.5 PT | S |
| Beobachten | AusschreibungsFlow | 1.5–3.5 PT | 0.5–1 PT | S |
| Befähigen | RegelFlow | 2–4 PT | 1 PT | S |
| Strukturieren | SprachFlow | 2–4 PT | 1–1.5 PT | S |
| Sprechen | ChatFlow | 2–4.5 PT | 1–2 PT | S–M |
| Sprechen | AnrufFlow | 3–6 PT | 2–3 PT | M |
| Strukturieren | AnfrageFlow | 4–7 PT | 3–4 PT | M |
| Strukturieren | DocFlow · ContentFlow · ProjektFlow · WissensFlow | 4–7 PT | 3–4 PT | M |
| Strukturieren | BelegFlow | 3.5–6 PT | 2–3 PT | M |
Alle Werte Setzungen, nicht validiert. Preisbänder dazu: Preismodell
Referenzrechnung: AnfrageFlow Starter
Das ist das Angebot, das aktiv verkauft werden soll. Alle anderen Schätzungen im Vault sind gegen diese Rechnung kalibriert.
Einmalig vorab: L0
| Inhalt | Manuel | Eric |
|---|---|---|
| Schema und Prompt fertigstellen, gegen die 14 erfundenen Fälle testen | 1 PT | – |
| Workflow aufbauen, Review-Tabelle einrichten | 1 PT | – |
| Demo durchspielen, Grenzen und Fehlerpfade zeigen können | 0.5–1 PT | 0.5 PT |
| Summe L0 | 2.5–3 PT | 0.5 PT |
Fällt genau einmal an und wird über die ersten Kunden getragen. Das Demo-Kit im Archiv deckt einen Teil davon ab — es wurde aber nie ausgeführt, siehe Lieferkatalog.
Pro Kunde
| Schritt | Erstbau Manuel | Erstbau Eric | Wdh. Manuel | Wdh. Eric |
|---|---|---|---|---|
| L1 Prozess-Check, Basiswert | 0.5–1 | 0.5–1 | 0.5 | 0.5 |
| L2 Eingang anbinden | 0.5–1 | – | 0.25 | – |
| L3 Feldschema | 1–1.5 | 0.5 | 0.5 | 0.25 |
| L4 KI-Schritt | 0.5–1 | – | 0.25 | – |
| L5 Validierung, Schutzregeln | 0.5–1 | – | 0.25 | – |
| L6 Review-Inbox | 0.5 | 0.25 | 0.25 | – |
| L7 Ausgabe als Entwurf | 0.5–1 | – | 0.25–0.5 | – |
| L8 Test T1–T6 | 1–2 | 0.5–1 | 0.75 | 0.5 |
| L9 Übergabe | 0.5–1 | 0.5 | 0.5 | 0.5 |
| Begleitung, Koordination | 0.5 | 0.5 | 0.5 | 0.25 |
| Summe ohne KI-Unterstützung | 6–10.5 | 2.25–3.75 | 4–4.25 | 2 |
| Summe mit KI-Unterstützung | 2–4 | 2–3 | 1.5–2 | 1.5–2 |
| Beide zusammen | 4–7 PT | 3–4 PT | ||
| + Luft | 5–9 PT (+25 %) | 3.5–4.5 PT (+15 %) | ||
| Klasse | M | S–M |
Was die Preise damit tatsächlich hergeben
Das ist die Zahl, nach der Eric gefragt hat.
| Angebot | Preis | Aufwand mit Luft | Ergibt pro PT |
|---|---|---|---|
| KI-Prozess-Check | CHF 1’200 | 1–1.5 PT | CHF 800–1’200 |
| AnfrageFlow — Erstbau | CHF 4’900 | 5–9 PT | CHF 545–980 |
| AnfrageFlow — Wiederholung | CHF 4’900 | 3.5–4.5 PT | CHF 1’090–1’400 |
| AnfrageFlow — 12 Monate zu CHF 890 | CHF 10’680 | 7–10 PT im Jahr | CHF 1’070–1’525 |
| Auffindbarkeits-Abo — 12 Monate zu CHF 390 | CHF 4’680 | 3 PT im Jahr | CHF 1’560 |
Der Befund hat sich gedreht. Mit konsequent KI-gestützter Entwicklung trägt auch der erste Bau einen vertretbaren Satz, und ab dem zweiten Kunden liegt die Rechnung über CHF 1’000 pro Personentag. Die frühere Aussage — der Erstbau trage sich nicht — galt für eine Bauweise, die heute niemand mehr wählen würde. → Preismodell · Umsatzstart
Was das für die Preise heisst: Die Bänder in Preismodell bleiben, wo sie sind. Der gewonnene Spielraum geht nicht in den Preis, sondern in mehr Kunden pro Woche und in die Möglichkeit, beim Einstieg günstiger anzubieten als der Wettbewerb.
Das ist kein Rechenfehler im Bericht. Der Bericht sagt ausdrücklich, die Preise leiteten sich nicht aus einem Stundensatz ab, und das Ziel der ersten Kunden sei „nicht maximale Marge, sondern ein sauberer Ablauf, belastbare Referenzen und eine Grundlage für Folgeaufträge”. Diese Aussage wird durch die Rechnung bestätigt — aber sie war bisher nie beziffert.
Drei Konsequenzen, über die entschieden werden muss:
- Der Erstbau je Baustein trägt sich — aber schlechter als die Wiederholung. Er sollte weiterhin nur einmal pro Baustein passieren. Ein zweiter „Erstbau” derselben Sache bleibt der teure Fehler.
- Erics Rabattidee von bis zu 25 % ist jetzt tragbar: Die Wiederholung läge noch bei rund CHF 820 pro PT, der Erstbau bei CHF 410–735. Auf den Erstbau bleibt sie trotzdem knapp. → Offene Entscheidungen
- Der KI-Prozess-Check ist weiterhin das am saubersten kalkulierte Angebot — und mit CHF 800–1’200 pro Personentag das rentabelste im Fixpreis.
Zum Vergleich: Ein üblicher Tagessatz für Senior-Entwicklung in der Schweiz liegt deutlich höher. Was für dieses Vorhaben der richtige Zielsatz ist, ist nicht entschieden. offen → Offene Entscheidungen Punkt 3
Was in diesen Zahlen nicht enthalten ist
Ehrlichkeit an dieser Stelle entscheidet, ob die Rechnung trägt.
| Nicht enthalten | Warum es zählt |
|---|---|
| Akquise, Erstgespräche, Angebotserstellung | Fällt auch bei Absagen an. Erics Ansprache von 10–12 Adressen pro Woche ist echter Aufwand |
| Reise- und Präsenzzeit | Basel ↔ Oberaargau. Ab dem dritten Kunden nicht mehr nebenbei |
| Fehlerbehebung nach der Übergabe | Erics offene Frage: „‚Garantie’? Fehlerbehebung nach Implementierung vs. Ergänzungs-Wünsche, Kostenfolge der beiden Szenarien?” offen |
| Betrieb und Wartung | Ist Stufe 4 der Produktleiter, ein eigenes Angebot |
| Werkzeugkosten | Automationsplattform, Modell-API, Review-Tabelle, Passwortverwaltung. Eric: „Die aber, wenn nicht schon vorhanden, Kosten auslösen und diese MÜSSEN begründet werden” — konkrete Frankenbeträge fehlen noch offen |
| Eigene Weiterbildung und Werkzeugpflege | Läuft nebenher, gehört aber in eine Jahresrechnung |
Wie geschätzt wird
Damit alle Zahlen im Vault vergleichbar bleiben:
- Immer gegen die Referenzrechnung oben. Eine neue Automation wird nicht frei geschätzt, sondern gefragt: Welcher Schritt weicht vom AnfrageFlow ab, und um wieviel?
- Getrennt nach Manuel und Eric. Auch wenn ein Anteil null ist — dann steht dort ein Strich.
- Als Spanne, nie als Punktwert. Ein Punktwert suggeriert eine Genauigkeit, die es nicht gibt.
- Luft immer sichtbar. Nie in die Schätzung hineingerechnet.
- Erstbau und Wiederholung immer beide. Der Unterschied ist die Aussage, nicht die Zahl.
- Ab dem ersten echten Projekt: tatsächliche Stunden erfassen und diese Notiz korrigieren. Dann verschwindet der Warnhinweis oben — und erst dann.