Prozessautomatisierung: der Praxisleitfaden für Gründer und CTOs

Prozessautomatisierung bedeutet, eine Abfolge wiederkehrender manueller Schritte durch Software zu ersetzen, die sie jedes Mal gleich ausführt. Das ist weiter gefasst, als es klingt. Ein Salesforce Flow, der einen neuen Lead zuweist, ist Automatisierung. Ein Python-Skript, das Rechnungen über eine API abruft und gegen Ihr Ledger abgleicht, ist Automatisierung. Eine Terraform-Pipeline, die bei jedem Merge Infrastruktur bereitstellt, ist Automatisierung. Der gemeinsame Nenner ist ein definierter Auslöser, ein definierter Satz von Aktionen und ein vorhersehbares Ergebnis, das Sie nicht mehr beaufsichtigen müssen.

Es hilft, klar zu sein, was Automatisierung nicht ist. Sie ist nicht dasselbe wie das Bauen einer Produktfunktion, auch wenn sich beides oft überschneidet. Sie ist kein Ersatz dafür, einen kaputten Prozess zu reparieren: Wenn Ihr Quote-to-Cash-Ablauf chaotisch ist, weil niemand sich einig ist, wer Rabatte genehmigt, macht Automatisierung das Chaos nur schneller. Und sie ist ausdrücklich keine einmalige Sache. Jede Automatisierung, die Sie ausrollen, wird zu einem kleinen System, das Sie besitzen, mit Abhängigkeiten, Fehlerquellen und laufenden Kosten. Genau diesen letzten Punkt unterschätzen Gründer am meisten.

Das nützliche Denkmodell ist ein Spektrum. An einem Ende stehen deterministische, regelbasierte Automatisierungen: Wenn X passiert, tue Y. Diese sind günstig, zuverlässig und im besten Sinne langweilig. Am anderen Ende stehen urteilsintensive Aufgaben, bei denen die Regeln unscharf sind oder die Eingaben aus unstrukturiertem Text, Bildern oder Freiform-Dokumenten bestehen. Solche Aufgaben widersetzten sich lange jeder Automatisierung, und genau hier verändern große Sprachmodelle heute die Rechnung. Die meisten realen Automatisierungen liegen irgendwo dazwischen, und die Kunst besteht darin, vor der ersten Codezeile zu wissen, welche Teile eines Prozesses zu welchem Ende des Spektrums gehören.

Gute Automatisierungskandidaten haben ein gemeinsames Profil: hohe Häufigkeit, klare Regeln, strukturierte Eingaben und echte Kosten, wenn sie von Hand erledigt werden. Beginnen Sie damit, aufzulisten, wo Ihr Team tatsächlich wiederholt Zeit verbringt. Am schnellsten fördern Sie diese Stellen zutage, indem Sie in allen Abteilungen drei Fragen stellen. Welche Aufgaben erledigen Menschen mehrmals pro Woche? Welche Aufgaben folgen jedes Mal denselben Schritten? Und welche Aufgaben verursachen, wenn jemand sie vergisst, eine Kundenbeschwerde, eine verpasste Verlängerung oder eine Compliance-Lücke?

Die Antworten häufen sich an vorhersehbaren Stellen. Lead-Routing und das Anlegen von Follow-ups. Rechnungs- und Zahlungsabgleich. Onboarding-Checklisten, die beim Abschluss eines Deals auslösen. Dateneingabe, die denselben Datensatz von einem System in ein anderes kopiert. Reporting, das jemand jeden Montag von Hand zusammenstellt. Dokumentenerstellung, bei der eine Vorlage aus strukturierten Daten befüllt wird. Das sind die unspektakulären, hochvolumigen Abläufe, bei denen sich Automatisierung am schnellsten auszahlt, und meist will sie ohnehin niemand manuell verantworten.

Seien Sie ebenso bewusst darin, was Sie in Ruhe lassen. Ein Prozess, der zweimal im Jahr läuft, oder einer, bei dem sich die Regeln mit jedem Fall ändern, ist ein schlechter Kandidat. Der Engineering-Aufwand, alle Ausnahmen abzubilden, kann ein Jahrzehnt manueller Arbeit übersteigen. Eine Faustregel, die wir nutzen: Wenn Sie die Entscheidungslogik nicht als Flussdiagramm aufschreiben können, dem ein neuer Mitarbeiter folgen könnte, ist der Prozess noch nicht reif für Automatisierung. Automatisieren Sie ihn zuerst im Kopf, auf Papier, und greifen Sie erst zum Code, wenn die Schritte stabil sind. Die verfrühte Automatisierung eines instabilen Prozesses ist einer der teuersten Fehler, die wir sehen, denn Sie zahlen doppelt: einmal für den Bau und erneut für den Umbau, wenn sich der Prozess verschiebt.

