Order-to-Cash ist in vielen Unternehmen der End-to-End-Prozess, an dem sich die reale Prozessreife am deutlichsten zeigt. Vom ersten Kundenkontakt bis zum Zahlungseingang durchläuft der Vorgang mehrere Abteilungen, wechselnde Verantwortlichkeiten und in vielen Betrieben noch immer mehrere Systeme. Jede dieser Übergänge ist eine potenzielle Bruchstelle. Während Methoden des Business Process Management (BPM) ein klares Bild vom Soll-Prozess zeichnen, entscheidet sich im Alltag an den operativen Systemen, ob dieses Bild tatsächlich wiederholbar umgesetzt wird. Der folgende Beitrag analysiert, wo die typischen Medienbrüche liegen, welche Rolle ein ERP an der Prozessdurchsetzung spielt und wo seine Grenzen gegenüber einem dedizierten Business Process Management System (BPMS) verlaufen.

Warum Auftragsabwicklung der Paradefall für End-to-End-Denken ist

Order-to-Cash verknüpft Abteilungen mit sehr unterschiedlichen Zielfunktionen. Der Vertrieb optimiert Abschlussquote und Deckungsbeitrag, die Disposition arbeitet auf Liefertreue und Bestandsreichweite, die Produktion oder der Einkauf auf Auslastung und Lieferantenzuverlässigkeit, das Lager auf Pickqualität und Durchsatz, der Versand auf Termineinhaltung, die Fakturierung auf Periodengenauigkeit und das Inkasso auf Days Sales Outstanding (DSO). Jede dieser Funktionen hat valide Ziele, und jede kann optimiert werden, ohne dass der Gesamtprozess dadurch besser wird. Genau dieses Phänomen hat End-to-End-Denken überhaupt erst als Leitgedanken etabliert.

Der Kunde erlebt den Prozess als Einheit. Er unterscheidet nicht, ob eine Lieferverzögerung an der Produktion, am Lager oder am Versand liegt. Für ihn zählt, wann er seine Ware bekommt und ob die Rechnung dazu passt. Die interne Organisation dagegen ist häufig entlang der Abteilungsgrenzen strukturiert, und diese Grenzen finden sich eins zu eins in den Systemlandschaften wieder. Aus Prozessmanagement-Perspektive ist Auftragsabwicklung damit weniger eine Funktion als ein organisatorischer Stresstest: Sie zeigt in jeder Iteration, ob die Abteilungen koordiniert spielen oder nebeneinander agieren.

Klassische Abteilungsoptimierungen stoßen an dieser Stelle an strukturelle Grenzen. Ein perfekt getakteter Versand nützt wenig, wenn die Disposition zwei Tage später liefert als geplant. Ein hochautomatisiertes CRM entlastet den Vertrieb, sorgt aber nicht dafür, dass der Auftrag korrekt in die Produktion läuft. Wer End-to-End-Leistung verbessern will, muss an den Übergängen arbeiten, nicht an den Teilschritten.

Die typischen Bruchstellen der Order-to-Cash-Kette

Medienbrüche sind die spezifisch digitale Variante von Prozessbrüchen. Sie treten überall dort auf, wo Daten zwischen Systemen wechseln, neu erfasst oder über E-Mails, Excel-Dateien und manuelle Freigaben transportiert werden. Fünf Stellen sind in den meisten mittelständischen Unternehmen wiederkehrende Schwachpunkte.

Angebot zu Auftrag: Medienbruch zwischen CRM und ERP

Wenn Vertriebsvorgänge in einem CRM gepflegt und Aufträge in einem getrennten ERP ausgelöst werden, entsteht am Übergang ein strukturelles Risiko. Positionen werden manuell übernommen, Preiskonditionen neu eingegeben, Sonderabsprachen gehen verloren oder müssen im Freitext nachgereicht werden. Die erste Version des Auftrags ist oft nicht identisch mit dem vom Kunden angenommenen Angebot. Je nach Organisation dauert die Klärung dieser Abweichungen Stunden oder Tage, bevor überhaupt disponiert werden kann.

Auftrag zu Disposition: Verfügbarkeitsprüfung als manueller Abgleich

