lukaszkogut.pl

Odcinek 8 serii: AgileBA w praktyce wdrożenia WMS

Pierwsze pytanie dostawcy WMS na początku projektu bywa takie:

„Jakie funkcje są Wam potrzebne?”

A pierwsze pytanie analityka powinno brzmieć:

„Jak to działa dzisiaj?”

Bo jeśli nie wiemy, jak proces wygląda teraz, to nie wiemy, co poprawiamy. Możemy tylko przenieść obecny bałagan do nowego systemu, tym razem z licencją.

Czym jest model w AgileBA

Zacznijmy od tego, czym w ogóle jest model. AgileBA definiuje go szeroko: schematy, szkice, ilustracje, zbudowane artefakty i prototypy, które uwidaczniają sytuację, którą chcemy przekazać innym. Mogą przedstawiać aktualną sytuację, proponowaną zmianę albo coś, co ma być wykorzystane w przyszłości.

I od razu ważne zastrzeżenie, które metodyka podkreśla wprost: modele nie powinny zastępować komunikacji twarzą w twarz. Diagram jest pretekstem do rozmowy, a nie jej substytutem. Jeśli rysujemy proces w samotności i wysyłamy PDF do akceptacji, to pominęliśmy najcenniejszą część: dyskusję, w której ludzie sami zauważają, że „chwila, przecież my tego tak nie robimy”.

Diagram procesu z torami pływackimi

Do opisania procesu „jak jest” AgileBA proponuje Diagram Procesów Biznesowych z torami pływackimi. To graficzna prezentacja scenariuszy działania w biznesie, w której każdy „tor” odpowiada roli albo obszarowi, a diagram pokazuje, kto wykonuje daną czynność i gdzie przekazuje pracę dalej.

Prosty przykład, ilustracyjny: przyjęcie dostawy.

Tor	Czynność
Kierowca	Zgłasza się na rampie
Magazynier	Rozładowuje i porównuje towar z awizacją
Jakość	Kontroluje wybrane palety
Magazynier	Odkłada towar na lokalizację
Biuro	Księguje przyjęcie w ERP

Brzmi niewinnie. Ale kiedy rysujemy to na tablicy z ludźmi, którzy to faktycznie robią, zaczynają padać zdania, których nie ma w żadnej procedurze:

• „Chwila, my te dokumenty przepisujemy ręcznie, bo skaner nie widzi tej etykiety.”
• „Biuro księguje przyjęcie dopiero następnego dnia, więc sprzedaż przez 24 godziny nie widzi tego towaru.”
• „A jak towar jest uszkodzony, to dzwonimy do kierownika, bo nie wiadomo, czyja to decyzja.”

Takie rzeczy widać dopiero na diagramie. W głowie kierownika proces jest spójny. Na kartce widać każde przekazanie pracy między ludźmi, a w tych przekazaniach najczęściej giną czas, informacje i towar.

Dlaczego to jest ważne: gdzie marnuje się wysiłek

AgileBA mówi o tym wprost: model „jak jest” może zapewnić wgląd w to, gdzie marnuje się wysiłek, a procesy można następnie przeprojektować tak, by dawały większą wartość.

To dobry moment, żeby przypomnieć myślenie Lean, które jest tłem całego podejścia. Straty, często nazywane muda, to wszystko, co nie ma wartości dla klienta, wewnętrznego lub zewnętrznego. Ręczne przepisywanie dokumentów, czekanie na decyzję, szukanie towaru, podwójne księgowanie: to klasyczne muda, które po wdrożeniu WMS albo znikną, albo zostaną zautomatyzowane.

Jeśli zostaną zautomatyzowane, mamy dokładnie to, o czym była mowa w pierwszym odcinku serii: świetnie działającą maszynę do produkcji problemów.

Powrót do trzech wersji procesu

W odcinku 5 mówiliśmy o tym, że w każdym magazynie istnieją trzy wersje procesu: jak powinien działać (procedura), jak jest opisany w systemie i jak naprawdę robi to magazynier o 6:15 rano.

Diagram AS-IS jest narzędziem, które pozwala te trzy wersje zestawić obok siebie. Rysujemy:

• to, co jest, a nie to, co powinno być,
• razem z ludźmi, którzy to robią,
• z wyjątkami (uszkodzenia, brak awizacji, niezgodność ilościowa), a nie tylko ze ścieżką idealną.

Różnice między wersją z procedury a wersją z hali to najcenniejsza informacja w całym projekcie. To tam leżą prawdziwe wymagania.

Sześć perspektyw modelowania

Proces to tylko jedno z możliwych spojrzeń. AgileBA proponuje sześć perspektyw, które pomagają sprawdzić, czy niczego nie pomijamy:

Perspektywa	Czego dotyczy
CO	Informacje, dane, relacje i reguły biznesowe
JAK	Funkcje, cechy i procesy
GDZIE	Lokalizacje, w których działa rozwiązanie
KTO	Ludzie: klienci, użytkownicy, interesariusze, dostawcy
KIEDY	Wydarzenia ważne dla firmy: czas i harmonogramy
DLACZEGO	Cele, motywacje i oczekiwane korzyści

