Geschäftsprozesse automatisieren: Der Leitfaden für KMU

Warum dieses Thema gerade in KMU auf dem Tisch liegt

Der typische Auslöser ist selten ein Strategiepapier. Es ist die Buchhaltung, die jeden Monat zwei Tage lang Rechnungen abtippt. Der Vertriebsinnendienst, der Bestellungen aus E-Mails ins ERP überträgt. Die Projektleitung, die Zahlen aus drei Systemen in eine Excel-Tabelle kopiert, damit freitags ein Report steht. Einzeln wirken diese Aufgaben klein — zusammen binden sie in vielen Unternehmen spürbar Kapazität von Leuten, die eigentlich für anderes eingestellt wurden.

Dass hier noch viel offen ist, zeigt der Digital Office Index 2024 des Branchenverbands Bitkom: Von 1.103 befragten Unternehmen in Deutschland arbeiten rund 39 Prozent überwiegend papierlos, während 20 Prozent noch stark papierbasierte Prozesse nutzen. Gleichzeitig plant oder nutzt mehr als die Hälfte der Befragten bereits KI-gestützte Lösungen, um Geschäfts- und Verwaltungsprozesse zu automatisieren. Übersetzt: Das Thema ist im Mittelstand angekommen, aber zwischen „wir haben ein digitales Dokumentenarchiv” und „unsere Prozesse laufen durchgängig automatisiert” liegt bei den meisten noch ein weiter Weg.

Dieser Leitfaden richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in kleinen und mittleren Unternehmen. Er beantwortet die fünf Fragen, an denen Automatisierungsvorhaben in der Praxis hängen: Welche Prozesse eignen sich? Wie nimmt man einen Prozess sauber auf? Welche Technik passt? Wie geht man mit Ausnahmen um? Und wie betreibt man das Ganze dauerhaft, ohne dass es zur Altlast wird?

Begriffe kurz sortiert: Was „automatisieren” hier heißt

„Geschäftsprozesse automatisieren” ist ein Sammelbegriff, unter dem sehr unterschiedliche Dinge laufen. Für den Rest des Artikels reichen vier Begriffe:

• Workflow-Automatisierung: Ein digitaler Ablauf mit definiertem Auslöser, festen Schritten und Regeln — „wenn eine Bestellung eingeht, dann lege den Auftrag an, informiere das Lager und sende die Bestätigung”. Das ist der Kern der meisten Automatisierungsprojekte und wird typischerweise über Integrations- und Workflow-Plattformen umgesetzt (z. B. n8n, Make, Power Automate).
• RPA (Robotic Process Automation): Software-Roboter, die Programme so bedienen wie ein Mensch — klicken, tippen, kopieren, auf Bildschirmoberflächen. RPA ist vor allem dann relevant, wenn ein Altsystem keine Schnittstelle hat.
• KI-gestützte Automatisierung: Sprachmodelle oder andere ML-Verfahren übernehmen Schritte, die sich nicht in feste Regeln fassen lassen — E-Mails nach Anliegen sortieren, Daten aus unterschiedlich aufgebauten Dokumenten extrahieren, Texte zusammenfassen oder vorformulieren. Zapier beschreibt den Unterschied treffend: Klassische Automatisierung folgt starren Regeln, KI-Workflows können Inhalte lesen, klassifizieren und interpretieren, wo sich Regeln nur schwer manuell formulieren lassen.
• Process Mining: Die Analyse von Ereignisdaten aus bestehenden Systemen (ERP, CRM, Ticketsystem), um sichtbar zu machen, wie Prozesse tatsächlich ablaufen — inklusive Engpässen und Abweichungen vom Soll. Microsoft beschreibt es als Technologie, die Unternehmen hilft, ihre realen Prozesse zu verstehen und Verbesserungs- und Automatisierungspotenziale zu identifizieren.

