Branche · Druck und Formularwesen
Ein Druckprodukt existiert vor der Bestellung nicht. Format, Papier, Farbigkeit, Auflage und Weiterverarbeitung ergeben zusammen erst das Produkt und den Preis. Wir bauen die Systeme dahinter: Konfiguratoren mit Abhängigkeiten, Kalkulationsregelwerke mit Auflagenstaffeln, Druckdatenupload mit automatischer Auswertung und OCI-Punch-out in die Beschaffungssysteme im Bankenumfeld. Belegt an bank-formular.de für Lijnco und plotplus.de für Küper Digital.
Ein Flyer in A5 auf 170 g Bilderdruck, vierfarbig beidseitig, 2.500 Stück, geschnitten und in Päckchen gebündelt ist kein Artikel, sondern eine Rechenaufgabe mit fünf Eingaben. Der Artikelstamm, an dem sich ein Standardshop orientiert, hat dafür keine Entsprechung. Gebraucht wird ein Regelwerk, das rechnet, statt einer Tabelle, die nachschlägt.
Auflagenkosten bestehen aus Einrichtung und Fortdruck, deshalb kostet die doppelte Menge nie das Doppelte. Und gelegentlich kostet die höhere Menge weniger, weil ab dort ein anderes Verfahren greift. Technisch korrekt, für den Besteller ein vermuteter Fehler. Solche Sprünge müssen in der Staffel erklärt werden, nicht geglättet.
Bei einem Plotservice steckt der halbe Auftrag in der Datei: Seiten, Maße, bedruckte Fläche. Upload und Auswertung gehören deshalb in den Bestellprozess und nicht in eine Mail danach. Wer erst nach Auftragsannahme rechnet, verhandelt über Preis und Termin ein zweites Mal.
Im Bankenumfeld wird nicht frei im Internet eingekauft. Budgets, Kostenstellen und Freigabestufen liegen im Beschaffungssystem des Kunden. Ein Lieferantenshop daneben erzeugt Medienbrüche: abtippen, separat freigeben, doppelt erfassen. Deshalb ist OCI-Punch-out im Formularwesen weniger ein Feature als eine Zugangsvoraussetzung.
Der Unterschied zu jedem anderen Sortiment liegt schon vor der Bestellung: Was der Kunde kauft, gibt es zu diesem Zeitpunkt noch nicht. Bei einem Schraubenhändler steht die Artikelnummer am Anfang und der Preis daneben. Bei einer Druckerei stehen am Anfang fünf oder sechs Eingaben — Format, Papiersorte und Grammatur, Farbigkeit, Auflage, Weiterverarbeitung, gelegentlich Personalisierung — und erst daraus entsteht ein Produkt mit einem Preis. Ein Shopsystem, das intern von einem gepflegten Artikelstamm ausgeht, arbeitet an dieser Stelle gegen den Markt.
Wer es trotzdem über eine Variantenmatrix versucht, merkt es beim zweiten Papier. Sechs Formate, acht Papiere, vier Farbigkeiten, zwölf Auflagenstufen und fünf Weiterverarbeitungen ergeben rechnerisch über elftausend Kombinationen. Jede bräuchte einen Datensatz, eine Artikelnummer und einen gepflegten Preis. Ein erheblicher Teil davon ist produktionstechnisch gar nicht herstellbar — dieses Papier läuft nicht in diesem Format, diese Prägung erst ab einer Mindestauflage, diese Falzart nicht bei dieser Grammatur. Die Matrix pflegt sich nicht selbst, und sie kennt diese Regeln nicht.
Ein Konfigurator dreht das um. Er hält Optionen und deren Abhängigkeiten vor, sperrt unmögliche Kombinationen, statt sie anzubieten, und erzeugt den Artikel erst im Warenkorb. Praktisch wichtig ist dabei ein Detail, das oft vergessen wird: Ein Konfigurationsstand sollte verlinkbar sein. Der Innendienst braucht die Möglichkeit, eine fertige Konfiguration per Mail an den Kunden zu schicken, und der Kunde braucht die Möglichkeit, sie beim nächsten Mal wiederzufinden. Sobald die Konfiguration nur im Formularzustand einer Sitzung existiert, sind Angebot, Rückfrage und Nachdruck jedes Mal Handarbeit.
Auflagenkosten haben zwei Anteile. Der eine fällt einmal an: Einrichtung, Platten oder Druckvorstufe, Rüstzeit an der Maschine, Einrichten der Weiterverarbeitung. Der andere läuft mit: Bogen, Farbe, Fortdruck, Schneiden, Verpacken. Deshalb kostet die doppelte Auflage nie das Doppelte, und deshalb ist die Kleinstauflage im Verhältnis immer teuer. Eine Staffel, die diese Degression nicht abbildet, ist entweder in kleinen Mengen unverkäuflich oder in großen Mengen verlustbringend. Beides fällt erst nach Monaten auf, wenn jemand die Nachkalkulation macht.
Dazu kommen Sprünge. Ein Format fällt ab einer bestimmten Auflage anders auf den Druckbogen, weil sich eine andere Nutzenaufteilung rechnet. Ab einer bestimmten Menge wird Offsetdruck günstiger als Digitaldruck. Eine größere Maschine bringt einen anderen Bogenpreis mit. Das Ergebnis sind Stellen in der Staffel, an denen die höhere Menge weniger kostet als die niedrigere. Für den Besteller sieht das nach einem Fehler aus, und er tut, was Menschen bei vermuteten Fehlern tun: anrufen oder abbrechen. Die Antwort darauf ist kein anderer Preis, sondern ein Hinweis an der Staffel — die nächsthöhere Menge ist günstiger, und das ist der Grund. Das nimmt Rückfragen aus dem Innendienst heraus, ohne dass jemand Zahlen verbiegt.
Bleibt die Frage, wo diese Rechnung liegt. Der Shop braucht den Preis in Echtzeit, sonst gibt es keinen Konfigurator. Ob die Regeln im Web-System gepflegt werden oder über eine Schnittstelle aus der Kalkulation des Betriebs kommen, entscheidet sich daran, wer sie fachlich verantwortet. Bei plotplus.de haben wir das Regelwerk konfigurierbar gebaut, damit neue Materialien ohne Codeänderung ergänzt werden können; die Kalkulationslogik selbst liegt im eigenen Code und lässt sich dort anpassen, wenn sich das Angebot ändert. Wichtiger als die Platzierung ist die Eindeutigkeit: Zwei Kalkulationen parallel — eine im Shop, eine im ERP — sind der Fehler, den man am teuersten korrigiert.
In der Druckdienstleistung verkauft niemand Artikel, sondern eine Verarbeitung. Bei plotplus.de der Küper Digital GmbH & Co. KG ist das der Ausgangspunkt des ganzen Systems: Was der Kunde bestellt, steckt in der Datei, die er hochlädt. Seitenanzahl, Formate, bedruckte Fläche, Farbanteile. Erst daraus ergibt sich, was der Auftrag umfasst und was er kostet. Die Anwendung nimmt auch große Druckdateien an, legt sie in eine Warteschlange, analysiert sie und erzeugt daraus zusammen mit Material, Ausgabeart und Stückzahl die Auftragspositionen samt Preis. Ohne diese Analyse steht der Preis erst fest, wenn jemand die Datei geöffnet und ausgemessen hat — und das skaliert mit der Bestellmenge nicht mit.
Technisch hat das Folgen für die Architektur. Die Verarbeitung läuft in Hintergrundprozessen, entkoppelt vom Webserver, damit ein großer Auftrag die Bedienung für alle anderen nicht ausbremst. Der Besteller sieht während des Processings einen Bearbeitungsstand, statt in einen Timeout zu laufen. Der Speicher ist auf große Dateimengen ausgelegt, nicht auf Produktbilder. Betrieb und Deployment laufen containerisiert auf eigenen Servern in Deutschland — was bei Druckdaten weniger eine Marketingfrage ist als eine der Übertragungsmenge und der Auskunftsfähigkeit gegenüber dem Kunden.
Von der Analyse zu trennen ist die Datenprüfung. Sie ist kein Automatismus jedes Projekts, sondern eine eigene Entscheidung — und wo sie gefordert wird, gilt: Formal prüfbar sind Seitenformat und Beschnittzugabe, Farbraum, Bildauflösung, eingebettete Schriften, Seitenanzahl, Überdrucken-Einstellungen. Nicht prüfbar ist, ob der Inhalt richtig ist. Entscheidend ist deshalb, was das System mit dem Prüfergebnis macht. Ein Protokoll, das der Besteller sieht und bestätigt, ist belastbarer als eine stille Korrektur im Hintergrund — und es ist das Dokument, auf das man sich bezieht, wenn später über eine Reklamation gesprochen wird. Wer Dateien automatisch geradezieht, ohne es zu sagen, verlagert die Diskussion nur nach hinten.
Formulardruck für Banken, Sparkassen und Behörden ist ein anderes Geschäft als Werbedruck, auch wenn dieselbe Maschine läuft. Es gibt keine Kampagne und keinen Termin, sondern einen Bestand, der nachgeschoben wird. Die Artikel sind fest, oft seit Jahren, häufig mit eigenem Layout und eigener Nummerierung je Institut. Und eingekauft wird nicht im Internet, sondern in einem Beschaffungssystem, in dem Budgets, Kostenstellen und Freigabestufen hinterlegt sind. Ein Lieferantenshop, der außerhalb dieses Systems steht, erzeugt genau die Medienbrüche, die der Einkauf abgeschafft haben wollte: abtippen, separat freigeben lassen, doppelt erfassen.
bank-formular.de von Lijnco ist unser Beleg dafür, im Bankenumfeld. Grundlage ist Shopware, auf B2B ausgelegt: Kundengruppen mit eigenen Konditionen, kundenspezifisch freigeschaltete Sortimente, Bestellhistorie, Nachbestellung bekannter Formulare, Produktkonfigurationen für Auflagen, Ausführungen und Varianten — im Formularwesen bis hin zu Durchschreibesätzen. Kern des Projekts ist das OCI-Plugin. Der Einkäufer startet in seinem Beschaffungssystem, wird per Punch-out mit den übergebenen Zugangsdaten am Shop angemeldet und sieht sein freigeschaltetes Sortiment zu seinen Preisen. Der fertige Warenkorb wird nicht als Bestellung ausgelöst, sondern im OCI-Feldformat an die Hook-URL des Beschaffungssystems zurückgegeben — mit Artikelnummer, Beschreibung, Menge, Preis und Einheit. Freigabe und Kostenstellenzuordnung bleiben beim Kunden.
Der Aufwand steckt nicht im Standard, sondern in der jeweiligen Gegenstelle. Feldbelegungen, Zeichensätze und Rückgabeverfahren unterscheiden sich in der Praxis, deshalb wird jede Anbindung gegen das reale Kundensystem getestet und nicht gegen eine Annahme. Ist die erste Anbindung gebaut, wird die zweite eher zur Konfigurationsaufgabe als zum Einzelprojekt. Wie das technisch im Detail funktioniert, steht auf unserer Leistungsseite zu OCI und Punch-out; hier gehört nur der Marktbefund hin: Ohne diese Anbindung kommt ein Formularlieferant an bestimmte Kunden nicht heran, und mit ihr bleibt der Shop daneben ganz normal nutzbar für alle, die kein Beschaffungssystem haben.
Der Erstauftrag ist Akquise. Verdient wird an der Wiederholung. Ein Formular ändert sich selten, die Auflage ständig; ein Prospekt geht in die zweite und dritte Runde; ein Plakatmotiv wird für die nächste Filiale nachgezogen. Genau an dieser Stelle entscheidet sich, ob ein Kunde bleibt. Wenn die Wiederbestellung bedeutet, dass jemand im Innendienst den alten Auftrag sucht, die Konfiguration rekonstruiert und die Datei aus einem Postfach holt, dann dauert es Stunden und der Kunde bestellt beim Anbieter, bei dem es zwei Klicks sind — auch wenn der beim Erstauftrag teurer war.
Technisch ist das eine Frage der Datenhaltung, nicht der Oberfläche. Ein Auftragsarchiv muss mehr speichern als die Bestellung: die vollständige Konfiguration mit allen gewählten Optionen und die Druckdatei in exakt der Version, die gedruckt wurde. Dann besteht ein Nachdruck aus zwei Eingaben, Auflage und Termin, und der Preis wird neu gerechnet, weil er von der Menge abhängt. Dazu gehört eine Versionierung, damit nachvollziehbar bleibt, welcher Stand in welchem Auftrag lief — bei Formularen mit rechtlich relevantem Text ist das keine Bequemlichkeit, sondern der Grund, warum man überhaupt archiviert. Und es gehört eine ehrliche Rechnung zum Speicherbedarf dazu, denn Druckdaten sind groß und Aufbewahrungsfristen lang.
Der Sonderfall im Formularwesen ist die Abruflieferung. Gedruckt wird einmal die kontrahierte Gesamtmenge, geliefert wird über Monate auf Abruf. Der Shop muss dafür zwei Bestände kennen — die vereinbarte Menge und den Rest im Lager —, die Restmenge anzeigen und warnen, bevor sie aufgebraucht ist. Das ist Lagerlogik in einem Shop-Frontend und in Standardsystemen nicht vorgesehen. Belegt ist in unseren Projekten bisher die Nachbestellung bekannter Formulare aus der Bestellhistorie; die Abruflogik hängt am jeweiligen Rahmenvertrag und wird dafür gebaut. Ob dafür ein Modul auf einem bestehenden Shop reicht oder eine eigene Anwendung nötig ist, sehen wir uns vorher an. Wenn Ihr System das im Kern schon trägt und nur die Nachbestellung fehlt, sagen wir das — auch wenn der Neubau der größere Auftrag wäre.
2 Kunden. Was hier steht, trägt täglich Umsatz, Anfragen oder Prozesse.
Ein Auszug — nicht die vollständige Kundenliste.
Weil er von einem Artikelstamm ausgeht. Ein Druckprodukt entsteht erst bei der Bestellung aus Format, Papier, Farbigkeit, Auflage und Weiterverarbeitung. Diese Kombinationen als Varianten anzulegen führt schon bei mittleren Sortimenten in fünfstellige Artikelzahlen, von denen ein Teil produktionstechnisch nicht herstellbar ist. Gebraucht wird ein Konfigurator mit Regelwerk und eine Kalkulation, die rechnet — nicht eine Tabelle, die nachschlägt.
Solange die Zahl der Kombinationen überschaubar bleibt und jede davon einen sinnvollen eigenen Datensatz hat, trägt eine Variantenmatrix. Sobald Abhängigkeiten dazukommen — dieses Papier nicht in diesem Format, diese Weiterverarbeitung erst ab dieser Auflage — wird die Matrix zur Pflegefalle, weil sie diese Regeln nicht kennt. Dann ist der Konfigurator die günstigere Lösung, auch wenn er in der Umsetzung zunächst aufwendiger aussieht.
Aus zwei Anteilen: einmaligen Kosten für Druckvorstufe, Platten und Rüstzeit und laufenden Kosten je Bogen oder Stück. Deshalb kostet die doppelte Auflage nie das Doppelte. Dazu kommen Sprünge, wenn ein Format anders auf den Druckbogen fällt, wenn von Digital- auf Offsetdruck gewechselt wird oder wenn eine andere Maschine sinnvoller ist. Ein Kalkulationsregelwerk muss diese Sprünge abbilden, nicht glätten.
Weil die höhere Menge gelegentlich weniger kostet als die niedrigere. Technisch ist das korrekt: Ab einer bestimmten Auflage greift ein anderes Verfahren. Für den Besteller sieht es nach einem Bug aus, und er ruft an oder bricht ab. Die Antwort ist kein anderer Preis, sondern ein Hinweis an der Staffel: Die nächsthöhere Menge ist günstiger, und hier ist der Grund. Das nimmt Rückfragen aus dem Innendienst.
Der Shop braucht den Preis in Echtzeit, sonst gibt es keinen Konfigurator. Ob die Regeln im Web-System gepflegt werden oder über eine Schnittstelle aus der Kalkulation des Betriebs kommen, entscheidet sich daran, wer sie fachlich verantwortet. Liegt die Preishoheit im Betrieb, holen wir sie ab. Liegt sie im Vertrieb, ist ein konfigurierbares Regelwerk im System selbst der kürzere Weg. Zwei Kalkulationen parallel sind in beiden Fällen der Fehler.
Ja. Bei plotplus.de der Küper Digital GmbH & Co. KG ist der Upload sogar der Ausgangspunkt der Kalkulation: Das System nimmt große Druckdateien an, legt sie in einer Warteschlange ab, analysiert Seiten, Maße und bedruckte Fläche und leitet daraus zusammen mit Material, Ausgabeart und Stückzahl die Auftragspositionen ab. Die Verarbeitung läuft entkoppelt vom Webserver, damit ein großer Auftrag die Bedienung nicht ausbremst.
Automatisch prüfbar sind die formalen Dinge: Seitenformat und Beschnittzugabe, Farbraum, Bildauflösung, eingebettete Schriften, Seitenanzahl. Nicht prüfbar ist, ob der Inhalt stimmt. In unseren bestehenden Projekten ist der automatische Schritt die Auswertung der Datei für Auftragsumfang und Preis; eine Preflight-Prüfung ist ein eigener Baustein und je Projekt zu entscheiden. Wichtig ist dann, was das System mit dem Ergebnis macht: Ein Prüfprotokoll, das der Besteller sieht und bestätigt, ist belastbarer als eine stille Korrektur — vor allem, wenn später über eine Reklamation gesprochen wird.
OCI ist ein von SAP etablierter Standard für die elektronische Beschaffung. Der Einkäufer springt aus seinem Beschaffungssystem in den Lieferantenshop, stellt den Warenkorb zusammen und überträgt ihn strukturiert zurück; bestellt wird im eigenen System, mit dessen Budgets, Kostenstellen und Freigabestufen. In Banken und Behörden wird nicht frei im Internet eingekauft, deshalb ist die Anbindung dort Zugangsvoraussetzung. Der technische Ablauf steht auf unserer Leistungsseite zu OCI und Punch-out.
bank-formular.de von Lijnco ist ein Shopware-Shop für Formular- und Drucklösungen im Bankenumfeld. Über ein OCI-Plugin wird der Einkäufer mit den übergebenen Zugangsdaten angemeldet, sieht sein freigeschaltetes Sortiment zu seinen Konditionen, und der fertige Warenkorb geht im OCI-Feldformat an die Hook-URL des Beschaffungssystems zurück. Jede Anbindung wird gegen das reale Kundensystem getestet, weil Feldbelegungen, Zeichensätze und Rückgabeverfahren sich in der Praxis unterscheiden.
Im Formularwesen ist das keine Zusatzfunktion, sondern die Grundlage. Jeder Kunde hat eigene Artikel, oft mit eigenem Layout, eigener Nummerierung und eigenen Konditionen aus einem Rahmenvertrag. Ein Formular eines Instituts hat außerhalb dieses Kunden keinen Zweck und soll dort auch nicht auffindbar sein. Umgesetzt wird das über Kundengruppen mit freigeschalteten Sortimenten und kundenspezifischen Preisen.
Voraussetzung ist ein Auftragsarchiv, das nicht nur die Bestellung speichert, sondern die vollständige Konfiguration und die Druckdatei in der gedruckten Version. Dann besteht der Nachdruck aus zwei Eingaben, Auflage und Termin, und der Preis wird neu gerechnet, weil er von der Menge abhängt. Wer die Wiederbestellung stattdessen von Hand aufnehmen lässt, verliert den Kunden an den Anbieter, bei dem es zwei Klicks sind.
Gedruckt wird einmal die kontrahierte Gesamtmenge, geliefert wird auf Abruf. Der Shop muss dafür zwei Bestände kennen: die vereinbarte Menge und den Rest im Lager. Der Besteller ruft ab, sieht die Restmenge und wird gewarnt, bevor sie aufgebraucht ist. Belegt ist bei uns bisher die Nachbestellung bekannter Formulare aus der Bestellhistorie; die Abruflogik hängt an den Regeln des jeweiligen Rahmenvertrags und wird dafür gebaut. Das ist Lagerlogik in einem Shop-Frontend und in Standardsystemen nicht vorgesehen — aber es ist der Punkt, an dem Formularlieferanten ihre Kunden halten.
Nur, wenn er den Produktionsplan kennt. Ein Termin entsteht aus Bestellschlusszeit, Produktionstagen für die gewählte Weiterverarbeitung, Versandart und Feiertagen — nicht aus einem Textfeld. Solange diese Angaben nicht aus der Planung kommen, ist die ehrliche Variante eine Bandbreite mit Bestätigung nach der Prüfung der Daten. Eine harte Zusage, die der Betrieb nicht halten kann, kostet mehr als eine vorsichtige Angabe.
Es kommt darauf an, wo das Gewicht liegt. Steht der Vertrieb im Vordergrund — Kundengruppen, Konditionen, B2B-Bestellprozess, Punch-out —, ist Shopware die tragfähige Grundlage; so läuft bank-formular.de. Steht die Verarbeitung im Vordergrund, also Datei rein und Kalkulation raus, ist eine eigene Anwendung neben einem TYPO3-Auftritt der klarere Schnitt; so läuft plotplus.de. Wir sehen uns vorher an, was vorhanden ist. Wenn ein Umbau sich nicht rechnet, sagen wir das.
Schicken Sie uns eine Produktseite aus Ihrem Sortiment und die Preisstaffel dahinter. Daran lässt sich in einem Gespräch klären, ob Konfiguration reicht oder Entwicklung nötig ist. Mo–Fr 9:00–16:00, 0441 21 21 63 0.