Die Verfügbarkeit von Materialien, Kapazitäten oder Ressourcen ist ein klassischer Engpass-Indikator. In Systemlandschaften, in denen Auftrag und Disposition nicht am selben Datenmodell hängen, wird die Verfügbarkeit über Rückfragen, Tabellen und Telefonate geprüft. Das mag funktionieren, ist aber weder skalierbar noch transparent. Engpässe werden eher im Gespräch als im System sichtbar, und die Reaktionszeit hängt von der Verfügbarkeit der beteiligten Personen ab, nicht von der Dringlichkeit des Vorgangs.

Wareneingang und Lagerbuchungen: Statustransparenz im Lager

Die Materialverfügbarkeit, die im ERP steht, ist nicht immer identisch mit der Materialverfügbarkeit, die im Lager tatsächlich greifbar ist. Wareneingänge werden nachgepflegt, Entnahmen manchmal erst am Ende der Schicht gebucht, Umlagerungen fehlen in der Systemlogik. Das Ergebnis ist ein systematischer Zeitversatz zwischen Realität und Datenstand. Für die Auftragsabwicklung ist das kritisch, weil jede Disposition auf den falschen Daten aufsetzt.

Versand zu Fakturierung: Zeitversatz und Ausnahmebehandlung

Die Fakturierung sollte idealerweise kurz nach dem Versand erfolgen, idealerweise automatisch. In der Realität liegen zwischen Verladung und Rechnungsstellung oft mehrere Tage. Teillieferungen, Abweichungen zum Auftrag, nachträgliche Korrekturen und Retouren verlangsamen den Prozess zusätzlich. Die finanziellen Folgen (verlängerte DSO, spätere Zahlungseingänge, unpräzise Periodenabgrenzung) werden selten direkt mit der Prozessqualität in Verbindung gebracht.

Fakturierung zu Inkasso: Zahlungsdisziplin und Mahnprozesse

Der letzte Übergang wird oft übersehen, obwohl er Cashflow-relevant ist. Wenn Zahlungsziele überschritten werden, stellt sich die Frage, wer reagiert und wann. Wo Mahnprozesse nicht systematisch gesteuert werden, entstehen zwei Fehlermuster: gute Kunden werden unnötig gemahnt, chronisch säumige Kunden kommen zu spät unter Druck. Beides beschädigt die Auftragsabwicklungsqualität aus Sicht des Kunden und aus Sicht der eigenen Liquidität.

An jeder dieser fünf Bruchstellen entstehen drei Effekte gleichzeitig: Die Durchlaufzeit wächst, das Fehlerpotenzial steigt, und die Prozesstransparenz sinkt. Jede dieser Stellen ist für sich genommen beherrschbar. In Summe erklären sie den Abstand zwischen modelliertem Soll-Prozess und operativer Wirklichkeit.

Prozessmodell versus Prozesswirklichkeit und die Rolle des ERP

Ein gut modellierter Soll-Prozess ist eine wertvolle Grundlage für jede Veränderungsarbeit. Modelle in Business Process Model and Notation (BPMN) machen implizites Wissen explizit, sie ermöglichen Diskussionen, sie sichern Compliance-Anforderungen dokumentiert ab. Was sie nicht leisten, ist die tägliche Durchsetzung des modellierten Ablaufs. Ein Modell ist nur so viel wert, wie das operative System, das es stützt.

Genau an dieser Stelle übernimmt ein ERP eine Rolle, die komplementär zur BPM-Ebene ist. Eine integrierte Auftragsabwicklung Software führt die einzelnen Stationen des Order-to-Cash-Prozesses in einem gemeinsamen Datenmodell zusammen und hält sie transaktional konsistent. Der Auftrag ist nicht mehr eine Zusammenstellung von Dokumenten aus verschiedenen Systemen, sondern ein Vorgang mit Status, Historie und eindeutigen Zuständigkeiten. Der modellierte Ablauf wird nicht durch das ERP ersetzt, aber er wird durch das ERP wiederholbar ausführbar.

Das klingt trivial, ist in der Praxis aber der zentrale Unterschied zwischen BPM-Projekten, die in Handlungsempfehlungen enden, und solchen, die sich in der Organisation festsetzen. Ohne ein operatives Rückgrat bleibt das Modell ein Bild, das nach dem Workshop in einem Sharepoint liegt. Mit einem operativen Rückgrat wird das Modell zur Grundlage täglicher Entscheidungen.

Status-Transparenz und automatisierte Übergaben als operativer Hebel

