ERP-System für eine Lasergravur
Aufträge, Kalkulation und Lager in einer Oberfläche statt E-Mail-Verläufen. Der Bestand ergibt sich aus Bewegungen, das Dashboard zeigt die Angebotsquote.
- Kunde
- LaserProdukt
- Branche
- Lasergravur
- Projektdauer
- 3 Wochen bis zum Produktivstart
- Technologien
- Laravel
- MySQL
- Laravel Cloud

Die Herausforderung
Aufträge lebten in E-Mail-Verläufen, und den Materialbestand musste jemand jede Woche von Hand zählen, um zu wissen, ob noch genug zum Gravieren da ist.
Was wir geliefert haben
- Drei Auftragsarten mit Kalkulation und Statusablauf
- Lager mit Bestand aus Bewegungen
- Dashboard mit Vertriebsanalyse und Angebotsquote
LaserProdukt graviert im Auftrag mit dem Laser – manche Arbeiten auf eigenem Material, manche auf Material, das der Kunde stellt, und manche direkt beim Kunden vor Ort. Das sind drei verschiedene Arten, dieselbe Maschine abzurechnen, und drei verschiedene Sätze an Informationen, die bei jedem Auftrag zusammenkommen müssen.
Ein System gab es nicht. Der Auftrag kam per E-Mail und blieb in der E-Mail: die Absprachen im Verlauf, das Angebot in einer Antwort, eine geänderte Menge irgendwo weiter unten, die Bestätigung in der nächsten Nachricht. Um zu sagen, wo ein bestimmter Auftrag steht, musste man den richtigen Verlauf finden und von vorn lesen.
Am meisten Zeit fraß aber das Lager. Den Materialbestand gab es nur als Summe dessen, woran sich jemand erinnerte und was er im Regal nachsehen konnte, also setzte sich einmal pro Woche jemand hin und zählte neu. Diese Zeit ging nicht in den nächsten Auftrag. Das Problem war nicht das fehlende Programm, sondern dass jede Antwort zum Stand des Unternehmens von Hand zusammengetragen werden musste.
Womit wir angefangen haben
Mit dem Weg eines Auftrags, nicht mit Bildschirmen. Wir sind ihn von der Anfrage per E-Mail bis zu dem Moment gegangen, in dem das Geld auf dem Konto ist, und haben bei jedem Schritt gefragt, wer diese Information hat und wo sie dann liegt.
Zwei Dinge kamen dabei heraus, die nicht in der Auftragsbeschreibung standen:
- Ein Auftrag ist nicht ein einziger Prozess. Es gibt drei Arten – eigenes Material, Kundenmaterial und Leistung beim Kunden –, und sie unterscheiden sich darin, was eingetragen werden muss und was vom Lager abgeht. Ein universelles Formular fragt entweder nach Dingen, die es bei der jeweiligen Art nicht gibt, oder schweigt zu denen, die nötig sind.
- Das Unternehmen brauchte kein vollständiges ERP. Die Rechnungsstellung lief woanders und sollte dort weiterlaufen. Es fehlte der Teil dazwischen: Auftrag, Material und Geld auf der Ebene einer einzelnen Arbeit gesehen, nicht auf der Ebene eines Buchhaltungsbelegs.
Die zweite Beobachtung hat über den Umfang entschieden – und darüber, was wir bewusst nicht gebaut haben.
Was wir gebaut haben
Eine Oberfläche im Browser, deren Kern der Auftrag ist. Das Formular passt seine Felder an die Auftragsart an, und die Kalkulation ergibt sich aus Laserzeit mal Satz mal Menge, plus Material und Transport – oder wird von Hand eingetragen, wenn der Preis anders vereinbart ist. Der Auftrag durchläuft seinen Statusablauf vom Angebot bis zur Abrechnung, und die Entscheidung des Kunden zum Angebot wird gesondert gespeichert, denn auch ein abgelehntes Angebot ist eine Information.
Darum herum steht der Rest: eine Kartei der Geschäftspartner, die die Kopfzeilen der Dokumente füllt, ein Artikelkatalog mit Graviersatz und Laserzeit, mehrzeilige Lieferscheine mit eigener Nummerierung und PDF sowie Qualitätsprüfberichte mit einer bearbeitbaren Kriterientabelle. Das Dashboard fasst das in Zahlen zusammen – Aufträge, Umsatz, offene Forderungen, Aufteilung nach Status und Angebotsquote –, filterbar nach Datum, Geschäftspartner, Artikel und Status.
Der Lagerbestand ist ein Ergebnis, kein Eingabefeld
Die entscheidende Festlegung: Der Lagerbestand lässt sich in diesem System nicht bearbeiten. Er ergibt sich aus Bewegungen – Zugängen, Abgängen und Korrekturen – und nur aus ihnen.
Das sieht man in der täglichen Arbeit. Geht ein Auftrag in den Status „in Bearbeitung“, wird das Material automatisch vom Lager abgebucht, denn in diesem Moment kommt es tatsächlich unter den Laser. Der Status „geliefert“ erscheint erst, wenn die Lieferscheine die gesamte bestellte Menge abdecken – niemand klickt ihn von Hand an.

