Chcesz porozmawiać z ekspertem? Kliknij tutaj!
Podobnie jak przy tworzeniu dedykowanych aplikacji, również przy wdrożeniu nowego systemu ERP możemy wyróżnić analogiczne lub bardzo podobne kroki. Tworząc i dostarczając aplikacje często wykorzystujemy metodykę Agille, podobnie jest w przypadku wdrażania częściowo gotowych systemów ERP u naszych klientów.
Zanim udostępnimy oprogramowanie w wersji podstawowej konieczne jest przeprowadzenie analizy przedwdrożeniowej oraz mapowania procesów. Dlaczego? Ponieważ są one fundamentem do udanego wdrożenia. Bez zbudowania solidnych podstaw dołączymy do grona ponad 50% firm, dla których wdrożenie systemu ERP było porażką.
Efektem dobrze przeprowadzonej analizy przedwdrożeniowej i mapowania procesów powinna być skrzętnie stworzona dokumentacja projektowa, na której oprze się cały przyszły projekt. Z pojęciem analizy przedwdrożeniowej chyba każdy z nas miał styczność, czym jednak jest tajemnicze mapowanie?
Mapowanie to nic innego jak narysowanie każdego procesu, który powinien odwzorować nasz system. Firma wdrażająca system ERP nigdy nie wie, czego w rzeczywistości oczekują jej klienci, a w każdej firmie procesy różnią się od siebie. Do procesu mapowania powinny być zaangażowane osoby nie tylko osoby z szczebla C-level, ale wszyscy, którzy są odpowiedzialni za dany proces. Nigdy jedna osoba nie zna wszystkich procesów, receptur, workflowu, czy technicznych aspektów.
Przykładem może być proces obsługi dokumentów przychodzących
Zazwyczaj za odbiór i przekierowanie poczty odpowiada wyznaczona osoba w biurze, w zależności od rodzaju korespondencji nadaje ona odpowiedni bieg dokumentu. W mapowaniu chodzi o to aby określić odbiorców, czasy oraz to co musi zadziać się przy danym dokumencie. Dzięki temu każdy proces będzie można odwzorować i maksymalnie przyśpieszyć.
Proces mapowania i analizy jest wbrew pozorom bardzo złożony, wiele czynników należy brać pod uwagę, dlatego warto aby za mapowanie procesów i analizę przedwdrożeniową odpowiadała osoba, która ma doświadczenie w tej dziedzinie. Dobrze zmapowany proces pozwoli nam na wygenerowanie oszczędności w procesie całego wdrożenia nowego systemu ERP. Programiści będą mieli dostęp do rzetelnych danych, a testerzy otrzymają wręcz gotowe "historyjki" na podstawie których będą sprawdzać poprawność działania systemu ERP.
Stworzenie harmonogramu wdrożenia jest wbrew pozorom kluczowym elementem. Dzięki temu wszyscy będą mieli świadomość ile czasu będzie przeznaczone na cały projekt oraz kiedy i w jakiej kolejności będą podejmowane kolejne kroki. Dla firmy IT harmonogram będzie deadlinem dla poszczególnych prac, dla firmy wdrażającej nowy program harmonogram będzie podstawą do rozliczenia prac dostawcy.
Do stworzenia harmonogramu prac również będą nam potrzebne dane zawarte w dokumentacji przedwdrożeniowej. Na jej podstawie doświadczony project menagerowie (PM) będzie mógł wstępnie oszacować praco i czasochłonność wdrożenia. Odpowiednio przygotowany harmonogram ułatwi nam trzymanie kosztów wdrożenia w ryzach.
Zespół projektowy to grupa osób wybranych do realizacji określonego projektu pod przewodnictwem kierownika projektu. Kierowanie projektem to zazwyczaj działanie i odpowiedzialność wielu osób. Główne role w zespole odgrywa komitet sterujący, sponsor, kierownik projektu oraz zespoły robocze czy też zadaniowe. Ważne jest, aby do współpracy w projekcie nie wybierać osób całkiem przypadkowych a także jasno i wyraźnie określać zakres odpowiedzialności i uprawnień, jakimi dysponuje każda z ról w projekcie. Dzięki temu unikniemy nieporozumień i konfliktów w trakcie jego realizacji.
Proces podejmowania decyzji jest efektem powiązanych ze sobą czynności, w efekcie których podjęta zostaje ostateczna decyzja. Następuje to w trzech etapach: najpierw następuje identyfikacja i zrozumienie problemu, następnie poszukuje się możliwych rozwiązań problemu a także określa kryteria oceny poszczególnych wariantów. Jest to najtrudniejszy etap całego procesu, gdyż wymaga wysokich kwalifikacji oraz twórczego myślenia. Całość kończy porównanie między sobą wariantów i wybór najlepszego rozwiązania, które spełnia w największym stopniu przyjęte kryteria.
W zespole projektowym decyzje często podejmowane są przez grupę osób biorących udział w projekcie. Mogą jednak być również podejmowane indywidualnie. Każda z tych form na wady i zalety.
W przypadku indywidualnego podejmowania decyzji zaletą będzie szybkość jej podejmowania, a także jednoznaczna odpowiedzialność za jej podjęcie. Będzie to jednak oznaczać ograniczoną liczbę informacji, przeanalizowanie zbyt małej liczby rozwiązań oraz wysokie prawdopodobieństwo, że taka decyzja spotka się z dezaprobatą ze strony pozostałych pracowników.
Decyzje podejmowane przez grupę są zazwyczaj lepsze od decyzji jednoosobowych, ze względu na większą liczbę generowanych pomysłów i rozwiązań. Stwarza to duża szansę wyboru najlepszego rozwiązania, a także jest w dużym stopniu akceptowalna przez członków zespołu projektowego. Często wiążą się jednak z dłuższym czasem potrzebnym na podjęcie decyzji. Ponadto rozproszeniu ulega odpowiedzialność za decyzję a wzrasta akceptacja ryzyka, pojawić się może także tzw. syndrom grupowego myślenia, który ograniczy zdolności intelektualne zespołu. Każda z form ma więc zalety i wady.
„Programowanie zwinne jest grupą metod wytwarzania oprogramowania opartego na programowaniu iteracyjno – przyrostowym.” Takie tłumaczenie zagadnienia jest dostępne niemal na każdej stronie, w którą wejdziemy wyszukując informacji w internecie. Jak jednak to wygląda w praktyce?
Przy wykorzystaniu zwinnych metod tworzenia oprogramowania podstawą jest współpraca i małe kroczki. Rozpoczynając projekt przyjmujemy cele, które mamy osiągnąć, jednak dokładny sposób ich realizacji nie jest ostatecznie zdefiniowany. Projekt podzielony jest na małe części, każdy z elementów po stworzeniu jest przekazywany do testów i akceptacji. Jeśli zaakceptujemy wygląd i sposób działania – możemy iść dalej. Jeśli nie, dana funkcjonalność jest zmieniana i dostosowywana do uwag.
Dzięki zastosowaniu takiego podejścia klient ma realny wpływ na ostateczny wygląd i dopasowanie całego systemu. A wprowadzenie zmian generuje znacznie mniejsze koszty.
W klasycznym modelu wdrożenia klient otrzymuje program z większością wprowadzonych zmian, które zostały zdefiniowane na początku. Często okazuje się wtedy, że wizja developerów odbiega od oczekiwań klienta. Ze względu na złożoność procesów i rozbudowane zależności wprowadzenie nawet jednej zmiany może wywołać lawinę innych zmian, które prowadzą do konieczności zwiększenia nakładów pracy – czyli wzrostu kosztów.
Wdrożenie nowego systemu z wykorzystaniem zwinnego podejścia wymaga zaangażowania wielu pracowników firmy. Jednak takie podejście daje większą gwarancje sukcesu niż standardowe modele wdrażania.
Jak do każdego projektu również przy wdrożeniu programu ERP musimy mieć wybrany zespół projektowy. Chcąc wykorzystywać zwinne metody wdrażania systemów ERP nasz zespół będzie większy niż przy wykorzystaniu standardowych modeli. Większa liczba osób nie oznacza jednak, że projekt będzie bardziej skomplikowany. Prócz kierownika projektu, zespołów roboczych, etc. należy włączyć do projektu użytkowników końcowych, mogą to być np. kierownicy działów lub wybrani pracownicy firmy. Takie osoby po każdej fazie będą w stanie zaopiniować czy dana funkcjonalność działa w sposób prosty i rzeczywiście ułatwi pracę. Krótko mówiąc, takie osoby szybko zweryfikują „useability” naszego ERP. Osoby pracujące w procesie od samego początku nie dostrzegają wielu błędów czy niedociągnięć. Pracownicy „z zewnątrz” zawsze spojrzą na wykonaną pracę z innej pespektywy, wniosą świeże spojrzenie oraz wypunktują wszystkie niedociągnięcia.
I nie chodzi tu o zaplanowanie kolejnych kroków projektu – to już mamy spisane w dokumentacji przedwdrożeniowej. Planujemy każdy krok rozkładając wszystko na czynniki pierwsze. Dzięki temu każdy zespół i osoba wie dokładnie co i jak powinno być zrobione.
Przy planowaniu warto określać pracochłonność każdego zadania. Pozwoli to na optymalne zaplanowanie zadań dla każdego z osobna. Np. Jeśli planujemy pracę dla zespołu 4 osobowego na najbliższy tydzień, wiemy że mamy do wykorzystania 160h. Planując pracę nie możemy nałożyć na zespół zadań, które mogą pochłonąć więcej niż 160h pracy. Co ważniejsze, przy takim planowaniu warto zostawić dla każdej osoby kilkugodzinny bufor czasowy.
Nasz plan wdrożenia systemu ERP powinien być podzielony na krótkie, jedno, maksymalnie dwu tygodniowe interwały. W czasie trwania takiego interwału warto codziennie robić 10-15 minutowe spotkanie zespołu, podczas którego każda osoba przedstawia wyniki swojej pracy z poprzedniego dnia oraz informuje o planach na rozpoczynający się dzień. Dzięki temu członkowie zespołu mogą zasygnalizować potrzebę wsparcia lub pojawiające się nowe problemy.
Często słyszymy, że w firmach spotkania wewnętrzne pochłaniają tylko czas. Nie oszukujmy się, nikt nie lubi wielogodzinnych spotkań. Dlatego warto pilnować aby nasze spotkanie ograniczyło się do kilku minut, jeśli mamy problem do omówienia, którego nie możemy szybko rozwiązać, to znaczy, że jest to temat na inne spotkanie, które już niekoniecznie musi angażować cały zespół.
Na zakończenie pracy każdej funkcjonalności/zadania konieczne jest przeprowadzenie testów zarówno automatycznych jak i manualnych. Automatyczne testy zazwyczaj piszą sami programiści lub testerzy. Po takich testach nasz kod powinien trafić do drugiego programisty, który jeszcze raz go sprawdzi i zatwierdzi poprawność.
Dopiero poprawny kod może zostać udostępniony testerom manualnym, którzy „przeklikają” część programu na jak największą ilość sposobów, przejdą tzw. historyjki użytkowania. Jeśli testerzy nie będą mieli uwag dana cześć programu może zostać wydana klientowi docelowemu do testów.
Użytkownik końcowy po otrzymaniu programu powinien go dokładnie przetestować i zebrać jak najszerszy feedback. Jeśli wszystko zostanie zatwierdzone, można przejść do tworzenia i wdrażania kolejnych elementów. Jeśli nie, wracamy do etapu 2, czyli ponownego zaplanowania pracy i wprowadzenia wskazanych zmian.
Etap zbierania feedbacku jest kluczowym dla powodzenia całego wdrożenia. Jeśli np. sposób wprowadzania nowych danych do bazy nie jest czytelny lub intuicyjny, ale wyjdziemy z założenia, że „przecież to jest do zniesienia” – możemy być pewni, że w przyszłości znajdą się użytkownicy, którzy przez taki niedociągnięcie będą wprowadzać nieoprawne, nieczytelne dane. Takie działanie będzie miało bezpośrednie przełożenie na pracę całego systemu ERP.
Porozmawiaj z ekspertem
POROZMAWIAJ Z EKSPERTEM