Ergebnisse eines Prozessentwicklungsprojekts mit Beispiel

Jemand lädt jeden Morgen die Webshop-Bestellungen herunter und erfasst sie manuell in einem anderen System. Das Lager arbeitet damit, während die Rechnungsstellung aus einer dritten Datenquelle erfolgt. Wenn eine Abweichung festgestellt wird, ist das Paket bereits verspätet, und der Kundenservice sucht nach einer Erklärung. Die Ergebnisse eines Prozessentwicklungsprojekts mit Beispielen sind wirklich verständlich, wenn man nicht nur auf den Bildschirm eines neuen Systems schaut, sondern darauf, was sich an einem solchen Arbeitstag ändert.

Ein gut geführtes Entwicklungsprojekt ist nicht deshalb erfolgreich, weil viele Aufgaben automatisiert werden, und auch nicht, weil eine alte Anwendung ersetzt wird. Es ist erfolgreich, weil der Betrieb berechenbarer wird: weniger wiederholte Dateneingaben, klarere Verantwortlichkeiten, zuverlässigere Informationen und die Führung sieht schneller, wo die Arbeit stockt.

Was bedeutet das Ergebnis einer Prozessentwicklung wirklich?

Unternehmen suchen oft die Antwort in einer einzigen Kennzahl: Wie viele Stunden haben wir eingespart, wie viel hat sich die Kapazität erhöht, um wie viel Prozent sind die Fehler gesunken. Diese Kennzahlen sind notwendig, sagen aber allein wenig aus. Ein Prozess wird meist deshalb umständlich, weil während des Wachstums neue Ausnahmen, Tabellen, E-Mail-Abstimmungen und manuelle Prüfungen hinzukommen.

Das eigentliche Ergebnis zeigt sich daher in mehreren Schichten. Die Bearbeitungszeit einer Bestellung kann verkürzt werden, aber ebenso wertvoll ist es, wenn die Kollegen nicht mit unterschiedlichen Datenversionen arbeiten. Die Fehlerbehebung kann reduziert werden, aber es ist auch wichtig, dass der Prozess nicht nur im Kopf eines erfahrenen Mitarbeiters existiert. Wenn diese Person im Urlaub ist oder das Unternehmen verlässt, muss der Betrieb dennoch funktionieren.

Bei der Messung lohnt es sich, neben der Durchlaufzeit, der Fehlerquote, der Anzahl manueller Eingriffe, der Menge offener Vorgänge und der Aktualität der Informationen auch die Ausnahmen zu betrachten. Eine durchschnittliche Bestellung kann schnell sein, während die Bearbeitung problematischer Bestellungen weiterhin völlig undurchsichtig bleibt. Die Entwicklung muss auch diese versteckte Belastung sichtbar machen.

Ergebnisse eines Prozessentwicklungsprojekts mit Beispielen: Webshop und Lager

Nehmen wir ein wachsendes Handelsunternehmen. Es bearbeitet täglich 80-120 Webshop-Bestellungen mit mehreren Lagerstandorten. Der Webshop, die Lagerverwaltung und das Abrechnungssystem arbeiten getrennt. Das Vertriebsteam exportiert morgens die Bestellungen, überprüft den Zahlungsstatus und übergibt die Informationen in einer Tabelle an das Lager. Nachmittags werden dieselben Daten erneut für die Rechnungsstellung und den Managementbericht überprüft.

Auf den ersten Blick scheint das Problem eine technische Integration zu sein. Doch bei der Untersuchung kann sich ein anderes Bild ergeben. Es könnte sich herausstellen, dass die Bestellungen deshalb zweimal überprüft werden, weil das Lager nur einmal täglich zuverlässige Bestandsinformationen erhält. Es könnte auch sein, dass für bestimmte Bestelltypen früher eine Genehmigung durch die Führung erforderlich war, diese Regel jedoch für alle Bestellungen beibehalten wurde. Oder die Rechnungsstellung wartet bis zum Nachmittag, weil der Bestätigungsstatus nicht klar definiert ist.