Status-Transparenz ist das unterschätzte Führungsinstrument jedes Prozesses. Wer zu jedem Zeitpunkt sagen kann, in welcher Phase sich ein Auftrag befindet, wer dafür verantwortlich ist und welche Engpässe gerade auftreten, braucht keine Eskalationsmeetings, um Probleme zu erkennen. Die Eskalation ergibt sich aus der Abweichung zwischen Soll- und Ist-Durchlaufzeit, und sie trifft den richtigen Bearbeiter, nicht den lautesten.

Automatisierte Übergaben zwischen den Phasen sind die praktische Umsetzung dieser Transparenz. Wenn der Wareneingang gebucht wird, wechselt der Auftrag automatisch in den Status “bereit zur Kommissionierung”. Wenn die Kommissionierung abgeschlossen ist, ist der Versand informiert. Wenn der Versand verladen hat, wird die Fakturierung ausgelöst. Jede dieser Übergaben ist in einem integrierten System ein technischer Mechanismus, kein organisatorischer Akt.

Die Alternative kennt jeder Prozessmanager aus der Praxis. Aufträge, die im Lager “verloren” gehen, weil niemand den Wareneingang gebucht hat. Fakturen, die eine Woche lang liegen bleiben, weil die Information über den Versand den Buchhaltungsbereich noch nicht erreicht hat. Zahlungsverzüge, die niemandem auffallen, weil keine Regel definiert ist, wer auf welchen Saldo wann reagiert. Jede dieser Situationen ist im modellierten Prozess nicht vorgesehen, taucht aber in jeder realen Auftragsabwicklung auf. Eine Software für Auftragsabwicklung, die diese Übergaben systematisch abbildet, reduziert das Auftreten dieser Ausnahmefälle deutlich.

Kennzahlen, die den Unterschied messbar machen

BPM-Arbeit lebt von belastbaren Kennzahlen. Für die Auftragsabwicklung haben sich vier Messgrößen als besonders aussagekräftig erwiesen.

Die erste ist die Durchlaufzeit pro Phase, häufig als Order Lead Time operationalisiert. Sie zeigt, wo im Prozess tatsächlich Zeit verbracht wird, unabhängig von anekdotischen Berichten der Beteiligten. Wer diese Zeiten über Wochen sauber misst, identifiziert Engpässe präziser als jedes qualitative Interview.

Die zweite ist die On-Time-in-Full-Quote, kurz OTIF. Sie erfasst, wie viele Aufträge vollständig und zum vereinbarten Termin beim Kunden eintreffen. Sie ist die ehrlichste Kennzahl für die Prozessqualität insgesamt, weil sie keine Abteilungssicht kennt. Ein Auftrag ist entweder on-time-in-full oder er ist es nicht.

Die dritte ist die Rückstandsquote, also die Anzahl offener Vorgänge pro Phase im Verhältnis zur Gesamtzahl der aktiven Aufträge. Sie gibt Hinweise auf Engpässe, bevor sich diese in der Durchlaufzeit niederschlagen.

Die vierte ist die Reklamationsquote mit Ursachen-Klassifikation. Nicht die Gesamtzahl der Reklamationen ist aus BPM-Sicht entscheidend, sondern die Verteilung der Ursachen. Transportschäden, Pickfehler, Mengenabweichungen, Terminabweichungen und Qualitätsprobleme sind unterschiedliche Probleme mit unterschiedlichen Gegenmaßnahmen.

Alle vier Kennzahlen werden nur dann belastbar, wenn das operative System die zugrundeliegenden Ereignisse sauber erfasst. Ohne eine Software zur Auftragsabwicklung, die Status, Zeitstempel und Zuständigkeiten verlässlich festhält, bleibt die Kennzahlenermittlung eine Schätzung auf Basis manueller Nachdokumentation.

Wo ERP keine BPMS ersetzt und umgekehrt

Aus Prozessmanagement-Sicht ist an dieser Stelle eine klare Abgrenzung wichtig. Ein ERP ist kein Prozessmodellierungs-Tool. Es ist kein BPMN-Interpreter, es kommt ohne grafische Workflow-Modellierung aus, und es ist nicht darauf ausgelegt, variable, fachbereichs-übergreifende Workflows dynamisch zu orchestrieren. Wer diese Erwartungen an ein ERP richtet, wird enttäuscht werden, und zwar unabhängig vom Hersteller.

