W dobie szybkiej cyfryzacji i automatyzacji procesów biznesowych, wybór odpowiedniej metodologii zarządzania projektami nabiera szczególnego znaczenia. Dwa popularne podejścia, Agile (Zwinny) i Waterfall (Kaskadowy), oferują różnorodne strategie dla efektywnego wdrażania projektów automatyzacji. Ich porównanie i analiza mogą pomóc w wyborze najlepszego rozwiązania dla specyficznych potrzeb przedsiębiorstwa.

Posłużę się prostym przykładem, dla lepszego zobrazowania różnic w poniższych sposobach pracy nad projektem:

• podejście kaskadowe (zwane potocznie “Waterfall”),
• podejście przyrostowe,
• podejście iteracyjne.

Wyobraźmy sobie, że programujemy bota RPA, który będzie logował się do poczty elektronicznej, pobierał z niej faktury a następnie wprowadzał dane z tych faktur do odpowiednich miejsc w systemie ERP firmy.

Waterfall – podejście kaskadowe do konkretnych wymagań klienta

W podejściu kaskadowym (Waterfall), mamy konkretnego Bota RPA do zaprogramowania. Znamy wszystkie wymagania klienta, które ma on spełniać.

Podejście to polega na liniowym sekwencyjnym zarządzaniu projektem, gdzie każda sekwencja musi być zakończona przed rozpoczęciem kolejnej. Budowa bota RPA w tym modelu, może teoretycznie składać się z poniższych, następujących po sobie sekwencji:

1. Analiza wymagań klienta
2. Faza projektowania bota RPA
3. Faza implementacji
4. Faza testów
5. Wdrożenie bota RPA u klienta.

Aby powstał bot RPA, każda z w/w faz musi zostać ukończona, by móc przejść do następnej.

To rozwiązanie sprawdza się w pracy nad nieskomplikowanymi projektami, w których wymagania są jasno określone na początku współpracy i jest mało prawdopodobne, aby uległy zmianie w czasie jej trwania. Taka praca nad projektem umożliwia łatwe monitorowanie postępów i zapewnienie zgodności z początkowymi wymaganiami klienta.

Pomimo, iż na pierwszy rzut oka podejście to wydaje się być bardzo poukładane, w kontekście budowania złożonych produktów posiada wiele wad, takich jak:

• Brak Elastyczności w adaptacji do zmieniających się potrzeb klienta.
• Późna weryfikacja rezultatów możliwa dopiero pod koniec fazy testów, co może stwarzać ryzyko nie trafienia w oczekiwania klienta.
• Brak możliwości otrzymania uboższej wersji Bota RPA, niż planowano, np. gdy trzeba zredukować budżet np. o połowę.
• Trzeba wydać cały budżet, aby otrzymać produkt finalny, nie można więc korzystać z uboższych wersji Bota RPA i zarabiać na nim.
• Występuje duże ryzyko problemów technicznych w fazie implementacji i testowania, które nie zostały przewidziane w fazie analizy i projektowania.
• Ryzyko starzenia się rozwiązania w przypadku, gdy prace nad nim trwają wiele miesięcy lub lat.

Agile: podejście przyrostowe i interakcyjne

Metodologia Agile, opierając się na koncepcji przyrostowego i iteracyjnego podejścia, stanowi innowacyjną strategię zarządzania projektami, która jest szczególnie przydatna w dynamicznie zmieniających się środowiskach. Agile skupia się na ciągłej współpracy z klientem i zespołem projektowym, co umożliwia błyskawiczne reagowanie na nowe wyzwania i zmiany w specyfikacji projektu.

Przyrostowe budowanie produktu – jasna wizja produktu

W przypadku podejścia przyrostowego, mamy jedynie jasną wizję produktu. Praca nad nią prowadzona jest w powtarzalnych, krótkich krokach o stałej długości, trwających najczęściej 1 lub 2 tygodnie. W dużym uproszczeniu, każdy taki krok, to praca nad poszczególną, niedużą funkcjonalnością bota RPA.  Składają się na niego:  cząstka analizy,  cząstka projektowania, cząstka implementacji oraz cząstka testów. Wszystko w bardzo okrojonym zakresie. Efektem prac w trybie przyrostowym jest niewielki, działający i skończony przyrost produktu.

Prace w podejściu przyrostowym można przyrównać, np. do produkcji roweru. W pierwszym kroku wyprodukowaliśmy kierownicę, a w następnym zajmiemy się produkcja ramy. W przypadku naszego bota RPA, takim przyrostem może być np. integracja z API systemu ERP klienta.