Wichtig ist die Abgrenzung nach unten: Ein PDF statt Papier, ein geteilter Ordner statt E-Mail-Anhängen — das ist Digitalisierung, aber noch keine Automatisierung. Automatisiert ist ein Prozess erst, wenn Schritte ohne menschliches Zutun ablaufen. Und die Abgrenzung nach oben: Vollautomatisierung ist selten das richtige Ziel. Die meisten wirtschaftlich sinnvollen Lösungen automatisieren 70 bis 90 Prozent der Fälle und geben den Rest gezielt an Menschen — diese Spanne ist keine Messgröße, sondern eine Design-Entscheidung, zu der ich weiter unten bei den Ausnahmen komme.

Welche Prozesse lassen sich automatisieren?

Die ehrliche Antwort hat zwei Ebenen: technisch geht heute sehr viel — wirtschaftlich sinnvoll ist deutlich weniger. Ob sich ein Prozess eignet, hängt weniger von der Branche ab als von seinen Eigenschaften. Vier Kriterien tragen die Entscheidung:

1. Frequenz: Läuft der Prozess täglich oder wöchentlich in relevanter Stückzahl? Ein Ablauf, der dreimal im Jahr vorkommt, rechnet sich fast nie.
2. Regelhaftigkeit: Lässt sich beschreiben, was in 80 bis 90 Prozent der Fälle passieren soll? Wenn jede Bearbeitung eine individuelle Abwägung ist, automatisierst du nur die Zuarbeit, nicht die Entscheidung.
3. Datenlage: Liegen Ein- und Ausgaben digital vor oder lassen sie sich digital erfassen? Medienbrüche (Papier, Telefon, Zuruf im Flur) sind der häufigste Blocker — und oft der erste sinnvolle Fixpunkt.
4. Fehlertoleranz: Was kostet ein Fehler? Eine falsch einsortierte E-Mail ist billig korrigiert, eine falsch gebuchte Zahlung nicht. Je höher das Schadenspotenzial, desto mehr menschliche Kontrolle gehört in den Prozess.

Typische Kandidaten, die in fast jedem KMU existieren:

Prozessbereich	Typische Beispiele	Charakter
Finanzen & Backoffice	Eingangsrechnungen erfassen und zur Freigabe routen, Mahnwesen, Reisekosten	regelbasiert, hohes Volumen
Vertrieb & Auftrag	Bestellungen aus E-Mail/Portal ins ERP übernehmen, Angebotsdokumente erzeugen, CRM-Pflege	regelbasiert + KI für Eingangsdaten
Kundenservice	Anfragen kategorisieren und zuweisen, Antwortentwürfe für Standardfälle, Statusauskünfte	KI-gestützt, Mensch gibt frei
Datenflüsse zwischen Systemen	Stammdaten synchron halten, Webshop ↔ Warenwirtschaft, Formulare → CRM	API-Integration, „stille” Automatisierung
Reporting	Kennzahlen aus mehreren Quellen zusammenführen, wiederkehrende Berichte erzeugen	regelbasiert, geringe Fehlerkosten
HR-Administration	Onboarding-Abläufe (Konten, Zugänge, Checklisten), Abwesenheitsprozesse	Workflow mit Freigabeschritten

Und die Gegenliste — Prozesse, bei denen ich in Projekten regelmäßig abrate, sie komplett zu automatisieren: alles mit Ermessensspielraum und großer Tragweite (Personalentscheidungen, Preisverhandlungen, Kulanzfälle mit wichtigen Kunden), Prozesse, die sich gerade organisatorisch ändern (du automatisierst sonst den alten Zustand fest), und Prozesse, die niemand vollständig erklären kann. Ein chaotischer Prozess wird durch Automatisierung nicht besser, sondern schneller chaotisch.

Wie beginnt die Prozessaufnahme?

Der häufigste Fehler ist, mit dem Tool zu beginnen statt mit dem Prozess. Die Prozessaufnahme klingt banal, entscheidet aber über Erfolg oder monatelanges Nachbessern — denn automatisiert wird nicht der Prozess, wie er im Kopf der Führungskraft existiert, sondern der, der tatsächlich abläuft. Die beiden unterscheiden sich fast immer.

Mein Vorgehen in Kundenprojekten:

1. Zeigen lassen, nicht erzählen lassen. Setz dich neben die Person, die den Prozess ausführt, und lass ihn dir am Bildschirm zeigen — einen echten Fall, nicht ein Idealbeispiel. Die entscheidenden Details („da schaue ich kurz in der alten Excel nach, ob der Kunde Sonderkonditionen hat”) tauchen in keiner mündlichen Beschreibung auf.
2. Mehrere Fälle anschauen, auch die hässlichen. Ein Fall zeigt den Happy Path. Erst der fünfte oder zehnte zeigt die Varianten: der Lieferant, der Rechnungen als Foto schickt; die Bestellung mit fehlender Kundennummer. Frag gezielt: „Wann ist das zuletzt schiefgegangen, und was hast du dann gemacht?”
3. Den Prozess in einem Steckbrief festhalten. Keine 30-seitige BPMN-Dokumentation — eine Seite reicht für die Entscheidung, ob und wie automatisiert wird.

Der Prozess-Steckbrief, den ich dafür verwende:

Feld	Leitfrage
Auslöser	Was startet den Prozess (E-Mail, Formular, Termin, Systemereignis)?
Eingaben	Welche Daten/Dokumente kommen rein, in welchem Format, in welcher Qualität?
Schritte	Welche Arbeitsschritte folgen, in welchen Systemen?
Entscheidungspunkte	Wo wird entschieden — nach welcher Regel, und wer entscheidet heute?
Ausnahmen	Welche Sonderfälle gibt es, wie oft, und was passiert dann?
Ergebnis	Was ist das Ergebnis, wer bekommt es, woran erkennt man „fertig und korrekt”?
Volumen & Aufwand	Wie oft läuft der Prozess, wie lange dauert ein Durchlauf heute (geschätzt reicht)?
Fehlerkosten	Was passiert, wenn das Ergebnis falsch ist — wer merkt es, wann, was kostet es?

Wenn Prozesse über viele Personen und Systeme laufen und niemand den Gesamtablauf überblickt, kann Process Mining die Aufnahme ergänzen: Es rekonstruiert aus den Ereignisdaten der Systeme, welche Pfade Vorgänge tatsächlich nehmen, und macht Engpässe und Abweichungen sichtbar. Für die meisten KMU-Prozesse ist das allerdings Overkill — Interviews plus Steckbrief liefern in ein bis zwei Tagen genug Klarheit, um zu entscheiden. Process Mining lohnt sich dort, wo Volumen hoch ist und die Datenlage in den Systemen gut.

Ein Nebeneffekt, den ich nicht verschweigen will: Ein erheblicher Teil des Nutzens entsteht schon bei der Aufnahme. Regelmäßig stellt sich heraus, dass drei Schritte niemand mehr braucht, dass zwei Abteilungen dasselbe doppelt prüfen oder dass ein Formularfeld die Hälfte der Rückfragen verursacht. Erst vereinfachen, dann automatisieren — in dieser Reihenfolge.

Welche Technik passt?

Nach der Aufnahme steht die Technikfrage — und hier lohnt Nüchternheit, weil jede Option ihren Preis hat. Die vier Grundbausteine:

API-Integration verbindet Systeme über ihre offiziellen Schnittstellen. Das ist die stabilste und wartungsärmste Variante: Schnittstellen sind dokumentiert, versioniert und ändern sich selten unangekündigt. Wenn beide Systeme APIs haben, gibt es selten einen guten Grund für etwas anderes.

Workflow-Plattformen (n8n, Make, Zapier, Power Automate) orchestrieren solche Integrationen: Sie verbinden Auslöser, Regeln und Aktionen über viele Systeme hinweg, ohne dass du jede Verbindung selbst programmieren musst. Für KMU sind sie meist das Rückgrat der Automatisierung. Worauf du bei der Auswahl achten solltest: Datenverarbeitung und Hosting (bei personenbezogenen Daten relevant — n8n lässt sich z. B. selbst hosten), Preismodell bei wachsendem Volumen und ob die eigenen Kernsysteme angebunden werden können.

