Was eine Produktionssoftware im Druckbetrieb wirklich können muss

Sie beantworten die falsche Frage. Ob ein System im Betrieb trägt, entscheidet sich nicht daran, was es kann, sondern daran, ob es benutzt wird — und zwar von Leuten, die währenddessen etwas anderes zu tun haben.

Die beiden vorangegangenen Beiträge handelten vom Rechnen und von der Strecke bis zum Auftrag. Dieser hier handelt von dem, was danach passiert. Er besteht überwiegend aus Dingen, die ich falsch gebaut und wieder umgebaut habe.

Ein Status, den niemand setzt, ist kein Status

Der erste Anlauf hatte eine ordentliche Statuskette. Sie wurde nie durchlaufen.

Alle Aufträge standen auf „vollständig“. Nicht, weil sie es waren, sondern weil das der voreingestellte Wert war. Dazu kam ein sprachliches Problem: „vollständig“ klang nach fertig, gemeint war „alle Pflichtfelder sind da“. Und weil zwei Statusspalten nebeneinander herliefen, die von verschiedenen Stellen beschrieben wurden, standen 24 Aufträge gleichzeitig auf „neu“ und auf „vollständig“.

Der Fehler war nicht die Kette. Der Fehler war die Annahme, dass jemand sie pflegt.

Ein Feld füllt man nur aus, wenn das Ausfüllen einem selbst hilft. Ein Status, der ausschließlich der Auswertung dient, wird zur Klickarbeit — und Klickarbeit wird weggelassen, sobald es eilig wird. Es wird immer eilig.

Heute gibt es ein Board mit fünf Spalten: Neu, In Arbeit, Rückfrage, Fertig, Abgeholt. Die letzte ist standardmäßig ausgeblendet, sie ist faktisch das Archiv. Ein Auftrag ist eine Karte. Der Status entsteht dadurch, dass jemand eine Karte zieht — und gezogen wird, weil man danach sieht, was los ist. Der Nutzen liegt beim Ziehenden, nicht in einer Statistik.

Drei Details, die ich nachgezogen habe:

Wer zieht, übernimmt. Der Zug nach „In Arbeit“ setzt den Bearbeiter auf denjenigen, der zieht — änderbar mit einem Klick aufs Kürzel. Vorher gab es ein Feld für den Bearbeiter, und es blieb leer.

Rückfrage ist ein Seitenzweig, keine Zwischenstation. Sie verlangt einen Grund und führt nur nach „In Arbeit“ zurück. Eine automatische Mail geht dabei nicht raus.

Vollständigkeit ist kein Status mehr, sondern ein Warnzeichen. Fehlt etwas, hat die Karte ein rotes Zeichen. Gesperrt wird erst kurz vor Schluss. Ein Auftrag darf unterwegs unvollständig sein — er darf nur nicht so das Haus verlassen.

Drei Orte, drei Zwecke — und Papier gehört dazu

Ein Auftrag steht bei uns an drei Stellen, und das ist Absicht.

Auf der Karte steht, wo der Auftrag ist: Nummer, Kunde, Auftragsart als Farbfläche, Bearbeiterkürzel, Termin, die neueste Notiz, gegebenenfalls das Warnzeichen. Kein Preis. Rot ist auf dem Board für keine Auftragsart vergeben — die Farbe bleibt Warnungen vorbehalten, überfällig und Lücke.

Auf dem Auftragsblatt, dem gedruckten PDF, steht, was zu tun ist und was es kostet: Positionen mit Format, Papier und Farbigkeit, Lieferadresse, Steueraufteilung und der Rechenweg für die Kasse. Kein Status.

Und dann gibt es den Laufzettel an der Ware. Der ist nicht abgeschafft und soll es auch nicht werden. Er ist der physische Ort, an dem Auftrag und Papierstapel zusammenfinden. Das Board weiß nicht, in welchem Regal etwas liegt.

Bewusst nicht auf dem Board: einzelne Arbeitsschritte je Position, Fortschritt in Stückzahlen, Ablageort. Alles drei ließe sich abbilden. Alles drei müsste jemand pflegen, während er an der Maschine steht.

