system w łańcuchu dostaw jak start rakiety

System w Łańcuchu Dostaw – jak przeprowadzić wdrożenie?

System w Łańcuchu Dostaw jest źródłem wiedzy o wszystkich przepływach towarów, które mają lub powinny mieć miejsce w twojej organizacji.

Aborygeni mówią jednak, że wiedza to hałas dopóki nie wejdzie w mięśnie. Albo inaczej, nadmiar informacji wyłącznie przeszkadza. Dopiero wdrożenie wiedzy stanowi o sukcesie każdego plemienia.

Jeżeli jeszcze nie wiesz czy i jaki system informatyczny jest potrzebny w twojej firmie to przeczytaj najpierw mój poprzedni artykuł – Jak wybrać system wspierający planowanie dla Łańcucha Dostaw?

Jeżeli jednak wiesz co chcesz osiągnąć ale zastanawiasz się jak poprowadzić projekt to czytaj dalej. Poniżej przedstawiam szereg dobrych praktyk, które sprawdzą się na styku Łańcucha Dostaw, Logistyki, oraz IT. Nawet jeżeli nie prowadzisz operacji w Australii. 

Stwórz odpowiedni zespół

Dobry zespół to podstawa sukcesu każdego projektu. Dobry zespół składa się zarówno z osób wyselekcjonowanych z Łańcucha Dostaw (ekspertów funkcjonalnych) oraz z osób odpowiadających za oprogramowanie.

Z jednej strony doświadczenia operacyjnego praktycznie nie można przecenić w pracy nad nowymi rozwiązaniami. Wyłącznie ktoś kto na co dzień pracował w danym obszarze jest w stanie system w Łańcuchu Dostaw. 

Z drugiej strony wdrożenie nowego rozwiązania wymaga dużej wiedzy technicznej i analitycznego spojrzenia „z boku” na procesy, które mają zostać zautomatyzowane. 

Dlatego coraz częściej do pracy projektowej nad cyfryzacją Łańcucha Dostaw i Logistyki powołuje się tzw. zespoły DevOps, czyli łączące funkcje rozwoju, wdrożenia i utrzymania systemów. 

W pracy z tak  zróżnicowanym zespołem ważne jest poszanowanie doświadczeń oraz umiejętności poszczególnych osób. Inaczej  zespół posiadający teoretycznie idealne kompetencje nie dowiezie rezultatu.

Respect you team. Your team can literally make you or break you.

– Jennifer Bridges, Director www.projectmanager.com

Równie istotne jest wyznaczenie chociażby nieformalnych liderów poszczególnych obszarów projektu. Project Manager nie może i nie powinien prowadzić projektu samodzielnie. Po pierwsze nigdy nie posiada całej potrzebnej wiedzy. Po drugie nie byłoby to efektywne. 

Dobranie członków zespołu, zarządzanie relacjami między nimi i sprawienie, aby osobiście poczuli się właścicielami wdrażanego systemu stanowi sedno pracy menedżera projektu. 

Poza bezpośrednimi członkami zespołu, często zapomniana, a mająca znaczny wpływ na sukces całego projektu, jest rola mentora kierownika projektu. 

Dobrze aby mentorem była osoba, która posiada pewne doświadczenie w prowadzeniu projektów. Niemniej najważniejsza kwalifikacja mentora jest znajomość organizacji, jej procesów, a przede wszystkim kultury i ludzi w niej pracujących. 

Ponadto metor powinien charakteryzować się szeregiem cech i umiejętności miękkich. Ciekawą infografikę podsumowującą wspomniane cechy znalazłem na portalu The Engineered Lifestyles.

cechy mentora projektu

Mentorem nie musi być więc członek zarządu, dyrektor, czy starszy menedżer, który jest jednocześnie sponsorem projektu. Wręcz przeciwnie, mentorem powinna być osoba, która może na bieżąco wspierać project menedżera. 

W trakcie etapu poświęconego na stworzenie zespołu projektowego należy również zadbać o zgranie ze sobą osób pochodzących z różnych działów w organizacji jak i po stronie dostawcy oprogramowania. 

Zwłaszcza w wymagających znacznego zaangażowania projektach, konieczne jest zorganizowanie nieformalnej kolacji, lub innej aktywności towarzyskiej, która pozwoli na „przełamanie lodów” i poznanie się poszczególnych osób.

Zaniedbanie tego kroku formowania zespołu odbija się na późniejszych etapach prac. Ludzie, którzy do tej pory ze sobą nie pracowali i nie czują się częścią czegoś nowego rzadziej biorą na siebie odpowiedzialność za całość wdrożenia. 