W WMS wszystkie sześć ma bardzo konkretne odpowiedniki. CO to towar, partia, jednostka logistyczna. JAK to proces przyjęcia i kompletacji. GDZIE to strefy i lokalizacje. KTO to magazynierzy, brygadziści, przewoźnicy. KIEDY to okna czasowe dostaw i godziny odbioru przez kuriera. DLACZEGO to cele z Uzasadnienia Biznesowego, o którym mówiliśmy w odcinku 3.

Inne techniki modelowania: krótki przegląd

AgileBA wymienia 14 technik modelowania dla Analityka Biznesowego. Nie trzeba używać wszystkich. Warto jednak wiedzieć, że istnieją, i dobierać je do problemu. Kilka najbardziej przydatnych przy WMS:

Diagram kontekstu (zakresu). Prosty obraz zakresu zmiany. Pokazuje interfejsy i pomaga w ustaleniu oraz komunikowaniu, co jest w projekcie, a co poza nim. Przy WMS od razu widać, z jakimi systemami i podmiotami (ERP, przewoźnicy, systemy klientów) rozmawia magazyn. Pomaga też wskazać interesariuszy związanych z obszarem zmiany.

Model domen biznesowych (diagram klas). Pokazuje dane, reguły biznesowe i relacje, np. Klient, Zamówienie, Pozycja zamówienia. W WMS to świetny sposób na uzgodnienie słownika: czym dokładnie jest „lokalizacja”, „jednostka logistyczna”, „partia” i czy wszyscy rozumieją te pojęcia tak samo. Wiele sporów w projektach zaczyna się od tego, że dwa działy używają tego samego słowa w różnym znaczeniu.

Mapowanie podróży klienta. Modeluje przebieg przez usługę z punktu widzenia klienta, z użyciem Persony i punktów styku. Idealne na warsztaty. Mapa pozwala wskazać luki, problemy i szanse, zarówno z perspektywy klienta, jak i dostawcy. W kontekście magazynu „klientem” może być też odbiorca wewnętrzny, np. dział sprzedaży czekający na informację o dostępności towaru.

Bogaty obraz (Rich Picture). Prosty sposób komunikowania pomysłów lub wizualizowania problemów. Obok aktorów, danych i procesów pokazuje też „miękkie” informacje: problemy w relacjach i potencjalne konflikty. Struktura jest swobodna, jak mapa myśli, bez formalnej składni. Przydaje się na samym początku, kiedy jeszcze nie wiadomo, co jest problemem.

Scenorysy i szkielety ekranów (storyboards, wireframes). Seria obrazów pokazująca scenariusz klatka po klatce. Pozwalają sprawdzić strukturę rozwiązania, zanim rozpoczną się znaczące prace. Przy WMS to szkice ekranów terminala, które można pokazać magazynierowi w pół godziny, zanim ktokolwiek skonfiguruje cokolwiek.

Mapowanie łańcucha wartości. Służy do doskonalenia procesów i pokazuje, które działania faktycznie tworzą wartość dla klienta.

Jak to się łączy w praktyce

W praktyce kolejność, którą polecam, jest prosta (to moje podsumowanie, a nie cytat z podręcznika, ale zgadza się z duchem AgileBA):

1. AS-IS: rozumiemy, jak jest. Diagram z torami, Rich Picture, obserwacja na hali.
2. Analiza: gdzie tracimy czas, pieniądze i dokładność? Gdzie są przekazania pracy, które generują błędy?
3. TO-BE: projektujemy, jak ma być. Z uwzględnieniem priorytetów MoSCoW z poprzedniego odcinka.
4. Dopiero potem konfiguracja systemu.

Odwrotna kolejność zwykle kończy się systemem, który dobrze automatyzuje coś, czego nikt nie chciał.

Pytania kontrolne

1. Czy mamy narysowany proces „jak jest”, a nie tylko procedurę „jak powinno być”?
2. Czy rysowaliśmy go razem z ludźmi, którzy go wykonują, w tym z hali i z różnych zmian?
3. Czy zawiera wyjątki i przekazania pracy między rolami?
4. Czy zgadzamy się co do słownika podstawowych pojęć (lokalizacja, partia, jednostka logistyczna)?
5. Czy diagram posłużył jako punkt wyjścia do rozmowy, czy wylądował na dysku w katalogu „do akceptacji”?

---

To ósmy odcinek serii łączącej metodykę AgileBA z praktyką wdrożeń WMS. Kolejny odcinek: Persony na magazynie, czyli jak różne role różnie korzystają z tego samego systemu i dlaczego „jako magazynier” to za mało.

A jak było u Was? Czy przed wyborem lub konfiguracją systemu ktoś narysował proces „jak jest”, czy od razu przechodziliście do funkcji?