Eine Kleinigkeit mit großer Wirkung: Notizen haben einen Verlauf. Eine Notiz ist ein Eintrag, kein überschreibbares Feld. Wer ein Notizfeld überschreibbar macht, verliert genau die Information, die später gebraucht wird — nämlich warum etwas so entschieden wurde.

Ableiten statt eingeben

Jedes Eingabefeld für einen Wert, der sich ableiten lässt, ist eine Fehlerquelle. Das ist die Regel, die im ganzen System am meisten aufgeräumt hat.

Der Steuersatz folgt dem Produkttyp. Die Produktionsmaschine folgt der Grammatur — über 300 g/m² gibt es keine Wahl mehr. Der Bindungspreis folgt der Rückenstärke und der Exemplarzahl; ab fünf Exemplaren greift die Staffel von selbst, niemand sucht sie heraus. Der Mitarbeiter kommt aus der Anmeldung, das Kürzelfeld ist ersatzlos gestrichen. Und der Preis wird bei Annahme des Angebots eingefroren: Was der Kunde gelesen hat, gilt, auch wenn sich die Preisliste danach ändert.

Zwei Einschränkungen, die ich teuer gelernt habe.

Bei steuerrelevanten Entscheidungen ist Raten schlimmer als Fragen. Ob eine Arbeit als gebundenes Werk gilt, erkennt das System nicht automatisch, obwohl es das technisch könnte. Es gibt dafür einen Schalter, den jemand bewusst setzt. Eine Automatik, die in neun von zehn Fällen richtig liegt, ist bei Steuersätzen keine Hilfe, sondern ein Risiko mit guter Trefferquote.

Eine Ableitung darf man anzeigen, aber nicht bearbeiten. Der Fälligkeitstermin eines Auftrags ist eine Mischung aus eigenem Termin und Kundenwunsch: Steht kein eigener, gilt der Wunsch. Diese Mischung landete in der Eingabemaske. Folge: Das erste Speichern schrieb den Kundenwunsch unbemerkt als eigenen Termin fest, und „Termin entfernen“ wirkte nicht mehr. Zum Bearbeiten braucht es immer den ungemischten Wert.

Ein Datenmodell, drei Eingangswege

Es gibt drei Wege, auf denen ein Preis entsteht: den normalen Kalkulator, einen Sonderfall-Modus und die Erfassung am Tresen. Geteilt werden die Rechenfunktion, das Speichern samt serverseitiger Nachrechnung, das Datenmodell für Positionen und der PDF-Erzeuger. Unterschiedlich ist nur die Maske und wie viel Freiheit sie lässt.

Der Standardweg rechnet aus Regeln. Alle dürfen ihn benutzen.

Der Sonderfall verhandelt: Einkauf mal Aufschlag, Andrucke, Fremdleistungen. Hier lassen sich Preise von Hand setzen, und deshalb steht er nur der Geschäftsführung offen.

Der Tresen erfasst, was jemand gerade gegenüber sagt. Dort ist der Bruttobetrag die Wahrheit, nicht die Kalkulation. Es entsteht sofort ein Auftrag mit Nummer, Kassenerfassung und Zahlungsart — kein Angebot.

Den Tresen durch den Kalkulator zu ersetzen lag nahe und wurde geprüft. Verworfen aus zwei Gründen: Der Kalkulator kennt weder Auftragsnummer noch Kasse noch Laufzettel. Und der eigentliche Wert der Tresenmaske ist, dass sie kein einziges freies Preisfeld hat. Das Preiswissen steckt im System und nicht im Kopf desjenigen, der gerade Dienst hat. Ein freies Feld würde genau das zurückdrehen.

Fristen gehören an das Ereignis, nicht an den Versand

Ein automatisch erzeugtes Angebot gilt sieben Tage, eines aus dem Kalkulator dreißig. Läuft die Frist ab, passiert nichts Aktives: Der Link zeigt eine Seite „abgelaufen, bitte neu anfragen“. Es gibt keine Erinnerung bei unbestätigter Annahme. Das ist offen und nicht vergessen.