Rzadziej również stają się ambasadorami nowego systemu w swoich macierzystych zespołach po zakończeniu projektu. 

Natomiast bez takiego podejścia w zespole szanse na zakończenie projektu sukcesem drastycznie spadają.

Przedstaw wszystkim zakres projektu

Jeżeli skompletowales i zgrałeś zespół projektowy to kolejnym krokiem powinno być przedstawienie wszystkim zainteresowanym zakresu projektu. 

Zakres projektu oznacza zarówno objęty pracami  obszar funkcjonalny, oraz przewidywany czas i koszt wdrożenia.

Natomiast stwierdzenia „wszyscy zainteresowani” oznacza zarówno interesariuszy w twojej organizacji i poza nią. Obejmuje dosłownie wszystkich, na których pracę lub wyniki wpłyną planowane zmiany w Łańcuchu Dostaw. 

Zazwyczaj oznacza to sponsorów projektu, zespoły sprzedaży, oraz zespół logistyki bądź operacji. 

Niemniej na tym etapie, jeżeli masz wątpliwości czy kogoś poinformować o przewidywanych rezultatach projektu, najlepiej przyjąć, że powinieneś. 

Nikt. Nigdy. W żadnym projekcie. Nie powiedział jeszcze, że żałuje czasu poświęconego na przedstawienie innym czego powinni się spodziewać.

Komunikacja na tym etapie pozwala zarówno uniknąć zaskakiwania sponsorów pod koniec projektu jak i ograniczyć rozciąganie zakresu projektu w momencie gdy jest to najbardziej kosztowne. 

Scope creep: the ever present danger in any project where you keep adding requirements and objectives until the whole thing become unruly mess that you can’t deliver on.

– Brain Westfall, Senior Analyst, Gartner Company

Naprawdę pod koniec prac nie chcesz odkryć, że Dyrektor Handlowy poprzez stwierdzenie „zautomatyzowanie zamówień” rozumie również obliczanie wysokości rabatów, a nie wyłącznie wymaganych wolumenów.

Nie chcesz również na końcu prac projektowych podnosić budżetu projektu i wydłużać czasu jego trwania, ponieważ koniecznie trzeba uwzględnić funkcje pierwotnie nie ujęte w specyfikacji.

Dlatego w szczególności informuj wszystkich co nie wchodzi w zakres projektu i zbierz w ramach jednego dokumentu wszystko co zostało potwierdzone. 

Określ liczbowo cele i kamienie milowe

Wdrożyć system w Łańcuchu Dostaw to projekt. Dlatego powinieneś posiadać sprecyzowane oraz określone w czasie cele. 

Zazwyczaj nadrzędnym celem jest dopasowanie możliwości Łańcucha Dostaw do potrzeb reszty organizacji, lub zapewnienie ciągłości operacji przy rosnącej skali biznesu. 

Aby jednak na koniec projektu bez wątpliwości potwierdzić czy wdrożenie zakończyło się sukcesem należy określić jakie wskaźniki ilościowe odpowiedzą na to pytanie. 

Najczęściej w zależności od rodzaju biznesu stosuje się 2-3 z niżej wymienionych miar funkcyjnych:

  • poziom realizacji zamówień Klienta
  • dostępność produktu w sklepie
  • dokładność prognoz popytu
  • zapas przestarzały i nadmiarowy
  • ogólny poziom rotacji zapasu
  • straty w zapasie

Przy ocenie wyników wdrożenia nie powinno się natomiast stosować przekrojowych wskaźników takich jak koszty logistyki względem sprzedaży lub cykl cash-to-cash.

Tego typu międzyfunkcyjne miary mają wielkie znaczenie dla oceny efektywności całej firmy. Z definicji zależą jednak od działania wielu funkcji. Nie pomagają więc przy analizie tego jak działa system w Łańcuchu Dostaw. 

Po potwierdzeniu wskaźników warto również spisać sposób wyliczania każdego z nich oraz określić okres referencyjny względem, którego będziemy mierzyć różnice.

If you can not describe quantitatively what you are doing as a process, you do not know what you are doing.

– W. Edward Deming, The American Who Taught Japanese About Quality

Wiele firm w różny sposób wylicza wskaźniki Łańcucha Dostaw. Dlatego wszelkie różnice w rozumieniu wybranych miar najlepiej wyjaśnić z dostawcą oprogramowania już na etapie wyznaczania celów. 

