Każdy projekt rządzi się własnymi prawami, ponieważ nawet niuanse w funkcjonowaniu biznesu klienta, mogą wpłynąć na ostateczny wygląd systemu ERP. Czy w takim razie warto się trzymać sztywnych reguł jednej metodyki? A może lepiej dynamicznie reagować na zmiany w projekcie?

Podejścia do wdrożeń systemów ERP są zróżnicowane. Wiele zależy od doświadczenia zespołu oraz wiedzy na temat konkretnego środowiska. Jednak zawsze System ERP powinien być wdrażany według planu, z ustalonym budżetem i wyznaczonym terminem zakończenia prac. Żeby wszystko szło po naszej myśli, plan musi podlegać ustalonej z góry metodzie. W EIP na początku zawsze stawiamy sobie dwa główne pytania: jakie cele chcemy zrealizować podczas wdrożenia oraz jakie priorytety i kryteria we współpracy ustalamy z klientem. Poniżej przedstawiłam pięć pytań i odpowiedzi, które pomagają zrozumieć proces wyboru metodyki.

Klient i dostawca to kluczowe ?elementy? w każdym projekcie wdrożeniowym. Zdarza się, że budowane są równoległe zespoły po stronie klienta oraz dostawcy, ze zdublowaną rolą kierownika projektu. Przy tego typu projektach budowany jest projekt, którym zarządza i nadaje ton pracy kierownik projektu po stronie dostawcy. To on formuje swój zespół projektowy, rozdziela pracę poszczególnym członkom zespołu dostawcy oraz informuje o zadaniach po stronie klienta. Tutaj dobrze sprawdza się metodyka PRINCE2, która jasno określa obowiązki, definiuje role oraz porządkuje prace na danym etapie projektu.

Etapy w projektach wdrożeniowych odzwierciedlają wykonywane w kolejności prace developerów, konsultantów ? stopień realizacji jest łatwy do zbadania. Etapy te to najczęściej programowanie, testy wewnętrzne, testy akceptacyjne, szkolenia. Do oceny wyników, a także zamknięcia etapu wykorzystujemy konkretne założenia oraz oczekiwania spisane na początku projektu jako obowiązki zleceniodawcy i zleceniobiorcy. Są przypadki, kiedy te kroki nie muszą być zachowane, a etap pierwszy zawiera wszystkie zadania dostawcy, z kolei drugi wszystkie zadania klienta. Wtedy najlepiej sprawdzają się metodyki wytwórcze, np. Scrum ? zespół pracuje w określonym przedziale czasowym zwanym przebiegiem (ang. sprint).

W przypadku oprogramowania zintegrowanych systemów informatycznych Microsoft jest to dedykowana metodyka Sure Step. Składa się ona z sześciu głównych faz/etapów oraz dwóch dodatkowych do optymalizacji i podnoszenia wersji. W każdej fazie dokładnie określa się zadania dostawcy i klienta.

Wymagania funkcjonalne określają, co system ma robić oraz czego robić nie może. Dotyczą rezultatów oczekiwanych przez użytkownika. Zawierają: przewidziane tryby pracy systemu, funkcje wykonywane przez system, oraz postać interfejsów (źródło: Inżynieria oprogramowania w projekcie informatycznym pod red. Janusza Górskiego, wyd. Mikom). W zarządzaniu wymaganiami idealnie sprawdzają się wspomniane już wcześniej metodyki wytwórcze takie jak Agile czy Scrum, które zawierają procedury pozwalające na sprawdzenie, czy dane wymaganie zostało poprawnie określone, wykonane i na końcu zrealizowane. Dla przykładu w metodyce Scrum na początku pracy nad produktem zbierana jest lista wymagań użytkownika, są one przeważnie gromadzone w postaci ?historyjek? (ang. User Stories). Każda historyjka opisuje jedną cechę systemu. Właściciel produktu (ang. Product Owner) jest też zobowiązany do przedstawienia priorytetu wymagań oraz głównego celu pierwszego przebiegu. Po tym formułowany jest rejestr wymagań (ang. Product Backlog). Tak powstają potwierdzone wymagania do systemu.

Zwykle jest to element wdrożenia lub procesu sprzedażowego przed podpisaniem umowy generalnej. Wtedy naturalnie wyodrębnione są potrzeby oraz przedstawiony końcowy budżet projektu wdrożeniowego. Po akceptacji następuje przełożenie wymagań na specyfikację techniczną, a na tej podstawie kreowany jest budżet stateczny projektu. Czasem jednak na początku projektu znamy już budżet, a wymagania funkcjonalne przychodzą później. Istnieją jednak metodyki które i z takim podejściem sobie radzą. Przykład takiego podejścia to Agile, które oferuje elastyczność, przy jednoczesnym zachowaniu koncepcji, realizacji i zarządzania projektem. W odróżnieniu od tradycyjnego podejścia, Agile ustala czas, koszt i jakość na wczesnych etapach projektu. System oddawany jest klientowi we fragmentach, również na środowisko produkcyjne (środowisko live, na którym pracują pracownicy). Testy wykonywane są na bieżąco na każdym etapie, a nie dopiero na zakończenie wszystkich prac. Nowy system tworzy się dynamicznie, dopuszczalne są zmiany w wyprodukowanych już funkcjonalnościach i założeniach poczynionych na początku. Jednym słowem potrzeby weryfikowane są na bieżąco.

Najlepiej jest to zrobić według wcześniej ustalonych etapów. Etapy warto ustalić na początku współpracy zgodnie z metodyką przyjętą do zarządzania całym projektem ogólnie. Każda metodyka zwraca uwagę na inne elementy z wyżej wymienionych. Sami producenci oraz dostawcy systemów ERP najczęściej sugerują z góry ustalone metodyki dla swoich produktów. W zależności od skali, jak również złożoności projektu, te rekomendowane metodyki mogą być uzupełniane przez inne, np. tylko w poszczególnych etapach, tak jak etap wytwarzania samego oprogramowania na poziomie zespołów projektowych. Doświadczone firmy wdrożeniowe wypracowują swoje autorskie metodyki. Tutaj za przykład niech posłuży nasza EIP Dynamics Way. Bazuje ona na zalecanej metodyce Microsoft Sure Step, jednak jest wzbogacona o kroki, elementy oraz najlepsze doświadczenia z wcześniejszych wdrożeń firmy. Dzięki temu projekt na każdym etapie może być poprowadzony stabilnie.