Für Termine gilt eine andere Logik, und die halte ich für die wichtigere: Wer einen Wunschtermin nennt, bekommt einen Bestätigungslink ohne Anmeldung, und der gilt bis zum Ende des Termintags — nicht sieben Tage ab Versand. Ein Termin kann weit in der Zukunft liegen, und nach dem Termin ist eine Bestätigung sinnlos.

Am Auftrag hängt außerdem eine Wiedervorlage: worauf gewartet wird — Kunde, Preisklärung, Freigabe eines Musters, Material — dazu eine Notiz und ein Datum zum Nachfassen.

Der lehrreichste Punkt betrifft die Aufbewahrung. Druckdateien von Kunden werden nach 90 Tagen gelöscht, hart, allein nach Alter. Ursprünglich gab es eine zweite Regel: dreißig Tage, nachdem ein Auftrag abgerechnet ist. Diese Regel ist toter Code, weil der Status „abgerechnet“ über keine Oberfläche erreichbar ist. Hätte die Löschung daran gehangen, wäre nie etwas gelöscht worden — und niemandem wäre es aufgefallen. Eine Datenschutzfrist darf nicht davon abhängen, dass jemand ein Häkchen setzt.

Was bewusst fehlt

Eine Funktionsliste sagt wenig. Interessanter ist, was nicht drin ist und warum.

Buchhaltung. Rechnungen entstehen außerhalb. Vorbereitet ist nur eine Löschsperre: Sobald ein Rechnungsbezug gesetzt ist, lässt sich der Auftrag nicht mehr löschen. Der Anschluss selbst besteht aus vier Feldnamen an einer Stelle. Mehr auf Vorrat zu bauen, solange nicht feststeht, an welches System angeschlossen wird, wäre Arbeit für den Papierkorb.

Papierbestand. Es gibt eine Materialbestellung, aber keine Bestandsführung. Kein „eingetroffen“, keine Stückzahlen. Ein Lagerbestand, den niemand pflegt, ist schlimmer als keiner — er sieht aus wie eine Zahl.

Auswertung der Kassendifferenzen je Mitarbeiter. Wer öfter allein zumacht, hat zwangsläufig mehr Differenzen. Aus so einer Liste zieht man leicht den falschen Schluss. Deshalb gibt es sie nicht.

Automatisches Ausstempeln. War gebaut und ist wieder abgeschaltet. Ein offener Eintrag mit dokumentierter Korrektur ist arbeitsrechtlich sauberer als eine automatisch gekappte Zeit, die aussieht wie eine Messung. Stattdessen erinnert ein Bot.

Stempeln per Knopf im Chat. Abgelehnt. Bei einer Regelung mit Minusstunden wäre ein Knopf im Messenger ein Fälschungsanreiz. Der Bot erinnert und verlinkt, mehr nicht.

Vollautomatische Auftragsbestätigung. Wäre eine Zeile. Bleibt aus. Ein Mensch sieht jeden Preis, bevor er verbindlich wird.

Sieben Leute, ein System

Der größte Fehler am Anfang: Das System war gebaut, das Team arbeitete weiter mit Papier. Nicht aus Widerstand. Die Zettel funktionierten, und jedes zusätzliche Statusfeld war Klickarbeit ohne erkennbaren Gegenwert. Ein Umbau muss den Zettel ersetzen oder ergänzen. Doppeln darf er ihn nicht.

Was aus dem Alltag heraus umgebaut wurde:

Das Feld für den Mitarbeitercode fiel weg. Das Tresen-Angebot fiel weg — „wenn ich soweit bin, ist das doch immer ein Auftrag.“ Neben Drag-and-drop kam ein „Weiter“-Knopf dazu, weil der Rechner im Laden per Touch bedient wird; und dieser Knopf brauchte ein fest verdrahtetes Ziel, weil er sonst in die Rückfrage-Spalte sprang und Karten nie fertig wurden. Ein Mehrfachzug in der Listenansicht hätte alle Bearbeiter auf den Ausführenden umgeschrieben — dieselbe Funktion, zwei Kontexte, ein Ergebnis, das niemand wollte.

