01 · Briefing — Flexopack OPS

Ausgangslage, Unternehmen, Eigentümerstruktur, Stakeholder und was tatsächlich angefragt wurde. Stand: 09.08.2026, vor dem Erstgespräch im Werk Allhaming.

1. Das Unternehmen#

Flexopack Verpackungen GmbH, Allhaming 110, 4511 Allhaming, Oberösterreich.

Wirtschaftliche Kennzahlen (Stichtag 31.01.2025, laut Firmenbuch-Aggregatoren):

Bilanzsumme im Zeitverlauf: 2021 € 7,9 Mio · 2022 € 8,0 Mio · 2023 € 7,2 Mio · 2024 € 6,4 Mio · 2025 € 4,7 Mio.

Interpretation: Der starke Rückgang bei Bilanzsumme, Anlagevermögen und Eigenkapital fällt zeitlich exakt mit der Übernahme zusammen (siehe unten) und ist mit hoher Wahrscheinlichkeit transaktionsbedingt — Vermögenswerte, die im Zuge des Verkaufs entnommen, ausgeschüttet oder in eine andere Gesellschaft übertragen wurden. Kein Krisenindikator. Der ausgewiesene Bilanzgewinn von € 1,5 Mio. spricht für ein solide verdienendes Unternehmen.

Nicht im Erstgespräch ansprechen. Bilanzstruktur und Transaktionsdetails sind nicht unser Thema und wirken indiskret. Relevant ist ausschließlich: das Unternehmen kann eine Investition dieser Größenordnung tragen.

2. Eigentümerstruktur — der wichtigste Kontext#

Flexopack wurde im Januar 2025 zu 100 % von der Loxone Lighthouse GmbH übernommen.

• Verkäufer: Engelbert und Silvia Hundsberger (Nachfolgeregelung, kein Notverkauf).
• Zeitverlauf: Erstkontakt Juli 2024 → Grundsatzeinigung November 2024 → Closing Januar 2025 → neuer Geschäftsführer ab 14.02.2025.
• Die Transaktion war beim Bundeswettbewerbsbehörde-Zusammenschlussregister angemeldet (Fall 6849).

Loxone Lighthouse GmbH, Smart Home 1, 4154 Kollerschlag (FN 455454 k):

