Prozessmapping 101: Ein praktischer Leitfaden
Jedes Unternehmen hat Prozesse. Die meisten haben sie nie dokumentiert. Wie Sie anfangen und warum es wichtig ist.
Eine Tourenplanungssoftware optimiert, was Sie ihr geben. Das sind die Lehren aus dem Rollout von Roadnet in einem periodischen Lieferbetrieb: Daten, Gebiete, ein regionaler Pilot und die Fahrer, die wissen, was das System nicht weiß.
Tourenplanungssoftware verspricht weniger Kilometer, vollere Transporter und berechenbarere Tage. Ob Sie das bekommen, hängt weit weniger von der Software ab als davon, wie Sie sie ausrollen. Eine Planungsengine optimiert, was Sie ihr geben. Füttern Sie sie mit veralteten Adressen, geschätzten Servicezeiten und Gebieten, die seit Jahren niemand hinterfragt hat, liefert sie sauber optimierte Versionen derselben Probleme.
Dieser Artikel teilt die Lehren aus dem Rollout von Roadnet in einem periodischen Lieferbetrieb, und was jedes Unternehmen, das eine Roadnet-Implementierung plant (oder eine bestehende neu aufsetzen will), richtig machen sollte.
Die Anbieter sind sich in diesem Punkt einig. Descartes, das Tourenplanungssoftware verkauft, formuliert es in seiner eigenen Implementierungsanleitung klar: Daten und Integration sind die zwei größten Implementierungsrisiken und verdienen ebenso viel Aufmerksamkeit wie die Auswahl der Lösung. [1]
Für die Tourenplanung bedeutet „Daten“ mehr als Kundenadressen:
Kommen diese Eingaben aus der Historie („wir waren immer dienstags dort“), respektiert die Engine die Historie. Kommen sie aus Messung, kann sie sie verbessern. Diese Daten zu erheben und zu prüfen ist der unspektakulärste Teil des Projekts, und der Teil, der das Ergebnis entscheidet.
Viele Lieferbetriebe haben Gebiete, die organisch gewachsen sind: das Revier eines Fahrers, eine Region, die vor Jahren gezeichnet wurde, ein Tag, der zugewiesen wurde, weil ein Kunde einmal danach gefragt hat. Touren innerhalb dieser Grenzen zu optimieren bringt eine lokale Verbesserung. Die Grenzen mit Daten neu zu ziehen ist der Ort, an dem die größeren Gewinne meistens liegen.
Das ist ebenso eine Geschäftsentscheidung wie eine Planungsentscheidung. Kunden zwischen Tagen oder Fahrern zu verschieben berührt Servicezusagen, Vertriebsbeziehungen und den Alltag der Menschen. Treffen Sie diese Entscheidungen ausdrücklich, mit Betrieb, Vertrieb und Kundendienst am Tisch.
Ein Rollout der Tourenplanung sollte kein Big Bang sein. Wählen Sie eine Region oder ein Depot, fahren Sie die neuen Pläne, und messen Sie sie gegen eine vereinbarte Basis: Distanz, Zeit auf der Straße, Stopps pro Tour, Pünktlichkeit. Passen Sie die Parameter an die lokalen Bedingungen an, und gehen Sie dann zur nächsten Region.
Dieser Ansatz leistet zwei Dinge. Er fängt Daten- und Parameterprobleme ab, solange sie noch klein sind. Und er gibt Planern und Fahrern den Beweis, aus ihren eigenen Touren, dass die neuen Pläne funktionieren. Die Anleitung des Anbieters empfiehlt dasselbe: zuerst in einem begrenzten Umfang validieren, dann nach Region oder Geschäftsbereich ausweiten. [1]
Fahrer wissen Dinge, die kein System weiß: welcher Kunde vor 10 Uhr nie da ist, welche Straße am Markttag gesperrt ist, wo ein Transporter tatsächlich parken kann. Ignorieren die neuen Touren dieses Wissen, ändern Fahrer sie stillschweigend, und Plan und Wirklichkeit driften auseinander.
Beziehen Sie erfahrene Fahrer ein, wenn Servicezeiten und Zufahrtsregeln geprüft werden. Zeigen Sie den Planern, warum die Engine eine Reihenfolge gewählt hat, nicht nur welche. Und machen Sie es einfach, einen Stopp zu melden, der nicht funktioniert, damit die Daten besser werden, statt dass der Workaround dauerhaft wird.
Tourenplanung ist keine einmalige Konfiguration. Kunden ziehen um, öffnen oder schließen, Mengen ändern sich und neue Einschränkungen kommen hinzu. Ohne jemanden, der die Planungsparameter verantwortet und weiter misst, fallen Touren zur Gewohnheit zurück. Richten Sie ein regelmäßiges Reporting auf denselben Kennzahlen ein, die Sie im Pilot genutzt haben, und geben Sie einer Person die klare Verantwortung für die Tourenplanung.
Bei Sip-Well hat Ben den Roadnet-Rollout geleitet. Der Ansatz folgte den Schritten oben: zuerst die Lieferdaten analysieren, Roadnet auf Basis dessen konfigurieren, was die Daten zeigten, Region für Region ausrollen und danach weiter beobachten. In den Worten von Eddy Brotmann, Operations Director, Sip-Well:
Bens strukturierter, datengetriebener Ansatz beim Roadnet-Rollout gab uns vom ersten Tag an Vertrauen. Die Ergebnisse übertrafen unsere Erwartungen und haben grundlegend verändert, wie wir unsere Lieferungen planen.
Eddy Brotmann, Operations Director, Sip-Well
Die ganze Geschichte steht auf unserer Sip-Well-Fallstudienseite.
Fallstudie: der Roadnet-Rollout bei Sip-Well
Eine Roadnet-Implementierung gelingt oder scheitert an Daten, Gebieten und Menschen, in dieser Reihenfolge. Die Software übernimmt die Optimierung. Ihre Aufgabe ist es, ihr die Wahrheit über Ihren Betrieb zu geben und dafür zu sorgen, dass die Organisation dem Ergebnis vertraut.
1. Descartes, „Route Planning Buying and Implementation Tips“
WEITERLESEN
Jedes Unternehmen hat Prozesse. Die meisten haben sie nie dokumentiert. Wie Sie anfangen und warum es wichtig ist.
Die meisten ERP-Projekte dauern 6 bis 18 Monate. Wir haben sie in 12 Wochen live genommen, und ein ERP in Tschechien war in 16 Wochen bereit. Der Kunde hat den Go-live danach gestoppt.
Ben Van Aken arbeitet als freiberuflicher Business Application Architect für ERP, CRM und Planungstools wie Roadnet, vor Ort, hybrid oder remote.
Aktuell nehmen wir neue Engagements an, ab sofort und bis ins Jahr 2027.
Kommentare
Kommentare werden geladen…