Und der Schichtplan zeigte jedem nur die eigene Zeile, Tauschen war unmöglich. Der Engpass saß nicht im Plan, sondern in der Mitarbeiterliste dahinter — weshalb die Tagesansicht dauernd Unterbesetzung meldete: Sie zählte nur eine Person.

Die Sprache der Oberfläche ist eine Anforderung, keine Kosmetik. „Es fehlen 12,00 €“ statt „Soll-Ist-Differenz“. „Geld aus der Kasse genommen“ statt „Entnahme Lade“. Die Tagesansicht der Kasse zeigt genau eine Aufgabe: morgens die Kontrolle, abends die Zählung, dazwischen „nichts zu tun“. Niemand soll entscheiden müssen, was er anklickt.

Statt eines Schulungstermins steckt die Einweisung im System: zehn Module, 106 Abschnitte, 19 Bildschirmfotos, 45 Kontrollfragen, sichtbarer Fortschritt. Bewusst kein Erklärvideo — ein Video taugt nicht zum Nachschlagen, und in vier Wochen sucht niemand die Stelle bei Minute 14. Eine harte Regel gilt für dieses Material: Dort stehen ausschließlich die Ladenpreise, Onlinepreise kommen nicht vor, auch nicht als Gegenüberstellung. Sonst nennt jemand am Tresen den falschen.

Zu den Rechten noch ein Punkt, der mir wichtig ist. Es gibt eine Vorschau, mit der sich die Oberfläche aus Sicht einer anderen Rolle ansehen lässt — und sie ändert genau das: die Oberfläche. Die Datenbank sieht weiter die Geschäftsführung. Der Schichtplan-Fehler oben wäre damit nicht aufgefallen. Für einen echten Rechtetest braucht es ein zweites Konto. Ein Prüfwerkzeug, das Sicherheit nur aussehen lässt, ist gefährlicher als keines.

Wenn es nicht läuft

Einen längeren Ausfall hatten wir bisher nicht, und ich werde hier keinen erfinden. Was ich sagen kann, ist, wie der Betrieb dagegen abgesichert ist.

Der Papierweg ist kein Notfallplan, sondern Normalbetrieb. Der Laufzettel hängt an der Ware. Wer produziert, braucht das System nicht — er braucht den Zettel und den Stapel. Der Zettel selbst wird bei jedem Aufruf neu erzeugt und nicht aus dem Speicher geholt, damit ein nachträglich korrigierter Auftrag nicht als altes PDF weiterlebt. Nebeneffekt: Man kann jederzeit neu drucken.

Der einzige Vorfall, der in diese Richtung ging, hatte eine andere Ursache. Vorschau und Livebetrieb schrieben in dieselbe Datenbank. Zwei geöffnete Tabs, aus jedem einmal abgeschickt — zwei echte Aufträge, zwei Nummern, zwei Kundenmails, in derselben Sekunde. Das sah nach doppeltem Versand aus, war aber keiner: Pro Auftrag lief alles genau einmal. Der Fehler saß nicht im Programm, sondern in meiner Annahme, eine Testumgebung sei eine.

Was davon übertragbar ist

Wer für den eigenen Betrieb auswählt oder baut, kommt mit vier Fragen weiter als mit jeder Funktionsliste:

Wem nützt es, dieses Feld auszufüllen? Lautet die Antwort „der Auswertung“, bleibt es leer.

Welche Werte tippt jemand ein, obwohl sie sich ableiten lassen? Jeder davon ist eine spätere Abweichung.

Was passiert, wenn das System steht? Wenn die Antwort „nichts geht mehr“ ist, fehlt der Papierweg.

Und woran hängen die Fristen? An einem Ereignis oder an einem Häkchen, das jemand setzen müsste.

Die Software war bei uns nicht der schwierige Teil. Der schwierige Teil war herauszufinden, welche Arbeit tatsächlich stattfindet — und nicht die, von der wir dachten, dass sie stattfindet.