Erst klären, dann digitalisieren: Warum Tools den Prozess nicht reparieren

Ein Unternehmen führt ein Ticketsystem für Reklamationen ein. Die Auswahl dauert vier Monate, die Einführung weitere drei. Nach einem halben Jahr Betrieb zeigt die Auswertung: Die Durchlaufzeit hat sich kaum verändert. Kunden warten weiterhin wochenlang auf eine Lösung.

Das Team schaut sich die Tickets an und findet die Erklärung schnell. Die Tickets wandern zwischen Service, Qualität und Vertrieb hin und her, genau wie vorher die E-Mails. Jede Gutschrift braucht weiterhin die Freigabe des Vertriebsleiters. Das System dokumentiert das Weiterreichen jetzt nur lückenlos.

Diese Geschichte steht als Stolperfalle auf meiner Process Card zur Reklamation: Das Ticketsystem allein löst nichts, wenn der Case Owner keine Entscheidungsbefugnis hat. Ähnliche Sätze stehen auf fast jeder Card.

Was Software leistet und was nicht

Prozess-Software ist gut darin, Regeln auszuführen. Sie leitet weiter, erinnert, eskaliert, dokumentiert. Sie tut das schneller und zuverlässiger als jeder Mensch.

Sie ist schlecht darin, Regeln zu erfinden. Wer bei welchem Betrag freigeben darf, wer vertritt, wann ein Vorgang eskaliert und an wen: Diese Fragen muss die Organisation beantworten. Wenn sie es nicht tut, übernimmt das Implementierungsprojekt die Aufgabe nebenbei. Dann entscheiden Berater und IT-Projektleiterinnen in Konfigurationsworkshops über Zuständigkeiten, die eigentlich die Fachbereiche klären müssten. Die Ergebnisse sind entsprechend.

Progressive BPM ordnet Software deshalb der dritten Lösungsstufe zu, der strukturellen. Sie kommt nach der Sofortmaßnahme und nach der Regel, die die Organisation in der mittelfristigen Stufe geklärt hat.

Die Klärungsfragen vor jeder Tool-Auswahl

Bevor ein Team ein Workflow-System auswählt, sollten fünf Fragen beantwortet sein. Wenn eine davon offen ist, beginnt die Arbeit dort.

Wo kommt der Vorgang herein? Gibt es einen zentralen Eingangskanal, oder landen Vorgänge bei Einzelpersonen? Beim Rechnungseingang heißt das: eine Rechnungsadresse, die alle Lieferanten kennen.

Wer ist für den einzelnen Vorgang verantwortlich? Gibt es pro Fall eine Person, die ihn bis zum Abschluss begleitet?

Wer entscheidet was? Gibt es eine Freigabematrix oder einen Entscheidungsrahmen, und ist er mit den Beteiligten abgestimmt?

Was passiert, wenn jemand nicht da ist? Ist für jede Rolle eine Vertretung definiert?

Wann gilt ein Vorgang als überfällig? Gibt es eine Frist, und ist geklärt, was nach ihrem Ablauf passiert?

Diese Fragen klingen banal. In vielen Organisationen lässt sich keine davon in einem Satz beantworten. Und jede Frage, die vor der Einführung offen bleibt, taucht danach als Konfigurationsproblem wieder auf.

Die E-Rechnung als Anlass

Ein aktuelles Beispiel aus dem Rechnungseingang: In Deutschland müssen Unternehmen seit 2025 elektronische Rechnungen im B2B-Bereich empfangen können. Die Pflicht zum Ausstellen folgt schrittweise in den kommenden Jahren. Viele Unternehmen behandeln das als IT-Projekt. Sie beschaffen eine Lösung, die XRechnung und ZUGFeRD lesen kann, und schließen sie an die Buchhaltung an.

Das erfüllt die gesetzliche Pflicht. Es verändert aber nichts daran, dass die Rechnung danach per E-Mail an eine Kostenstellenverantwortliche geht, die sie eine Woche liegen lässt.

Meine Card zum Rechnungseingang empfiehlt deshalb, die E-Rechnungspflicht als Anlass zu nutzen und nicht als reines IT-Projekt zu behandeln. Wenn das Unternehmen ohnehin an den Rechnungseingang heranmuss, kann es bei dieser Gelegenheit die Freigabematrix klären, die Bestellnummer zur Pflichtangabe machen und den 3-Way-Match für Standardfälle einführen. Der Aufwand für diese Klärung ist gering im Vergleich zur technischen Umstellung. Die Wirkung auf Durchlaufzeit und Skontoquote ist dafür deutlich größer.

Digitalisieren, was schon funktioniert

Ein nützlicher Test vor jeder Software-Einführung: Funktioniert der Prozess bereits in einer einfachen Form, mit Tabelle, E-Mail-Verteiler oder Checkliste? Wenn ja, wird ihn die Software beschleunigen. Wenn nein, wird sie ihn nicht retten.

Beim Onboarding heißt das: Erst arbeiten HR, IT und Führungskräfte drei Monate mit einer gemeinsamen Checkliste mit Fristen relativ zum Starttermin. Wenn diese Checkliste funktioniert, also die Arbeitsfähigkeit am ersten Tag steigt, lohnt sich die Automatisierung. Das Team weiß dann genau, welche Aufgaben das System bei Vertragsunterschrift auslösen soll und an wen.

Diese Reihenfolge hat noch einen Vorteil. Die einfache Lösung liefert die Anforderungen für die Software. Wer drei Monate mit einer Checkliste gearbeitet hat, kann einer Softwarefirma sehr präzise sagen, was sie braucht. Lastenhefte, die aus gelebter Praxis entstehen, sind kürzer und treffender als solche aus Anforderungsworkshops.

Wenn das Tool schon da ist

Häufig ist die Software bereits eingeführt, und der Prozess funktioniert trotzdem nicht. Dann hilft es, das Tool vorübergehend gedanklich auszublenden und die fünf Klärungsfragen zu stellen.

Meist zeigt sich, dass das System technisch alles kann, was nötig wäre. Es gibt eine Vertretungsfunktion, aber niemand hat Vertretungen eingetragen. Es gibt Eskalationsregeln, aber sie sind mit einer Frist von 30 Tagen konfiguriert. Es gibt Pflichtfelder für Fehlerkategorien, aber die Kategorien sind so allgemein, dass 70 Prozent der Fälle unter „Sonstiges“ landen.

In diesen Fällen ist die Lösung eine Klärungsarbeit, die nachgeholt wird, gefolgt von einer Konfigurationsänderung. Das ist deutlich günstiger als ein Systemwechsel, auch wenn ein Systemwechsel oft attraktiver wirkt.

Digitalisierung als Lohn

Ich verstehe Software im Progressive BPM als Belohnung für geklärte Prozesse. Wenn ein Team die Sofortmaßnahme umgesetzt, die Regeln geklärt und die Wirkung gemessen hat, hat es sich die Investition verdient. Es kann begründen, warum es das System braucht, und es kann zeigen, was es damit erreichen will.

Für Geschäftsführungen ist diese Logik leicht nachvollziehbar. Sie finanzieren ein Tool für einen Prozess, der bereits besser läuft, statt einer Hoffnung für einen Prozess, der nicht funktioniert.