Umgekehrt ist ein BPMS kein Warenwirtschaftssystem. Es führt keine Bestände, es fakturiert nicht, es liefert keine Finanzbuchhaltung. Die Stärke eines BPMS liegt in der Modellierung, Ausführung und Überwachung variabler, oft abteilungsübergreifender Workflows mit hoher Ausnahmevielfalt. Compliance-Workflows, Antragsprozesse, Genehmigungsketten und Sonderprozesse mit hohem Änderungsdruck sind typische BPMS-Domänen.

Die sinnvolle Koexistenz beider Welten ist inzwischen gut dokumentiert. Das BPMS modelliert den Soll-Prozess, dokumentiert die Regeln und orchestriert die Sonderfälle. Das ERP führt die transaktionale Kernstrecke aus, hält die Daten konsistent und erzeugt die operativen Kennzahlen. Integrationsmuster reichen von einfachen API-Aufrufen über ereignisbasierte Event-Brücken bis zu tieferen Kopplungen über Process-Mining-Plattformen. Welche Integration im Einzelfall sinnvoll ist, hängt von Volumen, Variabilität und Änderungsdynamik ab.

Wichtig ist, dass die Rollenverteilung bewusst getroffen wird. Ein ERP, das zu weit in BPMS-Territorium drängt, wird unflexibel. Ein BPMS, das operative Kernprozesse abbilden soll, wird schnell komplex und schwer zu betreiben. Die saubere Trennung ist für die langfristige Wartbarkeit beider Systeme entscheidend.

Implementierungsreihenfolge: erst Prozess oder erst System?

Im BPM-Reflex lautet die Antwort klar: erst den Prozess modellieren, dann ein System auswählen. Das stimmt in einer Welt, in der das System noch nicht existiert und der Prozess frisch definiert werden kann. In der Realität mittelständischer Unternehmen existiert fast immer schon ein System, und der Prozess hat sich um dieses System herum eingeschwungen. Eine strikt Prozess-zuerst-Sequenz ignoriert diese Realität und führt in Projekten zu einem Modell, das sich nicht ohne Systemwechsel umsetzen lässt.

Die pragmatische Antwort ist iterativ. Modell und System werden in Schleifen aneinander angeglichen. Das Prozessmanagement beschreibt den Soll-Zustand, die IT prüft die Umsetzbarkeit, der Fachbereich validiert die Praktikabilität. In jeder Iteration wird entschieden, ob der Soll-Prozess an das System anzupassen ist, ob das System anzupassen ist oder ob eine Anpassungslücke dokumentiert und zurückgestellt wird. Diese Arbeitsweise ist weniger elegant als eine saubere Wasserfall-Planung, aber sie liefert in endlicher Zeit tatsächlich umgesetzte Prozessverbesserungen.

Die Rolle des Prozessmanagers verschiebt sich in diesem Zyklus. Er ist nicht mehr ausschließlich Modellierer, sondern auch Moderator der Abwägung zwischen Modell und System. Er übersetzt zwischen Fachbereich und IT, identifiziert Lücken und priorisiert Anpassungen nach Wirkung. Eine Software zur Auftragsabwicklung, die sowohl konfigurierbar als auch prozesstreu ist, erleichtert diese Arbeit deutlich. Eine Software, die entweder starr oder beliebig flexibel ist, macht sie schwerer.

Fazit

Auftragsabwicklung ist weder eine reine IT-Aufgabe noch eine reine Organisations-Aufgabe. Ihr Erfolg entscheidet sich im Zusammenspiel von Modell, System und Menschen. BPM liefert die Struktur, das ERP liefert die operative Durchsetzung, die Fachbereiche liefern das Erfahrungswissen. Wer diese drei Ebenen gleichzeitig ernst nimmt, reduziert Medienbrüche, verkürzt Durchlaufzeiten und macht die Order-to-Cash-Kette messbar steuerbar.

Mit zunehmender Digitalisierung verschiebt sich das Gewicht etwas stärker in Richtung operativer Systemebene, ohne dass BPM überflüssig würde. Je mehr Prozessschritte digital vorliegen, desto wichtiger wird die saubere Modellierung dessen, was sie abbilden sollen. Für Prozessmanager im Mittelstand heißt das konkret: Das BPM-Handwerk wird nicht weniger relevant, aber die Zusammenarbeit mit den operativen Systemen wird enger. Wer diese Schnittstelle aktiv gestaltet, bringt sein Unternehmen weiter als jede methodische Reinheit es könnte.