Zwinne projekty systemów ERP – dlaczego to się sprawdza w naszych projektach?

Zwinne zarządzanie projektami informatycznymi staje się coraz popularniejsze. Agile, czyli zwinne podejście (metodyki: SCRUM, Kanban, XP itd.), na dobre wkroczyło do świata IT, ale nie tylko. Zwinnie pracuje coraz więcej organizacji i zespołów poza branżą informatyczną. Agile to elastyczne podejście do zarządzania pracą w projektach, zakładające stałą i cykliczną współpracę zespołów projektowych z klientami, nastawioną na osiągnięcie celów biznesowych stawianych przed wdrożeniem. Z czego wynika rosnąca popularność metodyk zwinnych? Jakie korzyści przynosi wykorzystanie Agile we wdrożeniach rozwiązań IT? Jak przebiegają zwinne wdrożenia systemów ERP?

Podejście zwinne jest coraz częściej stosowane, ponieważ dynamika rynku i otoczenia biznesowego, w którym działają przedsiębiorcy, stale się zwiększa. Taka sytuacja wymaga zmiany podejścia – szybszego reagowania na sytuacje nietypowe, elastyczności w prowadzeniu biznesu, zdolności stałej adaptacji do pojawiających się nowych okoliczności. Zmieniają się również oczekiwania względem rozwiązań informatycznych, wspierających zarządzanie firmą. Przewagą w coraz bardziej dynamicznym otoczeniu jest możliwość szybszego wdrażania rozwiązań dostosowanych do specyficznych wymagań naszego biznesu oraz otwartych na rozszerzanie funkcjonalności w przyszłości. Takie możliwości dają zwinne wdrożenia systemów ERP.

Klasyczne (kaskadowe) podejście do realizacji projektów IT w obliczu obecnej dynamiki gospodarczej powoli przestaje mieć biznesowe uzasadnienie. Zakłada ono na początku projektu długi (trwający od kilku tygodni do kilku miesięcy) okres analizy przedwdrożeniowej, poświęcony na opisywanie procesów zachodzących w organizacji, tworzenie obszernej listy funkcjonalności systemu, planowanie z góry poszczególnych działań w projekcie, określenie sztywnych ram związanych z zakresem i budżetem przedsięwzięcia. Kolejne kilka miesięcy zajmują prace projektowe. Wdrożenia systemów ERP trwają zwykle po kilka lub kilkanaście miesięcy.

W metodyce klasycznej etap wdrożenia zaprojektowanych rozwiązań to zazwyczaj pierwszy moment, kiedy przedstawiciele firmy i docelowi użytkownicy mają styczność z zaprojektowanym na ich potrzeby systemem. Często okazuje się jednak, że założenia przyjęte na etapie analizy przedwdrożeniowej w międzyczasie przestały być aktualne. Procesy biznesowe firmy i jej otoczenie zmieniło się przez ten czas w wielu kluczowych aspektach. W związku z tym okazuje się, że wyobrażenia przedstawicieli firmy na temat funkcjonowania systemu rozminęły się z rozwiązaniami, które zaprojektował zespół.

Metodyka zwinna zakłada, że zmiany w projekcie będą się pojawiać, jest to coś naturalnego. Dlatego w samych założeniach tej metodyki pracy jesteśmy przygotowani do wprowadzania zmian. Podejście zwinne bazuje na tym, że nie sposób jest określić sztywnych ram projektu z kilkumiesięcznym wyprzedzeniem. To przekłada się na sposób organizacji prac w projekcie. Zamiast analizy przedwdrożeniowej w podejściu zwinnym przeprowadzamy w Sente Sprint analityczny z klientem. Trwa on od kilku dni do kilku tygodni. Jego produktami są zdefiniowane cele biznesowe projektu, opracowana koncepcja wdrożenia, określona lista wszystkich wymagań pożądanych w systemie. Nie zakłada się z góry szczegółowej listy funkcjonalności, jakie ma posiadać produkt końcowy. Określamy na ogólnym poziomie przebieg wszystkich procesów biznesowych.

