lukaszkogut.pl

Odcinek 7 serii: AgileBA w praktyce wdrożenia WMS

Warsztat priorytetyzacji wymagań do WMS. Po dwóch godzinach na tablicy wygląda to tak:

Musi być: przyjęcie, kompletacja, wydanie, FEFO, cross-docking, replenishment, raporty, integracja z przewoźnikami, dashboardy dla zarządu.

Wszystko „musi”. Czyli nic nie jest priorytetem.

To nie jest złośliwość uczestników. Każdy dział naturalnie broni tego, co dla niego ważne, a „Musi być” to najbezpieczniejsza etykieta. Problem w tym, że przy takiej liście projekt traci jedyne narzędzie, jakie ma, gdy czas albo budżet zaczynają się kurczyć: możliwość świadomego wyboru, co zrobić najpierw.

Czym jest MoSCoW

AgileBA używa do priorytetyzacji techniki MoSCoW. Cztery kategorie (samogłoski w nazwie są tylko dla czytelności):

Kategoria	Znaczenie	Pytanie kontrolne
Must have (Musi być)	Bez tego rozwiązanie nie ma sensu	Czy możemy uruchomić system bez tego?
Should have (Powinno być)	Ważne, ale da się obejść w krótkim terminie	Czy bez tego da się pracować, choć niewygodnie?
Could have (Może być)	Miłe, jeśli starczy czasu	Czy ktokolwiek zauważy, że tego nie ma?
Won’t have this time (Nie będzie tym razem)	Świadomie odkładamy na później	Czy to na pewno nie jest potrzebne teraz?

Ostatnia kategoria jest najważniejsza i najczęściej pomijana. „Nie tym razem” nie znaczy „nigdy”. Znaczy: świadomie odkładamy, a nie zapominamy po cichu. Różnica ma duże znaczenie dla relacji z interesariuszami: dział, którego wymaganie trafiło do „nie tym razem”, wie, że ono istnieje i że wróci do rozmowy. Dział, którego wymaganie po prostu zniknęło z listy, zapamięta to na długo.

Przykład z WMS

Ilustracyjny, bo prawdziwa klasyfikacja zależy od konkretnego magazynu.

FEFO (pierwszy wygasa, pierwszy wychodzi) dla towarów z krótkim terminem ważności może być „Musi być”. Bez niego magazyn wysyła przeterminowane lub bliskie przeterminowania partie, a skutki to reklamacje, zwroty i utrata zaufania klienta.

Cross-docking przy obecnym wolumenie? Bardzo możliwe, że „Nie tym razem”. Doda wartość, ale dopiero wtedy, gdy podstawowe procesy (przyjęcie, składowanie, kompletacja, wydanie) będą stabilne. Jeśli nie ma przewagi, której dziś brakuje, to dodatkowa złożoność na starcie jest ryzykiem bez zysku.

Dashboardy dla zarządu? Dla zarządu pewnie „Musi być”. Dla uruchomienia magazynu: „Should” albo „Could”, bo magazyn może pracować bez ładnych wykresów, a zarząd przez pierwsze tygodnie dostanie prosty raport.

Zauważcie, że ta sama funkcja może mieć różny priorytet w zależności od tego, z czyjej perspektywy patrzymy. Dlatego tak ważne jest, kto prowadzi tę rozmowę i kto ma ostatnie słowo.

Po co to wszystko: MoSCoW i Timeboxing

MoSCoW nie jest ćwiczeniem porządkowym dla samego porządkowania. Działa razem z Timeboxingiem, o którym będzie osobny odcinek. Zasada jest prosta: termin jest sztywny, a zakres elastyczny.

Kiedy coś się opóźni (a się opóźni), w Timeboxie są elementy „Should” i „Could”, z których można zrezygnować bez zatrzymywania projektu. Według AgileBA nieprzewidziane okoliczności są zarządzane właśnie w ramach rezerwy, jaką daje priorytetyzacja MoSCoW. Jeśli wszystko jest „Must”, nie ma żadnego bufora, a każde opóźnienie to kryzys.

W praktyce DSDM, na którym opiera się AgileBA, przyjmuje się zwykle zasadę, że wymagania „Must” nie powinny zajmować więcej niż około 60% szacowanego nakładu pracy. To zasada z praktyki DSDM/AgilePM, a nie sztywny przepis, ale daje dobry punkt odniesienia: jeśli po oszacowaniu okazuje się, że „Must” zajmują 90% czasu, to albo część z nich nie jest naprawdę „Must”, albo plan jest zbyt ryzykowny.

Kto rozstrzyga spory: wracamy do Sponsora i Wizjonera