Sobald Sie eine Liste von Kandidaten haben, widerstehen Sie dem Drang, den technisch interessantesten zuerst zu bauen. Priorisieren Sie nach Ertrag. Die Rechnung muss nicht exakt sein, um nützlich zu sein. Schätzen Sie die Stunden, die eine Aufgabe pro Monat verschlingt, multiplizieren Sie mit einem vollen Stundensatz und stellen Sie das den Kosten für Bau und Wartung der Automatisierung gegenüber. Rechnen Sie dann die schwerer quantifizierbaren Faktoren hinzu: weniger Fehler, schnellere Reaktionszeiten und die Kosten dafür, dass die Aufgabe schlicht liegen bleibt, wenn jemand im Urlaub ist.

Eine einfache Art zu ranken ist eine Zwei-Achsen-Sicht: gelieferter Wert gegen Aufwand zum Bauen. Der Quadrant oben links, hoher Wert und geringer Aufwand, ist Ihr Startpunkt. Ein Salesforce Flow, der Leads zuweist und in Slack postet, kostet vielleicht einen Tag Bau und spart für immer Stunden pro Woche. Der geht zuerst live. Die Arbeit mit hohem Wert und hohem Aufwand, etwa eine individuelle Integration zwischen Ihrem ERP und Ihrem CRM, kommt mit einem echten Budget auf die Roadmap. Arbeit mit geringem Wert wird zurückgestellt, egal wie einfach sie aussieht, denn jede Automatisierung verursacht laufende Kosten.

Seien Sie bei diesen laufenden Kosten ehrlich, denn hier scheitert naive ROI-Mathematik. Eine Automatisierung, die eine externe API berührt, bricht, wenn sich diese API ändert. Eine, die ein Dokument parst, versagt, wenn sich das Dokumentformat verschiebt. Planen Sie Wartung von Tag eins an ein und lassen Sie die Stabilität des Anbieters in Ihre Make-or-Buy-Entscheidung einfließen. Zur Einordnung: Ein fokussiertes Automatisierungsprojekt liegt deutlich unter der Spanne eines vollständigen Custom-MVP, das wir für einen einfachen Bau mit rund 25.000 bis 40.000 EUR ansetzen. Viele wertvolle Automatisierungen kosten einen Bruchteil davon, und genau deshalb bringt es den besten Ertrag für Ihr Budget, die schnellen, langlebigen Erfolge zuerst umzusetzen.

Wenn Ihr Prozess in Salesforce liegt, bietet die Plattform drei Hauptwerkzeuge, und die richtige Wahl ist wichtiger, als die meisten Teams glauben. Flows sind die deklarative No-Code-First-Option. Sie decken den Großteil der Geschäftsautomatisierung gut ab: datensatzgetriggerte Logik, bildschirmbasierte geführte Prozesse, geplante Batch-Aktionen und mehrstufige Orchestrierung. Unser Standardrat lautet, zuerst zum Flow zu greifen. Er ist von einem Admin pflegbar, in der Oberfläche sichtbar und erfordert keinen Entwickler, um eine Geschäftsregel sechs Monate später zu ändern.

Apex, die Programmiersprache von Salesforce, ist der Ort, an den Sie gehen, wenn Flows an ihre Grenzen stoßen. Das passiert bei wirklich komplexer Logik, Massenoperationen über große Datenmengen, Callouts an externe Systeme mit sorgfältiger Fehlerbehandlung oder allem, was eine Transaktionskontrolle erfordert, die die deklarativen Werkzeuge nicht sauber ausdrücken können. Apex ist mächtig, aber es ist Code: Er braucht Tests, einen Deployment-Prozess und jemanden, der ihn pflegen kann. Der Fehler, den wir sehen, ist, dass Teams für Dinge zu Apex springen, die ein Flow erledigt, und sich so eine Wartungslast schaffen, die sie nicht gebraucht hätten. Der umgekehrte Fehler, einen Flow zu dem zu zwingen, was klar nach Apex verlangt, erzeugt unwartbaren Spaghetti-Code mit Dutzenden Entscheidungselementen.

Lightning Web Components (LWC) kommen ins Spiel, wenn die Automatisierung eine individuelle Benutzeroberfläche braucht: eine geführte Dateneingabe, ein maßgeschneidertes Dashboard oder ein interaktives Tool, eingebettet in eine Datensatzseite. LWC ist Frontend-Engineering innerhalb von Salesforce, gebaut mit modernem JavaScript. Eine gesunde Salesforce-Automatisierungsstrategie schichtet meist alle drei: Flows für den Großteil der Orchestrierung, Apex für die schwere oder integrationskritische Logik und LWC dort, wo Nutzer eine Oberfläche brauchen, die die Standardplattform nicht bieten kann. Das Governance-Prinzip, das dies vor dem Verfall bewahrt, ist einfach: Halten Sie Geschäftsregeln dort, wo ein Admin sie finden und ändern kann, und reservieren Sie Code für die Dinge, die ihn wirklich erfordern.

