Zarządzanie projektami informatycznymi I Projekt: Wdrożenie systemu CRM w przedsiębiorstwie produkcyjnym \ Spis treści 1. Opis przedsiębiorstwa ………………………………………………………………… 2 2. Opis projektu ………………………………………………………………………….. 3 2.1. Wybór metodyki …………………………………………………………………. 3 2.2. Skład zespołu ……………………………………………………………..……… 4 2.3. Harmonogram ……………………………………………………………………. 5 3. Kalkulacja finansowa projektu ……………………………………………………….. 6 4. Testowanie oprogramowania …………………………………………………………. 7 1 1. Opis przedsiębiorstwa Przedsiębiorstwo, którego dotyczy realizowany projekt informatyczny zajmuje się produkcją suplementów diety. Dział sprzedaży tej firmy dzieli się na trzy jednostki – telemarketing, KAM (key accounts management) i przedstawicieli handlowych. Oprócz personelu najniższego szczebla w proces sprzedaży zaangażowani są kierownik krajowy, kierownicy regionalni i dwaj product managerowie. Do tej pory proces realizacji zamówień przebiegał w następujący sposób: Podczas kontaktu z klientem pracownik działu sprzedaży sporządzał listę zamawianych produktów wraz z cenami i ilościami. Lista była wysyłana do stacjonarnego działu sprzedaży i magazynu w celu przygotowania paczki i wystawienia dokumentów handlowych. Taki sposób obsługi zamówień charakteryzował się wieloma wadami, m. in.: Podczas składania zamówienia pracownicy nie mieli dostępu do informacji o stanach magazynowych produktów, które oferują. Skutkowało to niepełną realizacją zamówień i koniecznością zwracania klientom środków za produkty, których firma nie była w stanie dostarczyć na czas. Mailowe przesyłanie zamówień wiązało się z częstym występowaniem błędów, np. w cenach i ilościach. Jedyne dostępne informacje, które mogą posłużyć do oceny pracy pracowników działu sprzedaży to liczba wystawionych dokumentów handlowych i wartość sprzedaży. Pozyskanie nowych klientów jest szczególnie trudnym zadaniem, ponieważ wymaga wcześniejszego znalezienia aptek lub sklepów, które będą zainteresowane kupnem suplementów. Niestety wiele firm nie jest widocznych na Google Maps, które wykorzystują przedstawiciele do planowania swoich tras. Kadra zarządzająca nie ma informacji o tym jak wiele kontaktów z klientami nie zakończyło się złożeniem zamówienia. Aby usprawnić działania działu sprzedaży, dyrektor planuje zlecić zewnętrznej firmie wdrożenie systemu CRM. Sformułowano następujące cele, które powinny zostać osiągnięte dzięki realizacji tego projektu: Automatyzacja procesu składania zamówień – pracownicy działu sprzedaży powinni mieć dostęp do bazy klientów i aktualnie oferowanych produktów, natomiast 2 pracownicy magazynu powinni otrzymywać powiadomienia o złożonych zamówieniach. Zbieranie informacji o kontaktach pracowników z klientami. Po kontakcie pracownik powinien wprowadzić do systemu informacje o tym z jakim klientem rozmawiał, czy kontakt był fizyczny czy telefoniczny, czy klient skorzystał z aktualnej promocji. Uzyskanie dostępu do bazy klientów, którzy mogą być zainteresowani kupnem suplementów diety. Uzyskanie możliwości generowania raportów, które mają służyć ocenie pracy przedstawicieli handlowych. Ustalono także następujące ograniczenia: Pracownicy działu sprzedaży mogą widzieć raporty dotyczące tylko ich własnej sprzedaży, natomiast kierownicy mogą widzieć całą sprzedaż podległych im pracowników. Jeden product manager powinien widzieć raporty dotyczące tylko linii suplementów ziołowych, drugi – tylko linii suplementów FMCG. 2. Opis projektu Firma, którą reprezentujemy jest dostawcą rozwiązania składającego się z bazy klientów aptek, sklepów medycznych i sklepów zielarskich oraz aplikacji mobilnej służącej do zarządzania zamówieniami i relacjami z klientami. Przedsiębiorstwa korzystające z naszych usług uzyskują dostęp do bazy klientów, którzy mogą być zainteresowani zakupem suplementów i sprzętu medycznego. System umożliwia także zbieranie danych o sprzedaży i aktywności personelu. 2.1. Wybór metodyki Projekt zostanie zrealizowany wykorzystując podejście Dynamic Systems Development Method, w skrócie DSDM. Przed rozpoczęciem projektu wykonano analizę wykonalności, która jednoznacznie wskazała korzyści płynące z realizacji przedsięwzięcia. Faza wytwarzania jest podzielona na Timeboxy trwające 20 dni roboczych. Zaplanowano 7 takich iteracyjnych timeboxów. Podejście DSDM kładzie bardzo duży nacisk na testy, dlatego zostaną one szerzej 3 opisane w ostatnim rozdziale. Zgodnie z podejściem DSDM niezmienne muszą pozostać jakość, czas i budżet projektu. W razie konieczności modyfikowane będą cechy produktu. Rysunek 1. Zmienne w projekcie – podejście tradycyjne i DSDM Źródło: https://www.agilebusiness.org/ 2.2. Skład zespołu Zgodnie z podejściem DSDM w projekcie uczestniczą zarówno pracownicy Dostawcy IT jak i Klienta zamawiającego. Klient wyznaczył ze swojej strony dwóch pracowników, którzy w projekcie będą pełnić rolę Project Sponsora, Project Managera i Wizjonera biznesowego. Dostawca zapewnia dostępność zespołu wytwórczego składającego się z: Analityka, UX/UI Designera, Lead Developera, dwóch Developerów oraz Testera. Stawki godzinowe poszczególnych stanowisk kształtują się następująco: Stanowisko Stawka Analityk 90 zł/h UX/UI Designer 90 zł/h Lead Developer 140 zł/h Developer 110 zł/h Tester 80 zł/h 4 Są to stawki za standardowe godziny pracy w projekcie. Chociaż nie zakłada się konieczności pracy w nadgodzinach to ustalono, że obowiązywać za nie będzie stawka 200% stawki standardowej. Wynagrodzenie Project Sponsora i Project Managera leży po stronie Klienta, dlatego ich stawki nie zostały ujęte w tabeli. Rysunek 2. Model zespołu wg podejścia DSDM Źródło: https://www.agilebusiness.org/ 2.3. Harmonogram Wspólnie ustalono, że projekt ma się rozpocząć 6.03.2023 r. Na ten dzień zaplanowano kick-off projektu, czyli spotkanie wszystkich uczestników projektu, na którym zostaną przedstawione założenia prac, od ogółu do szczegółu. Poruszone zostaną kwestie zasadnicze, takie jak założenia projektu, cele czy tło powstania. Ponadto jest to możliwość poznania się i integracji interesariuszy. Następny etap, czyli analiza wymagań, rozpocznie się 8.03.2023 r. Jednocześnie rozpocznie się trzeci etap związany z wymaganiami technicznymi. Podczas gdy analityk będzie 5 opracowywał koncepcję biznesową i model procesów w BPMN, zespół deweloperski będzie przygotowywał środowisko techniczne. Etap czwarty stanowi główną część wytwórczą projektu. Prace zostaną zrealizowane w modułach tematycznych: 1. Dashboard 2. Kalendarz 3. Produkty 4. Zamówienia 5. Role i uprawnienia 6. Raporty 7. Pozostałe funkcjonalności Każdy z tych modułów zostanie zrealizowany w osobnym Timebox’ie. W każdym z modułów zakłada się pracę analityczną, wytwórczą i testerską. Po każdym module planowany jest kamień milowy w postaci Product Show dla interesariuszy projektu. Zadania są powiązane ze sobą, więc opóźnienia w realizacji jednego modułu automatycznie przesuwają rozpoczęcie prac nad następnym. Piąty etap to integracja systemu z dotychczasowymi aplikacjami Klienta. Zakłada się, że prace zostaną zrealizowane w 4 dni. Jednocześnie rozpoczyna się etap szósty, czyli szkolenia użytkowników. W pierwszej kolejności Analityk przygotowuje podręcznik dla użytkownika końcowego, a następnie przeprowadza szkolenie. Po zakończeniu etapu piątego deweloperzy przeprowadzają analogiczne szkolenie dla administratorów systemu od strony klienta. Ostatni, siódmy etap zaplanowano dokładnie na 13.11.2023 r. Wtedy mają się rozpocząć ostateczne testy akceptacyjne. Po pozytywnej weryfikacji powinno nastąpić wdrożenie produkcyjne. Zakończenie projektu planowane jest na 23.11.2023 r. 3. Kalkulacja finansowa projektu Zakłada się, że w dzisiejszym bardzo zmiennym otoczeniu ekonomicznym realizowany projekt będzie miał wpływ na organizację w perspektywie 5 lat. Istnieje bardzo duże 6 prawdopodobieństwo, że po tym czasie warunki biznesowe / otoczenie ekonomiczne zmieni się na tyle, że system będzie trzeba zaktualizować lub wymienić na nowy. W naszej kalkulacji zakładamy roczną stopę dyskontową wynoszącą 10%. Na koszty realizacji projektu składają się koszty pracy zespołu projektowego w kwocie: 314 640 PLN Koszt oprogramowania, sprzętu i usług chmurowych potrzebnych do przetestowania i wdrożenia projektu wyniósł 20 000 PLN. Zakłada się, że w perspektywie trwania projektu system będzie generował stałe koszty związane z usługami utrzymania / wsparcia przez dostawcę w kwocie 20 000 PLN rocznie oraz 10 000 rocznie związane z kosztem infrastruktury chmurowej. Dodatnie przepływy finansowe generowane przez realizację projektu składają się z 2 elementów: a) Oszczędność czasu w całej organizacji w związku z usprawnieniem wielu procesów np. obsługi zamówień. Szacunek wynosi 40 000 PLN rocznie i jest stały w okresie trwania projektu. b) Zwiększone przychody organizacji. Szacunki różnią się w zależności od danego roku. Zakładając bardzie optymistyczne i pesymistyczne scenariusze. W tym przypadku pozytywny efekt będzie wygenerowany przez lepsze metody nadzoru nad pracownikami, lepszą analityką oraz znaczącą większą kontrolą procesu sprzedaży. W kalkulacji NPV wyniósł ok. 77 000 PLN a IRR 20 %. 4. Testowanie oprogramowania Testowanie oprogramowania w przedsiębiorstwie może przedstawiać pewne problemy. W zależności czy budową oraz testowaniem oprogramowania zajmuje się profesjonalny software house, czy dział IT firmy działającej w innej branży możemy napotkać następujące problemy: 1. Brak odpowiedniego planu i strategii testowania - brak jasno określonej strategii testowania i planu działań może prowadzić do nieefektywnego wykorzystania zasobów i opóźnień w projekcie – tego typu problem mógłby pojawić się w omawianym 7 przykładzie, w przypadku, gdyby firma z suplementami, niemająca wcześniejszego doświadczenia z budową oraz wdrożeniem oprogramowania, zdecydowałaby się zrobić to na własną rękę. 2. Niedostateczne zasoby - brak odpowiedniego zespołu lub narzędzi do testowania oprogramowania może utrudnić przeprowadzanie testów i zwiększyć ryzyko błędów w przypadku omawianego projektu wdrożeniowego ten problem napotkała firma produkująca suplementy, natomiast problem został rozwiązany poprzez zatrudnienie zewnętrznego podmiotu. 3. Niedostateczne kompetencje - brak odpowiedniego doświadczenia lub wiedzy w zakresie testowania oprogramowania może prowadzić do nieefektywnego przeprowadzania testów i braku skuteczności - podobne jak w poprzednim punkcie, ten problem prawdopodobnie wystąpiłby w przypadku podjęcia przez niedoświadczoną w budowie oprogramowania firmę działającą w branży produkcji suplementów, która nie dość, że nie miała doświadczenia w podobny projektach, to nie miała również odpowiednich zasobów i kompetencji. 4. Ograniczony budżet - brak odpowiednich środków finansowych może uniemożliwić zakup odpowiednich narzędzi do testowania, zatrudnienia specjalistów lub ograniczenia objętości testów - w przypadku omawianego projektu wdrożenia, tego typu problem nie miał miejsca i zatrudniona firma zewnętrzna przeprowadzi wszelkie odpowiednie testy. 5. Brak automatyzacji - brak automatyzacji testów może prowadzić do dużego obciążenia pracą i opóźnień w projekcie – tego typu problem nie powinien się pojawić we wspomnianym wdrożeniu, ze względu na fakt, że wynajęty software house jest wyspecjalizowany w tego typu projektach oraz ma wypracowane odpowiednie procedury oraz dobre praktyki. Aby uniknąć tych problemów, ważne jest, aby przedsiębiorstwo miało odpowiedni plan i strategię testowania, odpowiednie zasoby, wykwalifikowany zespół, odpowiedni budżet oraz wykorzystywało automatyzację testów, co pozwoli na skuteczne i efektywne testowanie oprogramowania. W przypadku braku kompetentnych w tym zakresie osób, rozwiązaniem jest zatrudnienie firmy zewnętrznej, której zadaniem byłoby stworzenie, przetestowanie oraz wdrożenie wymaganego oprogramowania. Takie rozwiązanie zastosowano w przedstawionym projekcie, w którym firma zajmująca się produkcją suplementów diety, nie miała odpowiednich kompetencji, planu, strategii, jak również odpowiednich zasobów takich jak wewnętrzny dział IT mogący skutecznie napisać oraz wdrożyć oprogramowanie. 8 „Testowanie oprogramowania to wykonanie kodu dla kombinacji danych wejściowych i stanów w celu wykrycia błędów. Proszę zauważyć, że celem testów jest wykrycie błędów. Nie jest to analiza statyczna, ale dynamiczna, bo testowany kod jest wykonywany” 1. Testy projektuje się, analizując testowany system i rozstrzygając, do jakiego stopnia jest on obciążony ryzykiem błędów. Zaprojektowane testy następnie wykonuje się ręcznie lub poddaje automatyzacji, czyli napisaniu oprogramowania, które wypróbowuje inny system oprogramowania w celu znalezienia błędu. Uzyskane wyniki analizuje się i określa, czy test wykrył błąd, czy też było to prawidłowe zachowanie systemu. Test uznaje się za udany, jeśli wykryje nieznaleziony jeszcze błąd. Mówi się, że test jest efektywny, jeśli znajduje błędy z maksymalnym prawdopobieństwem. Jego celem jest zapewnienie jak największej jakości i niezawodności oprogramowania. Testowanie jest procesem składającym się z kilku etapów, które różnią się od siebie charakterem i celem. Zaliczają się do nich metody, takie jak testowanie jednostkowe, testowanie integracyjne, testowanie systemowe i testowanie akceptacyjne. Ze względu na ograniczenia budżetowe nie wszystkie etapy testów zostały zaplanowane w harmonogramie wdrożeniowym. Testowanie modułowe (jednostkowe) wykonuje się na etapie wytwarzania kodu. Uczestnikami tego rodzaju testów są programiści firmy zewnętrznej, tworzącej system CRM, którzy w fazie implementacji poddają weryfikacji własny kod. „Wspomniane testy muszą odnosić się do niewielkich i ściśle wyizolowanych fragmentów kodu. Polegają one na wykonywaniu wybranego fragmentu instrukcji w celu zweryfikowania, czy realizuje ona swoją funkcję zgodnie z założeniami”2. Testy modułowe nie zostały uwzględnione w harmonogramie, ponieważ harmonogram nie przewiduje na tyle szczegółowych kroków oraz ze względu na fakt, że testy wykonywane będą przez programistę będącego autorem kodu, który usuwa usterki jak tylko zostaną wykryte, bez formalnego zarządzania nimi. Tego typu testy przeprowadzane będą przy wsparciu środowiska rozwojowego (np. bibliotek do testów jednostkowych oraz narzędzi do debugowania). Kolejnym etapem jest testowanie integracyjne, które polega na testowaniu interakcji między różnymi komponentami oprogramowania. „Celem tego rodzaju testowania jest wykazanie czy moduły poprawnie współpracują, tj. czy nie wystąpiły przeszkody natury technologicznej oraz czy wzajemnie świadczone usługi spełniają oczekiwania; jak R. V. Bindera, Testowanie systemów obiektowych. Modele, wzorce i narzędzia, WNT Wydawnictwa NaukowoTechniczne Gandalf.com.pl, 2003. 2 R. Pawlak, Testowanie oprogramowania, Helion, 2014, s. 66. 1 9 zachowują się poszczególne elementy w sytuacji awarii, błędów lub niestabilnej pracy w przypadku dysfunkcji jednego z nich (wzajemne oddziaływanie); czy kojarzone wzajemnie elementy realizują założony proces biznesowy (logika biznesu); czy infrastruktura techniczna zapewnia optymalne warunki pracy dla skomplikowanego systemu (wielomodułowego); czy nie ma luk w logice biznesu, tj. czy nie ujawniły się problemy lub potrzeby, które nie zostały przewidziane na etapie projektowania rozwiązania”3. Tego typu testowanie zostanie podjęte jak najbliżej kodu, tj. na etapie prac programistycznych i testów wewnętrznych. W harmonogramie testy integracyjne nie są uwzględnione ze względu na niską szczegółowość projektu, natomiast wykonywane one będą na etapie developmentu w każdym z modułów. Następnym etapem jest testowanie systemowe, które polega na testowaniu całego oprogramowania jako jednostki, lub jego samodzielny fragment, który znajduje odwzorowanie w projekcie. Celem jest upewnienie się, że oprogramowanie działa jak powinno i spełnia swoje założenia funkcjonalne. Testowanie systemowe przeprowadzone zostanie dla każdego z modułów na etapie developmentu. Dodatkowo, przeprowadzane one będą na środowisku testowym, które jest w jak największym stopniu zbliżone będzie do środowiska produkcyjnego, na którym docelowo aplikacja będzie funkcjonować. Na tym etapie testów, testowanie przeprowadzane będzie przy pomocy działu IT klienta końcowego, dzięki czemu zespół teustujący będzie miał możliwość zachowania dużej autonomiczności w odniesieniu do zespołu programistycznego w aspekcie środowiska testów oraz zasobów ludzkich. Celem testów systemowych będzie upewnienie się, że oprogramowanie spełnia oczekiwania klienta i jest przyjazne dla użytkownika. Testowanie akceptacyjne (odbiorcze) jest ostatnim etapem testowania oprogramowania, którego celem jest upewnienie się, że oprogramowanie spełnia oczekiwania klienta lub użytkownika końcowego oraz jest przyjazne dla niego. Testowanie akceptacyjne polega na przeprowadzeniu prób użytkowania oprogramowania przez klienta lub użytkownika końcowego, który jest odpowiedzialny za ocenę jakości oprogramowania. Testy te mają potwierdzić zgodność weryfikowanego produktu z zapisami w umowie i obowiązującymi przepisami prawa. W testowaniu akceptacyjnym brane pod uwagę są również aspekty takie jak ergonomia, przyjazność dla użytkownika, estetyka i łatwość obsługi. Testowanie akceptacyjne jest ważne, ponieważ pozwala na potwierdzenie, że oprogramowanie jest 3 R. Pawlak, Testowanie oprogramowania, Helion, 2014, s. 67. 10 gotowe do wdrożenia i jest zgodne z oczekiwaniami klienta. Jest to również ostatni etap testowania przed wdrożeniem, dlatego ważne jest, aby zapewnić jak największą jakość i niezawodność oprogramowania. Testowanie odbiorcze zostało uwzględnione w harmonogramie wdrożeniowym i zostanie ono wykonane dla każdego z modułów osobno. Podmiotem wykonawczym testów będzie klient oraz potencjalni użytkownicy sytemu, którzy zweryfikują system pod kontem zgodności z założeniami i wymaganiami, które zostały postawione przed fazą developmentu, a także pod kątem zgodności z zapisami w umowach oraz z obowiązującymi przepisami prawa. W przypadku pozytywnie zakończonych testów akceptacyjnych, następnym krokiem harmonogramu będzie product show. Podsumowując, testowanie oprogramowania jest niezbędnym elementem tworzenia systemów, ponieważ pozwala na wykrycie błędów i zapewnienie jak najwyższej jakości i niezawodności systemu. Większość firm testuje tylko na poziomie systemowym nie doceniając niższych warstw testowania co zwiększa koszty związane z usuwaniem błędów, bo wykrywane jest ich mniej, a te znalezione trudniej jest zlokalizować i poprawić. W prezentowanym projekcie wdrożenia systemu CRM zdecydowano się na wszystkie etapy testów co powinno zminimalizować koszty usuwania błędów oraz ewentualne błędy w funkcjonującym już systemie. Dodatkowo, wprowadzenie członków zespołu klienta na poszczególnych etapach testów, powinno ułatwić sam proces oddania oprogramowania ze względu na fakt, że jeszcze przed momentem oddania, po stronie klienta będą jednostki zaznajomione z funkcjonalnością systemu. 11
