Jak ustalić priorytety wymagań dla systemu ERP? Poznaj model MoSCoW!

Decydując się na system ERP mamy wiele oczekiwań od systemu. Często myśląc o wdrożeniu do głowy przychodzi wiele pomysłów, jeśli chodzi o wymagania dla systemu i jego przyszłe funkcjonalności. Warto jednak zebrać je wszystkie razem i nadać im odpowiednie priorytety.

Krótko o modelu

Ustalenie wymagań dla systemu jest jednym z kluczowych działań przy wyborze systemu ERP. Spisanie samych wymagań to jednak za mało, aby móc w najlepszy sposób wybrać system. Stworzenie zbyt szerokiej palety oczekiwań może wiązać się z wieloma dostosowaniami, dodatkowymi kosztami czy znaczącym wydłużeniem czasu wdrożenia.

Przeczytaj:

Dla ustrukturyzowania oczekiwań warto skorzystać z metody zarządzania wymogami MoSCoW. Metoda została opracowana przez specjalistę ds. rozwoju oprogramowania Dai’a Clegg’a, podczas jego pracy w firmie Oracle (dostawcy systemu NetSuite – LINK). Projektując swoją metodę Clegg chciał stworzyć platformę dla ustalania priorytetów projektów o określonym czasie. W szczególności jego metoda przeznaczona była dla inicjatyw przeprowadzanych w ramach wdrożeń/uruchomień systemów. Metoda ta stała się jednak bardzo popularna i może być używana w różnych aspektach.

W tym artykule chciałabym się jednak skupić na wykorzystaniu metody MoSCoW przy wyborze systemu ERP i podczas jego wdrożenia.

MoSCoW – co to znaczy?

Model MoSCoW określa 4 grupy priorytetów określanych dla wymagań systemu:

M – Must have – wymagania obligatoryjne, które system musi zapewniać.

S – Should have – wymagania, które powinny znaleźć się w systemie.

C – Could have – wymagania dodatkowe, które są pożądane, ale nie są niezbędne.

W – Won’t have – wymagania, które nie zostaną wdrożone (ale mogą być wdrożone w przyszłości).

MUST HAVE

Grupa wymagań MUST HAVE, to zbiór funkcjonalności, które musi zawierać system. Ich działanie w systemie nie podlega negocjacji. Konieczność ich wdrożenia może wynikać np. z przepisów prawa. Szukając więc systemu ERP odpowiedniego dla twojej firmy, jeśli odpowiednio ustalisz grupę wymagań MUST HAVE będziesz wiedział co sprawdzić/o co zapytać w pierwszej kolejności. Jeśli któryś z przeglądanych systemów nie będzie spełniał wymagań z grupy MUST HAVE powinien zostać odrzucony.

Jeśli nie jesteś pewien czy jakaś funkcjonalność powinna się znaleźć w tej kategorii zadaj sobie 3 pytania dotyczące tego wymagania:

• Co się stanie, jeśli funkcjonalności nie będzie w systemie?
• Czy jest prostsza droga, żeby spełnić to wymaganie?
• Czy jest możliwość, żeby produkt/system funkcjonował bez niego?

Jeśli system nie będzie działał bez tej funkcjonalności lub będzie bezużyteczny wtedy na pewno należy do grupy „MUST HAVE”.

SHOULD HAVE

SHOULD HAVE zawiera wymagania, które są znaczące dla naszego wdrożenia, ale nie są niezbędne. Jeśli nie będą zaimplementowane system wciąż będzie działał. Funkcjonalności określone w tej grupie stanowią jednak znaczną wartość dodaną dla systemu. W tej grupie można umieścić działania, które mogą zostać wprowadzone w przyszłej wersji bez wpływu na funkcjonowanie obecnej. Priorytety ustalone w tej kategorii są potrzebne, ale nie są niezbędne z punktu widzenia funkcjonowania systemu.

W tej grupie będą zawierać się wymagania, które jednak mają wysoką istotność. Takie, dla których będziemy w stanie ponieść dodatkowe koszty czy wydłużyć czas wdrożenia. W przypadku konieczności zrezygnowania z pewnych wymagań, będziemy starać się zachować w systemie funkcjonalności z grupy SHOULD HAVE. Jednak, jak zostało już wspomniane, można dopuścić do rezygnacji z ich zaimplementowania lub przełożenie ich wdrożenia w czasie.

COULD HAVE

Wymagania z tej grupy, to funkcjonalności, które dobrze jest mieć jednak nie są bardzo istotne. Porównując je z grupą MUST HAVE to wymagania, bez których nasz system będzie dobrze funkcjonował. Ich wdrożenie nie jest konieczne dla podstawowej działalności ERP. W tej grupie należy umieścić wymagania, które mają znikomy wpływ na „wynik”, a ich pominięcie nie wpłynie znacząco na nasze zadowolenie z wdrożonego systemu.

W tym miejscu warto więc umieścić wymagania, z których w razie konieczności możemy zrezygnować.

By przełamać niechęć do zmiany (a implementacja nowego systemu zawsze niesie za sobą zmianę m. in. w organizacji pracy) – warto czasem przekonać sponsorów i właścicieli projektu do uwzględnienia jakiegoś elementu np. typu Could (jako elementu „nice to have – przyjemnie jest mieć”). Są to funkcje, które nie są niezbędne dla funkcjonowania systemu, jednak ich wdrożenie ułatwi przyszłym użytkownikom oswojenie się z nowym narzędziem, zmianą i ułatwi ich pracę.