Ein Eingabefeld für den Bestand wirkt bequem – genau bis zum ersten Fehler, nach dem niemand mehr weiß, ob der Fehler im Regal oder im Feld steckt. Ein aus Bewegungen berechneter Bestand lässt sich immer in das zerlegen, woraus er entstanden ist.
Was wir bewusst nicht gebaut haben
Außerhalb des Umfangs blieben die Rechnungsstellung (einschließlich KSeF, des verpflichtenden polnischen E-Rechnungssystems), ein Lager mit Bestellungen bei Lieferanten und ein CRM. Das war weder ein Versehen noch eine Budgetkürzung: Jede dieser Funktionen läuft im Unternehmen entweder schon woanders oder löst ein Problem, das dieses Unternehmen in dieser Phase nicht hat.
Das Ganze liegt hinter einer Anmeldung mit Zwei-Faktor-Authentifizierung (2FA) und Passkeys, ohne öffentliche Registrierung – Konten legt ein Administrator an. Es ist eine Oberfläche mit Preisen, Marge und der Kundenkartei, da ist ein Passwort allein ein zu schwacher Schutz.
Wie die Einführung lief
Nach Plan und ohne Wendungen: Etappe, Vorführung, Feedback, nächste Etappe. Der Kunde sah sich einen funktionierenden Bildschirm an statt einer Beschreibung und gab Hinweise zu dem, was er sah – bei einem System aus sechs Teilen ist das der einzige Weg, ein fehlendes Feld zu finden, bevor der Rest darum herum wächst.
Ehrlich gesagt: Es gab hier keinen Moment, in dem etwas zurückgenommen werden musste, und aus diesem Projekt haben wir keine Geschichte über einen Konflikt mit dem Team oder einen falsch angenommenen Prozess. Wir vermuten, dass das am zugeschnittenen Umfang liegt – der Teil, den wir nicht gebaut haben, ist zugleich der, in dem sich solche Einführungen am häufigsten im Kreis drehen.
Was sich nach dem Start geändert hat
Ehrlich zur Messung: Die im Lager gewonnene Zeit ist eine Schätzung des Inhabers vor der Einführung, nicht das Ergebnis zweier Messungen, denn vorher hat das Unternehmen nichts gemessen. Die Zahl der neuen Geschäftspartner stammt dagegen aus dem System selbst – es sind Datensätze, die im Lauf eines Monats in der Kartei dazukommen, angelegt mit einem Auftrag und nicht in einem eigenen Schritt „Kunde hinzufügen“.
Die Änderung, die man in den Zahlen nicht sieht, betrifft die Fragen, die der Inhaber jetzt stellen kann. Das Wissen darüber, was sich verkauft und welche Angebote zu Aufträgen werden, war über E-Mail-Verläufe verstreut – es ließ sich rekonstruieren, aber um den Preis eines Abends. Jetzt ist die Angebotsquote eine Kennzahl auf dem Dashboard, und die Frage „Lohnen sich solche Aufträge?“ ist keine Frage des Bauchgefühls mehr.
Offen geblieben ist, was wir bewusst außerhalb des Umfangs gelassen haben. Entscheidet sich das Unternehmen irgendwann, Verkaufsbelege aus demselben System zu erstellen, liegen die Daten schon in einem System und einem Format – aber das wird eine eigene Entscheidung sein und nichts, was wir beim Start stillschweigend festgelegt haben.
Ergebnisse in Zahlen
- 3 h
- pro Woche weniger für die Lagerzählung
- 15
- neue Geschäftspartner pro Monat in der Kartei
- 0
- von Hand eingetragene Lagerbestände