Poza wyznaczeniem jasno sprecyzowanych celów wdrożenia na tym etapie menedżer projektu powinien również określić główne kamienie milowe. 

Nie chodzi jeszcze o szczegółowy plan projektu. Na to przyjdzie pora później gdy sponsorzy i interesariusze projektu potwierdza ogólny kierunek prac. 

Wcześniej kamienie milowe stanowią sposób na podzielenie pracy na fazy zarządzalne z perspektywy osoby nie posiadającej wiedzy eksperckiej. 

Wdrażając system w Łańcuchu Dostaw można przyjąć następującą listę kamieni milowych:

  • ustalone źródła danych
  • stworzone mapy procesów 
    • prognozowania popytu
    • planowania produkcji
    • planowania dystrybucji
  • spisana lista rozbieżności
  • stworzona mapa interface’ów
  • udostępniona infrastruktura techniczna 
  • zainstalowane wszystkie moduły systemu
  • zakończone testy integracyjne systemu
  • akceptacja kluczowych użytkowników

Należy jednak pamiętać, że w każdym projekcie kamienie milowe będą odmienne. Będą zależeć od zakresu wdrażanych modułów, metodologii projektowej, oraz architektury technicznej wybranego systemu. 

Jak przejść przez techniczne meandry? 

Aby prowadzić projekt wdrożenia nie musisz być architektem systemów. Nie musisz również posiadać dyplomu z informatyki. 

Warto jednak wiedzieć o kilku kluczowych sprawach i świadomie wybierać pomiędzy alternatywnymi podejściami. 

Po pierwsze przed rozpoczęciem wdrożenia sprawdź razem z wybranym dostawcą oprogramowania czy wymagane dane podstawowe są dostępne.

Jeżeli jakość danych podstawowych nie spełnia wymagań, lub co gorsza jeszcze nie wszystkie potrzebne dane są zbierane, jest to ostatni moment aby wprowadzić zmiany. 

W wielu organizacjach zarządzanie danymi podstawowymi traktowane jest po macoszemu. Błędy na tym etapie przenoszą się jednak jak w efekcie domina na wyniki całego projektu.

Few people understand how many projects fail due to the lack of relevant master data.

– Mikre Ferguson, Managing Director, Intelligent Business Strategies

Po drugie wybór technicznej architektury systemu to decyzja biznesowa, której nie można pozostawić w rękach samego IT.

Najważniejszą decyzją w kwestii architektury będzie czy zdecydujesz się na wdrożenie lokalne czy też w chmurze. 

Systemy w chmurze (tzw. cloud based) są utrzymywane na serwerach dostawcy i dostępne dla użytkowników poprzez przeglądarki internetowe. 

Systemy implementowane lokalnie (tzw. on premise) są instalowane na komputerach i serwerach należących do firmy.

Niektórzy dostawcy oferują również wdrożenie hybrydowe, w których chmura jest „prywatna” tzn. lokalnie utrzymywana na serwerach organizacji. Większość posiada w swojej ofercie możliwość implementacji na oba wymienione sposoby. 

Szczegółowe omówienie różnic pomiędzy podejściami on-premise oraz cloud based, a także opis zalet i wad każdego z nich, możesz znaleźć na portalu SoftwareAdvice.

system w łańcuchu dostaw architektura

Najważniejsze z punktu widzenia biznesu jednak jest, że rozwiązania w chmurze przekładają się przede wszystkim na wydatki operacyjne. Natomiast rozwiązanie instalowane na własnych serwerach stanowią wydatek kapitałowy. 

Ponadto rozwiązania w chmurze stosowane są w wielu organizacjach jednocześnie i jako takie wymagają większej standaryzacji ale za to znacznie szybciej są aktualizowane. 

Systemy implementowane lokalnie dają natomiast większe możliwości dostosowania procesu do danej organizacji ale za to znacznie wolniej ulegają zmianom. 

Aby zdecydować o jaką architekturę powinien być oparty system w Łańcuchu Dostaw należy zadać sobie kilka pytań:

  • czy oczekujemy wyników szybko (cloud) 
  • czy chcemy sami zarządzać danymi (on premise)
  • jak standardowe jest nasze planowanie (cloud) 
  • jak chcemy kontrolować proces (on premise)

Każda kolejna, bardziej szczegółowa decyzja techniczna powinna również współgrać ze sposobem prowadzenia danego biznesu i podlegać podobnej weryfikacji na podstawie nietechnicznych pytań.