I tu dochodzimy do tego, co moim zdaniem decyduje o skuteczności całej techniki.

Priorytetyzacja to nie tylko metoda, to także decyzja. A decyzja wymaga kogoś, kto ma mandat, żeby ją podjąć. W odcinku 2 pisałem o trzech scenariuszach, kiedy w projekcie brakuje sponsora. Pierwszy z nich to dokładnie ten przypadek: konflikt priorytetów między magazynem, sprzedażą i IT, którego nikt nie ma prawa rozstrzygnąć. Projekt grzęźnie w niekończących się uzgodnieniach.

AgileBA przypisuje tu konkretne role:

• Wizjoner Biznesowy jest ostatecznym arbitrem w kwestii priorytetyzacji wymagań i wskazuje, gdzie można znaleźć najlepszą wartość biznesową.
• Sponsor Biznesowy pilnuje dopasowania projektu do celów strategicznych i budżetu. Wchodzi do gry, gdy spór wykracza poza priorytety wymagań, np. dotyczy dodatkowych środków albo zmiany celu projektu.
• Analityk Biznesowy wspiera priorytetyzację, łącząc oczekiwane korzyści z wymaganiami, ale sam nie rozstrzyga sporów.

Do tego potrzebny jest jasny proces eskalacji. Zanim projekt wystartuje, warto uzgodnić: kto decyduje na poziomie zespołu, kiedy sprawa idzie wyżej i do kogo, w jakim czasie ma zapaść decyzja. Bez tego każdy dział będzie walczył o swoje „Must”, a spory będą rozstrzygane tym, kto głośniej mówi albo wcześniej dotrze do prezesa.

Zasady skutecznej priorytetyzacji w AgileBA

Podsumowując, kilka praktycznych zasad:

1. Robią ją odpowiedni interesariusze razem, a nie sam dział IT i nie sam analityk.
2. Odnosi się do Uzasadnienia Biznesowego. Priorytet „Must” ma sens tylko względem celu projektu, o którym mówiliśmy w odcinku 3.
3. Nie wszystkie wymagania mogą być „Must”. To kluczowa zasada, bo bez niej technika traci sens.
4. Priorytety nie są wyryte w kamieniu. Stają się punktem odniesienia (baseline) na końcu fazy Podstaw i są oceniane na nowo w miarę postępu projektu, tak jak Uzasadnienie Biznesowe.
5. Poziomy umocowania są jasne. Wiadomo, kto o czym decyduje i kiedy sprawa idzie wyżej.

Inne techniki, które warto znać

MoSCoW nie jest jedyną metodą. AgileBA wymienia też prostsze podejścia: przypisywanie cyfr od 1 do 5, kategorie Wysoki/Średni/Niski albo listę ułożoną według priorytetu z linią odcięcia. Do oceny, co naprawdę wzbudza zadowolenie klienta, służy też model Kano, który rozróżnia cechy oczekiwane (brak powoduje niezadowolenie, obecność nie zachwyca), normalne (satysfakcja rośnie wraz z ich natężeniem) i ekscytujące (to, czego klient się nie spodziewał, a co robi różnicę).

W projektach WMS model Kano bywa przydatny do rozmowy z użytkownikami. Skanowanie, które działa szybko i bez zawieszeń, to cecha oczekiwana: nikt jej nie pochwali, ale brak wywoła frustrację. Podpowiedź kolejnej lokalizacji z uwzględnieniem trasy wózka może być czymś, co magazynierów miło zaskoczy.

Praktyczny test

Kiedy na warsztacie ktoś upiera się przy „Must”, zapytajcie:

„Co się stanie, jeśli tego nie będzie w dniu uruchomienia?”

Jeśli odpowiedź brzmi „będzie niewygodnie”, to nie jest „Musi być”. Jeśli „nie możemy wysyłać towaru”, to jest.

Pytania kontrolne

1. Ile procent naszych wymagań ma etykietę „Must”? Czy nie jest to większość?
2. Czy mamy kategorię „Nie tym razem” i czy ktoś ją faktycznie wykorzystał?
3. Kto jest ostatecznym arbitrem w sporach o priorytety i czy ta osoba wie, że nim jest?
4. Czy mamy uzgodniony proces eskalacji, zanim pojawi się pierwszy konflikt?

---

To siódmy odcinek serii łączącej metodykę AgileBA z praktyką wdrożeń WMS. Kolejny odcinek: Modelowanie procesu magazynowego, czyli jak wygląda AS-IS, zanim zaczniemy mówić o systemie.

A jak było u Was? Ile procent wymagań w Waszym projekcie dostało etykietę „Must”?