Die meisten Automatisierungen überschreiten irgendwann eine Systemgrenze, und genau an dieser Grenze entstehen brüchige Automatisierungen. Die zentralen Muster sind es wert, benannt zu werden. Synchrone API-Aufrufe sind die einfachste Variante: System A ruft System B auf und wartet auf eine Antwort. Sie sind leicht zu durchschauen, koppeln die beiden Systeme aber eng, sodass A stockt, wenn B langsam oder ausgefallen ist. Event-getriebene oder Webhook-Muster kehren das um: System B teilt System A mit, wenn etwas passiert, was sie entkoppelt und besser skaliert, um den Preis von mehr beweglichen Teilen. Batch-Pipelines verarbeiten Daten nach Zeitplan, was für Reporting und Abgleich passt, wo Nahezu-Echtzeit nicht nötig ist.

Das Engineering, das eine robuste Integration von einer fragilen trennt, steckt vollständig in der Fehlerbehandlung. Reale Systeme liefern Fehler, drosseln Sie per Rate-Limit, laufen in Timeouts und senden gelegentlich dieselbe Nachricht zweimal. Eine Integration, die nur den Happy Path annimmt, korrumpiert am ersten schlechten Tag Daten. Die Pflichtbausteine, die wir einbauen: Retries mit Backoff für vorübergehende Fehler, Idempotenz, damit eine wiederholte Nachricht keinen Kunden doppelt belastet oder einen Datensatz dupliziert, Dead-Letter-Handling, damit fehlgeschlagene Vorgänge sichtbar werden statt zu verschwinden, und Logging, das Sie tatsächlich durchsuchen können, wenn nachts um zwei etwas schiefgeht. Das ist unspektakulär und macht den ganzen Unterschied zwischen einer Automatisierung, der Sie vertrauen, und einer, die Sie trotzdem von Hand prüfen müssen.

Datenpipelines verdienen dieselbe Sorgfalt. Daten zwischen PostgreSQL, einem CRM und einem Analytics-Store zu bewegen klingt nach Klempnerarbeit, aber Schema-Drift, unvollständige Ladevorgänge und stille Typkonflikte vergiften leise nachgelagerte Entscheidungen. Validieren Sie Daten an der Grenze, scheitern Sie laut, statt Zeilen still zu verwerfen, und überwachen Sie die Pipeline als vollwertiges System mit Prometheus und Grafana oder Vergleichbarem. Der Stack, zu dem wir greifen, TypeScript oder Python mit Docker und einer ordentlichen CI/CD-Pipeline, existiert genau deshalb, damit Integrationen testbar und reproduzierbar sind und nicht ein Skript auf dem Laptop von jemandem, das nur diese Person versteht.

Die letzten Jahre haben eine wirklich neue Fähigkeit hinzugefügt: das Automatisieren von Aufgaben, die das Lesen unstrukturierter Eingaben und ein Urteil erfordern. Das ist real und verändert, was sich automatisieren lässt. Aber die Versuchung, ein großes Sprachmodell in jeden Workflow zu setzen, ist eine Falle, und die beiden Fälle auseinanderzuhalten ist heute eine zentrale Engineering-Entscheidung. Die ehrliche Heuristik lautet so: Wenn die Aufgabe klare Regeln und strukturierte Eingaben hat, nutzen Sie klare Regeln. Sie sind günstiger, schneller, vollständig deterministisch und halluzinieren nie. Eine Lead-Routing-Regel auf Basis von Land und Unternehmensgröße sollte niemals ein LLM einbeziehen.

KI verdient ihren Platz dort, wo die Eingabe unordentlich ist und menschliches Urteil bislang zwingend war. Freitext-Support-Tickets nach Absicht klassifizieren. Felder aus PDFs und E-Mails extrahieren, die in hundert verschiedenen Formaten eintreffen. Ein langes Dokument in einen strukturierten Datensatz zusammenfassen. Eine erste Antwort entwerfen, die ein Mensch prüft. Das war zuvor nicht zuverlässig automatisierbar, und Modelle von OpenAI, Anthropic oder eine Open-Source-Option auf Ollama machen es nun handhabbar, oft über eine RAG-Pipeline, die das Modell in Ihren eigenen Daten verankert. Für EU-Unternehmen kommen hier auch der EU AI Act und die DSGVO ins Spiel, weshalb wir standardmäßig auf Hosting-Optionen in EU-Regionen und offene Modelle setzen, wo die Datensensibilität es verlangt.

Das Muster, das funktioniert, ist ein Hybrid: Nutzen Sie deterministische Regeln für die deterministischen Teile und reservieren Sie das Modell für genau den Schritt, der ein Urteil braucht, stets mit einer Validierungsschicht und, bei allem Folgenreichen, einem Menschen im Ablauf. Lassen Sie niemals die Rohausgabe eines LLM ungeprüft eine irreversible Aktion auslösen. Behandeln Sie es als sehr fähigen, aber gelegentlich irrenden Assistenten, umgeben Sie seine Ausgabe mit derselben Fehlerbehandlung, die Sie jedem unzuverlässigen externen Dienst geben würden, und Sie erhalten den Nutzen von KI, ohne Ihre Datenintegrität einem probabilistischen System anzuvertrauen. Die Prozesse, die brechen, sind fast immer die, die dem Modell zu früh zu sehr vertraut haben.