• Gesellschafter: Loxone GmbH mit 74,9 %, Rainer Eisner mit 25,1 %.
• Geschäftszweck: Unternehmensberatung / Beteiligungsholding mit Fokus Unternehmensnachfolge.
• Weitere Beteiligungen: Elektroplan Ingenieur GmbH (Göppingen), eosDATA Systems GmbH (Wien), Toman GmbH (Wolfratshausen), SOUP Filmproduktion GmbH (Berlin).
• Selbstbeschriebene Philosophie: langfristige Verantwortungsübernahme für Mitarbeiter und Standort, ausdrücklich kein Exit-Fokus („Das Wort Exit kommt bei uns gar nicht vor").

Loxone GmbH ist der oberösterreichische Hersteller von Gebäudeautomation / Smart-Home-Technik: eigene Hardware, eigene Firmware, eigene Serversoftware, weltweites Partnernetz. Also ein technisch außerordentlich versierter Eigentümer.

Was das für uns bedeutet#

1. Das PDF ist die Agenda des neuen Geschäftsführers. Ein GF, der 18 Monate im Amt ist und von einem Technologie-Eigentümer eingesetzt wurde, digitalisiert die Produktion, weil genau das sein Auftrag ist. Wir helfen dem Käufer, sein Versprechen einzulösen — die stärkste denkbare Deal-Konstellation.
2. Budgetrahmen ist nicht das Problem. Ein Loxone-gehaltenes Unternehmen mit € 1,5 Mio. Bilanzgewinn bewertet ein mehrjähriges Produktionsplattform-Programm im niedrigen sechsstelligen Bereich als normal. Die reale Alternative — ein Standard-MES — kostet € 80.000–200.000 an Lizenz und Einführung plus 18–22 % Wartung jährlich, dauerhaft.
3. Die technische Messlatte liegt höher. Es ist damit zu rechnen, dass die Architektur von jemandem auf Gruppenebene gelesen wird. Das spricht für unseren Ansatz (Cloud + ausgehender Connector, Postgres, phasenweise, dokumentierter Notfallbetrieb) — und gegen jede Schluderei.
4. Der Haupteinwand wird lauten: „Warum ein Einzelentwickler?" Muss beantwortet sein, bevor er gestellt wird — siehe 06-kommerziell.md, Abschnitt „Bus-Faktor".
5. Die Entscheidungskette muss geklärt werden. Gibt es Gruppen-IT bei Loxone Lighthouse oder Loxone? Gibt es Konzernstandards (Microsoft/Azure)? Könnte man versucht sein, intern zu bauen?

Umgang mit diesem Wissen im Termin: nicht damit eröffnen — das wirkt wie vorgeführte Due Diligence. Stattdessen früh und beiläufig fragen: „Wer entscheidet über das Budget, und wer muss zustimmen?" Kommt die Eigentümerstruktur zur Sprache, zeigen, dass man sie kennt — ein Loxone-gestützter GF respektiert Hausaufgaben.

Nebenbefund: Die Positionierung „Familienunternehmen" auf flexopack.at ist seit Januar 2025 sachlich überholt. Das ist ein separater, höflicher Hinweis wert — nicht in diesem Termin, aber bei Gelegenheit.

3. Vorgeschichte der Zusammenarbeit#

• SB Media hat 2026 die neue Website flexopack.at gebaut und ausgeliefert (Jaeger-Stack, PHP, Hostinger). Volumen im mittleren vierstelligen Bereich, beauftragt über ein drittes Unternehmen.
• Beim Go-live ist ein Split-Brain-DNS-Problem aufgetreten: Die interne Active-Directory-Zone flexopack.at auf dem Domain Controller FPD02.flexopack.at ist im Firmennetz autoritativ und überstimmt die öffentlichen DNS-Einträge. Gelöst über einen zusätzlichen internen A-Record www → 145.223.84.137.

Was uns dieser Vorfall über die IT-Landschaft verrät:

Diese IT-Verantwortlichen sind der wichtigste einzelne Stakeholder für die technische Umsetzbarkeit. Wer immer den Connector-Server bereitstellt, die Firewall-Regel freigibt und die Tablets ins WLAN lässt, kann das Projekt beschleunigen oder still begraben. Im Termin identifizieren und mit ins Boot holen.

4. Was angefragt wurde#

Das Handout „Projektübersicht Digitalisierung" umfasst zehn nummerierte Bausteine, fünf Projektphasen und zwölf Fragen an uns.

Leitidee des Kunden: „Daten dort erfassen, wo sie entstehen — einmal erfassen, mehrfach nutzen. Papier und Doppeleingaben konsequent reduzieren."

Grundsätze laut Kunde: einfache Bedienung · Tablet-first · Rollen & Rechte · zentrale Datenbasis · Echtzeit wo sinnvoll · ABAS-Anbindung · modular erweiterbar.

Genannte Kernsysteme: Samsung Galaxy Tab Active5 · Microsoft 365 / Forms · ABAS ERP · neu zu entwickelnde Web-/Datenbankkomponenten.

Die zehn Bausteine im Detail: siehe 04-module.md.

Die entscheidende Neuinterpretation#

Das Dokument liest sich wie ein Projekt. Es sind faktisch drei Produkte auf einem Fundament:

Gemeinsam haben sie: einen Login, ein Rollenmodell, eine Datenbank. Mehr nicht. Sie als einen Monolithen zu behandeln ist der Weg zu einem Zwei-Jahres-Projekt, das nie live geht. Sie als drei Stränge auf einem Fundament zu behandeln ist der Weg, das Projekt zu gewinnen und auszuliefern.

Der Wertkern liegt in Block B, konkret in Baustein 7 plus dem Ampelstreifen auf Seite 3 des Handouts: Klischees vorhanden → Klischees fertig → Farben fertig → Material verfügbar → Produktionsbereit. Alles andere auf dieser Seite speist diese Ampel.

Genau dafür gibt es kein Standardprodukt, weil kein Hersteller die Vorstufenkette eines Flexodruckers so modelliert, wie Flexopack sie lebt. Das ist der Grund, warum sie mit uns sprechen und nicht mit einem MES-Anbieter — und das ist unsere Positionierung.

5. Stakeholder-Landkarte (im Termin zu vervollständigen)#

6. Zielsetzung dieses Erstgesprächs#

Dieser Termin ist Erkundung, kein Pitch. Das Ziel ist nicht, ein Angebot zu platzieren, sondern:

1. Zu verstehen, wie Flexopack tatsächlich produziert — vom Kundenauftrag bis zur fertigen Rolle.
2. Zu verstehen, was ABAS in diesem Unternehmen ist, kann und darf.
3. Die kritischen Unbekannten zu schließen: ABAS-Version und Lizenzstatus, IT-Verantwortung, WLAN in der Halle, Betriebsrat, Altsystem Zeiterfassung, Lohnverrechnung.
4. Fachlich so aufzutreten, dass die Architekturhoheit bei uns landet.
5. Eine Größenordnung nennen zu können, ohne eine Zahl zu raten.

Fragenkatalog, Ablauf und Beobachtungscheckliste: 07-meeting-kit.md. Kurzfassung fürs Handy: 08-cheatsheet.md.

02 · ABAS ERP — Studienmaterial

Was ein ERP ist, was ABAS besonders macht, wie man es technisch anspricht, welches Vokabular man im Raum braucht und welche Fragen man stellen muss. Lesbar in ~20 Minuten. Gedacht als Zugslektüre vor dem Termin.

1. Was ein ERP eigentlich ist#

Ein ERP (Enterprise Resource Planning) ist das System of Record für die kaufmännische Realität eines Unternehmens: Artikel, Stücklisten, Arbeitspläne, Kunden, Aufträge, Einkauf, Lager, Fertigungsaufträge, Kalkulation, Rechnungen, Buchhaltung. Jede Zahl, die auf einer Rechnung oder im Jahresabschluss landet, entsteht dort.

Der Denkfehler, den man als Webentwickler mitbringt, ist der wichtigste, den man ablegen muss:

Daraus folgt die einzig richtige Haltung: nicht „wir integrieren ABAS", sondern „wir sind ein guter Gast in einem fremden Haus".

Unsere Anwendung ist ein Satellit. Sie erfasst, was das ERP nicht gut erfassen kann — was minütlich in der Halle passiert, mit Handschuhen bedient — und übergibt dem ERP die Zusammenfassung, die es braucht. Das ERP bleibt Wahrheit für Aufträge, Artikel und Kosten. Wir sind Wahrheit für Shopfloor-Ereignisse.

Warum ERPs für Shopfloor-Arbeit schlecht geeignet sind#

Nicht, weil sie schlecht gebaut wären, sondern weil sie für andere Nutzer gebaut sind: Sachbearbeiter am Desktop, Maus und Tastatur, mit Zeit und Kontext. Ein Drucker mit Handschuhen an einer 8-Farben-Maschine, der um 03:40 Uhr eine Störung dokumentieren soll, ist kein ERP-Nutzer. Deshalb existiert die gesamte Produktkategorie MES/BDE — und deshalb ist unser Projekt kein Konkurrent zu ABAS, sondern dessen Verlängerung in die Halle.

Diesen Satz kann man im Termin fast wörtlich verwenden. Er beruhigt jeden, der Angst hat, dass hier ein Parallelsystem entsteht.

2. ABAS im Besonderen#

Deutscher Hersteller (Karlsruhe, Wurzeln in den 1980ern), Zielgruppe Fertigungsunternehmen mit 50–1.000 Mitarbeitern. Flexopack liegt exakt in der Mitte dieser Zielgruppe. Zwei Eigenschaften prägen alles:

2.1 Es ist keine SQL-Datenbank#

ABAS läuft auf einer eigenen, objektorientierten Datenbank. Objekte werden als Datenbank:Gruppe adressiert — Zahlenpaare, z. B. 2:1 für Artikel/Produkt, 3:30 für Verkaufschance, 09:02 für Rückmeldungen.

Praktische Folge: Man kann nicht einfach „die Tabellen abfragen". Es gibt zwar eine ODBC/SQL-Brücke, aber sie ist lesend und ein Sonderweg. Alles, was wir bekommen, bekommen wir über eine der offiziellen Schnittstellen.

2.2 Es ist pro Kunde individuell programmiert#

ABAS liefert eine eigene 4GL-Sprache namens FO sowie das Konzept der Infosysteme — vom Partner gebaute Auswertungs- und Eingabemasken. Praktisch jede ABAS-Installation hat eigene Felder, eigene Masken, eigene Logik, die in keiner Herstellerdokumentation stehen.

Praktische Folge: Es gibt kein generisches Mapping. Wer die Anpassungen gebaut hat, ist eine Person mit Namen und Stundensatz. Diese Person zu finden ist eine der wichtigsten Aufgaben des Erstgesprächs.

2.3 Betriebsmodell#

ABAS läuft traditionell on-premise auf einem Linux-Server im Kundennetz. Es gibt inzwischen partner-gehostete Private-Cloud-Varianten. Multi-Tenant-SaaS ist ausdrücklich nicht die Produktstrategie — die Anpassungstiefe ist damit nicht vereinbar.

Praktische Folge, und das ist die wichtigste Architekturerkenntnis des ganzen Projekts: ABAS steht hinter ihrer Firewall. Eine Cloud-App kann es nicht direkt anrufen. Die Lösung dafür ist der Connector — siehe 03-architektur.md.

3. Die Zugangswege, geordnet#

3.1 Die gute Nachricht zur Rückmeldung#

Produktionsrückmeldung ist in ABAS kein exotischer Sonderweg. Eine Rückmeldung ist ein Datensatz in 09:02 mit dem Modus DONE. ABAS liefert dafür ab Werk Infosysteme mit — BDE buchen und BDE-Rückmeldung — über die Mitarbeiter Zeiten und Mengen erfassen.

Wir bitten also nicht um etwas Neues, sondern darum, einen Mechanismus zu befüllen, den ihr System bereits hat. Dieser Satz im Termin nimmt der ganzen Integrationsfrage die Schwere.

3.2 Der Notausgang, den man sich immer sichern muss#

Falls REST nicht lizenziert ist, der Partner keine Zeit hat oder die Freigabe dauert:

Ein geplanter CSV-Export der offenen Fertigungsaufträge in ein Verzeichnis, das unser Connector liest, kostet ihren Partner ein bis zwei Stunden und entkoppelt unsere gesamte Phase 1 von der ABAS-Politik.

Ohne ein „Ja" zu dieser Frage sollte man den Termin nicht verlassen.

4. Das Vokabular, das im Raum Glaubwürdigkeit erzeugt#

Der wichtigste Satz zum Mitnehmen#

Was unsere App „ein Auftrag auf Maschine 3" nennt, muss auf ihren Fertigungsauftrag plus Arbeitsgang abgebildet werden.

Hat man dieses Mapping, folgt alles Weitere. Hat man es nicht, baut man ein Paralleluniversum, das nie wieder mit der Realität zusammenkommt.

5. Was man sich im Termin zeigen lassen sollte#

20 Minuten mit der Person, die tatsächlich in ABAS arbeitet (Arbeitsvorbereitung oder Innendienst), und einen echten Auftrag durchgehen:

1. Ein Kundenauftrag für einen realen Druckjob — welche Felder sind fachlich relevant?
2. Der daraus erzeugte Fertigungsauftrag — wo steht die Maschine, wo der Plantermin, wo die Menge?
3. Sein Arbeitsplan — sind Klischee und Farbvorbereitung eigene Arbeitsgänge in ABAS oder existieren sie nur auf Papier?

→ Das ist der Angelpunkt für Baustein 7. Sind sie Arbeitsgänge, ist unsere Ampel weitgehend eine Sicht auf ihre Daten. Sind sie es nicht, sind wir das führende System dafür — und das Datenmodell sieht völlig anders aus.

4. Die Druckliste, die das Büro heute ausdruckt — das ist die reale Ist-Spezifikation der Planungstafel. Abfotografieren.
5. Eine Rückmeldung beim Buchen — macht das heute überhaupt jemand, und woher kommt die Zahl?
6. Eine Charge auf einem Lieferschein — wie gelangen Chargennummern heute nach ABAS?
7. Ein Infosystem, das täglich benutzt wird — zeigt, was der Partner bereits gebaut hat und wie versiert er ist.

6. Der Fragenkatalog ABAS#

1. Welche ABAS-Version ist im Einsatz, und wann wurde zuletzt aktualisiert? (REST braucht etwa 2019r4+)
2. Wer ist Ihr ABAS-Partner, und wer dort macht Ihre Anpassungen? (der Gatekeeper)
3. Ist die REST-API lizenziert und aktiviert? Falls nein: was kostet die Freischaltung, und sind Ihre Lizenzbedingungen von 09/2017 oder neuer? (die konkrete Blockade)
4. Läuft ABAS on-premise auf Ihrem eigenen Server oder beim Partner gehostet? Welcher Server, welches Netzsegment?
5. Ist abas Connect oder eine EDI-Middleware bereits im Einsatz?
6. Wer hat jemals ein Infosystem oder eine FO-Anpassung für Sie gebaut — gibt es Dokumentation?
7. Sind Klischee und Farbvorbereitung als Arbeitsgänge im Arbeitsplan abgebildet, oder nur informell?
8. Bucht heute jemand Rückmeldungen in ABAS? Ist das BDE-Modul lizenziert?
9. Falls wir zunächst keinen API-Zugang bekommen: können Sie einen geplanten Export (CSV) der offenen Fertigungsaufträge bereitstellen? (niemals ohne ein Ja hier gehen)
10. Gibt es ein Test-/Sandbox-System von ABAS, gegen das wir entwickeln können?
11. Wer pflegt die Stammdaten (Artikel, Arbeitspläne)? Wie aktuell sind sie tatsächlich?
12. Gibt es bereits Auswertungen/Kennzahlen aus ABAS — und warum reichen sie nicht?

Frage 9 ist das Sicherheitsnetz. Frage 3 ist die Blockade. Frage 10 entscheidet, ob Integration eine ruhige Ingenieursaufgabe oder russisches Roulette auf Live-Produktionsdaten wird.

Regel ohne Ausnahme: niemals Rückschreiben gegen ihr Live-System testen. Kein Testsystem heißt: erst ein bezahlter Machbarkeits-Spike mit dem Partner, dann ein Angebot.

7. Antworten lesen — Ampel#

Der letzte rote Punkt ist der gefährlichste. Tritt er ein, ist die professionelle Antwort:

„Bevor ich die Integration seriös anbieten kann, brauchen wir einen kurzen, bezahlten Machbarkeits-Spike gemeinsam mit Ihrem ABAS-Partner. Alles andere wäre geraten."

Das ist keine Schwäche. Das ist die Antwort, die ein Profi gibt.

8. Kernbotschaft zur Integrationsarchitektur#

Auch wenn morgen kein Pitch ansteht — dieser eine Satz sollte fallen, weil er die gesamte spätere Diskussion prägt:

„ABAS ist ein System, mit dem wir synchronisieren, nie ein System, von dem wir synchron abhängen."

Konkret: Unsere Datenbank ist Wahrheit für Shopfloor-Ereignisse. Rückmeldungen gehen in eine ausgehende Warteschlange mit Wiederholungen und sichtbarer Fehlerkonsole — niemals als blockierender Aufruf im Moment, in dem jemand auf ein Tablet tippt.

Drei Konsequenzen, alle zu unseren Gunsten:

1. Phase 1 und 2 funktionieren ohne jeden ABAS-Schreibzugriff. Lesend oder sogar nur per Nachtexport. Das entkoppelt unsere Auslieferung vom Zeitplan ihres ERP-Partners — der klassischen Todesursache solcher Projekte.
2. Wenn ABAS steht oder langsam ist, laufen die Maschinen weiter.
3. Der Schreibpfad wird ein abgegrenztes, separat kalkulierbares Arbeitspaket statt ein diffuses Risiko im Gesamtpreis.

Quellen#

• abas REST API Demo-Clients (GitHub, abassoftware)
• abas Connectivity & IoT
• abas Dokumentation — Installer-Module (rest_api, oauth2, jwt_auth_userinfo)
• abas Cloud Connect — Installationsanleitung
• abas ERP (Wikipedia, englisch — Architektur, FO, AJO, ODBC)
• abas Business Suite (Wikipedia, deutsch)
• Betriebsdatenerfassung — abas Blog
• MES und abas ERP mit neuer REST-Schnittstelle (ERP Management)
• FO Basis / Infosysteme programmieren — Schulung bei mait
• abas ERP Profil für den DACH-Mittelstand (TCO, Betriebsmodelle)

03 · Architektur, Sicherheit und Datenschutz

Zielarchitektur, Netzwerktopologie, Technologieentscheidungen, Rollenmodell, Datenklassifizierung und Rechtsrahmen. Beantwortet die Kundenfragen 1, 3, 4, 6, 8, 9 und 11 aus dem Handout.

1. Die entscheidende Frage, die im Handout fehlt#

Das Handout fragt nach der Gesamtarchitektur, aber nicht nach dem, was sie tatsächlich determiniert:

ABAS steht on-premise hinter der Firewall. Wo läuft dann unsere Anwendung?

Der naheliegende Reflex — „dann muss unsere App auch dort laufen" — ist falsch, und diesen Irrtum zu vermeiden ist die wichtigste Einzelentscheidung des Projekts.

Nur das, was mit ABAS spricht, muss drinnen sein. Die Anwendung nicht.

2. Zielarchitektur: Cloud + ausgehender Connector#

                      Internet / Cloudflare
   ┌──────────────────────────────────────────────────┐
   │  Flexopack OPS (SvelteKit auf Cloudflare Workers)│
   │  Neon Postgres (EU / Frankfurt)                  │
   │  R2 (Fotos, Anhänge, Etiketten-PDFs)             │
   └───────▲───────────────────────▲──────────────────┘
           │ HTTPS                 │ HTTPS (nur ausgehend
           │                       │ vom Werk initiiert)
   ┌───────┴────────┐      ┌───────┴───────────────────┐
   │ Tablets, PCs,  │      │  Connector (VM im Werk)   │
   │ Terminals      │      │  · pollt Aufgaben         │
   │ (WLAN / LTE)   │      │  · spricht ABAS lokal     │
   └────────────────┘      │  · meldet Ergebnis zurück │
                           └───────┬───────────────────┘
                                   │ lokal (REST / EDP 6550 / Datei)
                           ┌───────┴───────────────────┐
                           │  ABAS ERP (Linux-Server)  │
                           └───────────────────────────┘

Wie der Connector funktioniert#

Ein kleines Programm auf einer VM im Werksnetz. Es hält keinen offenen Port. Es ruft in regelmäßigen Abständen unsere Cloud-API an — dieselbe Art Verbindung, die jeder Browser im Büro aufbaut — und fragt: „Liegt etwas für mich an?" Dann erledigt es die ABAS-Arbeit lokal und meldet das Ergebnis per HTTPS zurück.

Was das konkret einbringt:

Cloudflare Tunnel wäre eine fertige Variante derselben Idee. Wir bauen trotzdem einen eigenen Connector: Polling ist dümmer, und dümmer ist robuster — kein zusätzlicher Herstellervertrag, kein Verhalten, das wir nicht selbst debuggen können.

Warum nicht auf ihrem Server hosten#

Die Alternative — SvelteKit und Postgres auf ihrer Linux-Maschine — macht uns verantwortlich für Betriebssystem-Patches, Backups, TLS-Zertifikate, Verfügbarkeit und einen Anruf um 02:00 Uhr. Im Gegenzug erhalten wir nichts, was wir brauchen. Für ein Ein-Personen-Unternehmen ist das der falsche Tausch.

Der eine Umstand, der die Cloud-Variante kippen würde#

Haben die Tablets in der Produktionshalle überhaupt Internetzugang, oder ist das Shopfloor-WLAN isoliert? Manche Werksnetze sind es. Muss im Termin geklärt werden.

Wenn isoliert, ist die saubere Antwort nicht ein On-Premise-Server, sondern Tab Active5 mit LTE und Daten-SIM (rund € 5–10 pro Gerät und Monat). Das macht die Tablets zusätzlich unabhängig von der WLAN-Qualität und von ihrer Internetleitung — eine bessere Resilienzgeschichte als ein On-Premise-Server, zu einem Bruchteil des Betriebsaufwands.

DNS#

Sie haben Split-Brain-DNS (interne AD-Zone flexopack.at überstimmt öffentliches DNS). Für ops.flexopack.at braucht es daher denselben Handgriff wie bei der Website: zusätzlich einen internen A-/CNAME-Record auf dem Domain Controller. Bekannter, gelöster Vorgang — im Termin erwähnen, das zeigt Kontinuität.

3. Technologieentscheidungen#

Warum nicht Supabase#

Supabase bündelt Auth, Storage, Realtime und RLS attraktiv. Zwei Gründe sprechen dagegen: Supabase Auth passt schlecht zu Badge-/PIN-Anmeldung an einem geteilten Gerät, und wir wollen die Autorisierung ohnehin in einer Repository-Schicht statt in RLS-Policies (siehe §5). Damit bleibt vom Bündel zu wenig übrig.

Warum kein SQLite / D1#

Schreiblast ist zwar gering, aber wir brauchen Zeitreihen-Aggregate für Kennzahlen, timestamptz, saubere Enums und perspektivisch Auswertungen über Monate. Postgres kostet auf Neon im Leerlauf praktisch nichts und nimmt uns diese Frage dauerhaft ab.

4. Produktförmig, nicht bespoke-hardcodiert#

„Bespoke, aber produktförmig" heißt konkret: alles, was sich in fünf Jahren ändern kann, ist eine Zeile in einer Tabelle mit Admin-Oberfläche, nicht ein if im Code.

Als Daten modelliert:

• Maschinen / Arbeitsplätze (inkl. Bereichszuordnung, Reihenfolge, Status)
• Bereiche (Druck, Klischee, Farbe, Rollenschneider, Büro, Lager)
• Rollen und deren Berechtigungen
• Workflow-Schritte der Produktionsbereitschaft (die „Hakerl") — Name, Reihenfolge, wer darf setzen, wer darf zurücksetzen
• Statusdefinitionen und Farben
• Störungs- und Ausschusskategorien
• Schichtmodelle und Schichtzeiten
• Lagerplätze im Farblager
• Formulartypen im Service Portal inkl. Feldern und Zuständigkeiten

Dreifacher Nutzen: Flexopack wird selbst handlungsfähig („wir haben eine fünfte Maschine" ist kein Support-Ticket), unser Wartungsaufwand sinkt, und die Lösung wäre bei einer anderen Druckerei eine Konfigurations- statt einer Programmieraufgabe. Aufpreis rund 15 % im Fundament, der sich über die Laufzeit mehrfach zurückzahlt.

5. Autorisierung: Posture B, App-enforced#

Entscheidung: Autorisierung in einer server-seitigen Repository-Schicht, nicht über Row Level Security.

Begründung: Es gibt genau einen Mandanten. Die Gefahr eines mandantenübergreifenden Lecks existiert nicht. Das reale Risiko ist Rollen-Leakage — ein Maschinenbediener, der Krankenstände sieht; ein Schichtführer, der Lohndaten sieht. Dieses Risiko adressiert man besser mit expliziten, testbaren Rollenprüfungen an einer einzigen Stelle als mit Policies, die jede Abfrage schwer durchschaubar machen.

Strukturell abgesichert, nicht durch Disziplin:

• Genau ein server-seitiges Datenzugriffsmodul unter src/lib/server/db/. Routen, Actions und Komponenten importieren db niemals direkt.
• Jede Query-Funktion nimmt den Actor-Kontext (Benutzer + Rollen + Bereiche) als Pflichtargument entgegen — nie aus Ambient-State gelesen. Vergessener Kontext wird zum Typfehler, nicht zum Leck.
• Fetch-by-id filtert Berechtigung in derselben Abfrage, nie „erst holen, dann prüfen".
• Lint-/CI-Regel: kein db-Import außerhalb von src/lib/server/db/.
• Ergänzend: auf den Personaltabellen (Krankenstand, Zeitdaten) zusätzlich RLS als zweite Wand — dort, wo ein Fehler ein meldepflichtiger DSGVO-Vorfall wäre.

6. Rollen- und Rechtemodell (Kundenfrage 4)#

Modell: Rollentypen × Bereiche, beide administrierbar.

Bereichsdimension: Druck · Klischee · Farbe · Rollenschneider · Lager · Büro. Ein Benutzer kann mehrere Bereiche haben — der Praxisfall, an dem starre Rollenlisten scheitern.

Wichtig: Der Zugriff auf Personaldaten ist eine eigene Rolle, keine Stufe in einer Hierarchie. „Leitung" bedeutet nicht automatisch „darf Krankenstände sehen". Diese Trennung ist der Kern der DSGVO-Verteidigung und wird vom Betriebsrat als Erstes geprüft.

Anmeldung#

Prinzip der Datensparsamkeit: Nicht jede Handlung braucht eine Person. „Maschine 3 hat 4.200 lfm gedruckt" braucht keinen Namen. „Wer hat diesen Eintrag im Maschinenheft geändert?" schon. Wo kein Name nötig ist, wird keiner gespeichert — das reduziert die § 96-ArbVG-Angriffsfläche erheblich und ist gegenüber dem Betriebsrat gut argumentierbar.

7. Offline und Tablet-Betrieb (Kundenfrage 8)#

Eine Druckhalle ist eine feindliche Funkumgebung: Stahl, Motoren, große Maschinen. WLAN-Funklöcher sind kein Sonderfall, sondern der Normalfall.

Entscheidung: Read-Cache + Write-Outbox ab Phase 1.

• Die App ist eine PWA und hält den zuletzt bekannten Zustand lokal lesbar (aktuelle Aufträge, eigene Maschine, Stammdaten).
• Schreibvorgänge (Maschinenheft-Eintrag, Chargenscan, Rückmeldung) werden lokal in eine Outbox gelegt und bei Verbindung automatisch übertragen.
• Der Status ist sichtbar: „3 Einträge warten auf Übertragung". Nie stiller Datenverlust, nie die Illusion, es sei gespeichert.
• Konfliktstrategie: Shopfloor-Ereignisse sind append-only Fakten mit Zeitstempel — sie kollidieren fachlich nicht. Nur bei Statusänderungen („Hakerl") gilt Last-Write-Wins mit sichtbarer Historie.
• Erfassungszeit und Übertragungszeit werden getrennt gespeichert. Für Rückverfolgbarkeit und Rückmeldungen ist das nicht verhandelbar.

Rund eine Woche Mehraufwand in Phase 1, spart einen Umbau später.

Hardware:

8. Datenklassifizierung — was hier liegt und wer es sehen darf#

Die zentrale Frage, die vor dem Bauen beantwortet gehört: Was wäre das Schlimmste, das aus diesem System austritt?

Das Schlimmste, konkret benannt#

1. Ein Auszug der Krankenstände aller Mitarbeiter. Personenbezogene Gesundheitsdaten, unmittelbar meldepflichtig, verheerend für das Betriebsklima. → Deshalb minimal, getrennt, protokolliert, streng rollengebunden.
2. Eine Auswertung „Ausschuss pro Mitarbeiter", die den Weg ins Personalgespräch findet, ohne dass das je vereinbart war. Rechtlich (§ 96 ArbVG) und menschlich der GAU, und der sicherste Weg, dass die Belegschaft das System sabotiert. → Deshalb standardmäßig aggregiert, Zweckbindung schriftlich, Betriebsrat früh einbinden.
3. Die Auftragsliste mit Kundennamen und Mengen bei einem Mitbewerber. → Deshalb keine öffentlichen Endpunkte, protokollierte Exporte, private Objektspeicher.
4. Ein verlorenes, unverwaltetes Tablet mit gespeicherten Offline-Daten. → Deshalb MDM, Geräteverschlüsselung, PIN, Fernlöschung, begrenzter Offline-Cache-Umfang und -Zeitraum.

Formulierung für den Termin: „Wir haben vorab klassifiziert, welche Daten in so einem System entstehen und was davon besonders schützenswert ist. Krankenstände sind Gesundheitsdaten nach Artikel 9 DSGVO, Zeit- und Leistungsdaten sind eine Kontrollmaßnahme nach § 96 Arbeitsverfassungsgesetz. Beides behandeln wir technisch getrennt vom Rest — und beides bespricht man besser vor dem Bauen als danach."

Dieser Absatz ist im Gespräch mehr wert als jede Technologiefolie.

9. Rechtsrahmen — was vorab geklärt gehört#

§ 96 / 96a ArbVG — Betriebsvereinbarung#

Zeiterfassung und ein digitales Maschinenheft, das festhält, wer in welcher Schicht welchen Vorfall verursacht hat, sind Kontrollmaßnahmen, die die Menschenwürde berühren. In Österreich bedeutet das:

• Mit Betriebsrat: zustimmungspflichtige Betriebsvereinbarung. Ohne sie darf das System nicht eingeführt werden.
• Ohne Betriebsrat: individuelle Zustimmung jedes Mitarbeiters — praktisch heikel, weil Zustimmung im Arbeitsverhältnis nur eingeschränkt freiwillig ist.

Bei ~50 Mitarbeitern in der österreichischen Industrie ist ein Betriebsrat sehr wahrscheinlich. Zwei Fragen entscheiden über den Zeitplan:

1. Gibt es einen Betriebsrat?
2. Gibt es bereits eine Betriebsvereinbarung zur bestehenden Zeiterfassung? Falls ja: hervorragend — eine bestehende Vereinbarung zu ändern ist deutlich billiger und schneller, als eine erste zu verhandeln. Die politische Arbeit ist getan.

Der Vorlauf für eine neue Betriebsvereinbarung beträgt realistisch zwei bis sechs Monate. Das ist ein Terminrisiko, kein technisches — und ein Grund mehr, mit Maschinenheft und Service Portal zu starten und die Zeiterfassung nach hinten zu legen.

§ 26 AZG — Aufzeichnungspflicht#

Arbeitszeiten, Pausen, Überstunden und Ruhezeiten müssen lückenlos aufgezeichnet werden. Aufzeichnungen sind dem Arbeitsinspektorat auf Verlangen vorzulegen; der Betriebsrat hat Einsichtsrechte (§ 89 ArbVG); Mitarbeiter haben Anspruch auf Abschrift bzw. Einsicht.

Konsequenz für die Architektur: Wenn wir Zeiterfassung bauen, ist unsere Datenbank Teil einer gesetzlichen Aufzeichnungspflicht. Daraus folgen unverhandelbar: verlässliche Backups, Point-in-Time-Recovery auf einem bezahlten Neon-Tarif (nicht Free, dort nur 6 Stunden Historie), Exportierbarkeit und ein Nachweis der Unveränderbarkeit.

DSGVO — Betroffenenrechte#

• Verzeichnis von Verarbeitungstätigkeiten — Flexopack ist Verantwortlicher, wir sind Auftragsverarbeiter.
• Auftragsverarbeitungsvertrag (AVV) nach Art. 28 zwischen Flexopack und SB Media ist Pflicht, ebenso die Unterauftragsverarbeiter-Kette (Cloudflare, Neon, Resend).
• Datenresidenz: Neon EU-Region, R2 mit EU-Jurisdiktion, Resend EU. Sagbar und nachweisbar.
• Auskunft, Löschung, Berichtigung müssen bedienbar sein — bei Personaldaten praktisch relevant.
• Löschfristen je Datenklasse definieren, nicht „alles für immer".

Aufbewahrung (Vorschlag, mit Steuerberater/Anwalt zu bestätigen)#

10. Audit-Trail (Kundenfrage 9)#

Entscheidung: Append-only Protokoll auf allem, was zählt — ab Tag eins.

Jeder Schreibvorgang auf Produktions-, Personal- und Konfigurationsdaten erzeugt einen unveränderlichen Eintrag: wer, was, wann, vorher/nachher, von welchem Gerät. Eigene Tabelle, keine Updates, keine Deletes.

Warum sofort und nicht später:

• Rückverfolgbarkeit bei Lebensmittelverpackung ist nicht optional.
• Der erste Streit über eine Produktionsmenge („da stand aber 4.200") wird ohne Protokoll unentscheidbar.
• Lohnrelevante Daten ohne Nachvollziehbarkeit sind wertlos.
• Nachträglich einzubauen ist praktisch unmöglich, weil die Historie fehlt.
• Es ist die direkte Antwort auf ihre Frage 9 — und ein Argument, das ein technischer Eigentümer sofort versteht.

Zusätzlich protokolliert: jeder lesende Zugriff auf S1- und personenbezogene S2-Daten. Das ist der Nachweis gegenüber Betriebsrat und Datenschutzbehörde, dass die Rollentrennung nicht nur behauptet ist.

11. Betrieb, Backup, Fehlerbehandlung (Kundenfrage 9)#

Wir sind nie die einzige Kopie#

Täglicher Export der gesetzlich oder betrieblich kritischen Daten (Zeitaufzeichnungen, Chargen, Rückmeldungen) auf ihren eigenen Fileserver oder nach ABAS.

Kostet einen Entwicklungstag und nimmt gleich drei Ängste: „Was, wenn die Cloud weg ist?", „Was, wenn der Entwickler weg ist?", „Halten die unsere Daten in Geiselhaft?". Im Termin aussprechen — es entschärft den größten unausgesprochenen Zweifel gegenüber einem Einzelentwickler.

12. Kritikalitätsstufen und Notfallbetrieb#

Nicht jedes Modul verdient dieselbe Verfügbarkeitszusage. Einordnung nach der Frage: Was bricht, wenn wir vier Stunden ausfallen?

Jedes vitale Modul wird mit einem dokumentierten Notfallbetrieb ausgeliefert: druckbare Tagesproduktionsliste, Papierformular für Chargen, eine Seite „So arbeiten Sie weiter, wenn das System steht", vom Kunden formal abgenommen.

Das ist in der Fertigung völlig normale Praxis, verschafft Respekt — und ist der Haftungsschutz, der tatsächlich wirkt. Verfügbarkeitsversprechen schützen nicht; ein eingeübter Rückfallweg schon.

13. Modularität ohne Insellösungen (Kundenfragen 6 und 11)#

Ihre Sorge ist berechtigt und verdient eine strukturelle Antwort statt einer Beteuerung:

Der Satz für den Termin: „Insellösungen entstehen nicht durch Module, sondern durch mehrfache Benutzerverwaltung, mehrfache Stammdaten und mehrfache Schnittstellen. Genau diese drei gibt es bei uns jeweils nur einmal."

14. Zukaufen statt selbst bauen (Kundenfrage 10)#

15. Offene technische Punkte für den Termin#

• Haben die Tablets in der Halle Internetzugang? Ist das Shopfloor-WLAN isoliert?
• WLAN-Abdeckung an jeder Maschine, im Farblager, in der Klischeekleberei
• Wer stellt die Connector-VM? Welches Betriebssystem, wer administriert sie?
• Ist ausgehendes HTTPS aus dem Serversegment erlaubt? Gibt es einen Proxy?
• Gibt es bereits Badges/RFID von der alten Zeiterfassung — welcher Typ, wiederverwendbar?
• Existiert bereits eine Etikettierung im Farblager, oder müssen ~500 Etiketten neu erzeugt werden?
• Wie viele Tablets, an welchen Stellen, wer lädt sie?
• Gibt es Gruppen-IT bei Loxone Lighthouse / Loxone? Konzernstandards?
• M365-Tenant vorhanden — Entra-ID-SSO fürs Büro möglich?
• Wer ist Datenschutzverantwortlicher bei Flexopack?

04 · Die zehn Bausteine im Detail

Jeder Baustein aus dem Handout: was gemeint ist, was fachlich dahintersteckt, was wir bauen würden, was daran schwierig ist, welche Fragen offen sind. Am Ende: Kritikalitätseinstufung und Pilotempfehlung.

Baustein 1 · Mitarbeiterportal / Service Portal#

Im Handout: Bereichsabhängiger Einstiegspunkt. Bestehendes Service Portal via Microsoft Forms integrieren/weiterentwickeln: Rohware sperren, Sicherheits- und Technikmängel, Verbesserungen. Zusätzlich Urlaub und Krankenstand.

Was das fachlich ist: Ein internes Meldewesen. Jemand stellt fest, dass eine Rohwarenpalette nicht in Ordnung ist, ein Geländer wackelt oder eine Maschine anders laufen könnte — und meldet es. Heute über Microsoft Forms.

Warum Forms nicht reicht: Forms erzeugt Zeilen in einer Tabelle. Es hat keinen Status, keine Zuständigkeit, keine Wiedervorlage, keine Historie, keine Rechteverwaltung und keine Verbindung zu Maschine, Auftrag oder Material. Wer etwas meldet, erfährt nie, was daraus wurde — was Meldungen zuverlässig versiegen lässt.

Was wir bauen:

• Konfigurierbare Meldungstypen (Rohware sperren · Sicherheitsmangel · Technikmangel · Verbesserungsvorschlag · sonstiges), Felder je Typ administrierbar.
• Statusfluss: offen → in Bearbeitung → erledigt → geschlossen, mit Zuständigem und Fristen.
• Fotoanhang direkt vom Tablet — bei Rohwarenmängeln der eigentliche Mehrwert.
• Verknüpfung mit Maschine, Auftrag, Charge, Lieferant.
• Benachrichtigung an die zuständige Rolle; Rückmeldung an den Melder.
• „Rohware sperren" als Sonderfall mit Wirkung: gesperrtes Material darf in der Produktionsplanung nicht als verfügbar gelten. Das ist der Punkt, an dem aus einem Formular ein System wird.

Schwierigkeiten: gering. Das eigentliche Risiko ist Feature-Wucherung — jeder Bereich will ein eigenes Formular.

Offene Fragen:

• Welche Formulare gibt es heute in Forms, mit welchen Feldern? (Exporte erbitten)
• Wie viele Meldungen pro Monat?
• Wer bearbeitet sie heute, und wo landen sie?
• Soll „Rohware gesperrt" nach ABAS zurückwirken (Sperrkennzeichen am Los)?

Einschätzung: Idealer Pilotbaustein. Klein, sichtbar, null Produktionsrisiko, betrifft alle Bereiche und beweist Rollen, Benachrichtigungen, Fotoupload und Admin-Layer.

Baustein 2 · Zeiterfassung#

Im Handout: Ablösung des alten Systems. Kommen/Gehen, Pausen, Schichten, Überstunden, Abwesenheiten, Korrekturen und Freigaben. Hardwareoptionen: Tablet, Terminal, NFC/RFID.

Eigene, ausführliche Analyse: 05-zeiterfassung.md. Kurzfassung:

Zeiterfassung ist drei Systeme mit einem Namen — Erfassung (einfach), Regelwerk (der Killer: Kollektivvertrag, Zuschläge, Durchrechnung) und Lohnübergabe (abhängig von ihrer Lohnsoftware). Dazu § 96 ArbVG (Betriebsvereinbarung) und § 26 AZG (Aufzeichnungspflicht).

Empfehlung: nicht im Erstgespräch entscheiden. Erst herausfinden, was das Altsystem ist und woran es scheitert. Danach zwischen vier Optionen wählen (kaufen / Erfassung bauen + Regelwerk kaufen / alles bauen / Altsystem behalten und nur Selfservice ergänzen).

Einschätzung: höchstes Aufwands- und Haftungsrisiko im gesamten Programm. Gehört ans Ende der Roadmap, nicht an den Anfang.

Baustein 3 · Tablet in der Produktion#

Im Handout: Galaxy Tab Active5 als zentrale Bedienoberfläche: Aufträge, Rückmeldungen, Mengen, Ausschuss, Chargen, Maschineninformationen, Störungen und Schichtübergaben.

Was das fachlich ist: Kein Modul, sondern die Oberfläche, durch die fast alle anderen Module bedient werden. Im Handout als Punkt 3 gelistet, in Wahrheit Teil des Fundaments.

Was wir bauen:

• PWA, installierbar, Vollbild/Kiosk-fähig, für Tablet-Querformat entworfen.
• Maschinenkontext: Ein Tablet „gehört" zu einer Maschine und zeigt deren Auftragslage.
• Anmeldung per NFC-Badge + PIN, mit automatischer Abmeldung nach Inaktivität.
• Offline-Read-Cache und Write-Outbox mit sichtbarem Status.
• Bedienung für Handschuhe: Trefferflächen ≥ 56 px, große Schrift, kein Hover, keine Freitextfelder wo eine Auswahl genügt.
• Hohe Kontraste, Status nie nur über Farbe (Form + Text zusätzlich).

Schwierigkeiten: Die eigentliche Hürde ist nicht technisch, sondern ergonomisch. Ein Tablet-UI, das am Schreibtisch großartig wirkt, kann an der Maschine unbenutzbar sein. Deshalb: Prototyp früh auf einem echten Gerät an der echten Maschine testen, mit einem echten Bediener.

Offene Fragen:

• Wie viele Tablets, an welchen Positionen? Fest montiert oder mitgeführt?
• Ladekonzept, Ersatzakkus, Zuständigkeit?
• Wer administriert die Geräte (MDM)?
• Werden Handschuhe getragen? Schutzbrillen? Wie ist die Beleuchtung?
• Lärmpegel — sind akustische Signale sinnlos?

Einschätzung: Fundament, gehört in Phase 1. Nicht separat verkaufbar.

Baustein 4 · ABAS-Rückmeldung#

Im Handout: Auftragsdaten lesen und Produktionsrückmeldungen zurückschreiben. Zu prüfen: verfügbare Schnittstellen, Datenobjekte, Authentifizierung und Fehlerhandling.

Ausführlich: 02-abas-studie.md. Kurzfassung:

• Lesen ist der einfache Teil und kommt zuerst: offene Fertigungsaufträge, Arbeitsgänge, Artikel, Termine, Mengen.
• Schreiben ist der heikle Teil: eine Rückmeldung ist ein Datensatz in 09:02 mit Modus DONE. ABAS bringt dafür ab Werk BDE-Infosysteme mit — wir befüllen einen vorhandenen Mechanismus.
• Immer asynchron: Outbox, Wiederholung, sichtbare Fehlerkonsole. Nie ein blockierender Aufruf im Tablet-Tap.
• Notausgang: geplanter CSV-Export der offenen Fertigungsaufträge, falls REST nicht verfügbar ist.

Empfehlung zur Arbeitsteilung: Die ABAS-seitige Arbeit macht ihr ABAS-Partner, direkt an Flexopack abgerechnet, gegen eine von uns geschriebene Schnittstellenspezifikation. Wir bauen den Connector und die Verarbeitung auf unserer Seite. Das ist nicht nur risikoärmer für uns, es ist auch technisch die bessere Arbeitsteilung — der Partner kennt diese Installation.

Einschätzung: Höchstes Unbekanntheitsrisiko. Erst nach einem Machbarkeits-Spike belastbar kalkulierbar. Vital-Stufe, sobald Rechnungen davon abhängen.

Baustein 5 · Chargennummern per Scan#

Im Handout: Heute abschreiben → Zettel/Lieferschein → erneute Eingabe im Büro. Soll: Barcode/QR scannen → Auftrag zuordnen → speichern → idealerweise direkt an ABAS. Tablet, Handheld oder Bluetooth-Scanner prüfen.

Was das fachlich ist: Rückverfolgbarkeit. Bei Lebensmittelverpackung keine Bequemlichkeit, sondern regulatorische Pflicht (Rahmenverordnung 1935/2004, GMP-Verordnung 2023/2006, dazu ISO 22000, BRC-Standards). Es muss beantwortbar sein: welche Rohfolien-Charge steckt in welcher gelieferten Rolle bei welchem Kunden.

Der Schmerz ist echt und dreifach: abschreiben (Fehlerquelle 1), Zettel (Verlustquelle), erneut eintippen (Fehlerquelle 2). Jeder Tippfehler in einer Chargennummer macht die Rückverfolgbarkeit im Ernstfall wertlos.

Was wir bauen:

• Scannen am Tablet (Kamera + Knox Capture) oder per Bluetooth-Scanner.
• Sofortige Zuordnung: Charge → Auftrag → Maschine → Zeitpunkt → Person.
• Plausibilitätsprüfung beim Scan: Gehört diese Charge zu diesem Artikel? Ist das Material gesperrt (Verbindung zu Baustein 1)? Passt die Menge?
• Vollständige Historie, exportierbar, unveränderlich protokolliert.
• Ausgabe: Rückverfolgbarkeitsauskunft in beide Richtungen — von Rohcharge zu Lieferungen und von Lieferung zu Rohchargen.
• Übergabe an ABAS über die Outbox, sobald verfügbar.

Schwierigkeiten:

• Barcodeformate der Lieferanten sind uneinheitlich. Manche liefern GS1-128 mit Chargen-AI (10), manche Code128 mit Klartext, manche gar nichts. Es braucht eine Erkennungsschicht mit regelbasierter Zuordnung pro Lieferant — administrierbar, nicht hartcodiert.
• Was passiert, wenn eine Rolle keine maschinenlesbare Kennzeichnung hat? (Antwort: eigenes Etikett drucken und aufkleben — Etikettendrucker einplanen.)
• Teilverbrauch: Eine Rohrolle geht über mehrere Aufträge. Das Datenmodell muss n:m abbilden, nicht 1:1.

Offene Fragen:

• Welche Lieferanten, welche Etiketten? Fotos von echten Rohwaren-Etiketten mitnehmen.
• Wie viele Chargenwechsel pro Schicht?
• Wie sieht die Rückverfolgbarkeit heute aus, wenn ein Kunde reklamiert? Wie lange dauert eine Auskunft?
• Gibt es Anforderungen aus einem Audit (ISO 22000, BRC, FSC)?
• Wird bereits mit Chargen in ABAS gearbeitet?

Einschätzung: Hoher, sofort spürbarer Nutzen; guter zweiter Baustein. Vital-Stufe wegen der Rückverfolgbarkeit — aber mit sauberem Papier-Rückfall abbildbar.

Baustein 6 · Farblager — „Kammer des Schreckens"#

Im Handout: Farbkanne und Regalplatz digital verheiraten. Regalplatz scannen + Kanne scannen + Gewicht erfassen. Bei Rückgabe von der Maschine Restgewicht und neuen Lagerplatz dokumentieren. Ergebnis: Standort, Bestand und Historie nachvollziehbar.

Was das fachlich ist: Ein Lagerverwaltungsproblem mit einer Besonderheit — der Bestand ist kontinuierlich, nicht diskret. Man hat nicht „3 Kannen Pantone 485", sondern „eine angebrochene Kanne mit 12,4 kg Rest". Der Kunde hat die Lösung im Grunde selbst beschrieben, und sie ist richtig.

Was wir bauen:

• Etikettierung: QR-Etiketten für Regalplätze, QR-Etiketten für Kannen (mit fortlaufender interner ID, unabhängig vom Lieferantenetikett).
• Einlagern: Platz scannen → Kanne scannen → Gewicht erfassen → fertig. Drei Handgriffe, kein Tippen.
• Entnahme an die Maschine: Kanne scannen → Auftrag wählen → Ausgangsgewicht.
• Rückgabe: Kanne scannen → Restgewicht → neuer Platz scannen.
• Bestandsübersicht nach Farbe/Rezeptur, Suche „wo ist Pantone 485?", Historie je Kanne.
• Alterung: Anbruchdatum, Haltbarkeit, Warnung bei Überlagerung.
• Optional später: Waage per Bluetooth direkt angebunden — spart das Abtippen des Gewichts und ist eine spürbare Verbesserung.

Schwierigkeiten:

• Der Erstbestand ist der eigentliche Aufwand. Alle vorhandenen Kannen einmalig erfassen, etikettieren, wiegen, einlagern. Bei einem gewachsenen Farblager sind das leicht 300–800 Positionen und ein bis zwei Personentage — vom Kunden, nicht von uns. Muss früh und klar gesagt werden.
• Ohne Disziplin bei der Rückgabe verfällt die Datenqualität innerhalb von Wochen. Der Prozess muss schneller sein als „Kanne irgendwo hinstellen", sonst gewinnt die Kanne.
• Sonderfälle: Kanne umgefüllt, Farbe angemischt, Restmengen zusammengeschüttet. Das Datenmodell braucht „Kanne entstand aus Kanne(n)".

Offene Fragen:

• Wie viele Kannen/Positionen? Wie viele Regalplätze?
• Wer mischt Farben an, und entstehen dabei neue Gebinde?
• Gibt es eine Waage? Mit Schnittstelle?
• Wird der Farbbestand heute in ABAS geführt, oder gar nicht?
• Wie hoch ist der Schwund/Verfall heute? (Zahl für die Nutzenargumentation)

Einschätzung: Klar abgrenzbar, schnell nutzbar, geringes Risiko. „Kammer des Schreckens" verrät hohen Leidensdruck — gutes Kandidatenmodul für frühen sichtbaren Erfolg. Komfort-Stufe.

Baustein 7 · Durchgängige Produktionsplanung#

Im Handout: Zentrales Hauptprojekt. Büro priorisiert Aufträge; Vorstufen melden Bereitschaft; Maschine sieht vorbereitete Aufträge und kann innerhalb definierter Regeln reihen. Einfaches Statussystem mit grünen Hakerln.

Was das fachlich ist: Der Leitstand. Und mit dem Ampelstreifen von Seite 3 — Klischees vorhanden → Klischees fertig → Farben fertig → Material verfügbar → Produktionsbereit — der Wertkern des gesamten Programms.

Das eigentliche Problem, das gelöst wird: Heute weiß die Maschine nicht zuverlässig, ob ein Auftrag wirklich startbereit ist. Ist das Klischee geklebt? Ist die Farbe angemischt? Ist die Folie da? Das klärt man heute durch Hingehen, Nachfragen und Zurufen. Das Ergebnis sind Rüstvorgänge, die abgebrochen werden, und Maschinen, die stehen, obwohl Arbeit da wäre.

Was wir bauen:

• Auftragspool aus ABAS (oder anfangs Import), mit Termin, Menge, Artikel, Maschine.
• Priorisierung durch das Büro — Reihenfolge, Termindruck, Kundenpriorität.
• Bereitschaftsschritte als konfigurierbare Datensätze, nicht als fixe Spalten. Heute vier Hakerl, morgen vielleicht sechs. Jeder Schritt: Name, Reihenfolge, zuständiger Bereich, wer darf setzen, wer darf zurücksetzen, ob er blockierend ist.
• Maschinensicht: Was ist bereit, was kommt als Nächstes, was fehlt noch — pro Maschine, groß und eindeutig.
• Reihung innerhalb von Regeln: Die Maschine darf umsortieren, aber nur innerhalb definierter Grenzen (z. B. nicht über einen Termin hinweg, nicht an einem gesperrten Auftrag vorbei). Regeln sind Konfiguration.
• Statuswechsel erzeugen Ereignisse — daraus entstehen später die Kennzahlen, ohne dass irgendwer etwas doppelt pflegt.
• Papier-Rückfall: druckbare Tagesliste je Maschine.

Schwierigkeiten — hier liegt die eigentliche Projektschwierigkeit:

1. Ist Klischee/Farbe ein Arbeitsgang in ABAS oder nicht? Falls ja, sind wir eine Sicht auf ihre Daten und müssen mit ABAS synchron bleiben. Falls nein, sind wir das führende System für diese Schritte — einfacher zu bauen, aber es entsteht eine zweite Wahrheit neben ABAS, die bewusst gestaltet werden muss.
2. Wer darf umreihen und wie weit? Eine soziale und organisatorische Frage, keine technische. Wird die Antwort nicht sauber ausverhandelt, wird das System entweder ignoriert oder es entsteht Streit.
3. Datenqualität der Termine in ABAS. Wenn die Plantermine dort nicht gepflegt sind, kann die schönste Tafel nichts anzeigen.
4. Vollständigkeit ist Pflicht. Eine Planungstafel, die nur 80 % der Aufträge kennt, wird nicht benutzt — man schaut dann sicherheitshalber doch auf den Ausdruck.

Offene Fragen:

• Die heutige Druckliste zeigen und abfotografieren — sie ist die reale Ist-Spezifikation.
• Wie oft ändert sich die Reihenfolge pro Tag, und wer entscheidet?
• Was sind die tatsächlichen Gründe, warum ein Auftrag nicht starten kann? (Vermutlich mehr als vier)
• Wie lange dauert ein Rüstvorgang, und wie oft wird er abgebrochen? (Nutzenargument in Euro)
• Gibt es Rüstoptimierung (Farbfolge, Bahnbreite)? Wenn ja, ist das eine eigene Ausbaustufe.

Einschätzung: Höchster Wert, höchste Komplexität, vital. Nicht als Pilot — aber ein klickbarer Prototyp der Tafel ist das beste Verkaufsargument, das existiert.

Baustein 8 · Klischeekleberei & Farbvorbereitung#

Im Handout: Eigene Arbeitslisten mit Priorität und Termin. Rückmeldung „Klischee fertig" bzw. „Farben fertig" wird unmittelbar in der Produktionsplanung sichtbar.

Was das fachlich ist: Die Zulieferseite von Baustein 7. Diese beiden Bereiche erzeugen zwei der vier grünen Hakerl. Sie brauchen ihre eigene Sicht: nicht die Maschinenreihenfolge, sondern ihre Arbeitsliste, sortiert nach dem, wann die Maschine es braucht.

Was wir bauen:

• Arbeitsliste je Bereich, abgeleitet aus der Auftragspriorisierung und den Maschinenterminen.
• Ein Klick: „fertig" → das Hakerl in der Produktionsplanung wird sofort grün.
• Rückwärtssignal: „geht nicht" mit Grund (Klischee fehlt, Motiv defekt, Farbe nicht lieferbar) → der Auftrag wird in der Planung sichtbar blockiert statt still liegen zu bleiben.
• Optional: Klischeeverwaltung (welches Klischee liegt wo, wie oft benutzt, Zustand) — eigenständiger Nutzen, eigene Ausbaustufe.

Schwierigkeiten: gering, sofern Baustein 7 steht. Ohne ihn sinnlos.

Offene Fragen:

• Wie viele Personen arbeiten in diesen Bereichen?
• Wie erfahren sie heute, was zu tun ist?
• Wie lange dauert eine Klischeevorbereitung, wie lange eine Farbanmischung?
• Werden Klischees archiviert und wiederverwendet? Wo liegen sie?

Einschätzung: Kleiner Baustein mit großer Hebelwirkung. Gehört unmittelbar zu Phase 3.

Baustein 9 · Rollenschneider#

Im Handout: Dynamische Übersicht aus Druckliste + Tagesrückmeldungen: Was ist im Druck? Was wird fertig? Was steht bereits zum Schneiden bereit? Rückmeldung ebenfalls direkt am Tablet.

Was das fachlich ist: Die nachgelagerte Weiterverarbeitung. Der Rollenschneider braucht keine Planung im eigentlichen Sinn, sondern Vorschau: Was kommt in den nächsten Stunden von den Druckmaschinen, und was liegt schon bereit?

Was wir bauen:

• Abgeleitete Sicht: laufende Aufträge mit Fortschritt aus den Rückmeldungen, geschätzter Fertigstellung, und bereits fertigen, wartenden Rollen.
• Eigene Rückmeldung: geschnittene Mengen, Ausschuss, Fertigmeldung.
• Bestandsübersicht der wartenden Mutterrollen.

Schwierigkeiten: Die Fertigstellungsprognose ist nur so gut wie die Rückmeldungen von den Druckmaschinen. Ohne Baustein 4/7 ist das Raten. Mit ihnen ist es fast geschenkt.

Offene Fragen:

• Wie viele Rollenschneider, wie viele Schichten?
• Wie erfährt der Bereich heute, was kommt?
• Entstehen dort weitere Chargen-/Nummernkreise?

Einschätzung: Weitgehend eine abgeleitete Sicht — geringer Zusatzaufwand, wenn 7 steht. Phase 3.

Baustein 10 · Digitales Maschinenheft#

Im Handout: Das zentrale analoge Maschinenheft auf den Tablets abbilden. Schicht, Mitarbeiter, Vorkommnisse, Technik-/Qualitätsthemen und Übergabeinfos. Leitung kann Einträge in Echtzeit einsehen.

Was das fachlich ist: Das Betriebstagebuch der Maschine. Heute ein physisches Buch, das an der Maschine liegt. Enthält: wer hatte Schicht, was ist passiert, was muss die nächste Schicht wissen, welcher Techniker war da, welches Qualitätsproblem trat auf.

Warum das der ideale Pilot ist:

• Es existiert bereits als Prozess — wir digitalisieren etwas Bekanntes, statt etwas Neues einzuführen. Der geringste denkbare Änderungswiderstand.
• Keine ABAS-Abhängigkeit. Keine.
• Sofort sichtbarer Nutzen für die Leitung: Einträge in Echtzeit, statt einmal pro Woche ein Buch durchzublättern.
• Beweist das gesamte Fundament: Anmeldung, Rollen, Bereiche, Tablet-Bedienung, Offline, Foto-Upload, Suche, Export, Admin-Layer.
• Fällt es aus, passiert vier Stunden lang: nichts.

Was wir bauen:

• Eintrag mit Typ (Störung · Technik · Qualität · Übergabe · Hinweis), Maschine, Schicht, Person, Zeitpunkt, Freitext, Fotos.
• Schichtübergabe als eigenes Objekt: eine Übergabe wird abgeschlossen und von der Folgeschicht zur Kenntnis genommen. Das ist der Punkt, an dem aus einem Notizbuch ein Prozess wird.
• Volltextsuche und Filter über Maschine, Zeitraum, Typ — heute faktisch unmöglich.
• Echtzeitsicht für die Leitung.
• Verknüpfung: aus einem Eintrag eine Meldung im Service Portal erzeugen (Baustein 1).
• Export als PDF je Zeitraum/Maschine, für Audits und Reklamationen.

Schwierigkeiten:

• Freitext ist verführerisch, aber unauswertbar. Balance: strukturierte Pflichtfelder plus optionaler Freitext. Wer alles ins Freitextfeld schreiben lässt, hat ein digitalisiertes Papierbuch statt einer Datenquelle.
• § 96 ArbVG: Ein Buch, das festhält, wer in welcher Schicht welchen Vorfall hatte, ist eine Kontrollmaßnahme. Auch wenn das Papierbuch dasselbe tat — digital, durchsuchbar und in Echtzeit für die Leitung ist es rechtlich eine andere Qualität. Vor der Einführung mit dem Betriebsrat besprechen. Datensparsame Gestaltung (Personenbezug nur wo nötig) entschärft das erheblich.
• Akzeptanz: Wenn der Eintrag am Tablet länger dauert als mit dem Kugelschreiber, wird das Buch weiterbenutzt. Zielwert: ein Standardeintrag in unter 20 Sekunden.

Offene Fragen:

• Das echte Maschinenheft ansehen und jede vorkommende Seitenart fotografieren.
• Wie viele Einträge pro Schicht?
• Was passiert heute mit den Informationen? Liest die Leitung sie überhaupt?
• Gibt es eine formale Schichtübergabe?
• Muss das Heft bei Audits vorgelegt werden?

Einschätzung: Der beste Pilotbaustein des gesamten Programms. Komfort-Stufe, hohe Sichtbarkeit, null Risiko.

Kritikalität, Aufwand, Reihenfolge#

Pilotempfehlung (ihre Frage 7)#

Der eigentliche Pilot: Maschinenheft + Service Portal.

Begründung, die im Termin gut funktioniert:

„Ich würde mit den beiden Bausteinen anfangen, bei denen es ungefährlich ist, wenn wir uns irren. Beide brauchen kein ABAS, beide ersetzen etwas, das es schon gibt, und beide zusammen beweisen das komplette Fundament: Anmeldung mit Badge, Rollen und Bereiche, Tablet-Bedienung mit Handschuhen, Offline-Fähigkeit, Fotos, Suche, Auswertung und die Administrationsoberfläche. Wenn das nach acht Wochen an der Maschine funktioniert und benutzt wird, wissen Sie und ich, dass der Rest tragfähig ist. Und wenn nicht, haben Sie wenig verloren und viel gelernt."

Direkt danach: Chargenscan. Braucht die Hardwareentscheidung und profitiert von einer ABAS-Antwort — also besser an zweiter Stelle.

Die Produktionstafel ist die Überschrift von Phase 3, nicht der Pilot. Stattdessen früh einen klickbaren Prototyp zeigen: verkauft die Vision, ohne uns auf das schwierigste Modul zuerst festzulegen.

Das beantwortet ihre Frage 7 besser, als sie gestellt wurde — die richtige Auswahl sind nicht die wichtigsten zwei Module, sondern die zwei, bei denen ein Fehler folgenlos bleibt.

05 · Zeiterfassung — Studie und Optionen

Warum dieser Baustein komplizierter ist, als er aussieht; welche Optionen es gibt; was das jeweils kostet und riskiert; und welche Fragen im Termin gestellt werden müssen.

1. Warum das nicht „nur Kommen und Gehen" ist#

Zeiterfassung wirkt wie das einfachste Modul im Handout: zwei Knöpfe, ein Zeitstempel, eine Tabelle. Diese Einschätzung ist der Grund, warum Zeiterfassungsprojekte regelmäßig entgleisen.

Es sind in Wahrheit drei Systeme mit einem gemeinsamen Namen:

System 1 · Erfassung — wirklich einfach#

Badge oder PIN an einem Terminal, Tablet oder Smartphone. Zeitstempel, Person, Ereignistyp. Ein Wochenende Arbeit.

Und genau hier scheitern die meisten Altsysteme: ein Terminal aus 2009, das nur an einer Tür hängt; keine Selbstauskunft für Mitarbeiter; kein mobiles Stempeln; das Büro tippt Korrekturen von Hand nach; der Hersteller supportet nicht mehr. Der wahrgenommene Schmerz sitzt fast immer in diesem System — der Aufwand fast nie.

System 2 · Das Regelwerk — der Killer#

Aus rohen Zeitstempeln müssen bewertete Arbeitszeiten werden. Was dabei alles hineinspielt:

• Kollektivvertrag — für Flexopack vermutlich der KV der papierverarbeitenden Industrie oder Druckindustrie. Jeder KV hat eigene Regeln.
• Normalarbeitszeit, Gleitzeit oder feste Schichten, Gleitzeitrahmen, Kernzeit
• Schichtmodelle, Schichtzulagen, Nachtarbeitszuschläge
• Überstundenzuschläge (50 % / 100 %), Abgrenzung Mehrarbeit vs. Überstunden bei Teilzeit
• Pflichtpause: 30 Minuten nach 6 Stunden — automatisch abziehen oder erfassen?
• Ruhezeit 11 Stunden, Wochenruhezeit
• Durchrechnungszeiträume, Zeitausgleich, Gutstunden-Kappung
• Sonn- und Feiertagsarbeit, Feiertagsentgelt
• Urlaubsanspruch (Aliquotierung, Vorgriff, Verfall), Pflegefreistellung, Sonderurlaub
• Krankenstand inkl. Entgeltfortzahlungsstufen

Jede einzelne Regel ist trivial. Die Kombination ist eine Matrix, und jeder Fehler darin ist die falsche Bezahlung eines echten Menschen — mit Nachzahlungspflicht, Betriebsratsthema und Vertrauensschaden.

System 3 · Lohnübergabe#

Export in ihre Lohnsoftware (BMD, Sage DPW, RZL oder das System des Steuerberaters), abgebildet auf deren Lohnarten. Formatfrage, technisch überschaubar, aber nur lösbar, wenn man weiß, wohin es geht — und die Lohnverrechnung mitspielt.

2. Der Rechtsrahmen#

§ 26 AZG — Aufzeichnungspflicht#

Arbeitszeiten, Pausen, Überstunden und Ruhezeiten müssen lückenlos dokumentiert werden. Das Arbeitsinspektorat kann Einsicht verlangen (§ 3 ArbIG), der Betriebsrat hat Einsichtsrechte (§ 89 ArbVG), Mitarbeiter haben Anspruch auf Abschrift oder Einsicht.

Konsequenz: Wer das System baut, baut ein Stück gesetzlicher Aufzeichnung. Backups, Wiederherstellbarkeit, Unveränderbarkeit und Exportierbarkeit sind keine Kür.

§ 96 / 96a ArbVG — Betriebsvereinbarung#

Zeiterfassung ist eine Kontrollmaßnahme, die die Menschenwürde berührt:

• Mit Betriebsrat: zustimmungspflichtige Betriebsvereinbarung. Ohne sie keine Einführung.
• Ohne Betriebsrat: individuelle Zustimmung — arbeitsrechtlich heikel, weil Freiwilligkeit im Arbeitsverhältnis fraglich ist.

Vorlauf für eine neue Betriebsvereinbarung: realistisch zwei bis sechs Monate. Das ist ein Terminrisiko, das nichts mit Software zu tun hat.

DSGVO#

Zeitdaten sind personenbezogen; Krankenstände sind Gesundheitsdaten nach Art. 9 und damit besondere Kategorie. Getrennte Speicherung, minimale Felder (niemals ein Diagnose-Freitextfeld), strenge Rollenbindung, protokollierte Zugriffe, definierte Löschfristen.

3. Die vier Optionen#

Option A · Fertiges PZE-Produkt kaufen#

Ein österreichisches oder deutsches Produkt lizenzieren: TimeTac, Personalwolke, ISGUS, oder alltrotec, das eine ABAS-integrierte Personalzeiterfassung anbietet. Wir binden es an (SSO, Daten im Portal sichtbar).

Option B · Erfassung selbst bauen, Regelwerk kaufen — Empfehlung#

Wir bauen das, was heute weh tut: Terminal, NFC/PIN-Stempeln am Tablet, Selbstauskunft, Urlaubs- und Krankenstandsanträge, Freigabe-Workflows, Korrekturen, Monatsabschluss. Exportiert werden rohe, bewertbare Zeitdaten an ihre Lohnsoftware — die das KV-Regelwerk ohnehin besitzt und dafür bereits verantwortlich ist.

Kernfrage für diese Option: Kann Ihre Lohnverrechnung mit Rohzeiten arbeiten, oder erwartet sie bereits bewertete Stunden je Lohnart? Diese eine Frage entscheidet über Option B.

Option C · Alles selbst bauen, inklusive Regelwerk#

Niemals „bauen Sie es so wie das alte System" als Spezifikation akzeptieren. Niemand im Haus weiß vollständig, was das alte System rechnet.

Option D · Altsystem behalten, nur die schmerzhaften Teile ersetzen#

Selbstauskunft, Urlaubs- und Krankenstandsanträge und Freigaben laufen im neuen Portal; die Daten werden ins bestehende System übergeben. Die Stempelung bleibt, wie sie ist.

Nicht unterschätzen: Wenn sich im Gespräch herausstellt, dass der eigentliche Schmerz „Urlaubsanträge auf Zetteln" ist und nicht die Stempeluhr, ist Option D die ehrlichste Antwort — und sie kauft enormes Vertrauen.

4. Entscheidungsbaum#

Gibt es einen Betriebsrat?
├── ja → Gibt es eine bestehende Betriebsvereinbarung zur Zeiterfassung?
│        ├── ja  → gute Ausgangslage, Änderung statt Neuverhandlung
│        └── nein → 2–6 Monate Vorlauf einplanen, Zeiterfassung ans Ende der Roadmap
└── nein → individuelle Zustimmung nötig, arbeitsrechtlich prüfen lassen

Was erwartet die Lohnverrechnung?
├── Rohzeiten     → Option B  (Empfehlung)
├── bewertete Zeiten je Lohnart
│   ├── Modell einfach (feste Schichten, keine Gleitzeit) → Option C erwägen
│   └── Modell komplex (Gleitzeit, Zuschläge, Durchrechnung) → Option A
└── unklar / Steuerberater entscheidet → Option A oder D

Was ist der tatsächliche Schmerz?
├── Stempelhardware kaputt/abgekündigt      → A oder B
├── kein Selfservice, Zettelwirtschaft      → D oder B
├── keine mobile Erfassung                  → B
└── falsche Berechnungen im Altsystem       → A  (niemals selbst nachbauen)

5. Fragen für den Termin#

1. Was ist das Altsystem — Hersteller, Version, wo läuft es, gibt es noch Support?
2. Was genau funktioniert nicht? (Hardware defekt · kein Selfservice · nicht mobil · kann keine Schichten · Hersteller weg · Büro tippt alles nach)
3. Wer macht die Lohnverrechnung — intern oder Steuerberater — und mit welcher Software?
4. Was übergibt das Altsystem heute an die Lohnverrechnung, in welchem Format? Rohzeiten oder bewertete Stunden?
5. Gleitzeit oder feste Schichten? Wie viele Schichtmodelle? Gibt es Zeitausgleichskonten?
6. Welcher Kollektivvertrag gilt für Arbeiter, welcher für Angestellte?
7. Gibt es einen Betriebsrat?
8. Gibt es eine bestehende Betriebsvereinbarung zur Zeiterfassung? (die entscheidende Zeitplanfrage)
9. Wie laufen Urlaubsanträge heute? Papier, Forms, Excel? Wer genehmigt?
10. Wie wird Krankenstand heute gemeldet und dokumentiert?
11. Wie viele Zutritte brauchen ein Terminal? Gibt es bereits Badges — welcher Typ (Mifare, Legic, EM4102)?
12. Brauchen Außendienst, Fahrer oder Monteure mobile Erfassung?
13. Wie viele Korrekturen pro Monat fallen an, und wer macht sie?
14. Gibt es Zutrittskontrolle, die mit den Badges zusammenhängt?

Frage 8 entscheidet, ob dieses Modul drei oder neun Monate braucht. Frage 4 entscheidet zwischen Option B und A.

6. Empfehlung#

Im Termin nichts entscheiden. Die vierzehn Fragen stellen, zuhören, und danach mit einer belastbaren Empfehlung zurückkommen.

Vorläufige Präferenz, sofern nichts Überraschendes auftaucht:

1. Option B, wenn die Lohnverrechnung Rohzeiten annimmt und ein Betriebsrat konstruktiv mitgeht.
2. Option A, wenn bewertete Zeiten erwartet werden oder das Zeitmodell komplex ist.
3. Option D als schneller Zwischenschritt, unabhängig davon — Urlaubs- und Krankenstandsanträge im Portal sind billig und werden von allen 50 Mitarbeitern sofort bemerkt.
4. Option C nur bei nachweislich einfachem Modell und schriftlicher Spezifikation.

In jedem Fall gilt: Zeiterfassung ist der letzte Baustein der Roadmap, nicht der erste. Das Betriebsvereinbarungs-Risiko allein rechtfertigt das — und es ist gegenüber dem Kunden gut begründbar, weil es sein Risiko genauso senkt wie unseres.

Quellen#

• § 26 AZG — Aufzeichnungs- und Auskunftspflicht (JUSLINE)
• Pflicht zur Arbeitszeiterfassung in Österreich (lohn.at)
• Digitale Zeiterfassung Österreich — arbeitsrechtliche Anforderungen (Personalwolke)
• Arbeitszeiterfassungspflicht in Österreich (time cockpit)
• Von der Zeiterfassung zur Lohnabrechnung — Schnittstellen zu BMD, RZL, Sage DPW (ISGUS)
• alltrotec — Personalzeiterfassung integriert für abas ERP
• Sage DPW — Lohnverrechnung Österreich
• BMD — Lohnverrechnung

06 · Kommerzielles — Phasen, Preise, Vertrag, Positionierung

Was das Programm kostet, in welchen Stufen, was laufend anfällt, wie der Vertrag aussehen sollte und wie man den Einwand „warum ein Einzelentwickler?" beantwortet. Beantwortet Kundenfrage 12.

1. Ausgangsüberlegung#

Diese Beauftragung ist eine andere Klasse als bisherige SB-Media-Projekte. Der Unterschied ist nicht die Technik — Auth, Rollen, Dashboards, Postgres-Schema sind bekanntes Terrain. Der Unterschied sind drei andere Dinge:

1. Eine unbekannte Fachdomäne (Flexodruck-Produktionsfluss, ERP-Semantik). Lösbar, kostet aber echte Kalenderzeit — und diese Zeit muss bezahlt sein, nicht als Vorleistung erbracht werden.
2. Betriebliche Konsequenz. Fällt ein SaaS aus, lädt jemand neu. Fällt der Leitstand aus, stehen im schlimmsten Fall vier Druckmaschinen. Die Antwort darauf ist nicht ein niedrigerer Preis, sondern der dokumentierte Notfallbetrieb.
3. Laufzeit. Der volle Ausbau ist ein Bogen über 24–30 Monate. Das ist eine Beziehung, kein Projekt.

Die Absicherung gegen alle drei ist dieselbe: phasenweise Beauftragung, jede Phase eigenständig nutzbar und eigenständig abbrechbar. Niemals das Gesamtprogramm auf einmal unterschreiben.

2. Preisannahmen#

• Tagessatz € 800–1.000. Angemessen für spezialisierte Einzelarbeit in Oberösterreich. Zum Vergleich: ABAS-Partner rechnen mit € 140–180/Stunde, also € 1.100–1.400 pro Tag.
• Kalkuliert wird in Tagen pro Phase, nicht in Stunden pro Feature.
• Jede Phase enthält Fixpreis, definierten Umfang, Abnahmekriterien und Dokumentation als Liefergegenstand.

3. Stufenplan und Investitionsrahmen#

Gesamtrahmen#

Der Vergleich, der die Zahl trägt#

Ein Standard-MES für einen 50-Personen-Betrieb kostet € 80.000–200.000 an Lizenz und Einführung, zuzüglich 18–22 % Wartung pro Jahr — dauerhaft. Und es bildet die Vorstufenkette von Flexopack trotzdem nicht ab, weil kein Produkt das tut.

Unser Weg hat keine Lizenzgebühren, passt auf den tatsächlichen Prozess und gehört am Ende ihnen.

Dieser Absatz gehört ins Angebot und, falls das Thema aufkommt, ins Gespräch.

4. Laufende Kosten (Kundenfrage 12)#

Die Zahl € 50–100 pro Monat für die gesamte Infrastruktur früh und deutlich nennen. Mittelständische Käufer erwarten, dass Cloud teuer ist; ein zweistelliger Monatsbetrag für den Betrieb kauft viel Wohlwollen für die sechsstellige Bausumme.

5. Wartung und Support#

Sobald Produktion davon abhängt, besteht dauerhafte Verantwortung. Die gehört bezahlt.

Enthalten: Monitoring und Alarmierung, verifizierte Backups, Sicherheits- und Abhängigkeitsupdates, Fehlerbehebung, ein definiertes Stundenkontingent für kleine Anpassungen, Reaktionszeiten innerhalb Mo–Fr 08:00–16:00.

Nicht enthalten: Einsätze außerhalb dieser Zeiten (separat verrechnet oder ausdrücklich ausgeschlossen — der Notfallbetrieb ist die Antwort), neue Module, Schulungen.

Das ist nicht nur Umsatz: Es verwandelt „ich hafte auf unbestimmte Zeit" in „ich werde dafür bezahlt, verantwortlich zu sein".

6. Die drei kommerziellen Züge#

6.1 ABAS-Arbeit an ihren Partner abgeben#

Die ERP-seitige Arbeit macht ihr ABAS-Partner, direkt an Flexopack verrechnet, gegen eine von uns geschriebene Schnittstellenspezifikation (welche Daten, welches Format, welcher Endpunkt, welche Fehlerbehandlung).

Damit wird unsere größte Unbekannte zu einer Position auf einer fremden Rechnung — und es ist zugleich die technisch bessere Arbeitsteilung.

6.2 Analyse zuerst verkaufen, ausdrücklich ohne Lock-in#

Stufe 0 liefert eine Spezifikation, die jeder kompetente Entwickler umsetzen könnte. Das ist leichter zu kaufen, es ist ehrlich, und es sorgt dafür, dass die Lernkurve bezahlt wird. Selbst wenn damit ein Vergleichsangebot eingeholt wird, gewinnt man auf Preis und Verständnis.

6.3 „Was es fertig gibt, kaufen Sie"#

„Ich baue das, was es fertig nicht zu kaufen gibt. Was es fertig zu kaufen gibt, kaufen Sie — und ich binde es an."

Dieser Satz erhöht die Glaubwürdigkeit und senkt das eigene Risiko. Er ist auch schlicht richtig.

7. Der Einwand „warum ein Einzelentwickler?"#

Mit einem technologiegetriebenen Eigentümer im Hintergrund wird dieser Einwand gedacht, ob er ausgesprochen wird oder nicht. Er muss beantwortet sein, bevor er gestellt wird.

Zusätzlich stark: Wir haben bereits geliefert. Die Website steht, das Split-Brain-DNS-Problem wurde erkannt, dokumentiert und gelöst — inklusive einer Anleitung, die ihre IT direkt umsetzen konnte. Das ist ein belastbarer Referenzpunkt.

8. Vertragliche Eckpunkte#

9. Sprachregelung für den Termin#

Wenn nach Zahlen gefragt wird:

„Über alle Ausbaustufen bewegt sich so ein Programm im niedrigen sechsstelligen Bereich, verteilt über zwei bis drei Jahre — in Phasen, die einzeln beauftragt und einzeln gestoppt werden können. Die erste Phase, Analyse und Architektur, liegt im niedrigen fünfstelligen Bereich. Ein belastbares Angebot kann ich erst nach dieser Analyse machen; vorher wäre jede Zahl geraten."

Wenn nach den laufenden Kosten gefragt wird:

„Der Betrieb der Plattform selbst liegt bei 50 bis 100 Euro im Monat. Die relevanten laufenden Kosten sind Hardware, eventuell Lizenzen auf ABAS-Seite und die Wartung — und die kann ich beziffern, sobald der Umfang steht."

Wenn gefragt wird, warum nicht alles auf einmal:

„Weil ich Ihnen nicht seriös etwas anbieten kann, dessen wichtigste Voraussetzung — der Zugang zu ABAS — heute noch niemand im Raum kennt. Und weil Sie nach der ersten Stufe entscheiden können sollen, ob Sie weitermachen wollen. Das ist für Sie die günstigere Konstruktion, nicht für mich."

Wenn der Einzelentwickler-Einwand kommt:

„Berechtigte Frage. Deshalb liegt der Code von Anfang an in Ihrem Repository, das geistige Eigentum geht vollständig an Sie über, und der Stack ist bewusst absoluter Standard — TypeScript, SvelteKit, PostgreSQL. Jede Agentur kann das übernehmen. Zusätzlich gibt es einen täglichen Export Ihrer Daten in Ihr eigenes Netz. Sie sollen von mir nicht abhängig sein — Sie sollen mit mir arbeiten, weil es funktioniert."

07 · Meeting-Kit — Erstgespräch Flexopack

Zum Ausdrucken und Mitnehmen. Ablauf, vollständiger Fragenkatalog, Beobachtungscheckliste, Notizraum. Kurzfassung fürs Handy: 08-cheatsheet.md.

Ziel des Termins#

Erkundung, kein Pitch. Am Ende des Tages sollen fünf Dinge erreicht sein:

1. Verstehen, wie Flexopack tatsächlich produziert — vom Kundenauftrag bis zur fertigen Rolle.
2. Verstehen, was ABAS in diesem Haus ist, kann und darf.
3. Die kritischen Unbekannten schließen: ABAS-Version und Lizenz, IT-Verantwortung, WLAN in der Halle, Betriebsrat, Altsystem Zeiterfassung, Lohnverrechnung, Entscheidungsweg.
4. Fachlich so auftreten, dass die Architekturhoheit bei uns landet.
5. Eine Größenordnung nennen können, ohne eine Zahl zu raten.

Was ausdrücklich nicht Ziel ist: ein Angebot platzieren, Technologie verkaufen, Umfang zusagen.

Vorgeschlagener Ablauf#

Wenn die Zeit knapp wird: Block 2 und Block 3 sind unverzichtbar. Block 6 kann schriftlich nachgereicht werden — das ist sogar besser.

Mitnehmen#

• Ausdruck dieses Kits und des Cheatsheets
• Notizblock und Stift (nicht nur Laptop — auf dem Hallenrundgang unpraktisch)
• Handy mit voller Batterie für Fotos
• Laptop für den Architektur-Block
• Sicherheitsschuhe / -brille, falls verlangt — vorher fragen
• Visitenkarten

A · Unternehmen, Ziele, Entscheidung#

1. Was ist der Auslöser gerade jetzt? Was hat den Ausschlag gegeben?
2. Woran würden Sie in zwölf Monaten erkennen, dass sich die Investition gelohnt hat?
3. Was ist heute der teuerste einzelne Missstand — in Euro oder in Stunden?
4. Wer entscheidet über das Budget, und wer muss zustimmen?
5. Gibt es einen Zeitrahmen oder ein Ereignis, auf das hin geliefert werden soll?
6. Gab es schon Digitalisierungsanläufe? Was ist daran gescheitert?
7. Wurde bereits mit anderen Anbietern gesprochen — MES-Herstellern, dem ABAS-Partner?
8. Gibt es IT-Ressourcen oder Vorgaben auf Eigentümerebene?

B · Produktion und Prozess (auf dem Rundgang)#

9. Wie kommt ein Auftrag ins Haus, und was passiert bis zum ersten Meter Druck?
10. Wer legt die Reihenfolge auf den Maschinen fest? Wie oft ändert sie sich pro Tag?
11. Was sind die tatsächlichen Gründe, warum ein Auftrag nicht starten kann? (vermutlich mehr als die vier Hakerl)
12. Wie erfährt die Maschine heute, dass Klischee und Farbe fertig sind?
13. Wie oft wird ein Rüstvorgang begonnen und abgebrochen, weil etwas fehlt?
14. Wie lange dauert ein Rüstvorgang im Schnitt? Was kostet eine Maschinenstunde?
15. Wie viele Schichten, wie viele Personen je Schicht, wie läuft die Übergabe?
16. Wo wird heute Papier geführt? (Alles einsammeln oder fotografieren)
17. Was passiert bei einer Kundenreklamation — wie lange dauert eine Rückverfolgung?
18. Wie wird Ausschuss heute erfasst und ausgewertet?
19. Was passiert bei einer Störung? Wer wird wie informiert?
20. Welche Kennzahlen betrachtet die Leitung heute, und woher kommen sie?

C · ABAS#

21. Welche ABAS-Version, wann zuletzt aktualisiert?
22. Wer ist Ihr ABAS-Partner, und wer dort macht die Anpassungen?
23. Ist die REST-API lizenziert und aktiviert? Falls nein: Kosten? Lizenzbedingungen ab 09/2017?
24. On-premise auf eigenem Server oder beim Partner gehostet? Welches Netzsegment?
25. Ist abas Connect oder EDI-Middleware im Einsatz?
26. Wer hat Infosysteme oder FO-Anpassungen gebaut? Gibt es Dokumentation?
27. Sind Klischee und Farbvorbereitung Arbeitsgänge im Arbeitsplan?
28. Bucht heute jemand Rückmeldungen? Ist das BDE-Modul lizenziert?
29. Können Sie einen geplanten CSV-Export der offenen Fertigungsaufträge bereitstellen? ← nicht ohne Antwort gehen
30. Gibt es ein Test-/Sandbox-System?
31. Wer pflegt Stammdaten, und wie aktuell sind sie wirklich?
32. Welche Auswertungen gibt es heute aus ABAS, und warum reichen sie nicht?

Am Bildschirm zeigen lassen: Kundenauftrag → Fertigungsauftrag → Arbeitsplan → Druckliste → Rückmeldung → Charge auf Lieferschein → ein genutztes Infosystem.

D · Zeiterfassung und Personal#

33. Was ist das Altsystem — Hersteller, Version, Support noch aktiv?
34. Was genau funktioniert daran nicht?
35. Wer macht die Lohnverrechnung — intern oder Steuerberater? Welche Software?
36. Was übergibt das Altsystem heute an die Lohnverrechnung, in welchem Format? Rohzeiten oder bewertete Stunden?
37. Gleitzeit oder feste Schichten? Wie viele Schichtmodelle? Zeitausgleichskonten?
38. Welcher Kollektivvertrag für Arbeiter, welcher für Angestellte?
39. Gibt es einen Betriebsrat?
40. Gibt es eine bestehende Betriebsvereinbarung zur Zeiterfassung?
41. Wie laufen Urlaubsanträge heute? Wer genehmigt?
42. Wie wird Krankenstand heute gemeldet und dokumentiert?
43. Wie viele Zutritte brauchen ein Terminal? Gibt es Badges — welcher Typ?
44. Brauchen Außendienst oder Fahrer mobile Erfassung?
45. Wie viele Korrekturen pro Monat, und wer macht sie?

E · IT, Netzwerk, Geräte#

46. Wer ist für die IT verantwortlich — intern oder ein IT-Haus? Name und Kontakt.
47. Welche Servervirtualisierung ist im Einsatz? Kann eine VM für den Connector bereitgestellt werden?
48. Ist ausgehendes HTTPS aus dem Serversegment erlaubt? Gibt es einen Proxy?
49. Haben die Tablets in der Halle Internetzugang, oder ist das Shopfloor-WLAN isoliert?
50. Wie ist die WLAN-Abdeckung an jeder Maschine, im Farblager, in der Klischeekleberei?
51. Wie viele Tablets, an welchen Positionen? Fest montiert oder mitgeführt?
52. Wer würde die Geräte verwalten? Gibt es bereits ein MDM?
53. M365-Tenant vorhanden? Entra ID? Wer hat Lizenzen — auch die Produktion?
54. Welche Microsoft-Forms-Formulare laufen heute? Exporte erbitten.
55. Wer ist Datenschutzverantwortlicher?
56. Wie ist die Backup-Strategie im Haus? Gibt es einen Fileserver für Exporte?

F · Farblager und Chargen#

57. Wie viele Kannen/Positionen, wie viele Regalplätze im Farblager?
58. Gibt es heute eine Etikettierung, oder muss neu ausgezeichnet werden?
59. Gibt es eine Waage? Mit Schnittstelle?
60. Wer mischt Farben an? Entstehen dabei neue Gebinde?
61. Wie hoch sind Schwund und Verfall heute?
62. Welche Lieferanten liefern Rohware, mit welchen Etiketten/Barcodes? ← fotografieren
63. Wie viele Chargenwechsel pro Schicht?
64. Gibt es Auditanforderungen (ISO 22000, BRC, FSC)?

G · Maschinenheft#

65. Das echte Maschinenheft ansehen — jede Seitenart fotografieren.
66. Wie viele Einträge pro Schicht?
67. Was passiert heute mit den Informationen? Liest die Leitung sie?
68. Gibt es eine formale Schichtübergabe?
69. Muss das Heft bei Audits vorgelegt werden?

Beobachtungscheckliste — Hallenrundgang#

Nicht fragen, sondern anschauen:

• WLAN-Signal an jeder Maschine prüfen (Handy, Balken notieren)
• Beleuchtung: hell, dunkel, Gegenlicht, Reflexionen?
• Tragen die Bedienenden Handschuhe? Welche Art?
• Schutzbrillen? Gehörschutz? (→ akustische Signale sinnlos)
• Wo könnte ein Tablet physisch montiert werden? Steckdose in der Nähe?
• Wie schmutzig ist die Umgebung — Farbe, Staub, Lösemittel?
• Lärmpegel
• Wie viele Personen stehen an einer Maschine?
• Wie weit ist der Weg von der Maschine zum Farblager, zur Klischeekleberei?
• Welche Papiere hängen an den Maschinen? (fotografieren)
• Gibt es bereits Bildschirme oder Terminals in der Halle?
• Wie ist das Farblager organisiert — gibt es überhaupt Plätze?
• Wo hängt heute die Druckliste?
• Stimmung: neugierig oder abwehrend gegenüber Digitalisierung?

Fotos mitnehmen von: Maschinenheft (alle Seitenarten) · Druckliste · Rohwarenetiketten · Farblager · Maschinenumgebung · vorhandenen Papierformularen · Terminal der alten Zeiterfassung.

Was gesagt werden sollte, auch ohne Pitch#

Drei Sätze, die den Rahmen für alles Weitere setzen:

1 · Zur Architektur

„ABAS steht bei Ihnen im Haus, hinter der Firewall. Der übliche Fehler ist, daraus zu schließen, dass die neue Anwendung auch dort laufen muss. Muss sie nicht — nur ein kleiner Connector, der ausschließlich von innen nach außen telefoniert. Dann brauchen wir keine Firewall-Öffnung, kein VPN, und Ihre ABAS-Zugangsdaten verlassen das Haus nie."

2 · Zur Datenhaltung

„Wir haben vorab klassifiziert, welche Daten in so einem System entstehen. Krankenstände sind Gesundheitsdaten nach Artikel 9 DSGVO. Zeit- und Leistungsdaten sind eine Kontrollmaßnahme nach § 96 Arbeitsverfassungsgesetz und brauchen in aller Regel eine Betriebsvereinbarung. Beides behandeln wir technisch getrennt vom Rest — und beides bespricht man besser vor dem Bauen als danach."

3 · Zum Vorgehen

„Ich würde mit den beiden Bausteinen anfangen, bei denen es ungefährlich ist, wenn wir uns irren — Maschinenheft und Service Portal. Beide brauchen kein ABAS, beide ersetzen etwas, das es schon gibt, und beide zusammen beweisen das komplette Fundament. Wenn das nach acht Wochen an der Maschine benutzt wird, wissen wir beide, dass der Rest trägt."

Ihre zwölf Fragen — Kurzantworten#

Nächste Schritte vereinbaren#

• Wer liefert die Microsoft-Forms-Exporte? Bis wann?
• Wer stellt den Kontakt zum ABAS-Partner her? Bis wann?
• Wer klärt den REST-Lizenzstatus?
• Wer klärt Betriebsrat und bestehende Betriebsvereinbarung?
• Wer nennt die Lohnverrechnungssoftware?
• Foto-/Dokumentenmaterial: Druckliste, Maschinenheft, Formulare — wer schickt es?
• Termin für die Vorstellung des Vorschlags: ______________
• Ansprechpartner je Bereich benennen lassen

Notizen#

Anwesend:



Wichtigste Erkenntnis des Tages:



ABAS-Situation:



Netzwerk / IT:



Betriebsrat / Zeiterfassung:



Was mich überrascht hat:



Was ich unterschätzt habe:



Nächster Schritt, konkret:

08 · Cheatsheet — Handy-Version

Kurz. Im Termin unauffällig nachschlagbar.

Wer sitzt mir gegenüber#

• Thomas Kaisermair, GF seit 14.02.2025
• Flexopack gehört seit Januar 2025 zu 100 % der Loxone Lighthouse GmbH (Loxone GmbH 74,9 %, Rainer Eisner 25,1 %)
• Verkäufer waren Engelbert und Silvia Hundsberger — Nachfolgeregelung
• Loxone = technisch sehr versierter Eigentümer, langfristig orientiert, kein Exit-Fokus
• ~50 Mitarbeiter · 4 Flexodruckmaschinen, 8 Farben · Exportquote 45 % · Bilanzgewinn ~€ 1,5 Mio.
• Nicht damit eröffnen. Stattdessen fragen: „Wer entscheidet über das Budget, und wer muss zustimmen?"

Die 6 Fragen, ohne deren Antwort ich nicht heimfahre#

1. Welche ABAS-Version, und ist die REST-API lizenziert?
2. Können Sie notfalls einen CSV-Export der offenen Fertigungsaufträge liefern?
3. Gibt es ein ABAS-Testsystem?
4. Haben die Tablets in der Halle Internetzugang, oder ist das WLAN isoliert?
5. Gibt es einen Betriebsrat — und eine bestehende Betriebsvereinbarung zur Zeiterfassung?
6. Wer ist für die IT verantwortlich, und wer ist Ihr ABAS-Partner? (Namen!)

ABAS-Vokabular#

Technisch belegbar: REST-API mit OAuth 2.0, Objekte als Datenbank:Gruppe (z. B. 2:1 Artikel). EDP-Protokoll TCP Port 6550 als Rückfall. Rückmeldung = Objekt 09:02 mit Modus DONE; ABAS bringt dafür die Infosysteme BDE buchen und BDE-Rückmeldung ab Werk mit. REST braucht etwa Version 2019r4+ und eine freigeschaltete Lizenz.

Merksatz: Wir sind ein Satellit, kein Ersatz. ABAS bleibt Wahrheit für Aufträge und Kosten — wir sind Wahrheit für das, was in der Halle passiert.

Die drei Sätze#

Architektur

„ABAS steht hinter Ihrer Firewall. Der übliche Fehler ist, daraus zu schließen, die neue Anwendung müsse auch dort laufen. Muss sie nicht — nur ein kleiner Connector, der ausschließlich von innen nach außen telefoniert. Keine Firewall-Öffnung, kein VPN, und Ihre ABAS-Zugangsdaten verlassen das Haus nie."

Daten und Recht

„Krankenstände sind Gesundheitsdaten nach Artikel 9 DSGVO. Zeit- und Leistungsdaten sind eine Kontrollmaßnahme nach § 96 Arbeitsverfassungsgesetz und brauchen meist eine Betriebsvereinbarung. Beides behandeln wir technisch getrennt — und bespricht man besser vor dem Bauen als danach."

Vorgehen

„Ich würde mit den zwei Bausteinen anfangen, bei denen es ungefährlich ist, wenn wir uns irren: Maschinenheft und Service Portal. Kein ABAS nötig, beide ersetzen etwas Vorhandenes, und zusammen beweisen sie das ganze Fundament."

Wenn nach Geld gefragt wird#

„Über alle Ausbaustufen bewegt sich so ein Programm im niedrigen sechsstelligen Bereich, verteilt über zwei bis drei Jahre — in Phasen, die einzeln beauftragt und einzeln gestoppt werden können. Die erste Phase, Analyse und Architektur, liegt im niedrigen fünfstelligen Bereich. Ein belastbares Angebot kann ich erst danach machen; vorher wäre jede Zahl geraten."

„Der Betrieb der Plattform selbst kostet 50 bis 100 Euro im Monat."

Interne Zahlen (nicht nennen): Analyse € 10–14k · Fundament + Pilot € 30–45k · Chargen/Farblager € 15–25k · Produktionssteuerung € 40–65k · ABAS unsere Seite € 8–15k · Dashboards € 12–20k · Wartung € 400–1.200/Monat. Vergleich: Standard-MES € 80–200k Lizenz + Einführung plus 18–22 % Wartung jährlich.

Wenn der Einzelentwickler-Einwand kommt#

„Berechtigte Frage. Der Code liegt von Tag eins in Ihrem GitHub-Repository, das geistige Eigentum geht vollständig an Sie über, und der Stack ist bewusst absoluter Standard — TypeScript, SvelteKit, PostgreSQL. Jede Agentur kann übernehmen. Dazu ein täglicher Export Ihrer Daten in Ihr eigenes Netz. Sie sollen nicht von mir abhängig sein."

Pilotempfehlung#

1. Maschinenheft · 2. Service Portal → danach Chargenscan → Produktionstafel als Höhepunkt von Phase 3 (vorher nur als klickbarer Prototyp zeigen).

Begründung: die zwei Bausteine wählen, bei denen ein Fehler folgenlos ist — sie beweisen trotzdem das komplette Fundament (Badge-Login, Rollen, Tablet, Offline, Fotos, Suche, Admin).

Kritikalität — was darf ausfallen#

Jedes vitale Modul bekommt einen dokumentierten Notfallbetrieb (druckbare Tagesliste, Papierformular). Das ist normale Fertigungspraxis — und der Haftungsschutz, der wirklich wirkt.

Nicht vergessen#

• WLAN an jeder Maschine messen
• Maschinenheft fotografieren — jede Seitenart
• Druckliste fotografieren — das ist die Ist-Spezifikation
• Rohwarenetiketten fotografieren — Barcodeformate
• Handschuhe? Beleuchtung? Lärm? Montageorte?
• Namen notieren: IT-Verantwortung, ABAS-Partner, Produktionsleitung, Lohnverrechnung, Betriebsrat
• Microsoft-Forms-Exporte erbitten
• Termin für die Vorstellung des Vorschlags fixieren

Falls die Antwort lautet „das weiß bei uns niemand"#

(zur ABAS-Anpassung, zur Lizenz, zum Testsystem)

„Dann ist der erste Schritt ein kurzer, bezahlter Machbarkeits-Check gemeinsam mit Ihrem ABAS-Partner. Alles andere wäre geraten — und geratene Integrationsangebote sind der Grund, warum solche Projekte scheitern."

Und nie vergessen: niemals Rückschreiben gegen ihr Live-System testen.

09 · Risiken und offene Punkte

Was das Projekt zum Scheitern bringen kann, wie man es entschärft, und was nach dem Erstgespräch beantwortet sein muss.

1. Risikoregister#

Bewertung: W = Wahrscheinlichkeit, A = Auswirkung. Sortiert nach Produkt aus beidem.

2. Die drei Punkte, die das Projekt wirklich entscheiden#

1 · Sind Klischee und Farbvorbereitung Arbeitsgänge in ABAS? Davon hängt das gesamte Datenmodell von Baustein 7 ab — ob wir eine Sicht auf ihre Daten bauen oder das führende System für die Vorstufenkette werden. Nicht raten. Am Bildschirm ansehen.

2 · Gibt es einen Weg an ABAS-Daten heran, der nicht von der Lizenzfrage abhängt? Ein zugesagter CSV-Export macht Phase 1 bis 3 unabhängig von ABAS-Politik. Ohne diese Zusage hängt der Zeitplan an einem fremden Vertrag.

3 · Wird das Tablet in der Halle tatsächlich benutzt? Alles andere ist umsonst, wenn nicht. Deshalb der Pilot mit einem Prozess, den es schon gibt, und ein früher Test am echten Gerät an der echten Maschine mit einem echten Bediener.

3. Offene Punkte nach Themen#

ABAS#

• Version und Patch-Stand
• REST-API lizenziert? Kosten der Freischaltung?
• Partner: Firma, Ansprechpartner, Stundensatz, Verfügbarkeit
• Testsystem vorhanden oder herstellbar?
• BDE-Modul lizenziert?
• Klischee/Farbe als Arbeitsgänge abgebildet?
• CSV-Export der offenen Fertigungsaufträge zugesagt?
• Wie gepflegt sind Stammdaten und Termine?

IT und Netzwerk#

• IT-Verantwortung: intern oder extern? Name, Kontakt
• VM für den Connector: Betriebssystem, wer administriert
• Ausgehendes HTTPS aus dem Serversegment erlaubt? Proxy?
• Shopfloor-WLAN: Internetzugang vorhanden? Abdeckung gemessen?
• M365/Entra ID: Tenant, Lizenzverteilung, SSO möglich?
• MDM vorhanden?
• Fileserver für tägliche Exporte

Recht und Personal#

• Betriebsrat vorhanden?
• Bestehende Betriebsvereinbarung zur Zeiterfassung?
• Datenschutzverantwortlicher benannt?
• Kollektivverträge (Arbeiter, Angestellte)
• Lohnverrechnung: intern oder Steuerberater, welche Software, welches Format
• AVV-Vorlage — vorhanden oder von uns beizubringen?

Prozess und Fachlichkeit#

• Druckliste (Ist-Spezifikation) erhalten
• Maschinenheft fotografiert
• Papierformulare eingesammelt
• Microsoft-Forms-Exporte erhalten
• Rohwarenetiketten und Barcodeformate dokumentiert
• Vollständige Liste der Blockadegründe für Auftragsstarts
• Kennzahl: Maschinenstundensatz, Rüstzeit, Abbruchquote

Kommerziell#

• Entscheidungsweg und Budgetfreigabe
• Gruppen-IT auf Eigentümerebene?
• Zeitrahmen/Erwartung des Kunden
• Berufs-/Vermögensschadenhaftpflicht SB Media geklärt
• Termin für die Vorstellung des Vorschlags

4. Abbruchkriterien — wann man dieses Projekt nicht machen sollte#

Ehrlichkeit gegenüber sich selbst gehört in die Planung. Nicht annehmen, wenn:

• Der Kunde einen Fixpreis für das Gesamtprogramm verlangt, bevor die ABAS-Machbarkeit geklärt ist.
• Verfügbarkeitszusagen mit Pönale gefordert werden. Das erfordert Redundanz und 24/7-Bereitschaft, die ein Einzelunternehmen nicht leisten kann.
• Die Zeiterfassung als erster Baustein gesetzt wird und gleichzeitig weder Betriebsvereinbarung noch klare Lohnschnittstelle existieren.
• Kein Testsystem für ABAS bereitgestellt wird und trotzdem Rückschreiben verlangt wird.
• Kein Ansprechpartner in der Produktion benannt wird. Ohne fachlichen Sponsor in der Halle scheitert jedes MES-nahe Projekt.

Keiner dieser Punkte ist absehbar. Sie stehen hier, damit sie im Ernstfall bereits durchdacht sind.

CLAUDE.md

Status: pre-contract. Nothing is built. .planned/ holds the full research and architecture; .loop/ holds the build harness. Do not start building until a phase is actually commissioned — see .loop/TODO.md.

The project#

Flexopack OPS — an internal production and employee platform for Flexopack Verpackungen GmbH, a ~50-person flexographic printing plant in Allhaming, Austria. Tablets at the presses capture what happens on the shop floor; a readiness board makes production status visible in real time; an on-prem connector syncs with their ABAS ERP.

Stack: SvelteKit · Cloudflare Workers · Neon Postgres (EU) · Better Auth · Drizzle · Cloudflare R2 · Resend Product type: internal tool — single tenant, ~50 users, no signup, no billing, no public surface

Read before you work#

Full plans and client research: .planned/ (01 Briefing · 02 ABAS · 03 Architektur · 04 Module · 05 Zeiterfassung · 06 Kommerziell · 07 Meeting-Kit · 08 Cheatsheet · 09 Risiken).

Rules that can't wait for a file read#

• Authorization posture: B — app-enforced via a server-only repository layer. Every query lives in src/lib/server/db/; nothing outside that directory imports db. Every query function takes the actor context { userId, roles, areas } as a required argument — never from ambient state. Fetch-by-id filters on id and permission in the same statement, never fetch-then-check.
• Role scope comes from the verified session, never from client input. A tablet claiming to be "Maschine 3" is a claim; station identity is a server-side binding.
• "Personal/HR" is a separate role, not a level in a hierarchy. Leitung does not imply access to Krankenstand or time data.
• Krankenstand is Art. 9 DSGVO health data. Separate schema, minimal fields, no free-text diagnosis field ever, RLS as a second wall, every read logged.
• Zeiterfassung and Maschinenheft are Kontrollmaßnahmen under § 96 ArbVG. Aggregate by default; person-level data only for named roles, always logged.
• Append-only audit log from day one. Every write to production, personnel or configuration data. A write path without an audit entry is not finished.
• No ABAS call inside a request path — ever. Queue it, retry it, surface failures in an admin error console. ABAS credentials live only on the connector VM inside the factory, never in Cloudflare or Neon.
• captured_at and received_at are separate columns on every shop-floor event. Offline capture makes them differ and traceability depends on it.
• Nothing configurable may be hardcoded — machines, areas, roles, readiness steps, statuses, categories, shift models, form types are database rows with an admin UI. If changing it needs a deploy, it's modelled wrong.
• Privileged credentials are server-only. Never PUBLIC_-prefixed, never in a universal load.
• Every server entry point Zod-validates its input, including the connector endpoints.
• drizzle-kit owns schema; migrations are committed. Never define schema in a provider dashboard. timestamptz everywhere, UUIDv7 PKs.
• Health/uptime endpoints must not query Postgres (it pins the Neon compute awake and burns the quota). Dev uses its own Neon project, not a branch.
• UI copy is German (formal "Sie"); code is English — except domain nouns which stay German verbatim (klischee, charge, rueckmeldung, fertigungsauftrag, arbeitsgang, maschinenheft, schicht).
• Touch targets ≥56px on floor views. Status is never conveyed by colour alone — colour and shape and a word.
• No emojis in UI copy, code, comments, or commit messages.

Working agreement#

• Prefix long-running pnpm commands with a timeout; on Windows/PowerShell run them as background tasks instead. Never background a dev server with &.
• After a task: tick .loop/TODO.md, prepend a brief entry to .loop/DEVLOG.md (latest on top — what shipped + decisions, not a transcript).
• Before appending to those files, if DEVLOG.md has >~15 entries or TODO.md >5 completed phases, run node .loop/archive.mjs first.
• Commit after each meaningful task.
• Every vital-tier module ships with a written Notfallbetrieb document (printable fallback for when the system is down). Vital = Produktionssteuerung, Chargenscan, ABAS-Rückmeldung. A vital module without one is not done.

GOALS

Quick-glance picture of the project: what it is, who it's for, and what "done" means. Written at planning time, revised only when the direction actually changes — not a running log (that's DEVLOG.md) and not a task list (that's TODO.md). Reference .planned/ for detail rather than restating it.

Status#

Pre-contract. Nothing is built. The client meeting that decides scope happens 10.08.2026 in Allhaming. .planned/ holds the full research, architecture and commercial groundwork; this file describes the project as we intend to build it if the engagement lands.

What this is#

Flexopack OPS — an internal production and employee platform for a flexographic printing plant. It captures what happens on the shop floor where it happens (tablets at the presses), makes production readiness visible in real time, and hands the ERP the summaries it needs.

Product type: internal tool (single tenant, ~50 users, one factory) Users: ~30 production staff (press operators, shift leads, prepress/Klischee, colour prep, Rollenschneider) on rugged tablets; ~15 office staff (Arbeitsvorbereitung, Innendienst, HR) on desktop; management on dashboards.

Why it exists#

Today the plant runs on paper and shouting. The office prints a Druckliste, prepress and colour prep signal readiness verbally, machines discover missing prerequisites mid-setup, batch numbers are copied by hand three times, and the Maschinenheft is a physical book nobody can search. Every one of those is a source of lost machine hours or lost traceability.

The client documented this themselves in Flexopack_Projektuebersicht_Digitalisierung_Niklas_Simmel.pdf — ten building blocks, five phases, twelve questions.

Success criteria#

v1 (Fundament + Pilot) counts as working when:

• A press operator with gloves on makes a Maschinenheft entry in under 20 seconds, on a real tablet at a real machine.
• Entries made while the WLAN is down appear in the system once connectivity returns, with no user action and no silent loss.
• Management sees shop-floor entries live, filtered by machine and period, without asking anyone.
• A Service-Portal report (Rohware sperren / Mangel / Verbesserung) has an owner, a status and a visible outcome — the thing Microsoft Forms cannot do.
• Roles and areas are administered by Flexopack themselves, without a support ticket.
• HR-class data is unreachable for every role that has no business seeing it, and every access to it is logged.

Scope#

In (as currently planned):

• Foundation: NFC badge + PIN auth for the floor, Entra SSO for office, roles × areas, admin layer, tablet PWA with offline outbox, audit log
• Digitales Maschinenheft, Service Portal (Forms replacement)
• Chargenscan and Farblager
• Produktionssteuerung: readiness board, Klischee/Farbe work lists, Rollenschneider view
• ABAS read sync via an on-prem connector; write-back queue in a later stage
• Dashboards from data already captured — never separately maintained KPIs

Out (for now):

• Zeiterfassung rule engine — bought or brokered, not built (see .planned/05-zeiterfassung.md)
• ABAS-side customisation — delivered by the client's ABAS partner against our interface spec
• Multi-tenancy, self-serve signup, billing — single company, single deployment
• Anything running on client hardware except the connector agent
• Native mobile apps — PWA only

Shape of the build#

• Phase 0 · Discovery & Architektur — process mapping, data model, ABAS feasibility with their partner, pilot spec, clickable prototype of the readiness board
• Phase 1 · Fundament + Pilot — auth, roles, admin, tablet PWA + offline, design system, Maschinenheft, Service Portal
• Phase 2 · Chargen & Farblager — scanning, labels, weights, locations, traceability lookup
• Phase 3 · Produktionssteuerung — readiness board, Klischee/Farbe lists, sequencing rules, Rollenschneider
• Phase 4 · ABAS-Anbindung — connector, read sync, write-back queue, error console
• Phase 5 · Zeiterfassung — option decided after discovery; likely integration rather than build
• Phase 6 · Dashboards & KPIs — operative and management views, notifications

Open questions#

Settled by the client meeting and the discovery phase; delete as they resolve.

• Is the ABAS REST API licensed and activated? Which version? Is there a test system?
• Are Klischee and Farbvorbereitung modelled as Arbeitsgänge in ABAS, or only on paper? — decides the entire data model of Phase 3
• Do the shop-floor tablets have internet access, or is that WLAN isolated?
• Is there a Betriebsrat, and an existing Betriebsvereinbarung covering the current Zeiterfassung?
• Which payroll software, and does it accept raw stamps or expect evaluated hours?
• Who provides and administers the connector VM?
• Does the owner (Loxone Lighthouse / Loxone) have group IT with standards or a stake in the decision?

TODO

Keeping this file lean: the current phase and the 5 most recent completed phases stay here in full (this is the go-to record of what shipped per phase). Older, fully-ticked phases get moved verbatim to .loop/.archive/TODO-archived.md and replaced here with a one-line stub: ## Phase N — <title> ✅ → archived.

Run node .loop/archive.mjs todo to do it — don't move the content by hand, it's slow and easy to mangle. The script only touches fully-ticked phases, moves oldest-first, and appends to the archive. --dry-run to preview, --keep=N to change retention. Phase headings must start with ## Phase for it to see them.

Nothing is built yet. Phase 0 is pre-contract work. Phases 1+ start only once the corresponding stage is commissioned. Detail for every phase lives in .planned/.

Phase 0 — Erstgespräch & Discovery#

Goal: Leave the client meeting with the six blocking unknowns answered, and turn that into a specification precise enough to quote Phase 1 against.

Pre-meeting (done):

• PDF, prior project brief and DNS document analysed
• ABAS ERP researched — interfaces, licensing, object model, vocabulary
• Austrian legal frame researched — § 26 AZG, § 96/96a ArbVG, Art. 9 DSGVO
• Ownership situation established (Loxone Lighthouse, GF since 02/2025)
• Architecture decided — cloud + outbound connector, stack, authz posture
• Data classification and role model drafted
• Cost model and commercial strategy drafted
• .planned/ documents written (01–09)
• Meeting kit and cheatsheet produced

In the meeting:

• ABAS: version, REST licence status, partner contact, test system, BDE licence
• ABAS: are Klischee and Farbvorbereitung Arbeitsgänge? (decides Phase 3 data model)
• ABAS: CSV export of open Fertigungsaufträge confirmed as fallback
• Network: shop-floor internet access, WLAN coverage measured at every machine
• IT: responsible party named, connector VM feasibility, outbound HTTPS confirmed
• Legal: Betriebsrat, existing Betriebsvereinbarung, data protection officer
• Zeiterfassung: old system, payroll software, raw vs evaluated hours
• Commercial: decision path, budget authority, group IT involvement
• Collect: Druckliste, Maschinenheft photos, Forms exports, raw material label photos, paper forms

After the meeting:

• Write up findings; update .planned/ with the answers
• Decide Zeiterfassung option (A/B/C/D) with the client
• Write the ABAS interface specification for their partner
• Produce the proposal: phase 1 fixed price, later stages as ranges
• Clickable prototype of the Produktionsbereitschaft board
• Confirm professional indemnity insurance before committing to a vital-tier module

Done when: the six blocking unknowns are answered in writing, the Zeiterfassung option is chosen, and a fixed-price Phase 1 proposal has been sent.

Phase 1 — Fundament + Pilot#

Goal: A production-usable platform with two low-risk modules live on real tablets at real machines.

• Project scaffold: SvelteKit, TS strict, pnpm, Tailwind, adapter-cloudflare, Zod env validation
• Neon EU project (separate projects for dev and prod, not branches), Drizzle schema + migrations
• Core schema: users, roles, areas, machines, shifts, audit_log, attachments — UUIDv7 PKs, timestamptz, soft delete
• Server-only repository layer (src/lib/server/db/) + CI rule forbidding db imports elsewhere
• Append-only audit log wired into every write path
• Auth: Better Auth; NFC badge + PIN for floor, email/password for office, optional Entra SSO
• Session handling, idle auto-logout on shared devices, device/station binding
• Design system: tokens, typography scale, high-contrast industrial theme, ≥56px targets
• Tablet PWA shell: install, kiosk-friendly, offline read cache, write outbox with visible pending state
• Admin layer: machines, areas, roles, permissions, users, badges — all data-driven
• R2 bucket + server-side upload path (allowlist, size cap, generated keys) for photos
• Modul: Digitales Maschinenheft — entries, types, shift handover object, photos, search, live view, PDF export
• Modul: Service Portal — configurable form types, status flow, ownership, notifications, Rohware-sperren effect
• Email port (src/lib/server/email/send.ts) via Resend
• Monitoring: uptime check that does NOT touch the database, error logging, alerting
• Daily export of critical data to the client's own file server
• Notfallbetrieb document for anything vital-tier, signed off by the client
• On-site test: real operator, real machine, real gloves — measure entry time

Done when: a Maschinenheft entry takes under 20 seconds on a real tablet at a real machine, survives a WLAN dropout, and the shift handover is being used without prompting.

Phase 2 — Chargen & Farblager#

Goal: Batch numbers and colour inventory captured by scanning, with full traceability in both directions.

• Barcode/QR scanning via tablet camera (Knox Capture) + optional Bluetooth scanner support
• Supplier label format rules — configurable, not hardcoded (GS1-128 AI 10, Code128, plain text)
• Charge model: n:m between raw batches and orders (partial consumption is the normal case)
• Plausibility checks at scan time; blocked material (from Service Portal) rejected
• Traceability lookup: raw batch → deliveries, and delivery → raw batches
• Label generation + printing (Zebra) for unlabelled goods and colour cans
• Farblager: shelf locations, can identity, weights in/out, current stock, history per can
• Can lineage (decanted, mixed, merged) and ageing warnings
• Export/handover format prepared for ABAS outbox

Done when: a full traceability query for a delivered roll returns in seconds instead of hours, and the colour store shows where a given colour physically is.

Phase 3 — Produktionssteuerung#

Goal: The Leitstand — everyone sees the same production reality, and readiness is a fact rather than a phone call.

• Order pool imported from ABAS (or CSV) with term, quantity, article, machine
• Office prioritisation UI
• Readiness steps as configurable records (name, order, owning area, who may set/reset, blocking?)
• Machine view: what's ready, what's next, what's missing
• Sequencing within configurable rules
• Klischee and Farbe work lists with "fertig" and "geht nicht + Grund"
• Rollenschneider derived view: in press, finishing soon, ready to cut
• Rückmeldung capture (good quantity, scrap, times) — stored locally, queued for ABAS
• Status changes emit events (the substrate for Phase 6 KPIs)
• Printable daily production list per machine (Notfallbetrieb)

Done when: the paper Druckliste is no longer printed, and no setup is started for an order that isn't actually ready.

Phase 4 — ABAS-Anbindung#

Goal: Read production orders from ABAS automatically; write feedback back safely.

• Connector agent: outbound polling, local ABAS access, health heartbeat, credential storage on-prem only
• Read sync: Fertigungsaufträge, Arbeitsgänge, Artikel, terms
• Write-back queue: Rückmeldung (09:02, mode DONE) with retry and idempotency
• Admin error console: what failed, why, retry
• Four-eyes release during the introduction period
• Never tested against the live system

Done when: feedback posted at the machine appears in ABAS without anyone retyping it, and a failure is visible rather than silent.

Phase 5 — Zeiterfassung#

Goal: Per the option chosen in Phase 0. Not started before the Betriebsvereinbarung situation is settled.

• Option decided and documented
• (If integrating) product selected, SSO and data sync built, portal self-service layer
• (If building capture) terminal/NFC stamping, self-service, approvals, corrections, month close
• Payroll export in the agreed format
• Health data (Krankenstand) in a separate schema with RLS, minimal fields, access logging

Done when: § 26 AZG records are complete and auditable, and payroll receives the data in the format it expects.

Phase 6 — Dashboards & KPIs#

Goal: Management sees performance derived from data already captured — nothing maintained twice.

• Operative view: planned/done, in production/blocked, quantity, scrap, disruptions
• Management view: day/week/month, per machine/area/shift, performance trend
• Aggregate by default; person-level only for named roles, with access logging
• Notifications and thresholds

Done when: the management figures in the PDF's page 4 exist without anyone maintaining a spreadsheet.

STACK.md

Security + architecture guardrails for this project. Read before writing schema, auth, storage, or API code.

How to use this file

• §0 was decided during planning. Blocks that don't apply to this project have been deleted — this file describes one stack.
• These are pointers, not a tutorial — what's easy to skip or get wrong, and what's expensive to reverse later.
• The most important of these are distilled into CLAUDE.md.
• §9 is the live guardrail checklist. It is what the QA pass audits against.

0. Decisions#

UI language: German. Code language: English, except domain nouns that stay German verbatim — klischee, charge, rueckmeldung, fertigungsauftrag, arbeitsgang, maschinenheft, schicht. Translating those invites ambiguity in every conversation with the client and their ABAS partner.

1. Security — non-negotiable#

• Privileged credentials are server-only, forever. They live in $env/static/private / $env/dynamic/private or a Workers secret binding, used only in *.server.ts / hooks.server.ts. Never PUBLIC_-prefixed, never in a universal load.
• ABAS credentials never reach the cloud at all. They live on the connector VM inside the factory. Our infrastructure stores none.
• Trust boundary = *.server.* files. Universal load and .svelte run in the browser too. Whatever a server load returns is serialized to the client — never return full user rows, badge secrets, PIN hashes, or HR fields "just in case the UI needs them".
• Verify the session, don't just read it. Better Auth's server-side api.getSession in hooks.server.ts for every trust decision.
• Validate every server entry point with Zod — form actions, +server.ts, and the connector's inbound endpoints. superforms shares the schema.
• Keep SvelteKit's built-in CSRF origin check on. The connector API authenticates explicitly with its own credential.
• Rate-limit auth, PIN entry (with lockout), and the connector endpoints.
• Never trust a client-supplied identifier for scope. User, roles and areas come from the verified session — never from a body, query param or path segment. A tablet claiming to be "Maschine 3" is a claim, not a fact: station identity is a server-side binding.

2. Authorization posture — B, app-enforced#

There is no database safety net here. Compensate structurally, not by discipline:

• One server-only data-access module owns every query (src/lib/server/db/). Route files, actions and components never import db directly.
• Every query function takes the actor context as a required argument ({ userId, roles, areas }) — never reads it from ambient state. A forgotten scope becomes a type error instead of a leak.
• Fetch-by-id filters on id AND permission in the same query. Never fetch-then-check.
• CI grep / lint rule: no db import outside src/lib/server/db/. Cheap, catches the entire class.
• HR-class tables additionally carry RLS as a second wall — the tables where a mistake is a reportable DSGVO incident.
• Writes that must be atomic need real transactions — Neon HTTP is one-shot per query, so use the WebSocket driver (drizzle-orm/neon-serverless) only on the paths that need it.

3. Data layer#

• Schema + migrations: drizzle-kit owns tables/columns. Typed schema, migrations committed to git. RLS policies and triggers live in SQL migrations. Never define persistent schema in a provider dashboard.
• Keep schema additive — new columns nullable + defaulted.
• Soft-delete (deleted_at) for user-owned and production data. Audit entries are never deleted at all.
• Time-ordered UUIDv7 primary keys by default.
• timestamptz everywhere, never timestamp. created_at / updated_at on every table.
• Offline reality: captured_at and received_at are separate columns on every shop-floor event. Traceability and Rückmeldungen depend on knowing when something happened, not when it arrived.
• Runtime access: @neondatabase/serverless over HTTP (drizzle-orm/neon-http). No persistent connection, so no pool exhaustion.
• Free plan bills awake-time, not queries. Four things pin the compute awake and burn the quota: a health check that touches Postgres (health endpoints must not query the DB), cron more frequent than ~30 min, idle TCP connections, and a dev machine left connected. Dev gets its own Neon project, not a branch.
• This client's data goes on a paid plan. Free retention is 6 hours — that is the entire PITR window, and § 26 AZG records plus traceability data cannot live on that.
• Pin dev/preview computes at a fixed 0.25 CU. Enable Neon's 80%/100% usage alerts.

4. Serverless connection rules#

Short-lived isolates can't hold a connection pool. The HTTP driver above sidesteps this entirely — that's why it's the default. If a path genuinely needs interactive transactions, use the Neon WebSocket driver for that path only; do not introduce a TCP pool.

Cloudflare Workers ≠ Node. Use adapter-cloudflare; some Node-API libraries need nodejs_compat or simply break. Check before adding a dependency — this applies especially to barcode, PDF and image libraries.

5. Storage#

• R2 bucket stays private. Access via an authed proxy endpoint or short-lived presigned URLs; never expose storage credentials client-side.
• On upload, server-side: content-type allowlist, size cap, and keys we generate — never trust the client filename. Photos from tablets can be large; resize server-side or cap at capture.
• Access by binding (Workers → R2 binding, no credentials in play).
• Object keys carry the scope (machine, module, record id), and the authz check happens before the URL is signed — a presigned URL is a bearer token.
• Maschinenheft photos may contain people and defects. Treat them as S3-class (business secret) at minimum; never publicly linkable.

6. Email#

• Resend, sent through one thin internal port (src/lib/server/email/send.ts), never the provider SDK scattered around the codebase.
• Transactional mail is a side effect that can fail: never block a request on it where the user's action has already succeeded. A Maschinenheft entry must save even if the notification doesn't send.

7. Cheap cross-cutting wins#

• Zod-validate env at startup — missing config fails fast and loud.
• handleError hook for logging; never leak stack traces to clients. .env gitignored, .env.example committed.
• Pagination (keyset/cursor) designed into the first list view. Maschinenheft entries and audit rows grow without bound.
• Generate types from Drizzle so DB and code stay in sync. TS strict on.

8. Background / heavy work#

• Serverless = request/response only. No long-running or background processes in a Worker.
• The ABAS outbox is a queue, not a request path. A tablet tap writes locally and returns; delivery to ABAS happens asynchronously with retries and a visible error console. Never a blocking ERP call inside a user interaction.
• PDF generation (Maschinenheft export, label sheets) and any bulk export go through a queue if they outgrow a request.

9. Guardrails checklist#

Written at planning time. The QA pass audits against exactly this list. Tick items as they are implemented.

Authorization & tenancy#

• No db import outside src/lib/server/db/ — enforced by a CI lint rule, not by convention
• Every repository function takes an explicit actor context { userId, roles, areas } as a required parameter
• No repository function reads identity from ambient/module state
• Every fetch-by-id filters on id and permission in the same SQL statement
• Station/tablet identity is a server-side binding; a client-supplied machine id is never trusted for scope
• Role checks are unit-tested per role: for each role, an explicit list of what it must NOT see
• HR-class tables (krankenstand, zeiterfassung*, personnel) additionally have RLS enabled with explicit policies
• "Personal/HR" is a separate role, not a level in a hierarchy — Leitung does not imply HR access

Personal data (S1 / S2)#

• Health-adjacent data lives in its own schema, with the minimum viable field set
• No free-text diagnosis field exists anywhere in the schema
• Every read of S1 data and every person-level read of S2 data is written to the audit log
• Production/performance views are aggregated by default; person-level requires a named role
• Retention periods are defined per data class and enforced by a scheduled job, not by intention
• Data-subject export and deletion are implementable without a manual SQL session

Audit trail#

• Append-only audit_log table: actor, action, entity, before/after, timestamp, device — no UPDATE, no DELETE
• Every write to production, personnel and configuration data produces an audit entry
• Audit entries are never soft-deleted or purged before the data they describe
• Audit log is queryable in the admin UI by entity and by actor

Offline & data integrity#

• Every shop-floor event stores captured_at and received_at separately
• Outbox writes are idempotent — a retried submission never double-books a quantity
• Pending offline writes are visible to the user ("3 Einträge warten auf Übertragung"); silent loss is impossible
• Offline cache scope and lifetime are bounded (no unlimited local copy of production data)

ABAS boundary#

• No ABAS call happens inside a user request path — everything goes through the queue
• ABAS credentials exist only on the connector VM; no ABAS secret is stored in Cloudflare or Neon
• The connector authenticates to our API with its own credential, rate-limited and revocable
• Write-back is idempotent and carries a correlation id
• Failed ABAS deliveries are visible in an admin error console with a retry action — never silently dropped
• Write-back has never been tested against the client's live ABAS system

Secrets & environment#

• All secrets are Workers secret bindings or $env/*/private; none are PUBLIC_-prefixed
• Env is Zod-validated at startup
• .env gitignored, .env.example committed
• No credential, badge secret or PIN hash is ever returned from a load function

Storage#

• R2 bucket is private; no public bucket URL exists
• Uploads are server-mediated: content-type allowlist, size cap, server-generated keys
• Authorization is checked before any presigned URL is issued
• Uploaded images are size-bounded (resized or rejected)

Operations#

• Health/uptime endpoint does not query Postgres
• Dev uses its own Neon project, not a branch of production
• Production Neon is on a paid plan with ≥7-day PITR
• A restore has actually been performed and documented at least once
• Daily export of legally/operationally critical data to the client's own file server, monitored
• Alerting exists for: connector offline >15 min, outbox backlog over threshold, error rate over threshold
• handleError hook logs server-side; no stack trace ever reaches a client
• Every vital-tier module has a written, client-signed Notfallbetrieb document

Product-shaped#

• Machines, areas, roles, permissions, readiness steps, statuses, disruption categories, shift models and form types are database rows with an admin UI — none of them hardcoded
• Adding a machine or a readiness step requires no deployment

10. Project specifics#

• Deploy target: Cloudflare Workers. Custom domain ops.flexopack.at — note their split-brain DNS: the internal AD zone flexopack.at on FPD02 is authoritative inside the company network, so an internal record must be created in addition to the public one. Do not touch the zone apex (it points at the domain controllers) or the MX records.
• Connector: separate small service (own repo or apps/connector), runs as a Windows service or systemd unit on a client-provided VM. Outbound HTTPS only. Ships with an installer, a config file and a health heartbeat. It is the only component that knows ABAS exists.
• ABAS facts: REST API needs ~2019r4+ and an activated licence; OAuth 2.0; objects addressed as Datenbank:Gruppe (2:1 Artikel). EDP protocol on TCP 6550 is the fallback. Rückmeldung = object 09:02 with mode DONE; the BDE buchen / BDE-Rückmeldung Infosysteme ship with the product. A scheduled CSV export of open Fertigungsaufträge is the agreed escape hatch.
• Legal frame: § 26 AZG (record-keeping duty) applies if we build Zeiterfassung; § 96/96a ArbVG (Betriebsvereinbarung for monitoring measures) applies to Zeiterfassung and to the Maschinenheft; Art. 9 DSGVO applies to Krankenstand. An AVV per Art. 28 DSGVO between Flexopack and SB Media is mandatory, with the subprocessor chain (Cloudflare, Neon, Resend) listed.
• Data residency: Neon EU (Frankfurt), R2 with EU jurisdiction, Resend EU. This is a stated client-facing commitment — do not add a service that breaks it without raising it first.
• Criticality tiers: vital = Produktionssteuerung, Chargenscan, ABAS-Rückmeldung · important = Zeiterfassung, Rollenschneider, Klischee/Farbe · convenience = Maschinenheft, Farblager, Service Portal. Availability design and Notfallbetrieb obligations follow the tier.
• Hardware reality: Samsung Galaxy Tab Active5, gloves, hall lighting, metal environment. Touch targets ≥56px, no hover dependency, no double-tap, status never conveyed by colour alone.

PRINCIPLES.md

How we work in this codebase. Read before writing code.

How to use this file

• §1 ships with the harness and holds for most projects. It is default, not law — override any line with a Project: note in §3 and a one-line reason.
• §2 is written at planning time; §3 accumulates as the project teaches us things (QA passes append here).
• Visual/aesthetic rules live in DESIGN.md. Security/architecture rules live in STACK.md. This file is process and code craft.
• The most important lines get distilled into CLAUDE.md.

1. Shipped defaults#

Process management#

• Prefix any pnpm command that could be long-running with a timeout: timeout 30 pnpm <cmd>. This includes dev, preview, test, and anything you're unsure about. build, check, and lint don't need it. (POSIX shells. On Windows/PowerShell there's no timeout equivalent — run these in a background task instead, and never leave a dev server running in the foreground.)
• Never use &, nohup, or disown.
• If you need to interact with a running dev server (curl endpoints, check rendered HTML), say so first — I'll start it in my own terminal.

No emojis#

• None in UI copy, code, comments, or commit messages. Convey state with words, icons (lucide), or color — never with an emoji.
• The one exception is the existing ✅ → archived marker in TODO.md, which is a parsed convention, not decoration.

data-e identifier attribute#

• Give meaningful UI elements a data-e="some-name" attribute so I can point at elements in the DOM. No functional purpose, purely identification — Tailwind makes elements hard to pinpoint by class alone.

Comments#

• Comment the why, not the what. No comment restating the line below it, no section-divider banners, no changelog comments in code — that's what git and DEVLOG.md are for.

Dependencies#

• Prefer the platform and what's already installed. A new dependency needs a reason worth stating out loud; check it works on the target runtime (Workers ≠ Node) before adding it.

Scope discipline#

• Do the task asked. Adjacent problems you notice get reported, not silently fixed — unrelated changes in a diff make review expensive and bugs hard to bisect.
• Don't leave dead code, commented-out blocks, or placeholder/mock implementations behind as if they were finished work. If something is stubbed, say so explicitly.

2. Project additions#

Language#

• UI copy is German, formal "Sie". Code is English — identifiers, comments, commit messages, docs.
• Exception: domain nouns stay German verbatim, in code and in the UI: klischee, charge, rueckmeldung, fertigungsauftrag, arbeitsgang, maschinenheft, schicht, schichtuebergabe, farblager, rollenschneider. Translating them creates ambiguity in every conversation with the client and their ABAS partner. Use ASCII transliteration in identifiers (rueckmeldung, not rückmeldung); keep the umlaut in UI strings.
• Never invent a German term the plant doesn't use. If unsure what they call something, mark it // TERM? and ask — don't guess a synonym.

Folder layout#

src/lib/server/db/        the ONLY place that imports `db`. One module per aggregate.
src/lib/server/auth/      session, badge/PIN, station binding
src/lib/server/email/     send.ts — the single email port
src/lib/server/abas/      outbox writer + connector API. Nothing else knows ABAS exists.
src/lib/domain/           pure domain logic, no I/O, unit-tested
src/lib/components/       ui/ (primitives) · floor/ (tablet) · office/ (desktop)
src/routes/(floor)/       tablet routes — density mode "floor"
src/routes/(office)/      desktop routes — density mode "office"
src/routes/(admin)/       configuration UI
apps/connector/           the on-prem agent. Separate deploy, separate lifecycle.

Domain rules that are easy to get wrong#

• Every shop-floor event carries captured_at and received_at separately. Offline capture means these differ, and traceability depends on the first one.
• Every write produces an audit entry. If a write path has no audit entry, it is not finished.
• Nothing that a user can configure may be hardcoded — machines, areas, roles, readiness steps, statuses, disruption categories, shift models, form types. If it needs a deploy to change, it's modelled wrong.
• No ABAS call inside a request path. Queue it.
• Quantities are integers with an explicit unit column. Never floats, never an implied unit.
• A tablet's claim about which machine it is is not evidence. Station identity is a server-side binding.

Testing emphasis#

• Role matrices are unit-tested: for each role, an explicit list of what it must not be able to read or write. This is the single most valuable test suite in the project.
• Offline outbox: test idempotency (a retried submission must never double-book a quantity) and ordering.
• Domain logic in src/lib/domain/ is pure and tested without a database.

Process#

• Show, don't assume. Before building a shop-floor screen, sketch it and confirm with the client — the cost of a wrong UI here is measured in operators refusing to use it.
• Every vital-tier module ships with its Notfallbetrieb document. A module without a documented paper fallback is not done.
• Prefer boring, legible implementations over clever ones. This codebase must be readable by its owner and, one day, by another agency.

3. Overrides & accumulated lessons#

• Timeouts on long-running commands (§1) — Windows note: the dev machine is Windows/PowerShell, so there is no POSIX timeout. Run dev servers as background tasks, never in the foreground, and never with &.
• data-e attributes (§1) matter more than usual here — UI reviews happen by pointing at a tablet screenshot. Give every meaningful element one.

DESIGN.md

Outlines the direction of aesthetic specifically tailored to this project. Source of truth for visual + interaction design. Read before any UI/frontend work.

How to use this file

• Defaults below apply unless a Project: line overrides them.
• After a confirmed UI preview, update the relevant lines here (direction, tokens, overrides). Keep it concrete and roughly one page — a working spec, not documentation.

Direction#

• North star: an instrument panel, not a website. Legible at a glance from a metre away, in a bright hall, through safety glasses, while the machine is running. Calm and dense for the office; oversized and unambiguous at the machines.
• References: Linear-tier restraint for the office views; industrial HMI clarity for the floor views. Never decorative, never playful, never "internal tools can look rough".
• Tone: calm, dense, utilitarian. The product's job is to remove uncertainty, and confident quiet UI is how it does that.

Two contexts, one system#

This is the defining constraint of the project. Same tokens, same components, two density modes:

Density is a documented mode (data-density="floor" | "office"), not two codebases.

Typography#

• Sans only. No serif, no italics in headings or body.
• Restrained weight: normal body, bold reserved for headings and genuine emphasis.
• Tokenized scale (--text-xs … --text-3xl) and line-height tokens. No ad-hoc font sizes.
• Font: Inter (variable, self-hosted — no Google Fonts CDN, consistent with the DSGVO posture from the website project). Tabular numerals enabled for all quantities, weights and counts.

Color#

• Tokenize everything. No raw hex in components.
• Semantic roles: bg surface border fg fg-muted primary primary-fg accent destructive success warning.
• Flexopack gold (oklch(0.787 0.161 91)) is an accent only — brand recognition on the login screen, the active state, small emphasis. It is not a surface colour and it is never the base of a dense data view. A marketing palette is not a data palette.
• Light and dark from the same tokens. Dark mode matters for night shifts.
• Status is never carried by colour alone. Every state gets colour and an icon/shape and a word. Colour-blind operators exist, hall lighting distorts hue, and a green dot behind a reflection is not a signal.

Surfaces & separation#

• Don't reach for a soft tinted background to mark out a component. Filled panels in muted brand tints stack badly and read as unconsidered.
• Separate with, in order of preference: whitespace → a hairline border → typographic weight/scale → a small elevation step. A tinted fill is deliberate emphasis (the active order, the blocked step), never the baseline.
• Keep surface levels low: one page background, one raised surface.

Spacing & layout#

• 4px-base spacing scale via tokens (--space-1…).
• Radii: --radius-sm/md/lg, default md.
• Floor views: single column, full-bleed, no horizontal scrolling ever. Office views: 12-column grid, consistent gutters, container max-width.

Icons#

• lucide only. One icon set, ever. 20/24px on floor views, 16/20px in the office. Stroke 1.5–2.

Motion & interaction#

• Every interactive element gets hover / press / focus feedback. On the floor, press feedback is the important one — a gloved tap needs immediate visible confirmation or it gets tapped again.
• Duration/easing tokens; 150–250ms, ease-out on enter. No decorative motion, no scroll theatre — this is a tool people use for eight hours.
• Respect prefers-reduced-motion.

States (design all of them)#

• Offline is a first-class state, not an error: a persistent, calm indicator plus a pending-writes count ("3 Einträge warten auf Übertragung"). Never a modal, never a blocking toast, never silence.
• Loading: skeletons over spinners where layout is known.
• Empty: helpful message + primary action.
• Error: plain German, what happened and what to do. Never a stack trace, never an error code alone.
• Saved: unambiguous confirmation for every shop-floor write. The operator must never wonder whether it went through.

Graphical assets#

• Bespoke SVG where it earns its place: readiness-state marks, machine schematics, empty-state illustrations. On-token, lightweight, consistent.
• The readiness "Hakerl" strip is the product's signature element — design it deliberately, it is what people will point at.

Accessibility#

• Visible focus states, AA contrast minimum (AAA for floor views — hall lighting is hostile), full keyboard nav in office views, hit targets ≥40px office / ≥56px floor.
• All copy in German, formal "Sie", consistent with the client's existing brand voice.

Do / Don't#

• Do: tokenize, design every state including offline, separate with space and hairlines, confirm every write, use words + shape + colour for status, keep motion purposeful.
• Don't: raw hex/px in components, tinted fills as the default separator, gold as a surface, colour-only status, italic headings, heavy body weight, gratuitous motion, mixed icon sets, emojis in UI copy (use lucide), free-text fields where a selection would do.

Stack & tokens#

• Framework / UI: SvelteKit + TailwindCSS + shadcn-svelte (complex components only) + lucide icons
• Token source of truth: src/app.css :root (OKLCH), mirrored into the Tailwind config
• Live token names: maintained here as they're defined

Project specifics#

• Client brand: Flexopack gold oklch(0.787 0.161 91), near-black oklch(0.088 0.005 18.1), near-white oklch(0.98 0 0) — carried over from flexopack.at for recognition, applied with far more restraint than on the marketing site.
• UI language German throughout, formal address.
• Domain vocabulary in the UI stays exactly as the plant says it: Klischee, Charge, Rückmeldung, Fertigungsauftrag, Maschinenheft, Schichtübergabe. Never translate or "improve" these words — they are how people talk on the floor.
• Benchmark to design against: a standard Maschinenheft entry in under 20 seconds, with gloves, at the machine. Any design decision that costs seconds there is the wrong decision, however elegant.