In dieser Situation ist der erste Schritt nicht, die Systeme zu verbinden. Zuerst muss geklärt werden, welches System die zuverlässige Quelle für welche Daten ist, wann eine Bestellung bearbeitbar wird, welche Ausnahmen menschliche Entscheidungen rechtfertigen und wer dafür verantwortlich ist. Erst danach kann entschieden werden, ob eine Prozessumgestaltung, Regeländerung, Systemintegration oder eine Kombination davon die richtige Antwort ist.

Die Ausgangssituation messen

Zu Beginn des Projekts hat das Team vier Wochen lang den Bestellprozess gemessen. Aus den Daten ging hervor, dass die administrative Bearbeitung einer Bestellung durchschnittlich 11 Minuten in Anspruch nahm, obwohl die tatsächliche Datenbewegung viel weniger war. Der Unterschied wurde durch Prüfungen, unvollständige Bestandsinformationen, E-Mail-Anfragen und den einmal täglichen manuellen Export verursacht.

Bei durchschnittlich 100 Bestellungen pro Tag bedeutete dies etwa 18 Arbeitsstunden Verwaltung pro Woche. Darüber hinaus kam es monatlich 25-30 Mal vor, dass das Lager bereits eine Bestellung zusammengestellt hatte, deren Zahlung oder Adresse noch nicht ordnungsgemäß überprüft worden war. Diese verursachten nicht immer erhebliche finanzielle Verluste, aber sie führten zu einer Belastung des Kundenservices, Neupackungen und unnötiger Spannung.

Was hat sich im Prozess geändert?

Teil der Lösung war die strukturierte Datenverbindung zwischen dem Webshop und der internen Lagerverwaltung, aber das allein brachte nicht das Ergebnis. Der Prozess wurde ebenfalls neu gestaltet. Die Bedeutung der Bestellstatus wurde definiert, normale und außergewöhnliche Vorgänge wurden getrennt, und der Genehmigungsschritt, der Bestellungen unnötig verzögerte, wurde abgeschafft.

Das Lager erhielt nur solche Bestellungen als Aufgabe, die den zuvor festgelegten Prüfregeln entsprachen. Problematische Posten verschwanden nicht in einem gemeinsamen Postfach: Sie wurden in eine separate Ausnahmeliste mit Verantwortlichem und Frist aufgenommen. Die Rechnungsstellung war mit dem tatsächlichen Erfüllungsstatus verbunden, nicht mit einer manuellen Nachmittagsliste.

Die Automatisierung hat hier keine Menschen ersetzt. Ein Teil der zuvor für Export und Neuregistrierung aufgewendeten Zeit konnte für die schnellere Bearbeitung von Ausnahmen, die Vermeidung von Bestandsproblemen und die Kundenkommunikation genutzt werden. Das ist ein wesentlicher Unterschied: Die Maschine übernimmt die wiederholte Datenbewegung, der Mensch entscheidet dort, wo die Entscheidung geschäftlichen Wert schafft.

Die messbaren und weniger sichtbaren Ergebnisse

Drei Monate nach der Einführung des neuen Betriebs sank die durchschnittliche administrative Bearbeitungszeit von 11 Minuten auf 3,5 Minuten pro Bestellung. Wöchentlich bedeutete dies die Freisetzung von mehr als 12 Arbeitsstunden. Die Anzahl der aufgrund fehlerhafter oder unklarer Status zurückgehaltenen Bestellungen sank um fast 60 Prozent, während die Reihenfolge der Aufgaben für das Lager transparenter wurde.