RPA simuliert Menschen an der Oberfläche. Das funktioniert — ist aber fragil: Ändert sich die Maske des Altsystems, bricht der Roboter. Ich setze RPA nur ein, wenn es wirklich keine Schnittstelle gibt, und behandle es als Übergangslösung mit Ablaufdatum, nicht als Zielarchitektur.

KI-Bausteine (in der Regel Sprachmodelle per API) übernehmen die Schritte, an denen regelbasierte Automatisierung scheitert: unstrukturierte Eingaben verstehen, klassifizieren, extrahieren, formulieren. Der Preis: Die Ausgaben sind nicht deterministisch. Ein KI-Schritt kann sich irren, und zwar überzeugend. Deshalb gehören KI-Bausteine in Workflows immer mit Validierung (lassen sich extrahierte Werte gegen Stammdaten prüfen?) oder menschlicher Freigabe kombiniert, sobald Fehler etwas kosten.

Meine Entscheidungsmatrix für die Zuordnung — sie ersetzt keine Einzelfallprüfung, sortiert aber die allermeisten Fälle vor:

Situation im Prozess	Erste Wahl	Warum	Wovon ich abrate
Beide Systeme haben APIs, Regeln sind klar	API-Integration / Workflow-Plattform	stabil, wartungsarm, gut testbar	RPA (unnötig fragil)
Altsystem ohne Schnittstelle	RPA als Brücke	einzige Option ohne Systemwechsel	RPA als Dauerlösung ohne Exit-Plan
Eingaben unstrukturiert (E-Mails, PDFs, Freitext)	KI-Extraktion + Validierung im Workflow	Regeln lassen sich nicht formulieren	reine Regex-/Vorlagenlösung (bricht bei jeder Variante)
Entscheidung mit Ermessen oder hoher Tragweite	Workflow bereitet vor, Mensch entscheidet	Verantwortung bleibt zuordenbar	Vollautomatisierung
Einmalige Datenmigration	Skript, kein Dauerbetrieb	Wartung lohnt nicht	Workflow-Plattform dafür aufsetzen
Prozess ändert sich gerade organisatorisch	erst stabilisieren, dann automatisieren	sonst wird der alte Zustand zementiert	jetzt Technik auswählen

In der Praxis sind die meisten Lösungen hybrid: Eine Workflow-Plattform orchestriert, APIs bewegen die Daten, ein KI-Schritt interpretiert den unstrukturierten Eingang, und an definierten Punkten prüft ein Mensch. Die Frage ist nie „RPA oder KI?”, sondern: Welcher Baustein übernimmt welchen Schritt.

Noch ein Wort zur Make-or-Buy-Frage: Für Standardprozesse (Belegverarbeitung, Standard-Integrationen zwischen verbreiteten Systemen) gibt es oft fertige Lösungen oder Vorlagen — die sind schneller und günstiger als Eigenbau. Individuell bauen lohnt sich dort, wo der Prozess spezifisch für dein Geschäft ist und du die Kontrolle über Daten und Logik behalten willst.

Wie behandelt man Ausnahmen?

Das ist die Frage, die über die Alltagstauglichkeit entscheidet — und die in Tool-Marketing am konsequentesten ignoriert wird. Jeder reale Prozess hat Ausnahmen: die Rechnung ohne Bestellnummer, den Kunden, der zwei Anliegen in eine E-Mail packt, das System, das nachts nicht erreichbar ist. Ein Automatisierungsdesign ist erst fertig, wenn es auf drei Fragen eine Antwort hat:

1. Was darf der Workflow allein entscheiden? Zieh die Grenze explizit und konservativ. Bewährt hat sich eine einfache Dreiteilung: Fälle, die alle Prüfregeln sauber bestehen, laufen durch. Fälle mit erkennbaren Unstimmigkeiten (Beträge passen nicht zusammen, Pflichtangabe fehlt, KI-Extraktion widerspricht Stammdaten) gehen in eine Prüf-Queue. Alles, was der Workflow nicht eindeutig zuordnen kann, geht ebenfalls an Menschen — im Zweifel lieber eine Weiterleitung zu viel. Diese Grenze ist keine technische Konstante, sondern eine Risikoabwägung, die Fachbereich und Geschäftsführung treffen sollten, nicht der Dienstleister allein.

2. Wie kommt der Fall zum Menschen — und mit welchem Kontext? Eine Ausnahme, die als kryptische Fehlermeldung in einem Log landet, ist verloren. Gut gelöst heißt: Der Fall erscheint dort, wo das Team ohnehin arbeitet (Ticketsystem, geteiltes Postfach, Chat-Kanal), mit allem, was der Workflow schon weiß — Originaleingang, extrahierte Daten, und woran genau die automatische Verarbeitung gescheitert ist. Dann dauert die menschliche Prüfung Sekunden statt Minuten, und die Automatisierung lohnt sich auch für die Fälle, die sie nicht selbst abschließt.

3. Was passiert bei technischen Fehlern? Systeme sind zeitweise nicht erreichbar, APIs liefern Fehler, Formate ändern sich. Der Workflow braucht definiertes Verhalten dafür: Wiederholungsversuche mit Wartezeit bei vorübergehenden Fehlern, einen Abbruch mit Benachrichtigung bei dauerhaften — und er muss so gebaut sein, dass ein wiederholter Durchlauf keine Dubletten erzeugt (keine doppelte Auftragsanlage, keine doppelte E-Mail an den Kunden). Das gefährlichste Verhalten ist das stille Scheitern: Der Workflow bricht ab, niemand merkt es, und drei Wochen später fällt auf, dass Bestellungen fehlen.

Bei KI-Schritten kommt eine Besonderheit dazu: Sie scheitern nicht laut, sondern leise — mit einer plausiblen, aber falschen Ausgabe. Deshalb prüfe ich KI-Ausgaben, wo immer möglich, gegen harte Referenzen (existiert die Kundennummer? liegt der Betrag im erwartbaren Rahmen?) und lasse in der Anfangsphase einen höheren Anteil der Fälle von Menschen gegenzeichnen, bis das Vertrauen datenbasiert ist statt gefühlt.

Wie organisiert man den Betrieb?

Die unbequeme Wahrheit: Mit dem Go-live ist ein Automatisierungsprojekt nicht fertig, sondern im Regelbetrieb angekommen — und der braucht Struktur. Automatisierungen, die niemandem gehören, verrotten. Vier Dinge haben sich als Minimum bewährt:

Ownership. Jede Automatisierung hat eine namentlich benannte verantwortliche Person — im Fachbereich, nicht nur in der IT. Diese Person kennt den fachlichen Prozess, merkt als Erste, wenn Ergebnisse driften, und entscheidet über Änderungen. Die IT (oder der externe Partner) verantwortet die technische Seite. Ohne diese Rollenteilung landet jede Störung als diffuses „das Ding geht nicht” irgendwo.

Monitoring. Du willst von Fehlern erfahren, bevor es der Kunde tut. Minimal: Jeder fehlgeschlagene Durchlauf erzeugt eine Benachrichtigung an eine Adresse, die tatsächlich gelesen wird. Besser: ein einfaches Dashboard mit Durchläufen, Fehlerrate und Anteil der manuell nachbearbeiteten Fälle. Gerade der letzte Wert ist der ehrlichste Frühindikator — steigt er, hat sich am Prozess oder an den Eingangsdaten etwas geändert.

Dokumentation und Wartbarkeit. Eine Seite pro Workflow reicht: Was macht er, welche Systeme berührt er, wo liegen Zugangsdaten, was tun bei Störung, wer ist verantwortlich. Entscheidend ist, dass sie existiert, bevor die Person, die alles im Kopf hat, in den Urlaub fährt. Dazu gehört auch: Zugangsdaten gehören in eine zentrale Verwaltung, nicht in den Workflow eines einzelnen Mitarbeiter-Accounts — sonst stirbt die Automatisierung mit dem Offboarding.

Änderungsroutine. Prozesse, Systeme und Schnittstellen ändern sich — die Automatisierung muss mitziehen. Praktikabel ist ein kurzer monatlicher Review (15 bis 30 Minuten pro Workflow-Portfolio, nicht pro Workflow): Fehlerraten anschauen, manuell nachbearbeitete Fälle durchgehen, anstehende Systemänderungen abklopfen. Änderungen am Workflow werden erst in einer Testumgebung oder an Testfällen geprüft, bevor sie live gehen — das klingt selbstverständlich, wird aber bei „nur schnell eine Regel anpassen” am häufigsten übersprungen.

Zum Betrieb gehört auch die Team-Seite: Die Leute, deren Handgriffe wegfallen, müssen die neuen Abläufe verstehen und den Prüf-Queues vertrauen. Kurze interne Schulungen zum Umgang mit den Workflows und ihren Grenzen zahlen sich hier schneller aus als jedes zusätzliche Feature.

Umsetzung: In vier Etappen zum laufenden Prozess

Wie die Etappen zusammenhängen, in einer Übersicht:

Etappe	Kernfrage	Ergebnis	Typische Dauer*
1. Auswahl & Aufnahme	Welcher Prozess zuerst, und wie läuft er wirklich?	Prozess-Steckbrief, Entscheidung go/no-go	1–2 Wochen
2. Design	Welche Schritte übernimmt Technik, wo bleibt der Mensch?	Soll-Ablauf inkl. Ausnahme- und Fehlerpfaden	1–2 Wochen
3. Pilot	Funktioniert es mit echten Fällen?	Workflow im Parallel- oder Teilbetrieb, Messwerte	2–6 Wochen
4. Betrieb & Ausbau	Trägt es dauerhaft — und was kommt als Nächstes?	Monitoring, Ownership, priorisierte nächste Prozesse	laufend

*Bandbreiten aus meiner Projekterfahrung für einen einzelnen, mittelkomplexen KMU-Prozess (2–4 beteiligte Systeme, ein Fachbereich); Annahmen: Ansprechpartner sind verfügbar, Systemzugänge existieren, keine Beschaffung neuer Kernsysteme. Sonderfälle nach oben offen.

Drei Prinzipien machen den Unterschied zwischen Projekten, die tragen, und solchen, die versanden:

Klein anfangen, aber echt. Der erste Prozess sollte klein genug sein, um in Wochen live zu gehen, und wichtig genug, dass jemand den Unterschied spürt. Ein Pilot, dessen Ergebnis niemand nutzt, beweist nichts.

Parallel fahren, dann umschalten. In der Pilotphase läuft die Automatisierung neben dem manuellen Prozess: Sie produziert Ergebnisse, ein Mensch vergleicht. Das kostet vorübergehend doppelte Arbeit, liefert aber den Beleg, ab wann man umschalten kann — datenbasiert statt aus Bauchgefühl.

Messen, was vorher war. Halte vor dem Start fest, wie lange der Prozess manuell dauert und wie oft Fehler passieren (eine ehrliche Schätzung des Teams reicht). Ohne Baseline kannst du hinterher nicht sagen, ob sich das Projekt gelohnt hat — und die nächste Investitionsentscheidung wird wieder ein Glaubenskrieg.

Zu den Kosten bewusst keine Pauschalzahl, weil sie von Prozess, Systemlandschaft und Eigenanteil abhängt — nur so viel: Die laufenden Kosten (Plattform-Lizenzen bzw. Hosting, ggf. KI-API-Nutzung, vor allem aber Pflegeaufwand) werden systematisch unterschätzt, die einmaligen Baukosten eher überschätzt. Rechne bei der Wirtschaftlichkeitsbetrachtung beides über mindestens zwei bis drei Jahre, und rechne den internen Aufwand für Prozessaufnahme und Testen ehrlich mit ein. Misstraue jedem Angebot, das dir konkrete Einsparquoten verspricht, bevor jemand deine Prozesse gesehen hat.

Risiken und Grenzen

Ein paar Punkte, die in Erfolgsgeschichten selten vorkommen, in Projekten aber regelmäßig:

