Odcinek 5 serii: AgileBA w praktyce wdrożenia WMS
Kierownik magazynu opowiada, jak wygląda proces przyjęcia towaru. Spokojnie, logicznie, krok po kroku. Analityk notuje, wszyscy kiwają głowami.
A potem ktoś idzie na halę o 6:15 rano i widzi trzecią wersję tego samego procesu.
Trzy wersje tego samego procesu
W każdym magazynie istnieją zwykle trzy wersje procesu:
- Jak powinien działać: czyli procedura, instrukcja, schemat narysowany kiedyś na warsztatach.
- Jak jest opisany w systemie: czyli to, co wynika z obecnej konfiguracji ERP, Excela albo poprzedniego WMS-a.
- Jak naprawdę robi to magazynier, kiedy na rampie stoją trzy auta, skaner się zawiesza, a ktoś właśnie zadzwonił, że „to pilne”.
WMS konfigurujemy zazwyczaj pod wersję pierwszą albo drugą. Pracować w nim będzie wersja trzecia.
I tu leży sedno zbierania wymagań. Nie chodzi o to, żeby wersję trzecią piętnować ani na siłę „naprawiać”. Chodzi o to, żeby ją zobaczyć, zanim zaczniemy projektować rozwiązanie. Bo może się okazać, że część „obejść” to ukryta mądrość operacyjna, a część to realny problem do rozwiązania. Ale żeby je rozróżnić, trzeba je znać.
Elicytacja wymagań w AgileBA – więcej niż jedna rozmowa
W cyklu życia wymagania AgileBA wyróżnia cztery obszary: elicytację, analizę, walidację oraz zarządzanie i dokumentację. Dziś zatrzymajmy się przy pierwszym: elicytacji, czyli sposobach pozyskiwania wymagań.
Metodyka wymienia kilka technik, które się uzupełniają, a nie wykluczają:
Rozmowa twarzą w twarz. Najszybszy sposób na zrozumienie kontekstu i zadanie pytania „a dlaczego tak?”. Ale tylko punkt wyjścia.
Obserwacja. Patrzymy, co ludzie faktycznie robią, a nie tylko co mówią, że robią. To najpotężniejsze narzędzie do odkrycia wersji trzeciej procesu. Pół dnia na hali bywa warte więcej niż trzy spotkania w sali konferencyjnej.
Warsztaty facylitowane. Wspólne uzgodnienie wymagań, priorytetów i szczegółów, z udziałem ludzi, którzy mają wiedzę i uprawnienia do podejmowania decyzji. Dobre do rozstrzygania sprzeczności między działami.
Scenariusze. Opisujemy konkretne sytuacje: co się dzieje, gdy dostawa przyjeżdża bez awizacji, gdy towar jest uszkodzony, gdy brakuje jednej sztuki z zamówienia. Wyjątki ujawniają prawdziwe wymagania.
Modelowanie i prototypowanie. Rysujemy proces, szkicujemy ekrany, pokazujemy makiety. Ludzie lepiej reagują na coś, co mogą zobaczyć, niż na opis w dokumencie.
Demonstrowanie działających elementów rozwiązania. Najlepszy test na to, czy dobrze zrozumieliśmy potrzebę. Dopóki magazynier nie dotknie ekranu, wszystkie opinie o tym, czy będzie wygodnie, są przypuszczeniami.
Przykład: „każda paleta jest kontrolowana”
Prosty scenariusz (ilustracyjny, ale mechanizm bardzo realny).
Kierownik magazynu mówi: „Każda paleta jest kontrolowana przy przyjęciu.”
Na hali okazuje się, że przy dużej dostawie kontroluje się co piątą paletę, a resztę „ogarnia się później”, kiedy jest chwila oddechu.
Z punktu widzenia konfiguracji WMS to ogromna różnica:
- Jeśli zaprojektujemy kontrolę każdej palety, rampa zamieni się w korek, bo system będzie tego wymagał, a ludzie nie będą mieli na to czasu.
- Jeśli zaprojektujemy kontrolę wyrywkową z jasnymi zasadami (kiedy, ile, według jakich kryteriów), to rzeczywiście odzwierciedlimy sposób pracy i jednocześnie uporządkujemy to, co dziś dzieje się „z doskoku”.
Obie opcje są możliwe. Ale wybór między nimi jest decyzją biznesową, którą trzeba podjąć świadomie, a nie odkryć po uruchomieniu.
Facylitator kontra uczestnik: ważna rola Analityka
Przy warsztatach warto pamiętać o zasadzie z AgileBA. Facylitator odpowiada za strukturę i kontekst spotkania, a nie za jego treść. Jest neutralnym, bezstronnym przewodnikiem grupy, który pozwala jej skutecznie dojść do uzgodnionego celu.
To ma konsekwencje dla Analityka Biznesowego. Może on pełnić rolę facylitatora, ale jednoczesne facylitowanie i aktywne uczestnictwo nie jest możliwe. A w wielu warsztatach wymagań Analityk jest bardzo ważnym uczestnikiem, bo pomaga wydobywać szczegóły, zadawać pytania i wychwytywać sprzeczności. Wtedy lepiej, żeby warsztat poprowadził niezależny facylitator.
Dobra praktyka: Analityk współpracuje z facylitatorem, żeby warsztat miał jasny cel i jasno określony rezultat, a sam skupia się na treści.
Na początku wystarczą wymagania wysokopoziomowe
Jedna z najbardziej uwalniających zasad AgileBA: wymagania uzgadniamy na wysokim poziomie wcześnie, z ogólnymi kryteriami akceptacji. Szczegóły dopracowujemy dopiero tuż przed momentem, w którym ktoś faktycznie będzie to budować (zasada just in time).
W praktyce oznacza to, że nie musimy na starcie opisywać każdego scenariusza kompletacji w każdej strefie. Wystarczy wiedzieć, jakie są główne obszary, jakie mają znaczenie dla biznesu i co jest najważniejsze. Szczegóły wyłonią się w trakcie, w rozmowie z tymi, którzy będą z nich korzystać.
Dzięki temu nie piszemy 200 stron dokumentacji, która zestarzeje się szybciej niż wersja systemu.
Pytania kontrolne
- Czy ktoś z hali uczestniczył w zbieraniu wymagań, czy tylko osoby z poziomu zarządzania?
- Czy spędziliśmy choć kilka godzin na obserwacji faktycznej pracy, o różnych porach i zmianach?
- Czy mamy opisane scenariusze wyjątków (brak awizacji, uszkodzenia, braki), a nie tylko ścieżkę idealną?
- Czy wiemy, kto na warsztacie facylituje, a kto uczestniczy?
To piąty odcinek serii łączącej metodykę AgileBA z praktyką wdrożeń WMS. Kolejny odcinek: User Story w projekcie WMS: „Jako magazynier chcę wiedzieć, gdzie odłożyć paletę”, czyli jak zamienić to, co zebraliśmy, w wymagania zrozumiałe dla wszystkich.
A jak było u Was? Ktoś z hali uczestniczył w zbieraniu wymagań, czy wymagania powstały w sali konferencyjnej?