Jakie podejście do wdrożenia wybrać? 

Najczęściej stosowane obecnie podejścia do implementacji systemów informatycznych to podejście iteracyjne, oraz podejście przyrostowe. Oba należą do tzw. zwinnych metod projektowych.

Podejście iteracyjne oznacza stopniowe opracowywanie oraz dostosowywanie do wymogów kolejnych elementów systemu. Celem tego podejścia jest jak najszybsze dostarczenie działającego aczkolwiek wciąż nie kompletnego systemu.

Aby lepiej zobrazować co oznacza podejście iteracyjne posłużę się analogią pochodzącą z serwisu Agile247. Podejście iteracyjne można porównać do tworzenie rzeźby w następujący sposób:

system w łańcuchu dostaw wdrożenie  iteracyjne

Gdy wdrażamy system w Łańcuchu Dostaw podejście iteracyjne oznacza wdrożenie w pierwszej kolejności standardu oferowanego przez dostawcę. Następnie stopniowe dostosowywanie systemu do specyficznych potrzeb danej organizacji. 

W rezultacie zastosowania podejście iteracyjnego do implementacji można odnotować kilka korzyści biznesowych:

  • otrzymanie całościowego (choć standardowego) rozwiązania wcześniej, 
  • szybszy zwrot z inwestycji niż przy innych podejściach, 
  • jednoczesne uczenie się całego zespołu. 

Podejście przyrostowe oznacza natomiast dodawanie do działającego systemu samodzielnych fragmentów, które stanowią część większej planowanej całości. Ponownie posługując się analogia do tworzenia rzeźby można zobrazować podejście przyrostowe jako następujący proces:

system w łańcuchu dostaw wdrożenie przyrostowe

W odniesieniu do wdrażania systemu w Łańcuchu dostaw podejście przyrostowe może oznaczać najpierw implementację modułu do planowania popytu, później modułu do dystrybucji, a następnie kolejnych związanych z optymalizacja zapasu. 

Podejście przyrostowe cechuje się dwoma pozytywnymi rezultatami z punktu widzenia biznesu:

  • otrzymanie częściowej informacji o wynikach wdrożenia już w trakcie projektu, 
  • wprowadzenie kompletnych części systemu wcześniej niż w podejściu iteracyjnym,

Szerzej o potencjalnych korzyści oraz zagrożeniach związanych z zastosowaniem każdego podejścia możesz przeczytać w artykule opublikowanym na Agile247.

Które podejście jednak najlepiej wybrać we wdrożeniach na potrzeby Łańcucha Dostaw? 

Jeżeli w twojej organizacji funkcjonuje już zestaw rozwiązań, z których korzysta Łańcuch Dostaw prawdopodobnie lepszym rozwiązaniem jest podejście przyrostowe. 

W tym przypadku projekt polega na dodawaniu kolejnych elementów do działającego już środowiska. W pewnym sensie chodzi o cyfrowa ewolucję. 

Jeżeli natomiast jesteście na etapie wdrożenia pierwszego kompletnego zestawu rozwiązań dla Łańcucha Dostaw. Prawdopodobnie lepiej jest zdecydować się na podejście iteracyjne. 

W tym przypadku można mówić o cyfrowej rewolucji w Łańcuchu Dostaw.

Jak wystartować… bez falstartu?

Przyjmijmy, że prace projektowe poszły zgodnie z planem, system w Łańcuchu Dostaw został zainstalowany, przeszedł testy, a wyniki zostały potwierdzone przez kluczowych użytkowników.

Czego więc się obawiać? Dlaczego po prostu nie wystartować na dużą skalę? 

W praktyce na tym etapie jeszcze wszystko jest jeszcze możliwe. Naprawdę można się przekonać, że wiedza to hałas zanim wejdzie w mięśnie. 

Nasz nowy system to wciąż tylko teoria. W zderzeniu z prawdziwymi danymi, zmianami w czasie rzeczywistym, przy wielu jednoczesnych użytkownikach może dojść do nieprzewidzianych interakcji i błędów, które krytycznie wpłyną na biznes. 

Niestety boleśnie przekonał się o tym amerykański producent czekolady – firma Hershey. 

Zarząd Hershey postanowił przyspieszyć prace, aby zakończyć wdrożenie przed znaczącym dla producentów czekolady sezonem Halloween. Zespół projektowy ograniczył więc etap testów i wyznaczył nowe krótsze terminy.

