Ein Montagebetrieb mit sechs Leuten und vier Excel-Tabellen. Ein Modelldurchgang durch einen Nachmittag: was in den Prompt gehört, was von selbst entsteht, was von Hand nachjustiert werden muss und was sich im ersten Monat wirklich ändert.
Dieser Text ist ein Durchgang durch einen Nachmittag - von vier Excel-Tabellen zu einer funktionierenden Auftragsverwaltung. Er ist als Modellfall eines kleinen Montagebetriebs geschrieben, aber der Ablauf, die Reihenfolge der Schritte und die Stellen, an denen es üblicherweise hakt, entsprechen dem, was wir beim ersten Workspace am häufigsten sehen.
Ausgangslage: vier Tabellen und eine Pinnwand
Sechs Personen. Zwei Monteure im Außendienst, ein Vertriebler, eine Sachbearbeiterin, der Inhaber und seine Frau für die Rechnungen. Aufträge: Innenausbau, meist 15 bis 40 gleichzeitig.
Wo das alles vor diesem Nachmittag lebte:
- auftraege_2026.xlsx - die Haupttabelle, die niemand gleichzeitig mit jemand anderem öffnen durfte
- kontakte.xlsx - Kunden, gelegentlich doppelt
- termine.xlsx - wann was fällig ist, unregelmäßig gepflegt
- stunden.xlsx - Nachweise der Monteure, am Monatsende rekonstruiert
- eine Pinnwand im Büro mit Papierbestellungen
Der Schmerzpunkt, der entschied: zweimal in einem halben Jahr vergaß die Firma, einen fertigen Auftrag zu berechnen. Einmal über 2.700 €.
Was in den Prompt kam
Nichts Technisches. Wörtlich das:
Ich brauche eine Auftragsverwaltung für einen Montagebetrieb. Zu jedem Auftrag will ich wissen, wer der Kunde ist, wann der Montagetermin ist, welcher Monteur daran arbeitet, wie viele Stunden er gearbeitet hat und ob der Auftrag berechnet wurde. Ich will sehen, was diese Woche ansteht, und eine Meldung, wenn ein Auftrag fertig ist und keine Rechnung hat.
Keine „relationale Datenbank“, keine „Workflow-Engine“. Eine Beschreibung dessen, was das System können soll, in der Reihenfolge, in der es mir einfiel.
Aus der Beschreibung entstand ein Plan, nicht sofort die fertige Sache
Das System zeigte zuerst, was es anlegen will - Datenbanken, Verknüpfungen und Automatisierungen. Erst nach Freigabe hat es gebaut.
Was herauskam (und was ich nachjustieren musste)
In etwa zwanzig Minuten standen drei verbundene Datenbanken - Aufträge, Kunden, Monteure - plus Stundennachweise am Auftrag. Dazu drei Ansichten: Montagekalender, Tabelle der unberechneten Aufträge und ein Kanban nach Status.
Was sofort passte:
- die Verknüpfung zwischen Auftrag und Kunde (ein Auftrag, ein Kunde; ein Kunde hat mehrere Aufträge)
- Stundennachweise am Auftrag und am Monteur
- die Ansicht „diese Woche“ als Kalender
Was ich von Hand nachziehen musste:
- Auftragsstatus. Die erzeugten waren allgemein (Neu / Läuft / Fertig). Wir haben fünf, darunter „Wartet auf Material“ - bei uns der häufigste Verzugsgrund. Umbenennen und ergänzen dauerte Minuten.
- Wer was sieht. Monteure sollen keine Preise sehen. Das wird getrennt eingestellt - richtig so, denn das sollte keine Maschine entscheiden.
- Text der Erinnerung. Die automatische E-Mail hatte generischen Inhalt. Ich habe ihn umgeschrieben, damit er nach uns klingt.
Unterm Strich: der Prompt hat 80 % der Struktur gemacht, der Rest war Einstellen, nicht Bauen.
Der schwierigste Teil war nicht technisch
Am längsten hat gedauert, mir zu überlegen, was ein „Auftrag“ eigentlich ist. Ob ein Auftrag eine Montage ist oder die gesamte Bestellung eines Kunden, die drei Montagen umfassen kann. Diese Frage löst kein Werkzeug für Sie - aber es ist eine Stunde Nachdenken, kein Monat Entwicklung.
Die Automatisierung, wegen der das Ganze entstand
Eine Regel, zwei Bedingungen:
Wenn ein Auftrag länger als 3 Tage im Status „Fertig“ steht und keine Rechnung hat, schick mir eine E-Mail.
Das ist die vollständige Lösung eines Problems, das die Firma 2.700 € gekostet hat. Das Einrichten dauerte etwa sechs Minuten.
Eine zweite Regel kam eine Woche später dazu, als sich zeigte, dass Monteure das Stundenerfassen vergessen:
Jeden Freitag um 15:00 schick jedem Monteur die Liste der Aufträge dieser Woche ohne Stundennachweis.
Was sich in einem Monat änderte
Drei messbare Dinge:
Rechnungsstellung. Im ersten Monat wurden zwei Aufträge, die früher durchgerutscht wären, rechtzeitig berechnet. Das allein hat das System für mehrere Jahre bezahlt.
Schluss mit Tabellenversionen. Die Frage „welche Tabelle ist aktuell“ existiert nicht mehr. Nicht weil sich die Leute gebessert hätten, sondern weil es nur eine gibt.
Die Morgenrunde. Von zwanzig Minuten auf fünf, weil niemand mehr laut durchgehen muss, wo etwas steht. Der Montagekalender zeigt dasselbe schneller.
Was sich nicht geändert hat: Monteure vergessen weiterhin gelegentlich die Stunden. Das System erinnert nur am Freitag daran. Ein Werkzeug ändert keine Gewohnheiten, es verkürzt nur die Zeit bis zum Auffallen eines Fehlers.
Was ich anders machen würde
Drei Dinge:
- Kleiner anfangen. Ich habe gleich am Anfang eine Materialverwaltung ergänzt. Überflüssig - nach zwei Wochen nutzte sie niemand. Ergänzen kann man jederzeit.
- Die Leute früher einbeziehen. Ich habe allein gebaut und es dann gezeigt. Hätte ich die Sachbearbeiterin vorher gefragt, hätte ich mir zwei Umbauten der Ansichten gespart.
- Nicht die ganze Historie übernehmen. Ich habe drei Jahre alte Aufträge importiert. Das letzte Jahr hätte gereicht, der Rest hat nur die Ansichten zugemüllt.
Ein ausführliches Schritt-für-Schritt-Vorgehen für den Vertriebsteil steht in CRM ohne Programmierer bauen. Das praktische Vorgehen beim Datenumzug in Migration aus Excel oder Notion. Und wann es überhaupt Zeit ist, Tabellen zu verlassen, steht in Wann eine Tabelle nicht mehr reicht. Den gesamten Weg von der Entscheidung bis zum ersten Betriebsmonat führt der Leitfaden zum Firmensystem nach Maß.
Häufige Fragen zum Start mit einem eigenen System
Schafft das wirklich jemand ohne Technikhintergrund?
Ja, sofern er beschreiben kann, wie seine Firma arbeitet. Das ist der schwierigere Teil - und den nimmt Ihnen niemand ab. Die technische Umsetzung ist heute zweitrangig.
Wie viel Zeit sollte ich einplanen?
Für eine erste brauchbare Version einen Nachmittag. Für eine Version, mit der das Team zufrieden ist, zwei bis drei Wochen normalen Betriebs mit laufendem Nachjustieren.
Was, wenn sich zeigt, dass ich es falsch entworfen habe?
Das passiert fast immer und ist in Ordnung. Felder, Status und Verknüpfungen lassen sich im laufenden Betrieb ändern - anders als bei einer entwickelten App, wo eine Änderung des Datenmodells Entwicklerarbeit ist.