Wdrożenia ERP – cz. VII Agile’m w ERP? Case nr 4 i 5.

Wpis gościnny dr hab. inż. Andrzeja Zalewskiego

Prezentujemy ostatni z serii wpisów gościnnych dr hab. inż. Andrzeja Zalewskiego na temat wdrożenia ERP. Wpisy te pierwotnie opublikowane były na grupie FB, dzięki uprzejmości autora prezentujemy je również na łamach Rudej Strony Zarządzania.

Agile’m w ERP? Case nr 4 i 5.

Dziś zamykamy cykl postów na temat zarządzania wdrożeniami systemów ERP. Zamykamy z hukiem! Dziś o Agile’u we wdrożenia ERP o dwa case’y. Zaznaczyć trzeba, że rzecz jest stosunkowo nowa i póki co możemy mówić o pierwszych doświadczeniach.

DUŻE ERP’Y I WATERFALL

Duże ERP’y lubią waterfalla, bo ten dobrze do nich pasuje lub raczej ciężko takie wdrożenie podzielić na ileśtam małych kroków typu sprint, nie mówiąc o dostarczeniu na koniec każdego sprintu czegoś działającego.

Skąd się to bierze:

1. W dużych ERP’ach bardzo rozbudowana jest tzw. podstawowa konfiguracja (dane dotyczące firmy i podstawowych założeń ewidencji – takich, jak np. struktura nr konta czy obiektów kontrolingowych), którą w znacznej części trzeba wykonać upfront i nie można jej odłożyć na później
2. Ponieważ w systemie różne obszary są ze sobą powiązane przez działanie na wspólnych danych (przypomnijmy, że powszechnym oczekiwaniem jest, by dane były wprowadzane do systemu ERP tylko jednokrotnie) – np. danych kontrahenta czy pracownika. Podejmując decyzje ich dotyczące w istocie kształtujemy działanie wielu różnych modułów systemu.

W efekcie wdrożenia realizowane były wg schematu (np. w SAP’owej metodyce ASAP – zob: https://blogs.sap.com/…/basic-understanding-on-asap…/): przygotowanie projektu, analiza i modelowanie biznesu (ang. business blueprint), realizacja (konfiguracja i dostowania), ostateczne przygotowanie [uruchomienia] (testowanie, szkolenia użytkowników i go live & support (wsparcie po uruchomieniu).

SAP + AGILE = SAP ACTIVATE

Świat się jednak zmienia i by nie dołączyć do świata informatycznych dziadersów SAP wprowadził motywowaną Agile’m metodykę SAP Activate, której proces przedstawiam na rysunku za https://blog.sap-press.com/the-sap-activate-timeline-for….

Nie wdając się w rozwlekły opis, bo wszyscy pewnie czekają kiedy będą case’y , metodyka ta sprowadza się do: dobrego przygotowania i zaplanowania prac, a następnie iteracyjnego konfigurowania systemu (oznaczone czerwoną strzałką) i jego odpalenia. Zwróćcie uwagę, że uruchomienie (go-live) następuje (jak klasycznie na samym końcu).

Materia ERP’owa okazała się dość odporna na agile’a.

CASE 4. System księgowy

Pewna duża firma księgowa postanowiła sama z pomocą zaprzyjaźnionych programistów zbudować system księgowy na własne potrzeby do usługowego prowadzenia ksiąg i ewidencji towarzyszących klientów firmy. Trudno powiedzieć jaka dokładnie była tu biznesowa rachuba, ale pewnie taka, że system ten mógłby być instalowany u klientów firmy, co pozwoliłoby outsource’ować księgowość z większych podmiotów.

Oczywiście zakres projektu miał być tak szeroki, jak spektrum klientów firmy z naciskiem na najpopularniejsze moduły typu KPiR czy księga handlowa + standardowe ewidencje firmowe.

Zawarto nawet umowy z wykonawcami, gdzie na 7 stronach zapisano user stories, ale tak naprawdę wymagania doszlifowywano bezpośrednio z klientem. Zarząd firmy księgowej szybko zauważył, że wydał już duże pieniądze, a droga do korzystania jest daleka i dalej rzecz potoczyła się jak w odcinku III naszej sagi – pretensje, spory, wstrzymanie finansowania, sąd.

Co zawiniło? Wbrew pozorom nie był to Agile czy Scrum, prace prowadzone były stopniowo, ale i bez konkretnego całościowego planu i np. Scrum’owego reżimu sprintów. To powodowało, że klient czuł się w tym zagubiony a potem zaniepokojony. Zwłaszcza, gdy próbował testować dostarczany system, który pełen był usterek i nie obsługiwał procesów end-to-end.

Case 5. System ERP dla firmy wynajmującej przenośne toalety

Ten projekt miał być realizowany nieco wypaczonym Scrum’em. Nie było Product Ownera, Scrum Mastera, ale byli kierownicy projektu… były prowadzone w jednym z systemów typu Jira product backlogi, których elementy alokowano do sprintów, sprinty miały długość 2 tygodnie. Kluczowe: za kolejność, tj. priorytet prac, odpowiadał klient – w osobie samego szefa. No i to okazało się gwoździem do trumny.

Głównym zagrożeniem w Scrumie jest to, że chociaż w poszczególnych sprintach dostarczymy jakieś cząstkowo działający funkcjonalności, to przy złym uporządkowaniu zadań nie złożą się one w żaden proces biznesowy obsługiwany od końca do końca.

Np. po zawarciu umowy, konieczna jest wsparcie dostawy, odbioru sprzętu, systematyczne jego serwisowanie i rozliczanie realizacji umowy.

Nad tym w naszym projekcie powinien był czuwać klient… ale czy miał do tego niezbędną wiedzę, doświadczenie, umiejętności? Czy wiedzy o własnym biznesie jest do tego wystarczająca – bardzo wątpię.

Wadą też jest to, że budując rozwiązania ERP’owe musimy czasem wykonać prace niewidoczne dla klienta, których w takim małym sprincie nie da się zrealizować.

I tu również projekt dotarł do etapu frustracji brakiem całościowych rezultatów, a zwątpienie to przejawiło się jak zawsze: wstrzymaniem finansowania, wstrzymaniem prac i procesem sądowym.

Takeaways

1. Nie należy stosować podejść agile’owych traktując wybiórczo ich zalecenia;
2. Sprawdzonych metodyk zmieniać nie należy – najwyraźniej ten Scrum Master i Product Owner są do czegoś potrzebni…;
3. Należy dbać o to, by rezultaty sprintów/etapów integrowały się w całości obsługujące procesy biznesowe od końca do końca, wtedy klient dostrzeże wartość budowanego systemu.
4. Odpowiedni budżet i konsekwencja w działaniu, także odporność na pojawiające się wątpliwości zamawiającego i umiejętność ich rozwiania przez wykonawcę są kluczowe.

O autorze

Andrzej Zalewski, dr hab.

Informatyk pracujący na Politechnice Warszawskiej, gdzie uczy algorytmiki oraz zarządzania projektami informatycznymi w firmach. Udziela się również jako ekspert i biegły w dziedzinie inżynierii oprogramowania. Kieruje Studiami Podyplomowymi Zarządzanie Zasobami IT oraz Zarządzanie projektami.