[back then] it was a terrifying new prospect for investors to consider: Could a failed computer project take down a Fortune 500 company?

– Christopher Koch, Editor & Research Analyst, www.cio.com

W efekcie system wystartował przed Halloween. Niemniej, pomimo odpowiednich zapasów, ze względu na błędy systemu Łańcuch Dostaw Hershey nie był w stanie zrealizować zamówień o wartości blisko 100 mln USD. 

Przełożyło się to na 19% spadek zysków w 4 kwartale oraz 8% spadek cen akcji Hershey na koniec roku. Więcej na ten temat możesz przeczytać w analizie PEMECO Consulting.

Dlatego najlepsza praktyka jest zaczynać powoli. Wybrać „kawałek biznesu” na którym można przetestować realny proces zanim ruszy pełna parą. W zależności od rodzaju i struktury organizacji sensowne może być wybranie:

  • kategorii produktów z jednej fabryki, w firmach produkcyjnych
  • niewielkiej listy oddziałów, lub sklepów, w przypadku sieci handlowych
  • ograniczonej grupy Klientów, w przypadku firm usługowych

Przy czym na końcu projektu, tak jak na jego początku, należy poinformować wszystkich interesariuszy co się będzie działo. Na tym etapie lista osób zainteresowanych powinna obejmować również naszych Klientów i Dostawców. 

Pozwoli to na zarządzanie zmianą w trakcie prac projektowych, a nie po zakończeniu wdrożenia, oraz na przygotowanie lub aktualizację standardowych procedur działania. 

If supply chain had an arch enemy it would be called “Bad Communication”.

– www.EverythingSupplyChain.com

Testy na wybranym zakresie produktów, sklepów, lub Klientów muszą trwać przynajmniej 3 okresy planowania. W przypadku jeżeli wszystko idzie zgodnie z oczekiwaniami. W przeciwnym razie testy należy wydłużyć o czas na zmiany w ustawieniach systemu. 

Wydłużenie okresu testów może również okazać się konieczne jeżeli twoja organizacja planuje w cyklach krótszych niż miesiąc. 3 cykle planowania nie będą wtedy po prostu wystarczające do analizy uzyskanych wyników.

Jeżeli nasze “rozpoznanie bojem” poszło dobrze to wreszcie nadeszła pora na zmianę w kolejnych obszarach organizacji, dokumentację zdobytego doświadczenia i świętowanie zakończonego sukcesem projektu!

Zamiast zakończenia

Zarządzanie Łańcuchem Dostaw przechodzi w ostatnich latach wielkie zmiany. Zaczęła się cyfrowa transformacja w tym obszarze. 

Jeszcze nigdy sukces lub porażka organizacji produkcyjnych jak i handlowych nie zależały w takim stopniu od doskonałości Łańcucha Dostaw. Doskonałości, której nie można osiągnąć wykorzystując stare systemy (tzw. legacy solutions).

Dlatego tak wiele firm prowadzi, bądź będzie wkrótce prowadzić, wdrożenia nowych rozwiązań i poszukuje liderów posiadających nowe umiejętności. 

Prowadzenie projektów we współpracy z IT jest jedną z poszukiwanych cech nowoczesnego lidera. Zdolność do zarzadzania zmiana i rozwojem kompetencji zespołu pozostają jednak najważniejszymi umiejętnościami w Łańcuchu Dostaw.

Wchodzimy już jednak w kwestie kompetencji Dyrektora Łańcucha Dostaw (lub coraz częściej Chief Supply Chain Officer). Na ten temat napisałem już jednak jakiś czas temu artykuł – Cechy dobrego Logistyka czyli kto powinien zarządzać Łańcuchem Dostaw.

Jeżeli interesuje Cię jakich cech szukać u kandydata na szefa swojej Logistyki to zachęcam do jego przeczytania.

Jeżeli natomiast po przeczytaniu tego wpisu czujesz potrzebę dowiedzieć się więcej o tym jak wdrożyć system w Łańcuchu Dostaw dla swojej firmy – napisz do mnie bezpośrednio lub zostaw komentarz poniżej. Na pewno odpowiem.

Zachęcam również do zapisania się na newsletter. Zapisując się otrzymasz edytowalną listę systemów wspierających planowanie w Łańcuchu Dostaw. Zawsze będziesz również na bieżąco z najciekawszymi i najbardziej użytecznymi informacjami publikowanymi na blogu.

Tymczasem do kolejnego wpisu. Publikuję regularnie w sobotę co dwa tygodnie.

5 komentarzy

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *