Prozessautomatisierung im Mittelstand: Der umfassende Praxisleitfaden

Ein Auftrag ist fachlich freigegeben, bleibt aber bis zum nächsten Morgen im Postfach liegen. Danach überträgt der Vertrieb die Daten in eine Tabelle, die Disposition legt den Vorgang erneut in ihrer Software an und die Buchhaltung korrigiert später eine abweichende Kundenadresse. Wer Prozessautomatisierung im Mittelstand umsetzen will, beginnt deshalb nicht mit einem Bot oder einer Plattform. Zuerst muss geklärt werden, warum ein grundsätzlich klarer Vorgang zwischen Menschen und Systemen immer wieder liegen bleibt.

Dieser Praxisleitfaden beschreibt die Arbeit an einem konkreten Automatisierungsprojekt: vom belastbaren Ist-Ablauf über die Auswahl des Piloten bis zu Tests, Einführung und Betrieb. Er ergänzt den strategischen Überblick zur digitalen Transformation und Prozessautomatisierung. Im Mittelpunkt steht nicht, wie viele Schritte technisch ausführbar sind, sondern wie ein Unternehmen einen vollständigen Ablauf schneller, verlässlicher und mit weniger manueller Verwaltung organisiert.

Das Projektergebnis vor der Technik festlegen

„Wir möchten mehr automatisieren“ reicht als Auftrag nicht aus. Das Projekt braucht ein betriebliches Ergebnis, an dem sich jede spätere Entscheidung prüfen lässt. Ein solches Ergebnis kann lauten:

• vollständige Anfragen gelangen am selben Arbeitstag in die zuständige Bearbeitung
• freigegebene Aufträge werden ohne zweite Datenerfassung an die Disposition übergeben
• Rechnungen mit passenden Bestell- und Lieferdaten benötigen keine manuelle Standardprüfung
• Terminänderungen aktualisieren Kalender, Kundennachricht und internen Status gemeinsam

Die Formulierung nennt einen Vorgang, den gewünschten Zustand und die betroffene Arbeit. Sie verspricht noch keine Einsparung, solange aktuelle Fallzahlen und Bearbeitungszeiten fehlen. Diese Werte werden im Projekt erhoben und nicht durch allgemeine Branchenangaben ersetzt.

Zusätzlich wird festgelegt, was der Pilot ausdrücklich nicht lösen soll. Bei einer Angebotsautomatisierung können Sonderkonditionen, Ausschreibungen und technisch ungewöhnliche Leistungen zunächst bei erfahrenen Mitarbeitern bleiben. Eine klare Grenze schützt das Projekt vor der Erwartung, jeden denkbaren Fall im ersten Anlauf abzubilden.

Eine Prozessakte statt einer allgemeinen Wunschliste erstellen

Ein Automatisierungsprojekt benötigt für jeden Kandidaten eine kompakte Prozessakte. Sie verbindet fachliche und technische Informationen in einem Dokument. Damit lässt sich ein Ablauf bewerten, ohne frühzeitig eine bestimmte Software vorauszusetzen.

Die Prozessakte enthält:

• Auslöser und eindeutiges Ende des Vorgangs
• Fallzahl in einem definierten Zeitraum
• beteiligte Rollen und Systeme
• Eingaben, Pflichtdaten und erzeugte Ergebnisse
• heutige Bearbeitungs- und Wartezeiten
• bekannte Standardvarianten und Ausnahmen
• häufige Rückfragen, Korrekturen und Abbrüche
• finanzielle, vertragliche oder operative Folgen eines Fehlers
• fachlichen Prozessverantwortlichen

Die Angaben entstehen aus realen Vorgängen. Interviews erklären, wie Mitarbeiter den Ablauf verstehen. Stichproben zeigen, wie er tatsächlich ausgeführt wird. Diese Unterscheidung ist wichtig: In einer Arbeitsanweisung kann eine Freigabe vorgesehen sein, während im Tagesgeschäft stattdessen eine E-Mail mit „passt“ genügt. Eine Automatisierung, die nur die offizielle Beschreibung kennt, bildet womöglich einen Prozess ab, den niemand lebt.

Der Beitrag Geschäftsprozesse analysieren vertieft die Aufnahme von Auslösern, Rollen, Medienbrüchen und Engpässen. Für das Automatisierungsprojekt wird daraus eine entscheidungsfähige Prozessakte.

Automatisierungskandidaten mit einer Matrix bewerten

Der lauteste Wunsch aus einer Abteilung ist nicht zwingend der beste Pilot. Kandidaten sollten anhand derselben Kriterien verglichen werden. Eine einfache Bewertungsmatrix verhindert, dass nur Sichtbarkeit oder persönlicher Ärger entscheiden.

Eine hohe Fallzahl allein genügt nicht. Wenn Regeln täglich wechseln oder eine falsche Entscheidung erhebliche Folgen auslöst, kann zunächst eine bessere Arbeitsoberfläche sinnvoller sein als eine vollautomatische Ausführung. Umgekehrt kann ein kleiner, stabiler Teilprozess ein guter Pilot sein, wenn er eine kritische Übergabe zwischen zwei Systemen absichert.

Für jedes Kriterium genügt zu Beginn eine einheitliche Skala mit einer kurzen Begründung. Entscheidend ist die Diskussion über die Unterschiede. Eine scheinbar genaue Gesamtnote darf fehlende Daten nicht verdecken.

Den Ist-Prozess anhand einzelner Fälle zerlegen

Für den ausgewählten Kandidaten werden mehrere reale Vorgänge vom Auslöser bis zum Abschluss verfolgt. Dazu gehören ein typischer Standardfall, ein unvollständiger Fall, eine häufige Ausnahme und ein Vorgang, der bereits zu Nacharbeit geführt hat.

Jeder Schritt erhält fünf Angaben:

1. auslösende Rolle oder auslösendes System
2. gelesene oder veränderte Information
3. angewendete Entscheidungsregel
4. Speicherort des neuen Zustands
5. Fehlerweg bei fehlenden Eingaben oder einem nicht erreichbaren System

Diese Zerlegung macht versteckte Arbeit sichtbar. Das Kopieren einer Adresse dauert vielleicht nur Sekunden. Die Suche nach der aktuellen Version, eine Rückfrage und die spätere Korrektur erzeugen den eigentlichen Aufwand. Medienbrüche sind deshalb nicht bloß technische Unschönheiten. Sie unterbrechen die Zuständigkeit und erschweren die Frage, welcher Datenstand gilt.

Die Digitalisierung von Geschäftsprozessen im KMU erläutert, wie Abläufe vor der Automatisierung vereinheitlicht und digital verfügbar gemacht werden. Fehlt diese Grundlage, automatisiert das Projekt sonst lediglich den Transport widersprüchlicher Informationen.

Den Soll-Prozess ohne überflüssige Schritte entwerfen

Der Soll-Prozess ist keine digital nachgezeichnete Kopie des bisherigen Ablaufs. Jeder Schritt wird darauf geprüft, ob er das fachliche Ergebnis schützt, eine notwendige Entscheidung ermöglicht oder nur aus einer alten Systemgrenze entstanden ist.

Ein typischer Bestellprozess kann beispielsweise zwei Freigaben enthalten, weil früher unterschiedliche Papierordner geführt wurden. Wenn heute Betrag, Kostenstelle und Lieferant bereits eindeutig geprüft werden, ist zu klären, welche Freigabe tatsächlich eine andere Entscheidung trifft. Automatisierung soll nachvollziehbare Kontrolle erhalten, nicht historische Klickfolgen konservieren.

Für jeden verbleibenden Schritt wird eine der folgenden Rollen festgelegt:

• automatisch ausführen, wenn Regel und Daten eindeutig sind
• automatisch vorbereiten, wenn ein Mitarbeiter das Ergebnis fachlich bewerten muss
• manuell entscheiden, wenn Kontext, Risiko oder Verhandlung ausschlaggebend sind
• entfernen, wenn der Schritt keinen notwendigen Beitrag liefert

Anschließend werden Ausnahmen direkt in den Soll-Ablauf eingezeichnet. Ein fehlender Preis, eine unbekannte Kundennummer oder eine abweichende Lieferadresse sind keine Randnotizen. Sie brauchen einen sichtbaren Status, eine zuständige Rolle und einen definierten Weg zurück in den Hauptprozess.

Führende Systeme und Datenverträge festlegen

Sobald mehrere Anwendungen beteiligt sind, muss für jedes wichtige Datenobjekt eine führende Quelle feststehen. Das CRM kann die aktuelle Kundenbeziehung führen, das ERP die kaufmännische Auftragsnummer und die Einsatzplanung den verbindlichen Ressourcenzustand. Ohne diese Zuordnung überschreiben Integrationen einander oder erzeugen mehrere vermeintlich gültige Wahrheiten.

Für jede Übergabe wird ein kleiner Datenvertrag beschrieben:

