Folge 5: Die Implementierung
Ende des vierten Teils ist nach umfangreicher Bewertung die finale Entscheidung zum Outsourcing gefallen, auch der künftige Partner wurde ausgewählt. In dieser Folge kümmern wir uns nun um die erfolgreiche Implementierung mit dem ausgewählten Partner. Im Prinzip geht es hier um klassisches Projektmanagement, um im Rahmen zu bleiben werde ich daher nur einige Bereiche ansprechen, bei denen es gemäß meiner Erfahrung immer wieder Probleme bei Logistik-Outsourcing-Projekten gibt.
Wie wird im Projekt zusammengearbeitet?
Im Outsourcing-Projekt kommen zwei oder auch mehr Partner zusammen, die in den meisten Fällen noch nicht in vergleichbaren Umfang zusammengearbeitet haben. Implementierte Projektstandards bei Partner A unterscheiden sich, teils in Details, teils in maßgeblichen Punkten, von denen bei Partner B. Viele Unternehmen kennen in diesem Bereich auch noch gar keine Standards und überlassen die Methodik uneingeschränkt dem jeweiligen Projektleiter. Nicht immer werden auch Personen mit der Projektleitung betraut, die im Projektmanagement erfahren sind. Viel Raum für Missverständnisse – sofern man nicht zeitgerecht gemeinsame Regeln für das Projekt definiert.
Es empfiehlt sich somit, die wesentlichen Rahmenbedingungen und Regeln des Projekts schriftlich festzuhalten und gemeinsam zu verabschieden. Einigkeit muss, unter anderem, gegeben sein zu den Projektzielen, den Nichtzielen, dem Projektbudget, den Dokumentationspflichten, der Häufigkeit und Form der Projektmeetings, der regelmäßigen Information der Stakeholder, den Mechanismen im Konfliktfall und noch vielem mehr.
Wen brauchen wir im Projektteam?
Wir benötigen nicht die Menschen, die gerade verfügbar sind, sondern die Menschen, die die erforderliche Kompetenz für die jeweilige Aufgabe mitbringen. Klingt absolut logisch, oder? Leider sind es aber gerade diese kompetenten Experten, die oft schon mit anderen Aufgaben ausgelastet sind. Für ein erfolgreiches Projekt muss diesen Kollegen genügend Freiraum geschaffen werden. Anhand des zu erstellenden Projektplans kann der Aufwand im jeweiligen Zeitraum bestimmt werden – und die Zeit diesen Aufwand abzuarbeiten muss dem Projektteam von der Unternehmensführung zur Verfügung gestellt werden. Zugegebenermaßen eine schwierige Aufgabe, vor allem für kleinere Unternehmen, aber eine der wichtigsten Maßnahmen zum Projekterfolg.
Warum das Steering Committee wichtig ist
Ich habe in meiner Berufspraxis leider immer wieder Projekte miterlebt, in denen das Steering Committee entweder gar nicht oder nicht mit den richtigen Personen besetzt war. Dabei ist das Steering Committee ein wichtiges Gremium für den Projekterfolg, vor allem wenn es gilt in die Rahmenbedingungen des Projekts einzugreifen. Das Steering Committee hat, unter anderem, die Aufgabe, den Projektfortschritt zu überwachen und vom Projektleiter aufgezeigte Hindernisse zum Projekterfolg, die das Projektteam nicht selbst lösen kann, aus dem Weg zu räumen. Ein Beispiel dafür ist die Zuführung/Freistellung benötigter Ressourcen. Als Teil des Steering Committees in mehreren Projekten muss ich an dieser Stelle appellieren diese Aufgabe auch ernst zu nehmen. Diese Verantwortung ist mit Aufwand verbunden, der über die Teilnahme an den Steering Committe Meetings hinausgeht. Die Projektleiter wiederum sind gut beraten diese Meetings nicht als reine Informationsveranstaltung zu sehen, sondern das Forum auch für Entscheidungen bei offenen Fragen und für die Einbindung des Gremiums zur Lösung von Problemen, die über die Kompetenz des Projektteams hinausgehen, zu nutzen. Kein Manager will beim Steering Committee die Informationen der letzten Projektreports nochmal vorgetragen bekommen, da ist das Interesse ganz schnell weg. Mein Appell an die Projektleiter: Nutzen Sie die wertvolle Zeit und Aufmerksamkeit für wirklich Wichtiges.
Müssen wir alles aufschreiben?
Ja, definitiv. Und zwar nicht nur wenn es Konflikte im Projekt gibt sondern auch wenn die Entscheidungen reibungslos getroffen werden. Mangelnde Dokumentation wird spätestens dann zum Problem, wenn die handelnden Personen nicht mehr zur Verfügung stehen, sowohl im Projekt als auch im späteren operativen Betrieb. Alles was in schriftlicher Form ordentlich dokumentiert und von beiden Seiten bestätigt wurde ist unstrittig. Inhaltlich im Lichte neuerer Erkenntnisse vielleicht nicht mehr korrekt, aber unstrittig. Meetingprotokolle müssen Standard sein. Zusätzlich sollten einige Standarddokumente geführt, Fortschritte überwacht und Inhalte regelmäßig abgestimmt werden. Den Projektplan habe ich oben ja schon erwähnt, zusätzlich sind z.B. Tools zur Projektbudgetkontrolle, eine Open Issue-List, ein Decission-Log, ein Risk-Log und eine To-Do-List als Werkzeuge für den Projektleiter ratsam.
Prozesse und deren technische Umsetzung
Zusätzlich zu den oben erwähnten Tools sehe ich in Projekt zum Logistik-Outsourcing zumindest drei zentrale Dokumente. Zum einem der Dienstleistungsvertrag der die prinzipiellen Recht und Pflichten der Vertragsparteien regelt. So ein Vertrag ist in der Regel eine Kooperationsarbeit von Juristen und Logistikexperten. Das stellt sicher, dass sowohl die rechtlichen als auch die fachlichen Faktoren berücksichtigt werden.
Mehr in die Tiefe geht dann das Operations Manual, in dem alle Prozesse mit den jeweiligen Rechten und Pflichten der Partner definiert werden. Je mehr dieses Dokument in die Tiefe geht, z.B. in dem auch möglichst alle Abweichungs- und Sonderprozesse dokumentiert werden, umso weniger Raum für Konflikte und individuelle Interpretationen bleibt im operativen Betrieb. Ein wichtiger Bestandteil des Operations Manual sind auch Details zu den vereinbarten Leistungskennzahlen (KPI). Auf das Thema KPI im Logistikbereich und wie sehr man bei der Definition ins Detail gehen sollte werde ich in einem künftigen Blog-Beitrag eingehen.
Korrespondierend zum Operations Manual läuft die Erstellung der IT-Dokumentation. Prozess vor IT, das ist zumindest mein Credo. In der Praxis darf man das aber nicht ganz so strikt sehen. Nicht jedes IT-System ist in der Lage jeden Prozess wie gewünscht abzubilden, nicht alles was sich der Logistiker wünscht kann der IT-Kollege liefern. Nicht immer macht eine mögliche Anpassung des IT-Systems wirtschaftlich Sinn. Kompromisse sind somit gefragt. Die beste Gesamtlösung in Bezug auf Kosten zu Nutzen erhält man durch enge gegenseitige Einbindung der IT-Kollegen in die Prozessplanung und der Logistiker in die Planung der IT-Prozesse.
Die IT-Dokumentation muss, korrespondierend zum Operations Manual, die relevanten Prozesse aller involvierten Systeme sowie die für die Datenübergabe verwendeten Schnittstellen und Übertragungswege im Detail beschreiben. Widersprüche zwischen Operations Manual und IT-Dokumentation müssen auf jeden Fall vermieden werden.
Das funktioniert jetzt aber nicht wie geplant!
Auch mit bester Vorbereitung kann es passieren, dass man in der intensiven Projektarbeit auf Themen stößt die nicht wie geplant umgesetzt werden können. Kein Problem, sofern man einen soliden Change Management Prozess im Projekt implementiert hat. Jede Änderung zum ursprünglichen Plan wird dokumentiert und die Auswirkungen der Änderung in Bezug auf Machbarkeit, Kosten, Zeitplan und Wechselwirkungen auf andere Prozesse/Bereiche untersucht. Ob man die gewünschte Änderung umsetzt wird im Rahmen der zuvor definierten Projektregeln entschieden. Auch die kurzfristige Einbindung des Steering Committee ist bei größerer Auswirkung durchaus empfohlen. Durchaus legitim ist es auch Änderungen zu priorisieren und, sofern möglich, erst in einem zweiten Schritt nach dem Go Live zu implementieren. Das kann zwar den Gesamtaufwand erhöhen im Gegenzug aber durch die zeitliche Entzerrung das Implementierungsrisiko minimieren.
Testen, testen, testen – und dann schulen
Ein in vielen Projekten schwer unterschätztes Thema ist das Testen der implementierten Lösung. Für den Test operativer Prozesse muss man durchaus kreativ denken. Nicht immer ist es möglich die Prozesse bereits deutlich vor dem Go Live mit der richtigen Ware oder auch am vorgesehenen Standort durchzuführen. Vielleicht gibt es aber ähnliche Ware oder auch Dummy-Artikel mit vergleichbaren Parametern oder auch einen anderen Bereich oder Standort, an dem die Prozesse bereits implementiert wurden. Das gleiche gilt auch für das Training der Mitarbeiter. Von einem Tag auf den anderen grundlegende Prozesse zu ändern und dann erst im laufenden Betrieb damit zu starten die Mitarbeiter zu schulen ist zwar auch eine (risikobehaftete) Möglichkeit – aber nur mit sehr viel Planung und wenn es wirklich nicht anders geht.
Mehr im Fokus steht in der Regel der Test der IT-Prozesse. Diesen vollständig durchzuführen ist meines Erachtens nicht möglich. Immer wieder wird es in der Praxis Konstellationen geben, die man in der Planung der Tests nicht berücksichtigt hat. Das ist in Ordnung, wenn es sich dabei um Sonderfälle handelt. Wenn ich von 500 Vorgängen bei 2 eine Konstellation vorfinde, die in den Tests nicht berücksichtigt wurde, wird das Team in der Lage sein diese Probleme kurzfristig zu lösen. Wenn ich im operativen Betrieb aber z.B. bei 100 dieser 500 Vorgänge in Probleme laufe ist das kritisch für den Betrieb. Diese große Anzahl der Probleme wäre wohl nach Priorisierung nur sequenziell abzuarbeiten, die Anzahl der weiteren Problemfälle steigt während dieser Lösungszeit. Die Auswirkungen können dramatisch sein. Der Abbau solcher operativen Rückstände kann sich über viele Tage oder Wochen erstrecken – und das gleich zum Start der Zusammenarbeit. Oft auch mit direkten Auswirkungen auf das Kerngeschäft des Auftraggebers (Fehler in der Auslieferung, Nichteinhaltung von Lieferfristen, …).
Tests müssen also gut geplant werden und sollen alle denkbaren Konstellationen abdecken. Die Kombination der verschiedenen Parameter führt somit schnell zu einer dreistelligen Anzahl an Testfällen. Das ist viel Aufwand, der auch in der Planung der Projektlaufzeit berücksichtigt werden muss. Das Problem der Testphase: sie liegt zwischen der Implementierung der Prozesse und dem Go Live. Bei Verzögerungen in vorangegangenen Phasen wird leider oft die Dauer der Testphase verkürzt, um den Go Live Termin halten zu können. Ein gefährliches Spiel dessen mögliche Konsequenzen oft unberücksichtigt bleiben. Es geht ja nicht nur darum Fehler durch die Tests aufzudecken, diese müssen ja auch noch korrigiert und neuerlich getestet werden.
Fazit: Fokus auf das Projekt!
Die Implementierung ist der Teil mit dem meisten Aufwand aber auch mit den größten Auswirkungen auf die, hoffentlich langfristige, Zusammenarbeit. Projekte die weniger Aufwand als initial geplant aufweisen sind rar, meist stößt man in der Implementierung auf Aufgaben die ursprünglich gar nicht berücksichtigt oder zu optimistisch bewertet wurden. Planen Sie nicht am Limit sondern lassen Sie Raum für Unvorhergesehenes. Stellen Sie sicher, dass das Projekt den Stellenwert hat, den es benötigt. Fokus und Aufmerksamkeit auf die Aufgaben und deren Ausführung!
Wie geht es in der Serie weiter?
Im sechsten und letzten Teil der Serie starten wir mit dem Go Live und haben dann einen genauen Blick auf die langfristige Zusammenarbeit zwischen Auftraggeber und Dienstleister.
Ich freue mich sehr über Ihre Rückmeldung zur Serie und beantworte gerne Ihre Fragen. Meine Kontaktdetails finden Sie hier.
Sie wollen stets informiert bleiben? Kein Problem! Melden Sie sich für meinen kostenlosen Logistik-Newsletter an. Hier geht’s zur Anmeldung.
Die vollständige Blog-Serie zum Outsourcing von Logistikleistungen
Folge 1 | Folge 2 | Folge 3 | Folge 4 | Folge 5 | Folge 6
Veröffentlicht am 10. Februar 2021
Titelbild: iStock.com/AndreyPopov