• Automatisierung konserviert. Was du automatisierst, schreibst du fest. Ein schlechter Prozess wird schneller, nicht besser. Deshalb: erst vereinfachen, dann automatisieren.
• Wartung ist keine Option, sondern Teil des Preises. Jeder Workflow ist ein kleines Softwaresystem mit Abhängigkeiten zu Diensten, die sich ändern. Wer nur das Bauen budgetiert, hat in einem Jahr eine Sammlung halb funktionierender Automatisierungen.
• Schatten-Automatisierung. Wenn Fachbereiche unkoordiniert eigene Workflows bauen, entstehen Abläufe, die niemand überblickt — mit Zugangsdaten in persönlichen Accounts. Besser früh einen leichtgewichtigen Rahmen schaffen (wo wird gebaut, wer weiß davon, wo liegen Credentials) als später aufräumen.
• Datenschutz und Compliance mitdenken. Sobald personenbezogene Daten durch Workflows und ggf. KI-Dienste laufen, brauchst du Klarheit über Datenflüsse, Auftragsverarbeitung und Speicherorte — das beeinflusst die Tool-Wahl (Stichwort Self-Hosting) und gehört in die Design-Etappe, nicht in die Nachbesserung. Das ist keine Rechtsberatung; im Zweifel gehört der Datenschutzbeauftragte früh an den Tisch.
• Akzeptanz entscheidet mit. Menschen, deren Arbeit sich verändert, müssen früh einbezogen werden — nicht aus Höflichkeit, sondern weil sie die Ausnahmen kennen, an denen jede Automatisierung sonst scheitert. Die beste Prozessaufnahme bekommt man von Leuten, die das Projekt nicht als Bedrohung erleben.
• KI ist kein Pflichtbaustein. Ein erstaunlich großer Teil des Nutzens in KMU liegt in unspektakulärer regelbasierter Integration. KI dort einsetzen, wo unstrukturierte Daten sie nötig machen — nicht, weil es im Pitch besser klingt.

Mehr Grundlagen, Vergleiche und Vertiefungen zu einzelnen Techniken findest du fortlaufend in der Übersicht Prozessautomatisierung.

Checkliste: Bereit für die Automatisierung eines Prozesses?

Vor dem Bau — wenn du hier mehr als zwei Punkte nicht abhaken kannst, ist der Prozess noch nicht so weit:

• Der Prozess läuft regelmäßig und in relevanter Stückzahl (Bauchgefühl reicht nicht — grob gezählt).
• Eine Person, die den Prozess täglich ausführt, hat ihn dir an echten Fällen gezeigt.
• Der Ist-Ablauf steht in einem Prozess-Steckbrief, inklusive der Ausnahmen und ihrer Häufigkeit.
• Offensichtliche Vereinfachungen sind umgesetzt oder bewusst verschoben.
• Für jeden Schritt ist entschieden: API, RPA-Brücke, KI-Baustein oder Mensch — und warum.
• Die Grenze ist definiert: Was darf der Workflow allein, was geht in die Prüf-Queue, was eskaliert?
• Fehlerverhalten ist entworfen: Wiederholungen, Benachrichtigungen, keine Dubletten bei erneutem Durchlauf.
• Es gibt eine Baseline: heutige Dauer und Fehlerhäufigkeit sind festgehalten.
• Ownership ist geklärt: eine fachlich verantwortliche Person, eine technisch verantwortliche.
• Datenschutzfragen (Datenflüsse, beteiligte Dienste, Speicherorte) sind vor der Tool-Entscheidung geprüft.
• Der Pilot hat ein Enddatum und ein Kriterium, an dem ihr „umschalten oder stoppen” entscheidet.

Wenn du unsicher bist, welcher deiner Prozesse sich als Erster lohnt, oder eine zweite Meinung zu einem geplanten Setup willst: Genau dafür gibt es meine KI- und Automatisierungsberatung — oder du schilderst mir deinen konkreten Prozess direkt über das Kontaktformular, und ich sage dir ehrlich, ob sich Automatisierung dort lohnt.

Stand: Juli 2026. Dieser Artikel beschreibt Vorgehen und Einordnung aus Projektpraxis; er ersetzt keine Rechts- oder Datenschutzberatung.