• eindeutige Kennung des Vorgangs
• benötigte Pflicht- und optionale Felder
• erlaubte Formate und Werte
• Zeitpunkt der Übertragung
• Verhalten bei fehlenden oder ungültigen Daten
• Rückmeldung des Zielsystems
• Regel für erneute Übertragungsversuche
• Protokollierung ohne unnötige Inhaltskopien

Ein Datenvertrag ist auch bei No-Code-Workflows sinnvoll. Die grafische Verbindung zweier Anwendungen beantwortet nicht, welche Adresse Vorrang hat, ob ein leerer Wert vorhandene Daten löschen darf oder wie doppelte Ereignisse erkannt werden.

Bei unternehmenskritischen Übergaben schafft eine sauber geplante API-Entwicklung einen belastbaren Austausch. Die Systemintegration im Mittelstand ordnet ein, wie führende Systeme, Schnittstellen und Datenflüsse zusammenspielen.

Die passende technische Umsetzung wählen

Erst nach Soll-Prozess und Datenvertrag wird das Werkzeug ausgewählt. Vier Wege kommen häufig infrage:

Vorhandene Funktionen konfigurieren

CRM-, ERP-, Buchhaltungs- oder Ticketsysteme enthalten oft Regeln, Freigaben und Benachrichtigungen. Bleibt der Ablauf in einer Anwendung, ist deren Standardfunktion meist leichter zu betreiben als eine zusätzliche Plattform.

No-Code oder Low-Code einsetzen

Ein klar begrenzter Ablauf zwischen Anwendungen mit stabilen Schnittstellen lässt sich damit schnell umsetzen. Zu prüfen sind Rechteverwaltung, Fehlerprotokolle, Testmöglichkeiten, Datenstandort, Kosten bei wachsendem Volumen und die Frage, wer Änderungen kontrolliert.

Eine individuelle Integration entwickeln

Komplexe Zustände, spezielle Geschäftsregeln oder ein hoher Anspruch an Nachvollziehbarkeit können eigene Integrationslogik rechtfertigen. Das bedeutet nicht, jede Oberfläche neu zu bauen. Häufig genügt ein gezielter Dienst zwischen bestehenden Systemen.

Eine Oberfläche automatisiert bedienen

Hat ein Altsystem keine Schnittstelle, kann Software Eingaben über dessen Oberfläche ausführen. Diese Lösung bleibt von Bildschirmaufbau und Anwendungszustand abhängig. Für einen Übergang kann sie angemessen sein; für einen dauerhaften Kernprozess braucht sie besonders strenge Überwachung.

Der veröffentlichte Leitfaden zur Workflow-Automatisierung für KMU beschreibt konkrete Einsatzfelder und Werkzeugklassen. Für die Architektur eines geschäftskritischen Gesamtprozesses hilft eine Softwarearchitektur mit klaren Systemgrenzen.

Regeln, Ausnahmen und Kontrollen implementierbar beschreiben

Der Satz „Bestandskunden werden automatisch freigegeben“ beschreibt noch keine ausführbare fachliche Regel. Für die Umsetzung müssen Kundenmerkmal, zulässige offene Posten, einbezogene Leistungen und der Umgang mit widersprüchlichen Kundendatensätzen feststehen.

Eine implementierbare Regel nennt:

• verwendete Daten und ihre Quelle
• genaue Bedingung
• auszuführende Aktion
• erzeugten Status
• Ausnahme und zuständige Rolle
• Zeitpunkt und fachliche Freigabe der Regelversion

Kontrollen werden nach Wirkung platziert. Eine fehlerhafte interne Benachrichtigung kann wiederholt werden. Eine doppelte Rechnung, Reservierung oder Bestellung muss bereits vor der Aktion verhindert werden. Je größer die mögliche Folge, desto wichtiger sind eindeutige Vorgangskennungen, Wiederholbarkeit ohne Doppelwirkung und gegebenenfalls eine menschliche Freigabe.

KI-basierte Schritte brauchen eine zusätzliche Grenze. Wenn ein Modell eine Anfrage klassifiziert oder Daten aus einem Dokument extrahiert, muss der Prozess mit unsicheren oder widersprüchlichen Ergebnissen umgehen. Das System kann solche Fälle zur Prüfung vorlegen; es darf Unsicherheit nicht durch einen scheinbar eindeutigen Status verdecken.

Mit fachlichen Testfällen statt nur mit Techniktests prüfen

Ein erfolgreicher Verbindungstest beweist lediglich, dass zwei Systeme miteinander sprechen. Er beweist nicht, dass der Geschäftsprozess korrekt arbeitet. Die Abnahme benötigt fachliche Testfälle, die Regeln, Daten und Folgen gemeinsam prüfen.

Ein Testkatalog enthält mindestens:

• vollständigen Standardfall
• fehlende Pflichtangabe
• ungültiges Format oder unbekannte Kennung
• doppelt eingehendes Ereignis
• vorübergehend nicht erreichbares Zielsystem
• Korrektur während eines laufenden Vorgangs
• häufige fachliche Ausnahme
• unberechtigten Zugriff oder fehlende Berechtigung
• Wiederanlauf nach behobenem Fehler

Für jeden Fall werden Eingang, erwartete Zustände in allen beteiligten Systemen, sichtbare Meldung und verantwortliche Rolle notiert. Besonders wichtig ist die Rückkehr aus einer manuellen Ausnahme. Wenn ein Mitarbeiter fehlende Angaben ergänzt, muss der Vorgang kontrolliert weiterlaufen können, ohne neu angelegt zu werden.

Mit anonymisierten oder dafür freigegebenen Testdaten lässt sich der Ablauf außerhalb des Produktivbetriebs prüfen. Ein Pilot mit echten Vorgängen folgt erst, wenn Standard- und Fehlerwege nachvollziehbar funktionieren.

Den Pilotbetrieb begrenzen und trotzdem aussagekräftig machen

Ein Pilot braucht eine erkennbare Grenze: eine Leistungsart, eine Niederlassung, einen Eingangskanal oder eine klar definierte Vorgangsgruppe. Die Grenze soll Risiken kontrollieren, darf aber nicht sämtliche schwierigen Fälle ausblenden. Ein Test nur mit vorbereiteten Idealdaten sagt wenig über den späteren Betrieb aus.

Vor dem Start werden Ausgangswerte und Beobachtungszeitraum festgehalten. Je nach Ziel eignen sich:

• Zeit vom Eingang bis zur ersten fachlichen Bearbeitung
• Zahl manueller Übertragungen je Vorgang
• Anteil unvollständiger Eingaben
• Zahl der Rückfragen und Korrekturen
• Durchlaufzeit bis zum definierten Prozessende
• automatisch abgeschlossene, manuell geprüfte und fehlgeschlagene Fälle
• Aufwand für Störungsbehebung und Pflege

Die Kennzahlen werden mit identischen Definitionen vor und nach dem Pilot erhoben. Ein schnellerer Standardfall ist kein Erfolg, wenn Ausnahmen nun in einem unbeobachteten Postfach liegen. Deshalb werden Mengen, Zeiten und Fehlerwege gemeinsam betrachtet.

Verantwortungen und Betrieb vor der Freigabe klären

Nach der Einführung verändert sich der Prozess weiter. Preise, Zuständigkeiten, Pflichtfelder, Berechtigungen oder Zielsysteme werden angepasst. Ohne geregelten Betrieb wird eine anfangs funktionierende Automatisierung schleichend unzuverlässig.

Vor der Produktivfreigabe sind folgende Rollen benannt:

• fachlicher Eigentümer für Regeln und Prozessgrenzen
• technischer Eigentümer für Ausführung, Zugänge und Überwachung
• Ansprechpartner für manuelle Ausnahmen
• Freigabeverantwortlicher für Änderungen
• Supportweg bei einer akuten Störung

Warnungen müssen eine Handlung auslösen. Eine Meldung „Workflow fehlgeschlagen“ hilft dem Vertrieb wenig. Sie sollte Vorgang, betroffenen Schritt, bisherigen Zustand und nächste zuständige Stelle erkennen lassen. Für zeitkritische Prozesse wird zusätzlich festgelegt, wann eskaliert und wie vorübergehend manuell weitergearbeitet wird.

Änderungen durchlaufen einen kleinen kontrollierten Weg: Anlass dokumentieren, betroffene Testfälle aktualisieren, außerhalb der Produktion prüfen, fachlich freigeben und nach Aktivierung beobachten. Technische Konten gehören nicht einzelnen Mitarbeitern. Andernfalls kann ein Passwortwechsel oder Austritt einen Kernprozess unbemerkt stoppen.

Wirtschaftlichkeit mit dem tatsächlichen Betrieb rechnen

