Odcinek 3 serii: AgileBA w praktyce wdrożenia WMS
„Konkurencja wdrożyła WMS, my też musimy.”
To zdanie padło w niejednej sali konferencyjnej. I niejeden projekt wystartował właśnie od niego. Problem w tym, że to nie jest Uzasadnienie Biznesowe. To jest presja rynku w przebraniu argumentu.
A projekt WMS bez porządnego Uzasadnienia Biznesowego ma jeden poważny problem: w połowie drogi, kiedy pojawią się koszty, zmiany i trudne decyzje, nikt nie będzie wiedział, po co to wszystko robimy. I czy nadal warto.
Czym jest Uzasadnienie Biznesowe w AgileBA
W metodyce AgileBA Uzasadnienie Biznesowe nie jest dokumentem do podpisania i schowania do szuflady. To punkt odniesienia, względem którego mierzy się sukces projektu. Wykorzystuje się je w kluczowych momentach, żeby zdecydować, czy projekt powinien być kontynuowany, czy zamknięty.
Określa też, kiedy i jak korzyści będą mierzone oraz jakie działania są potrzebne w trakcie projektu, żeby te korzyści rzeczywiście zapewnić.
W tym kontekście przypomnijmy rolę z poprzedniego odcinka: to Sponsor Biznesowy jest właścicielem Uzasadnienia Biznesowego i je zatwierdza. Analityk Biznesowy łączy oczekiwane korzyści z wymaganiami, pomaga w priorytetyzacji i podpowiada, jak te korzyści mierzyć.
Z czego składa się dobre Uzasadnienie Biznesowe WMS
Bez wchodzenia w szablony, dobre Uzasadnienie odpowiada na kilka prostych pytań:
1. Jaki konkretnie problem rozwiązujemy? Nie „chcemy WMS”, tylko na przykład: błędy kompletacji, rozjazdy stanów magazynowych, zbyt długi czas realizacji zamówień, słabe wykorzystanie powierzchni.
2. Jakie mamy opcje? Łącznie z opcją „nie robimy nic”. I tu wracamy do sedna.
3. Ile to kosztuje i kiedy się zwróci? Koszty, korzyści, wycena inwestycji, ocena ryzyka inwestycyjnego. Nie musi to być arkusz na 40 zakładek, ale musi być policzone.
4. Jakie są kluczowe założenia, zagrożenia i zależności? Na przykład: zakładamy, że dane towarowe są wystarczająco czyste do migracji. Zakładamy, że magazynierzy zostaną przeszkoleni przed startem. Zakładamy, że integracja z ERP będzie gotowa na czas. Każde z tych założeń to potencjalne ryzyko.
5. Jaką opcję rekomendujemy i dlaczego? Z uzasadnieniem, a nie tylko ze wskazaniem.
Opcja „nie robimy nic” – najczęściej pomijana, najbardziej pouczająca
W wielu Uzasadnieniach Biznesowych brakuje tej opcji, bo „przecież już zdecydowaliśmy, że wdrażamy”. A to właśnie ona pokazuje, ile naprawdę kosztuje status quo.
Jeśli błędy kompletacji generują reklamacje, zwroty i nadgodziny, to brak decyzji też jest decyzją. Tylko droższą, bo rozłożoną na raty i trudną do zauważenia, bo nikt nie wystawia osobnej faktury za „koszt niezmieniania niczego”.
Policzenie opcji zerowej ma jeszcze jedną zaletę: daje punkt odniesienia dla pozostałych opcji. Bez niego trudno ocenić, czy inwestycja w WMS jest rozsądna, czy tylko modna.
Uzasadnienie musi być żywe – scenariusz zmiany w trakcie projektu
To jedna z najważniejszych myśli z AgileBA: Uzasadnienie Biznesowe musi pozostać aktywne i widoczne zarówno dla ról z poziomu projektu, jak i dla zespołu rozwoju rozwiązania, przez cały czas realizacji. I musi mieć wystarczającą elastyczność, żeby umożliwić naukę i dostosowanie do zmieniającego się środowiska.
Wyobraźmy sobie taki scenariusz.
Projekt WMS startuje z jasnym celem: podnieść dokładność stanów i ograniczyć błędy kompletacji. Wszystko policzone, Sponsor zadowolony, harmonogram zatwierdzony.
W połowie projektu firma wygrywa duży kontrakt z siecią handlową. Nowy klient wymaga wysyłki w ciągu kilku godzin od zamówienia i własnego standardu etykiet logistycznych. Nagle głównym problemem biznesowym przestaje być dokładność stanów. Staje się nim szybkość kompletacji i wysyłki.
I tu rozjeżdżają się dwie drogi.
Droga pierwsza: „bo tak było w dokumencie”. Zespół realizuje dalej pierwotny plan. System startuje zgodnie z harmonogramem i doskonale rozwiązuje problem, który przestał być najważniejszy. Formalnie projekt się udał. Biznesowo – niekoniecznie.
Droga druga: aktualizacja Uzasadnienia. Sponsor wraca do dokumentu, aktualizuje założenia i oczekiwane korzyści, a następnie razem z zespołem przepriorytetyzowuje zakres. Etykiety klienta i szybka wysyłka trafiają do kategorii „Musi być” (MoSCoW), a część funkcji, które wcześniej były pilne, przesuwa się na późniejszy etap.
Zmiana Uzasadnienia w trakcie projektu nie jest porażką planowania. Porażką jest jej nie zauważyć.
Uwaga: powyższy scenariusz ma charakter ilustracyjny i służy pokazaniu mechanizmu.
Korzyści bez miernika to życzenia
Na koniec jedna praktyczna zasada. Jeśli w Uzasadnieniu Biznesowym piszemy „poprawimy dokładność stanów”, to nie jest korzyść. To jest intencja.
Korzyść to: „podniesiemy dokładność stanów z 94% do 99% w ciągu 6 miesięcy od uruchomienia”.
Różnica? Tę drugą można zmierzyć, zweryfikować i rozliczyć. A jeśli nie da się rozliczyć, to w trudnym momencie projektu nikt nie będzie mógł powiedzieć, czy idziemy w dobrą stronę.
(Liczby w przykładzie mają charakter ilustracyjny.)
Trzy pytania na koniec
Jeśli jesteście na początku projektu WMS albo w jego trakcie, warto sobie zadać:
- Czy mamy spisane Uzasadnienie Biznesowe, które powstało przed wyborem systemu, a nie po nim?
- Czy zawiera opcję „nie robimy nic” z policzonym kosztem?
- Czy ktoś je kiedykolwiek zaktualizował od momentu startu projektu?
Jeśli na trzecie pytanie odpowiedź brzmi „nie”, to znaczy, że dokument żyje tylko w szufladzie.
To trzeci odcinek serii łączącej metodykę AgileBA z praktyką wdrożeń WMS. Kolejny odcinek: Interesariusze na magazynie – kto naprawdę wpływa na sukces wdrożenia i jak ich nie przeoczyć.
A jak było u Was? Uzasadnienie Biznesowe WMS powstało przed wyborem systemu, czy dopiero po, żeby „uzasadnić” decyzję, która już zapadła? I czy ktoś je później zaktualizował?