WON’T HAVE

W grupie WON’T HAVE znajdują się wymagania o najniższych priorytetach. Umieszczenie funkcjonalności, które nie będą zawarte w konkretnym wydaniu/wdrożeniu/ aktualizacji pomaga zarządzać oczekiwaniami względem systemu.

Wbrew pozorom, bardzo ważne jest określenie tej grupy wymagań. Wpływa ona nie tylko na zarządzanie oczekiwaniami, ale również na zarządzanie pełzaniem zakresu (scope creep). Dzięki temu, że umieścimy pewne funkcjonalności w grupie WON’T HAVE zakres projektu nie będzie się nieustannie rozszerzał.

WYMAGANIA WON’T HAVE I FUNKCJONALNOŚCI, KTÓRE NIE ZNALAZŁY SIĘ W SYSTEMIE

W przypadku przeprowadzania w przyszłości działań mających na celu rozwijanie systemu, w tworzeniu kolejnego modelu MoSCoW pomogą nam wymagania, które „wypadły” z wdrożenia oraz te ujęte w grupie WON’T HAVE. Te wymagania, które w pierwszej kolejności trafiają na listę priorytetów.

W niektórych podejściach grupę wymagań sklasyfikowaną jako W definiuje się jako tzw. grupę X – czyli eXcluded (wykluczonych) z projektu. Inni w tym miejscu używają W jako Wish – czyli wymagań o niższym znaczeniu i wartości z punktu widzenia całej organizacji i projektu, niż wymagania grupy COULD HAVE.

JAK KORZYSTAĆ Z METODY MOSCOW

Korzystając z metody MoSCoW warto włączyć do procesu przedstawicieli całej firmy. Pozwala to przede wszystkim spojrzeć na wymagania z szerszej perspektywy oraz zawrzeć wszelkie konieczne funkcjonalności z różnych działów przedsiębiorstwa.

Ustalenie priorytetów według metody MoSCoW pomaga również określić wysiłek, który będzie musiał zostać włożony dla osiągnięcia wskazanych wymagań. Dlatego też warto, aby w każdej grupie priorytetów znalazły się oczekiwania różnych działów.

Jak przygotować się do opracowania modelu MoSCoW?

Klasyfikacja według modelu MoSCoW jest zazwyczaj elementem analizy przedwdrożeniowej/ przygotowaniem do projektu. Biorąc pod perspektywy różnych osób w firmie (np. właściciel, zarząd, manager średniego szczebla, pracownik operacyjny) oznaczenie priorytetów dla poszczególnych wymagań może być trudne. Ponadto w większości firm kluczowe decyzje podejmuje zarządzająca kadra wysokiego szczebla. To oni określają, co musi być ujęte w systemie a czego w nim nie będzie – do drugiej grupy trafiają zazwyczaj te funkcjonalności, na które nie starcza budżetu, ich implementacja wykracza poza ramy czasowe lub też związane są z ograniczeniami formalno-prawnymi (np. ochrona danych wrażliwych, itp.).  Aby pogodzić oczekiwania kadry zarządzającej z oczekiwaniami funkcjonalnymi różnych działów warto jest powołać osobę lub zespół odpowiedzialny za finalne przygotowanie priorytetów i stworzenie listy, która godzi różne punkty widzenia. Taką funkcję może pełnić po pierwsze zespół wewnętrzny w firmie, która przygotowuje się do wdrożenia lub specjalista z zewnętrznej firmy czy przedstawiciel firmy wdrożeniowej/dostawcy oprogramowania.

ZOBACZ DLACZEGO WARTO POWOŁAĆ OSOBĘ ODPOWIEDZIALNĄ ZA PRZYGOTOWANIE MODELU MOSCOW

Przykład wymagań i różnych punktów widzenia

Integracja z modułem bankowości elektronicznej.

Dla części działów w firmie taka funkcjonalność będzie należała do grupy MUST HAVE. Jej wdrożenie pozwoli im uniknąć możliwości ingerencji w treść przelewów bankowych, podmianę numeru konta, itp. Jednak dla części pracowników to wymagania z grupy COULD, ponieważ dane transakcji można wprowadzać ręcznie, zwłaszcza jeśli dział/firma nie wykonuje ich wiele. W firmie na pewno znajdą się też działy, które same zakwalifikowałyby tę funkcjonalność do grupy SHOULD, ponieważ uważają, że mogą sobie chwilo poradzić bez tej funkcjonalności, jednak docelowo, ze względu na ilość prowadzonych transakcji, wymaganie musi być wdrożone by uniknąć ręcznej rejestracji.

Deklaracja VAT automatycznie wysyłana z systemu.

Ta funkcjonalność, z punktu widzenia działu finansowo księgowego należy to obszaru MUST HAVE, ponieważ jest ona wymagana przez prawo. Ponadto wymaganie oferowane jest nawet przez małe systemy (które kosztują kilkaset złotych). Jednak dla szefa produkcji, który nie ma styczności z tym obszarem funkcjonowania przedsiębiorstwa niekoniecznie będzie to MUST HAVE. Z jego perspektywy deklarację VAT można wysłać poza systemem i należy to do kompetencji działów księgowych. Ponadto nie jest to obszar firmy, który przynosi dochody.  

Masz pytania? Skontaktuj się z nami!