Pomimo, iż model ten posiada więcej zalet, niż Waterfall, nie jest doskonały. Do jego słabości można zaliczyć:

• Tylko częściową możliwość zebrania informacji zwrotnej, ponieważ  w 1-tygodniowych lub 2-tygodniowych krokach pracy nad projektem wytwarzane są tylko częściowe, ukończone fragmenty oprogramowania Bota RPA.
• Brak gwarancji, że będzie możliwa do otrzymania uboższa wersja Bota RPA, niż planowano, np. gdy trzeba zredukować budżet, np. o połowę. Wszystko zależeć będzie od tego, czy kroki, które już zostały zrealizowane, umożliwią uruchomienie takiej prostszej wersji produktu.
• Nadal występuje ryzyko projektowe, ale znacznie mniejsze, niż w przypadku Waterfall. Ponieważ mamy do czynienia z działającym oprogramowaniem, dostępnym po ukończeniu każdego kroku, możemy szybciej dowiedzieć się, czy wszystko działa poprawnie i w razie problemów odpowiednio wcześniej zareagować.

Iteracyjne podejście w Agile – ogólna wizja produktu

W podejściu iteracyjnym zespół pracuje na zasadzie “od ogółu do szczegółu”. W pierwszym kroku tworzy się ogólny szkielet produktu, który w kolejnych etapach jest stopniowo rozbudowywany i doprowadzany do pożądanego poziomu szczegółowości. To podejście wymaga całościowego myślenia o produkcie.  Zespół wielokrotnie wraca do wcześniej napisanych fragmentów, dodając kolejne detale i funkcjonalności.

Używając analogii do produkcji roweru, można powiedzieć, że producent ogólnie naszkicował rower, który chce wypuścić na rynek. W każdym kolejnym kroku, dopracowuje jego poszczególne elementy, aż do uzyskania perfekcyjnie działającego modelu. W przypadku bota RPA, praca w podejściu interacyjnym może się rozpocząć od zbudowania jego mocno uproszczonej wersji. Taki bot, np.: będzie logował się do poczty i przenosił dane z faktur do pliku xls. Nie będzie więc jeszcze zintegrowany z systemem ERP. W kolejnych krokach, które zwane są iteracjami lub sprintami, i trwają zazwyczaj od jednego do czterech tygodni, bot byłby rozbudowywany o kolejne funkcjonalności.

Podejście interacyjne, ma wiele pozytywnych cech:

• Po każdym sprincie otrzymujemy feedback dotyczący realizowanej interakcji całego ukończonego fragmentu produktu.
• Na każdym etapie możemy zakończyć projekt, jeżeli obliczymy, że kolejna interakcja będzie dla nas nieopłacalna i nie przyniesie wymiernych korzyści. Jest to możliwe, ponieważ od początku budujemy kompletne rozwiązanie (ang. end-to-end).
• Na wczesnym etapie prac jesteśmy w stanie rozpoznać ryzyka i ocenić, jaki mogą mieć wpływ na rozwój produktu, np. wczesne zapoznanie się z API systemu ERP może dostarczyć nam informacji o słabej jakość tej dokumentacji, co może mieć wpływ na dalsze plany projektowe. Dzięki temu podejściu dowiemy się o tym na początku rozwoju produktu, kiedy jeszcze można coś z tym problemem zrobić.

Wybór Metodologii: Klucz do Skutecznej Automatyzacji

Decyzja między Agile a Waterfall powinna być podyktowana charakterystyką projektu automatyzacji procesów biznesowych, w tym stopniem złożoności, dynamiką zmian w wymaganiach, oraz preferencjami i możliwościami zespołu projektowego. Projekty o wysokim stopniu niepewności i zmienności skorzystają na elastyczności Agile, podczas gdy te o jasno określonych i stabilnych wymaganiach mogą lepiej prosperować w ramach struktury Waterfall.

Więcej informacji: Marta Głuszek, E-mail: marta.gluszek@lpepoland.com, Tel.: +48 887 775 009, Odwiedź naszą stronę

#Automatyzacja #Robotyzacja #RoboticProcessAutomation #RPA #Bot #botRPA #Chatbot #Chatboty #VoiceBot #Voiceboty #AI #BOT4Me #Przemysł40 #Cyfryzacja #TransformacjaCyfrowa #Innowacje #LPEPoland