Von der Anfrage zum Auftrag — wo die 15 Minuten wirklich lagen
Ein Angebot hat bei uns früher rund 15 Minuten gebraucht. Heute sind es zwei bis drei. Die naheliegende Erklärung wäre: Das Rechnen geht jetzt schneller.
Die Erklärung greift zu kurz. Wer den Job kennt, hat einen groben Preis schnell im Kopf. Die Zeit ging für etwas anderes drauf.
Wo die Zeit lag
Vorweg ehrlich: Die Aufteilung unten ist nicht gemessen. Sie ist rückwärts abgeleitet aus dem, was die Software heute übernimmt. Als Größenordnung stimmt sie, als Statistik würde ich sie nicht verkaufen.
Der erste Schritt ist die Nutzenrechnung. Gedruckt wird auf Bogen, nicht auf Seiten. Auf einen A3-Bogen gehen zwei A4, vier A5, acht A6 oder sechs DIN-lang. Aus dem Endformat ergibt sich also erst die Bogenzahl und daraus die Zahl der Klicks. Wer beidseitig druckt, verdoppelt die Klicks — aber nicht das Papier. Ein Blatt bleibt ein Blatt. Genau an dieser Stelle macht man von Hand zuverlässig einen Fehler.
Dann die Staffelstufe: Farbe und Schwarzweiß getrennt zählen, in der Preistabelle die passende Stufe suchen, bei gemischten Aufträgen zweimal.
Dann der Aufschlag, und hier liegt eine Falle, die kaum jemand auf dem Schirm hat: Er gehört auf jeden Einzelpreis, einzeln aufgerundet, vor der Multiplikation mit der Menge. Von Hand rundet man am Ende. Das Ergebnis ist ein anderes — und es ist falsch.
Dann die Weiterverarbeitung: Einrichten, Schneiden nach Bogenzahl, gegebenenfalls Falzen oder Nuten. Dann die Maschinenfrage: Passt das Papier überhaupt auf den Kopierer, oder muss es zwingend in den Digitaldruck. Und zuletzt das Abtippen — Angebot schreiben, Zahlen übertragen, Mail formulieren, verschicken.
Der nervigste Schritt war der erste. Nicht wegen der Rechnerei an sich, sondern weil sie bei jeder Rückfrage von vorn losging. „Und was kostet es in A5?“ hieß: alles noch mal. Der ehrlichere Aufhänger als die Minutenzahl ist deshalb dieser: Heute ändert man ein Feld.
Ein Vorgang ist ein Zustand, kein Dokument
Ein Angebot ist bei uns kein PDF, das irgendwo herumliegt, sondern ein Zustand, den ein Vorgang gerade hat: Preis offen, Angebot gesendet, angenommen, bestätigt. Daneben gibt es Seitenwege für Sonderfälle und für den Abbruch.
Die Kette läuft so: Eine Anfrage kommt herein, das Angebot geht automatisch raus — bewusst ein bis drei Minuten versetzt, nicht in derselben Sekunde. Eine Antwort in Nullzeit wirkt nicht effizient, sie wirkt unbearbeitet.
Der Kunde bekommt einen Link auf eine eigene Seite. Dort hakt er AGB und Widerrufsbelehrung ab und klickt auf „Zahlungspflichtig bestellen“ — das ist die Schaltfläche, die § 312j BGB für Bestellungen im elektronischen Geschäftsverkehr vorschreibt. Ab da ist der Kunde gebunden. Wir sind es noch nicht. Der Vertrag steht unter dem Vorbehalt unserer Bestätigung.
Zwei Details, die ich unterschätzt hatte:
Der Link ist die Berechtigung. Kein Login, keine Registrierung. Ein Kunde, der die Mail auf dem Handy liest, soll dort bestellen können und nicht an einer Passwortmaske hängenbleiben.
Der Link wird beim Einlösen nicht ungültig. Das klingt nach einer Sicherheitslücke, ist aber das Gegenteil von einem Problem: Reloads, Doppelklicks und Mail-Scanner, die Links vorab abrufen, um sie auf Schadsoftware zu prüfen, sind der Normalfall und nicht die Ausnahme. Wer den Link beim ersten Aufruf verbrennt, zeigt dem Kunden beim zweiten Klick „ungültig“ statt „bereits bestätigt“. Ein technisch korrektes Verhalten, das sich für den Kunden wie ein Fehler anfühlt.
Dazu eine Regel zur Menge: Das Team bekommt pro Vorgang genau zwei Mails — „Angebot angenommen, bitte bestätigen“ und danach die vollständige Auftragsmail. Der Kunde bekommt beim Angebot genau eine. Ein System, das bei jedem Statuswechsel eine Mail schickt, wird nach drei Wochen weggefiltert und ist dann wertlos.
Die Stelle, an der die Automatik anhält
Das ist der Teil, über den ich am längsten nachgedacht habe.
Unterhalb von 500 € Auftragswert rechnet die Engine und schickt das Angebot selbstständig raus. Oberhalb passiert Folgendes: Der Vorgang wird trotzdem vollständig angelegt, der Link erzeugt, der Preis berechnet — aber nichts verschickt. Stattdessen bekommt das Team eine Nachricht „Anfrage, Preis festlegen“ und landet auf derselben Seite wie sonst, nur in einem anderen Modus: Auftragsübersicht, Druckdaten, der berechnete Vorschlag. Man übernimmt ihn oder überschreibt ihn und schickt ihn dann von Hand los. Ab diesem Punkt läuft alles identisch weiter.
Der Kunde bekommt in der Zwischenzeit eine Anfragebestätigung mit einer Zusage: Angebot innerhalb eines Werktags.
Der Gedanke dahinter lässt sich in einem Satz sagen: Die Automatik übernimmt die Fleißarbeit, nicht die Entscheidung. Bei größeren Aufträgen gibt es Verhandlungsspielraum, und den kann eine Preistabelle nicht kennen. Sie kennt weder den Kunden noch die aktuelle Auslastung noch die Frage, ob dieser Auftrag der erste von zwölf ist.
Dasselbe gilt eine Etage tiefer: Auch bei kleinen Aufträgen bindet die Bestellung den Kunden, aber der Auftrag entsteht erst mit unserer Bestätigung. Ein Mensch sieht jeden Preis, bevor er verbindlich wird. Vollautomatik wäre ein Einzeiler gewesen. Sie ist bewusst nicht gebaut.
Dass dieses Netz nötig ist, hat sich schnell gezeigt. Ein Kunde löste den Anfragemodus mit einer erfundenen Seitenzahl aus und lud danach die richtige Datei hoch — plötzlich lief ein Auftrag von rund zwanzig Euro als Großanfrage durch die Handkalkulation. Seitdem prüft der Server die Schwelle unabhängig davon nach, was der Browser gemeldet hat. Was aus dem Browser kommt, ist ein Vorschlag, kein Fakt.
Vier Dinge, die am PDF schiefgegangen sind
Ein Angebot als Textverarbeitungsvorlage zu pflegen funktioniert genau so lange, bis zwei Leute gleichzeitig Angebote schreiben. Danach gibt es zwei Vorlagen, dann drei, und irgendwann steht auf einem Angebot eine alte Telefonnummer. Also erzeugt die Anwendung das PDF selbst. Dabei ist mir Folgendes passiert:
Der falsche Steuersatz. Der ausgewiesene Satz wurde aus einer Liste gezogen, die auch Positionen mit noch offenem Preis enthielt. Ergebnis: Auf einem Beleg mit 19 % stand wegen einer offenen 7-%-Position „zzgl. 7 % USt.“ über einem 19-%-Betrag. Das ist die Sorte Fehler, die niemandem auffällt und trotzdem teuer wird.
Die verschwundene Gesamtsumme. Der Summenblock stand im falschen Zweig. Bei Vorgängen mit einer offenen Position fehlte der Bruttobetrag nicht etwa falsch — er fehlte ganz. Die Regel, die ich daraus mitgenommen habe: Ein Teilbetrag darf niemals an der Stelle stehen, an der jemand eine Gesamtsumme erwartet.
Der Seitenumbruch. Zwei Punkte. Überschrift, Spaltenkopf und die erste Zeile einer Position müssen zusammen auf eine Seite passen, sonst steht ein Titel allein am Seitenfuß. Und jede Seite, auf der die Gesamtsumme nicht steht, trägt einen Warnstreifen „Seite X von Y — Teilbetrag“, damit an der Kasse niemand die erste Seite abrechnet.
Die Sicherung, die stumm zuschlug. Jede Aufschlüsselung einer Position wird gegen deren Gesamtbetrag geprüft; weicht sie um mehr als einen Cent ab, wird sie verworfen und durch eine Sammelzeile ersetzt. Weil in einem Zweig die Schneidepauschale fehlte, ging diese Probe bei jedem geschnittenen Format nicht auf. Statt einer sauber aufgeschlüsselten Zeile stand monatelang eine unbrauchbare Sammelzeile auf dem Blatt. Die Sicherung hat funktioniert — sie hat nur niemandem gesagt, dass sie ständig greift. Seitdem gilt: Ein Fallback, der niemanden benachrichtigt, ist ein Fehler mit gutem Benehmen.
Ein fünfter Punkt zur Vollständigkeit, weil er dasselbe Muster zeigt wie die doppelte Preislogik aus dem ersten Beitrag: Ein Zuschlag war in zwei Dateien definiert. Die eine Stelle zog ihn ab, die andere prüfte gegen den anderen Wert — und die Mail rechnete sichtbar nicht auf.
Der Tresen ist eine andere Tätigkeit, nicht dieselbe in schnell
Eine Anfrage per Mail und ein Kunde, der mit einem Stick vor einem steht, sind nicht derselbe Vorgang.
Am Tresen ist das Angebot komplett weggefallen. Der Erfassungsdialog legt immer direkt einen Auftrag an. Wenn man am Tresen so weit ist, dass gerechnet wird, ist es ein Auftrag. Nebenbefund beim Aufräumen: Die alten Tresen-Angebote hatten keine Auftragsnummer und liefen trotzdem als neue Karten durch Board, Auftragsliste und Zählung im Dashboard.
Ebenfalls weggefallen ist die Eingabe eines Mitarbeiterkürzels — wer den Auftrag aufnimmt, ergibt sich aus der Anmeldung.
Vorbelegt wird alles, was sich vorbelegen lässt: Kundendaten aus der Kartei, die Rechnungsadresse fest mit einem Haken für eine abweichende Lieferadresse, der Steuersatz aus dem Artikeltyp, die Preise aus den hinterlegten Regeln. Es gibt im gesamten Dialog kein einziges freies Preisfeld. Der eigentliche Wert liegt genau darin: Das Preiswissen steckt im System und nicht im Kopf desjenigen, der gerade am Tresen steht.
Zwei Dinge haben sich dabei als falsch herausgestellt:
Die Detailseite belegte „Abholung oder Versand“ still mit Abholung vor. Ein Versandauftrag wurde beim ersten Speichern klammheimlich zur Abholung. Die stille Vorbelegung eines Feldes, das eine echte Konsequenz hat — der Klassiker.
Und der Haken für gebundene Studienarbeiten schaltete den Steuersatz um, ließ aber den Nettobetrag stehen. Folge: Der Preis, den der Kunde zahlt, sank beim Umschalten. Seitdem gilt durchgängig: Brutto ist die feste Größe, netto wird abgeleitet. Am Tresen tippt man den Betrag ein, den der Kunde tatsächlich zahlt. Gespeichert wird netto, eingegeben nie.
Offen und nicht schöngeredet: Zahlungsart und aufnehmender Mitarbeiter stehen bis heute nicht auf dem Auftragsblatt.
Was bewusst manuell geblieben ist
Nicht jeder Schritt gehört in Software. Vier Beispiele:
Die Auftragsbestätigung — ein Mensch sieht jeden Preis, bevor er verbindlich wird. Die großen Aufträge, weil dort der Verhandlungsspielraum sitzt. Die Blattzahlgrenzen bei Bindearbeiten, die Hinweise sind und keine Sperren: Ausnahmen kalkuliert ein Mitarbeiter von Hand, und eine Maske, die den Sonderfall verbietet, verhindert genau die Aufträge, die Geld bringen.
Und ein Beispiel, das wie Nachlässigkeit aussieht und keine ist: Bei einem Auftrag mit leichtem Innenteil und schwerem Deckel steht auf dem Auftragsblatt „Kopierer“, obwohl der Deckel zwingend in den Digitaldruck muss. Das ließe sich abbilden. Ich habe es gelassen, weil die Mitarbeiter diese Regel ohnehin kennen und sie im Kopf zuverlässiger sitzt als in einer weiteren Bedingung, die irgendwann jemand pflegen muss.
Auch der Tresen wurde nicht durch den Kalkulator ersetzt, obwohl das technisch naheliegt. Es sind zwei verschiedene Tätigkeiten: Der Kalkulator rechnet aus Einkauf und Aufschlag einen Preis. Am Tresen tippt jemand einen Betrag ein.
Was davon übertragbar ist
Der Fehler, den ich am häufigsten sehe, ist die Suche nach dem einen Werkzeug, das die Arbeit schneller macht. Die Zeit liegt aber selten in einem Schritt. Sie liegt in den Übergängen — dort, wo dieselbe Information von einem System ins nächste abgetippt wird, und dort, wo eine Rückfrage bedeutet, dass alles von vorn losgeht.
Wer wissen will, wo seine Zeit hingeht, sollte deshalb nicht fragen „wie lange dauert das Kalkulieren“, sondern: Wie oft geben wir dieselbe Information ein zweites Mal ein? Bei uns war die Antwort auf diese zweite Frage der Grund für alles Weitere. Im ersten Monat sind rund 60 Aufträge durch die Strecke gelaufen.