Das Managementergebnis war vielleicht noch wichtiger. Früher dauerte es am Freitagnachmittag mehrere Stunden, um zusammenzustellen, wie viele Bestellungen eingegangen waren, wie viele erfüllt wurden, wo es Engpässe gab und welche Bestandsprobleme zu erwarten waren. Mit dem neuen Datenfluss wurde der Bericht nicht als perfekt automatisiertes Dokument erstellt, sondern es standen zuverlässige, aktuelle Daten zur Verfügung. Das Management konnte somit nicht auf Probleme der letzten Woche reagieren, sondern tagesaktuelle Entscheidungen treffen.

Auch die menschliche Seite verbesserte sich. Die Lagerkollegen erhielten keine widersprüchlichen Listen, der Vertrieb musste nicht telefonisch überprüfen, wo eine Bestellung steht, und der Kundenservice hatte klarere Status zur Verfügung. Der Prozess war weniger abhängig von einem einzigen routinierten Administrator, der zuvor einen Großteil der Ausnahmen im Kopf hatte.

Nicht jedes Ergebnis ist eine sofortige Einsparung

Es gibt Situationen, in denen das erste Ergebnis der Prozessentwicklung nicht weniger Arbeitsstunden, sondern mehr Kontrolle ist. Bei einem Produktionsunternehmen kann beispielsweise die Erfassung von Produktionsabweichungen langsam und inkonsistent sein. Zu Beginn der Entwicklung kann die Verwaltung sogar zunehmen, weil die zuvor mündlich behandelten Informationen auf regulierte Weise dokumentiert werden müssen. Dies mag kurzfristig unbequemer erscheinen.

Dennoch schafft dies die Grundlage dafür, später sichtbar zu machen, bei welcher Maschine, Schicht oder welchem Rohstoff das Problem wiederkehrt. In solchen Fällen ist das Ziel nicht, dass jede Dateneingabe verschwindet, sondern dass die erforderlichen Daten einmal, an der richtigen Stelle und in nutzbarer Qualität entstehen. Die Beschleunigung eines schlechten Prozesses erzeugt nur schneller Fehler.

Der Wert der Entwicklung muss daher immer an der geschäftlichen Situation gemessen werden. Eine kleine, selten wiederkehrende Ausnahme lohnt sich nicht unbedingt, teuer zu automatisieren. Bei einem täglich hundertfach wiederkehrenden, fehleranfälligen Schritt kann jedoch bereits eine kleine Anpassung eine erhebliche Wirkung erzielen. Für eine gute Entscheidung sind nicht technologische Begeisterung, sondern ein Gefühl für Proportionen und ein messbarer Ausgangspunkt erforderlich.

Wie bleibt das Ergebnis erhalten?

In den ersten Wochen nach der Einführung funktionieren viele Entwicklungen noch gut, weil alle darauf achten. Für ein dauerhaftes Ergebnis sind jedoch Verantwortliche, klare Betriebsregeln und regelmäßige Überprüfungen erforderlich. Wenn sich das Produktsortiment ändert, ein neuer Vertriebskanal startet oder das Team wächst, muss der Prozess erneut überprüft werden. Die alten Ausnahmen schleichen sich leicht wieder ein.

Es ist ratsam, die Schlüsselkennzahlen nicht nur als monatlichen Managementbericht zu behandeln. Wenn die betroffenen Führungskräfte die Entwicklung der Durchlaufzeit, der Ausnahmen und der Fehler sehen, können sie früher eingreifen. Ein guter Prozess ist nicht starr: Er ist geregelt, messbar und in der Lage, Veränderungen zu bewältigen, ohne dass er aus neuen Tabellen und E-Mail-Umwegen besteht.

Wenn die Erstellung eines Berichts im Unternehmen regelmäßig einen halben Tag in Anspruch nimmt, eine Bestellung in mehreren Systemen manuell erfasst wird oder ein kritischer Arbeitsprozess auf dem Wissen einer einzigen Person basiert, sollte nicht sofort ein System ausgewählt werden. Zuerst sollte verfolgt werden, wie die Arbeit und die Informationen fließen. Bereits diese Kartierung zeigt oft, wo mit der kleinsten Änderung der größte geschäftliche Erfolg erzielt werden kann.