Prace projektowe przeprowadzane są w ścisłej współpracy z Product Ownerem po stronie klienta. Jest to tzw. Właściciel Produktu, czyli osoba decyzyjna, odpowiedzialna za zbieranie wymagań i oczekiwań w firmie, ich ewaluację oraz podejmowanie decyzji o kolejności prac realizowanych przez Zespół Deweloperski. Praca w metodyce zwinnej pozwala “pociąć” projekt na bardzo małe etapy. Zespół projektowy pracuje w cyklicznych fazach (tzw. Sprintach), czyli 1-4 tygodniowych okresach. Po każdym Sprincie Product Owner wraz z osobami zaangażowanymi merytorycznie w firmie w dany obszar odbiera i weryfikuje rozwiązania, które opracował zespół projektowy. Następnie wspólnie planowane są prace na kolejny Sprint.

Podejście zwinne zakłada, że zespół projektowy nie poświęca czasu na kilkutygodniowe rozważania, w jakiej formie zaimplementować dany proces. Wręcz przeciwnie – pomysł jest projektowany i realizowany, a po kilku dniach wykonawcy otrzymują informację zwrotną od Product Ownera – czy takie rozwiązanie jest dobre, czy należy je zmodyfikować. W zwinnej pracy feedback pojawia się co kilka dni, a nawet codziennie, nie po kilku miesiącach. To pozwala na bardzo szybkie wyciąganie wniosków i wdrażanie usprawnień w stylu pracy całego zespołu projektowego – tak, aby eliminować niezadowolenie, czy pojawiające się problemy w dalszych Sprintach. Dzięki temu również zespół oszczędza czas i nie tworzy rozwiązań, których klient nie będzie potrzebował. Wręcz przeciwnie, tworzy narzędzia odpowiadające na rzeczywiste potrzeby klienta, a nie takie, które realizują listę funkcjonalności, których klient nie oczekiwał.

Metodyka zwinna zakłada zaangażowanie Product Ownera i interesariuszy z Zespołem Deweloperskim jako podstawę realizacji projektu. Aspekt empiryczny wspólnej pracy sprawia, że zespół projektowy bardzo dobrze poznaje firmę, dla której projektuje rozwiązania, jej potrzeby, oczekiwania i specyfikę. Bieżąca weryfikacja kierunku prac pozwala korygować ewentualne błędy na bieżąco. Agile zakłada ciągłą adaptację do pojawiających się nowych okoliczności i zmian w biznesie – staramy się realizować tylko te założenia, które według Product Ownera i Zespołu Deweloperskiego mają sens, czyli przyniosą korzyści biznesowe.

Podejście zwinne pozwala osiągać szybszy tzw. time to market, czyli moment, w którym klient może samodzielnie przetestować fragment gotowego rozwiązania, uruchomić je w formie prototypu w firmie i udostępnić do zweryfikowania pracownikom i interesariuszom. W metodyce klasycznej, z założenia, dzieje się to dopiero po zakończeniu prac projektowych, czyli zwykle po kilku miesiącach pracy. Wtedy modyfikacje ewentualnych różnic są znacznie bardziej czasochłonne i kosztowne, a wdrożenia systemów ERP są mniej elastyczne.

Nie można zakładać, że w podejściu kaskadowym nie ma projektów z sukcesem – oczywiście, że są. Metodyka klasyczna sprawdza się w projektach, które zakładają implementację gotowych systemów, czy rozwiązań kompletnie zdefiniowanych pod względem wymagań. Podejście to wymaga jednak znacznie więcej formalności, obszernej dokumentacji, poczynienia ścisłych założeń. W przypadku, kiedy system dostosowywujemy do biznesu klienta, to zdecydowanie bardziej efektywne jest wykorzystanie metodyk zwinnych.

Podejście zwinne się sprawdza, ponieważ stawia znacznie większy nacisk na współpracę z klientem. To nie jest projekt klienta, to nie jest też projekt firmy wdrażającej – jest to wspólna praca, obustronne zaangażowanie i wspólna odpowiedzialność za efekty. Zmiany w założeniach czy ewolucja oczekiwań klienta są szansą do rozwoju i osiągnięcia jeszcze lepszych rezultatów końcowych projektu. To jedna z największych zalet tego podejścia.

W kolejnych artykułach będę starała się przybliżyć tematykę planowania prac w projektach zwinnych, kwestię budżetowania oraz specyfiki roli Product Ownera.