Ein befreundeter Bauunternehmer hat mich vor ein paar Wochen gefragt, ob man „das mit der Kommunikation und der Organisation nicht endlich mal einfacher machen" kann. Kein Kundenprojekt, kein Angebot — ein Gespräch unter Bekannten. Aber es ist die ehrlichste Version einer Frage, die ich in diesem Job ständig höre, und die Antwort darauf hat mich mehr beschäftigt als die meisten bezahlten Analysen.
Denn mein erster Reflex war der falsche.
Ich baue seit Jahren Automatisierungen mit n8n, Make und Zapier. Wenn jemand ein Prozessproblem beschreibt, zerlege ich es automatisch in Auslöser, Schritte und Ergebnis. Bei ihm ging das die ersten zwei Minuten gut — und dann fiel es auseinander. Nicht weil die Tools schlecht sind. Sondern weil er ein Problem beschrieben hat, für das ein Workflow die falsche Bauform ist.
Dieser Artikel handelt von dieser Grenze: wo Automatisierung aufhört, warum sie genau dort aufhört, und was danach kommt — ohne dass daraus ein sechsstelliges Softwareprojekt wird.
Das Gespräch, das diesen Artikel ausgelöst hat
Sein Betrieb: mittelgroß, mehrere Baustellen parallel, ein fester Stamm an Subunternehmern, dazu wechselnde Partien. Was er beschrieben hat, klang so:
- Ausschreibungen und Leistungsverzeichnisse gehen als PDF per E-Mail raus
- Rückmeldungen kommen per E-Mail, per WhatsApp, per Anruf, gelegentlich per Sprachnachricht
- Wer welches Gewerk in welchem Zeitfenster macht, steht in einer Excel — die auf einem Rechner im Büro liegt
- Fotos vom Baufortschritt liegen auf dem Handy des Poliers
- Ein Teil der Partien spricht kein Deutsch. Übersetzt wird mündlich, von dem, der es gerade kann
- Und mehrmals täglich ruft jemand an und fragt nach dem Stand
Sein Satz war: „Ich will einfach, dass jeder weiß, was Sache ist."
Das klingt nach einem Kommunikationsproblem. Es ist ein Zustandsproblem.
Niemand in diesem Betrieb weiß, was Sache ist, weil es keinen Ort gibt, an dem „Sache" steht. Es gibt sechs Halbwahrheiten in sechs Kanälen, und der Abgleich passiert im Kopf von zwei, drei Leuten, die deshalb nie Feierabend haben.
Was Automatisierung wirklich gut kann
Bevor ich zu den Grenzen komme, die faire Seite. Workflow-Automatisierung ist in einem klar umrissenen Bereich konkurrenzlos gut — und billiger als alles andere.
Typische Fälle, die wir genau so bauen:
- Rechnung kommt per Mail rein, wird ausgelesen, geprüft, in die Buchhaltung gebucht
- Formular wird abgeschickt, Lead landet im CRM, Vertrieb bekommt eine Benachrichtigung
- Jeden Montag um sieben liegt der Wochenreport im Postfach der Geschäftsführung
- Ein Auftrag wird bestätigt, drei Systeme werden nachgezogen
Das sind keine kleinen Effekte. In den dokumentierten Beispielen auf dieser Seite hängen an solchen Strecken Stunden pro Tag. Wer diese Fälle noch von Hand macht, sollte nicht über eigene Software nachdenken, sondern über einen Workflow — die Rechnung geht schneller auf und das Risiko ist klein.
Aber es lohnt sich, präzise zu sein, was so ein Workflow eigentlich ist:
Ein Workflow ist eine Leitung. Kein Ort.
Modell Schematische Darstellung — keine gemessenen Kundendaten.
Eine Leitung transportiert etwas von A nach B und ist danach fertig. Sie hält nichts. Sie zeigt nichts. Sie fragt nicht nach. Solange das Problem „etwas muss von A nach B" lautet, ist sie perfekt. Sobald das Problem „wir wissen nicht, wo wir stehen" lautet, ist sie die falsche Bauform — und jeder Versuch, sie trotzdem passend zu machen, erzeugt genau das wackelige Konstrukt, das später niemand mehr anfasst.
Vier Grenzen, an denen jeder Workflow kippt
Diese vier Punkte sind keine Tool-Schwächen. Sie gelten für n8n genauso wie für Make oder Zapier, und sie gelten auch für den selbst geschriebenen Python-Cronjob. Es sind Eigenschaften der Bauform.
1. Ein Workflow hat keine Oberfläche
Der Subunternehmer soll das Arbeitspaket sehen, bestätigen, später den Fortschritt dokumentieren, ein Foto anhängen, eine Rückfrage stellen. Dafür braucht er einen Bildschirm, auf dem etwas steht — mit Zuständen, Historie und Rechten.
Ein Workflow hat keinen Bildschirm. Er hat Trigger. Der übliche Ausweg ist ein Formular-Tool davor und ein Chat-Kanal danach, und schon ist der Prozess auf drei Werkzeuge verteilt, von denen keines den vollständigen Stand kennt.
2. Ein Workflow hat kein Gedächtnis
„Wer hat auf welches Los geboten, welcher Preis galt, wann wurde beauftragt, was ist davon abgenommen?" — das sind Fragen an einen Datenbestand, nicht an eine Leitung.
In der Praxis wird dieses Gedächtnis dann irgendwo hin ausgelagert: Google Sheets, Airtable, Notion. Damit entsteht eine heimliche Datenbank: sie hat keine Rechte, keine Pflichtfelder, keine Historie, keinen Verantwortlichen — und ist trotzdem innerhalb weniger Monate die wichtigste Datei im Unternehmen.
3. Ein Workflow kennt keine Rollen
Der Subunternehmer darf sein eigenes Los sehen. Nicht die Preise der Mitbewerber. Nicht die Kalkulation. Der Polier darf Fortschritt melden, aber keine Aufträge vergeben. Die Buchhaltung sieht Beträge, aber keine Baustellenfotos mit Personen drauf.
Rechte sind kein Feature, das man an einen Flow anflanscht. Sie müssen an den Daten hängen, damit sie halten. Ein Workflow, der brav nur die richtigen Zeilen verschickt, ist genau so lange sicher, bis jemand einen Zweig ergänzt — und das merkt niemand.
4. Sonderfälle wachsen schneller als der Flow
Das ist der Punkt, der Workflows in genau diesen Szenarien „wackelig" macht, wie mein Bekannter es genannt hat.
Version eins ist elegant: Mail rein, PDF auslesen, Nachricht raus. Dann kommt die Realität. Was, wenn der Subunternehmer nur teilweise zusagt? Wenn er einen Alternativpreis nennt? Wenn er per Sprachnachricht antwortet? Wenn der Termin verschoben wird und drei andere Gewerke daran hängen? Wenn jemand kurzfristig ausfällt?
Jeder dieser Fälle wird ein Zweig. Nach einem halben Jahr hat der Flow dreißig Zweige, kein Mensch kennt sie alle, und die Änderung an Zweig sieben bricht Zweig zweiundzwanzig. Bei Fachanwendungen ist das ein bekanntes Problem mit einer bekannten Antwort: Zustände modelliert man, man verzweigt sie nicht.
Modell Schematische Darstellung — keine gemessenen Kundendaten.
Der Test: Leitung oder Ort?
Bevor Sie das nächste Automatisierungsprojekt starten, fünf Fragen. Jedes „ja" spricht für einen Ort statt für eine Leitung.
Modell Schematische Darstellung — keine gemessenen Kundendaten.
Wenn Sie unsicher sind, wo Ihr Fall liegt: Die Engpassdiagnose stellt genau diese Art Fragen und braucht dafür rund fünf Minuten.
Wie das Bau-Beispiel als „Ort" aussieht
Jetzt das Konkrete. So würde ich den Fall meines Bekannten aufbauen — durchgespielt, nicht ausgeliefert:
Modell Schematische Darstellung — keine gemessenen Kundendaten.
1. Ausschreibung anlegen. Bauvorhaben, Lose, Leistungspositionen, Termine, Anhänge. Ein Datensatz mit Zuständen: Entwurf → veröffentlicht → in Bewertung → vergeben. Kein PDF-Versand ins Nichts, sondern ein Objekt, das seinen eigenen Stand kennt.
2. Subunternehmer erhalten Zugang zu ihrem Los. Nicht zur Ausschreibung, nicht zu den Preisen der anderen. Der Zugriff hängt an der Zuordnung, nicht an der Disziplin desjenigen, der die Mail verschickt.
3. Sprache. Die Oberfläche erscheint in der Sprache der Partie — Menüs, Felder, Statusnamen, Hilfetexte. Nicht als nachträgliche Übersetzungsschicht, sondern weil jedes Modul seine Texte als Schlüssel führt und diese Schlüssel gebündelt übersetzt werden. Die Übersetzung der Inhalte (Leistungstexte, Kommentare, Rückfragen) ist der nächste Schritt und ist heute noch nicht drin — dazu unten mehr.
4. Arbeitspaket statt Nachricht. Aus der Vergabe entsteht ein Auftrag mit Positionen, Terminen, Ansprechpartner, Dokumenten. Der Subunternehmer sieht ihn auf dem Handy, ohne einen einzigen Anruf.
5. Dokumentation vor Ort. Fortschritt melden, Foto anhängen, Checkliste abhaken, Zeiten erfassen, Rückfrage stellen. Alles am selben Datensatz, mit Zeitstempel und Urheber. Damit hat auch die Abnahme später eine Grundlage, die nicht aus dem Gedächtnis rekonstruiert werden muss.
6. Rückfluss. Der Bauleiter sieht alle Lose auf einem Bildschirm. Wer hat gemeldet, wo hängt es, was ist abgenommen, was ist offen.
Und genau hier kommt die Automatisierung zurück ins Spiel: Erinnerungen an ausstehende Rückmeldungen, Übergabe an die Buchhaltung, Anbindung an das Kalkulationsprogramm, Wetter- oder Lieferdaten. Das sind Leitungen — und Leitungen brauchen Enden, an die man sie anschließen kann.
Warum daraus kein Softwareprojekt werden muss
An dieser Stelle steigen die meisten Mittelständler aus, und zwar zu Recht. Denn die drei üblichen Wege sind alle schlecht:
| Weg | Was schiefgeht |
|---|---|
| Standard-ERP | Der Betrieb passt sich der Software an, nicht umgekehrt. Einführung dauert Monate, Beratungstage sind der eigentliche Preis. |
| Individualentwicklung | Sechsstellig, neun Monate, danach hängt die Wartung an einer Person oder Agentur. |
| Bastel-Stack | Sheets plus Chat plus Formulare plus Automatisierungen. Billig im Monat eins, unwartbar im Monat zwölf. |
Der vierte Weg, an dem ich seit einer Weile arbeite, sieht anders aus: fertige Fachmodule, die man mietet, zusammensteckt und auf dem eigenen Server betreibt.
Das ist usable.software. Kein KI-generierter App-Baukasten, sondern von Hand gebaute Module — Projekte, Aufgaben, Dokumente, Kontakte, Lieferanten, Checklisten, Zeiterfassung, Chat und weitere — die über gemeinsame Datenobjekte gekoppelt sind. Man wählt aus, was man braucht, und bekommt ein System, das sich wie ein Werkzeug anfühlt und nicht wie ein Formularordner.
Die drei Punkte, auf die es mir dabei ankommt:
- Daten auf dem eigenen Server. Dieselbe Logik wie bei self-hosted n8n. Wer die Kontrolle über den Betriebsort behält, muss über Datenabflüsse nicht diskutieren — bei Baustellenfotos mit Personen darauf ist das kein akademisches Thema.
- Monatliche Gebühr statt Projektbudget. Kein Einführungsprojekt, keine Beratertage, monatlich kündbar, Daten exportierbar.
- Kein Gerede. Ausprobieren, konfigurieren, sehen, was es kostet. Wer reden will, redet mit dem Entwickler, nicht mit dem Vertrieb.
12
Module, zwei Branchen: der aktuell öffentlich sichtbare Stand von usable.software
Quelle usable.software, abgerufen Juli 2026
Was Usable heute ist — und was nicht
Der ehrliche Teil, ohne den der Rest Werbung wäre.
Usable ist noch nicht live. Auf der Seite steht das auch so. Es gibt einen Konfigurator, es gibt Module, es gibt eine Roadmap — was es noch nicht gibt, ist ein Selbstbedienungs-Start. Wir suchen aktuell Pilotbetriebe, nicht Kunden im klassischen Sinn.
Bau ist keine der fertigen Branchen. Öffentlich stehen zwei: Logistik und Handel. Das Szenario oben würde aus geteilten Modulen gebaut, die es gibt — nicht aus einem fertigen Bau-Paket, das es nicht gibt. Wer heute ein zertifiziertes Bau-ERP mit GAEB-Import und Aufmaß nach VOB sucht, ist bei einem Fachanbieter besser aufgehoben, und das sage ich lieber jetzt als nach der ersten Rechnung.
Die Übersetzung ist gestaffelt. Die Oberfläche wird über eine Schlüssel-Pipeline in viele Sprachen übersetzt; der Rollout über alle Module läuft noch. Automatische Übersetzung der eingegebenen Inhalte ist der geplante nächste Schritt, nicht der heutige Stand.
Es ersetzt kein n8n. Und das ist kein Nachteil.
Was ich meinem Bekannten geantwortet habe
Nicht „das automatisieren wir". Sondern: „Du hast kein Automatisierungsproblem. Du hast keinen Ort."
Der Unterschied ist nicht akademisch. Hätte ich ihm einen Flow gebaut, hätte der drei Monate funktioniert, wäre dann an den Sonderfällen erstickt, und er hätte das gelernt, was viele Mittelständler an dieser Stelle lernen: dass Digitalisierung teuer ist und wenig bringt. Dabei war nur die Bauform falsch.
Wenn Sie an derselben Stelle stehen — mehrere Kanäle, eine unersetzliche Excel, täglich jemand, der nach dem Stand fragt — dann sind das keine losen Enden, die man wegautomatisiert. Das ist ein System, das noch nicht existiert.
Nächste Schritte, je nachdem wo Sie stehen:
- Sie haben klare Strecken zwischen Systemen: n8n vs. Make im Vergleich und die Fünf-Schritte-Methode
- Sie sind Handwerks- oder Baubetrieb und wollen erst mal aufräumen: Automatisierung für Handwerksbetriebe
- Sie wissen nicht, welches der beiden Probleme Sie haben: Engpassdiagnose in fünf Minuten
- Sie erkennen sich im Bau-Beispiel wieder und wollen Pilotbetrieb werden: usable.software
Häufige Fragen
Woran erkenne ich, dass ein Workflow an seine Grenze kommt?
An drei Symptomen: die Zahl der Sonderfall-Zweige wächst schneller als der Nutzen, es gibt eine Tabelle daneben, die den eigentlichen Zustand hält, und Menschen fragen weiterhin telefonisch nach dem Stand. Sobald zwei davon zutreffen, fehlt eine Anwendung, nicht ein weiterer Automatisierungsschritt.
Kann n8n nicht auch Oberflächen bauen?
Es gibt Formulare und einfache Eingabemasken, und für einen Freigabeklick reicht das. Was fehlt, ist alles, was eine Fachanwendung ausmacht: Listen mit Filtern, Detailansichten, Historie, Rollen und Rechte auf Datenebene, Offline-Nutzung auf dem Handy. Diese Dinge nachzubauen kostet mehr als sie zu mieten.
Ist das nicht einfach ein ERP mit anderem Namen?
Der Unterschied liegt in Einführung und Bindung. Ein klassisches ERP kommt mit Einführungsprojekt, Beratertagen und Jahresvertrag. Der Ansatz hier ist: Module auswählen, auf eigenem Server betreiben, monatlich zahlen, monatlich kündigen, Daten jederzeit exportieren.
Was passiert mit meinen bestehenden Automatisierungen?
Die bleiben. Sie bekommen sogar bessere Anschlusspunkte, weil sie auf saubere Datenobjekte zugreifen statt auf eine Tabelle, deren Spaltenreihenfolge sich jederzeit ändern kann.
Wo liegen die Daten?
Auf einem Server, den Sie bestimmen. Das ist dieselbe Überlegung wie bei self-hosted n8n und bei personenbezogenen Daten auf Baustellenfotos der entscheidende Punkt.