Die Wirtschaftlichkeit besteht nicht allein aus eingesparten Minuten. Auf der Nutzenseite stehen weniger Erfassung und Nacharbeit, kürzere Liegezeiten, schnellere Abrechnung, höhere Bearbeitungskapazität oder weniger vermeidbare Abbrüche. Welche Wirkung zählt, hängt vom Prozessziel ab.

Auf der Kostenseite stehen Analyse, Konfiguration oder Entwicklung, Schnittstellen, Datenbereinigung, Tests, Einführung, Lizenzen, Hosting, Überwachung, Support und spätere Änderungen. Auch die Bearbeitung verbleibender Ausnahmen gehört in die Rechnung.

Eine brauchbare Kalkulation trennt einmalige Einführungskosten vom laufenden Aufwand. Sie arbeitet zunächst mit dokumentierten Annahmen und ersetzt diese nach dem Pilot durch gemessene Werte. Der Artikel Prozesskosten im KMU senken zeigt, wie Bearbeitungs-, Warte- und Fehlerkosten gemeinsam betrachtet werden.

Automatisierung ist nicht wirtschaftlich, wenn ein selten genutzter Ablauf umfangreiche Sonderlogik benötigt oder das angebundene System bald ersetzt wird. In solchen Fällen kann eine standardisierte Vorlage, bessere Datenerfassung oder ein kleiner unterstützender Schritt die vernünftigere Entscheidung sein.

Beispiel: Auftragsübergabe vom Vertrieb an die Disposition

Das folgende Beispiel ist hypothetisch. Ein technischer Dienstleister erstellt Angebote im CRM. Nach Annahme überträgt der Vertrieb Kundendaten, Leistungspositionen und Terminwunsch in die Dispositionssoftware. Unvollständige Angaben führen zu Rückfragen; Änderungen am Angebot erreichen die Disposition manchmal erst per E-Mail.

Das Projektziel lautet: Freigegebene Standardaufträge sollen mit vollständigen Pflichtdaten einmalig an die Disposition übergeben werden. Sonderleistungen und ungeklärte Termine bleiben in fachlicher Prüfung.

Die Prozessakte zeigt einen häufigen Standardfall, zwei führende Systeme und wiederkehrende Korrekturen bei Einsatzort und Ansprechpartner. Im Soll-Prozess erhält jeder Auftrag eine eindeutige Kennung. Das CRM prüft Pflichtfelder vor der Freigabe. Die Integration überträgt nur freigegebene Versionen und speichert die Rückmeldung der Disposition. Eine spätere Änderung erzeugt keine zweite Bestellung, sondern aktualisiert den vorhandenen Vorgang nach einer festgelegten Regel.

Kann die Dispositionssoftware einen Datensatz nicht anlegen, bleibt der Auftrag im Status „Übergabe fehlgeschlagen“. Der Vertrieb sieht den Grund, der technische Support erhält die notwendigen Protokolldaten und eine erneute Übertragung verwendet dieselbe Vorgangskennung. Sonderleistungen wechseln in eine eigene Prüfaufgabe und kehren danach in denselben Ablauf zurück.

Der Pilot startet mit einer Leistungsart. Gemessen werden manuelle Übertragungen, Korrekturen, Zeit bis zur disponierbaren Auftragsakte und Störungsaufwand. Erst diese Werte zeigen, ob der Ablauf auf weitere Leistungen übertragen werden sollte.

Prozessautomatisierung im Mittelstand umsetzen und kontrollierbar betreiben

Ein belastbarer Start besteht nicht aus einer langen Werkzeugauswahl. Wählen Sie drei wiederkehrende Abläufe, erstellen Sie für jeden eine Prozessakte und bewerten Sie Geschäftswirkung, Regeln, Daten, Ausnahmen, Fehlerfolgen und Verantwortung. Der beste Pilot besitzt einen relevanten Engpass, einen dominanten Standardfall und eine Fachperson, die verbindlich über den Soll-Prozess entscheiden kann.

SW Business Solutions begleitet Automatisierungsprojekte von der Prozessaufnahme über Soll-Design und Systemarchitektur bis zur technischen Umsetzung und zum überwachten Betrieb. Das Ergebnis kann eine Konfiguration im vorhandenen System, ein No-Code-Workflow, eine Schnittstelle oder eine individuelle Anwendung sein. Die Entscheidung richtet sich nach Ihrem Ablauf und Ihrer Systemlandschaft. Ziel ist ein Prozess, der weniger Verwaltungsarbeit erzeugt, schneller zum Geschäftsergebnis führt und bei Abweichungen kontrollierbar bleibt.