Weinverwaltung
Internes Verwaltungstool für das Familienweingut Honsig
Die EU-Vorgaben zur Lebensmittelkennzeichnung verlangen seit Ende 2023 auch von Winzer:innen detaillierte Nährwert- und Inhaltsstoffangaben pro Wein. Auf dem Etikett ist dafür kaum Platz, also kommt ein QR-Code auf die Flasche, der auf ein digitales Produktdatenblatt verweist. Auch das Familienweingut Honsig suchte nach einem Weg, das ohne großen Verwaltungsaufwand umzusetzen. Daraus entstand eine Produktverwaltung, die weit über QR-Codes hinausgeht: Sie bündelt alle Informationen des Weinguts an einer Stelle und schafft damit die Basis für kommende Projekte, etwa eine neue Website.
Das Problem Zeit soll in guten Wein fließen, nicht in die Datenverwaltung
Gerade für ein kleines Weingut ist die EU-Verordnung eine Herausforderung. In einem Familienbetrieb fehlt schlicht die Zeit, sich intensiv mit solchen Anforderungen auseinanderzusetzen. Die Angaben müssen gepflegt werden und dauerhaft online abrufbar sein. Es gibt zwar Anbieter, die sich genau auf diesen Anwendungsfall spezialisiert haben, allerdings zu hohen laufenden Kosten. Neben dem Preis war dem Kunden vor allem der Zeitaufwand wichtig, denn die Produktdaten müssen für jeden künftigen Jahrgang neu erfasst werden.
Schnell zeigte sich außerdem, dass die Verwaltung schon vor den EU-Vorgaben ein Problem war: Auch die Weine auf der eigenen Website ließen sich kaum aktuell halten. Zwei getrennte Datenbestände – einer für die Lebensmittelkennzeichnung, einer für die Website – hätten die Sache noch komplizierter gemacht. Deshalb habe ich eine individuelle Softwarelösung vorgeschlagen, die den Aufwand langfristig so gering wie möglich hält und alle Informationen für sämtliche Einsatzzwecke zentral zusammenführt.
Die Lösung Zeit sparen durch optimierte Prozesse
Mein wichtigstes Ziel war, dem Kunden möglichst viel Zeit zu ersparen. Deshalb lag der erste Fokus auf einer durchdachten Datenstruktur und effizienten Abläufen. Einen neuen Jahrgang anzulegen sollte so schnell wie möglich gehen. Das rückte Funktionen wie die Übernahme der Werte aus dem Vorjahr in den Mittelpunkt. Ebenso wichtig war mir ein intuitives Interface, da die Anwendung im Wesentlichen einmal pro Jahr zum Einsatz kommt. Sich dann jedes Mal aufs Neue in ein komplexes System einzuarbeiten, würde zu Frustration führen.
Das Frontend ist eine Svelte-App, gestylt mit Tailwind und DaisyUI. Da es bei einem internen Tool nicht um ein möglichst individuelles Design geht, sondern um klare Bedienung und gute Usability, habe ich bewusst auf eine Component Library gesetzt.
Für das Backend habe ich mich für PocketBase entschieden – ein Open-Source-Framework mit SQLite-Datenbank, das sich einfach selbst hosten lässt und alle wesentlichen Bausteine wie Authentifizierung, File Storage und REST-API mitbringt. Auch wenn sich PocketBase noch in Entwicklung befindet, hat es sich in vorherigen Projekten als solide Basis erwiesen und passt gut zu einem Einsatz mit niedrigem Risikoprofil.
Pro Wein gibt es einen Datensatz mit Stammdaten wie Rebsorte und Anbaugebiet, welche unabhängig vom Jahrgang sind. Zu jedem Wein lassen sich beliebig viele Jahrgänge anlegen. Diese enthalten die variablen Angaben wie Alkoholgehalt und Restzucker, welche für die Produktdatenblätter relevant sind. Für jeden Jahrgang entsteht automatisch eine Produktdatenseite mit eindeutiger ID, zu der sich der passende QR-Code herunterladen lässt.
Learning Struktur ist alles
Die größte Herausforderung und damit mein wichtigstes Learning aus diesem Projekt war die Planung einer umfassenden Datenstruktur – gerade weil das Tool nicht nur die Lebensmittelkennzeichnung abdecken, sondern auch für künftige Einsatzzwecke gerüstet sein sollte. Umso wichtiger war es, gemeinsam mit dem Kunden alle relevanten Datenpunkte herauszuarbeiten. So kamen etwa eine eigene Verwaltung für die Auszeichnungen der einzelnen Weine und die Möglichkeit, Verkaufseinheiten zu hinterlegen, dazu, um jeden Wein später auch auf der Website optimal zu präsentieren.
Technisch war das Typing der PocketBase-Datenmodelle anspruchsvoll, vor allem bei Abfragen mit expandierten Relationen. Gelöst habe ich das im Frontend über expanded Interfaces.