Standaryzacja procesów w systemie ERP

Standaryzacja procesów w systemie ERP w różnych oddziałach tej samej firmy – czyli okazja do tego, aby najlepsze procesy rozpropagować do wszystkich oddziałów na świecie

Czym jest standaryzacja procesów w systemie ERP?

Globalne firmy różnie podchodzą do kwestii standaryzacji procesów w systemie ERP (Microsoft Dynamics NAV, Navision) w zależności od obszaru działalności, której ta standaryzacja miałaby dotyczyć. Dążenie do ścisłej standaryzacji procesów dotyczy zwłaszcza procesów produkcyjnych czy logistycznych. Nieco większe różnice pomiędzy procesami księgowymi wynikają z potrzeby uwzględnienia lokalnych wymagań prawnych. Największa dowolność z kolei dotyczy z reguły procesów sprzedażowych. Firmy wychodzą bowiem z założenia, że dopóki osiągane są dobre wyniki, lepiej nie zmieniać lokalnych procesów sprzedażowych.

Różne opcje w ramach procesu sprzedaży

Nawet jeśli projekt zakłada sporą dowolność w ramach procesów sprzedażowych w oddziałach, to standaryzacja dotyczy często innych obszarów. Przykładem są ustawieniaksięgowe, wprowadzenie jednolitego planu kont, standaryzacja w logistyce (numery zapasów, kontrola stanów magazynowych). Centralne zarządzanie danymi podstawowymi z kolei standaryzuje kartoteki nabywców w różnych firmach. Z tego powodu ustandaryzowany system wpływa również na procesy sprzedaży, np. w zakresie polityki rabatowej.

Rozwianiem problemu związanego z procesami sprzedażowymi jest więc zaprojektowanie alternatywnych rozwiązań dzięki możliwości włączania i wyłączania niektórych opcji. Dobrym przykładem jest tutaj różnica w polityce rabatowej pomiędzy Wielką Brytanią a np. południem Europy. Zwykle w Wielkiej Brytanii klient otrzymuje cenę podstawową za produkt i płaci dodatkowo za wszystkie kolejne usługi. W południowej Europie z kolei takie podejście jest nie do pomyślenia. Tu klient otrzymuje cenę za produkt, a za rozszerzanie zakresu usług z których korzysta jest wynagradzany rabatem. Tych dwóch podejść nie można pogodzić. Wybieramy albo jedną, albo drugą opcję.

Jak zatem umożliwić różne opcje w jednym grupowym, skonsolidowanym systemie ERP?

Wprowadziliśmy dwie możliwości. Narzędzie do importu cen jest w obu opcjach takie samo i będzie działało w Wielkiej Brytanii i we Francji. Natomiast narzędzie do importowania rabatów dla Navision we Francji jest wykorzystywane, a w Wielkiej Brytanii nie. Na Wyspach jest wykorzystywana funkcjonalność kosztów dodatkowych. Czyli w momencie roll-outu skonsolidowanego systemu ERP (np. MS Dynamics Navision) do danego oddziału podejmujemy decyzję odnośnie wykorzystywanej polityki cenowej i ustawiamy w systemie albo opcję rabatów, albo opcję „extra charge”. Zdarzają się również oddziały, które korzystają z obu tych opcji, w zależności od klienta, dla którego pracują.

Standaryzacja procesów produkcyjnych czy logistycznych

Z reguły, w firmach międzynarodowych procesy inne niż sprzedażowe nie podlegają już takiej dowolności. Właściwe jest np. wprowadzenie tego samego procesu produkcyjnego we wszystkich oddziałach. Często spotykamy się z przekonaniem klientów, że wprowadzenie tego samego systemu ERP w różnych oddziałach gwarantuje, że ich sposób działania, a więc procesy będą podobne. Prawda jest jednak taka, że systemy ERP takie jak Microsoft Dynamics NAV dają użytkownikowi pewną dowolność w procesach. Ten sam towar można w systemie wyprodukować na kilka różnych sposobów. Należy więc zwrócić uwagę na tę kwestię jeśli celem projektu opartego o Szablon Globalny jest również standaryzacja procesów.

Standaryzacja procesów dzięki ustawieniom lub poprzez funkcjonalność

Standaryzacja oznacza w praktyce, że centrala podejmuje decyzję, aby dany proces przebiegał w określony sposób we wszystkich oddziałach. Przykładem jest decyzja, że w przypadku złożenia (assembly management) mamy zawsze jeden etap w marszrucie produkcyjnej (czyli jeden element w routingu). Jeśli jest to globalne, grupowe założenie odnośnie procesu produkcyjnego, wówczas przed wdrożeniem lokalnym (roll-outem) nie mamy analizy procesu produkcyjnego. Proces jest już zdefiniowany na etapie budowy Global Template. Wynika on z polityki grupy (group policy). Partner wdrożeniowy ustawia dany proces w systemie ERP Microsoft Dynamics NAV. Użytkownicy z odpowiednimi uprawnieniami w oddziale mają możliwość zmiany procesu produkcyjnego. Jeśli jednak centrala podejmie decyzję, że użytkownicy lokalni nie powinni mieć takiej możliwości, wówczas niezbędne jest wprowadzenie odpowiedniej modyfikacji w systemie ERP. Dobrym przykładem takiej standaryzacji poprzez funkcjonalność jest opisywana przez mojego kolegę standaryzacja BOMów produkcyjnych. Mamy więc Design BOM (czyli BOM master) tworzony przez firmę odpowiedzialną za jego zaprojektowanie. W ramach design BOM definiujemy komponenty i ich ilości potrzebne do wyprodukowania danego zapasu. Wówczas każdy oddział, który produkuje określony zapas tworzy swój własny BOM produkcyjny na podstawie design BOM w centralnej bazie danych. Będzie on wykorzystywany tylko w danym oddziale. Jest on następnie replikowany do bazy lokalnej. Stąd też proces jest narzucony od początku do końca. Oddział nie ma możliwości samodzielnego założenia BOMu produkcyjnego. Niezbędne jest jego utworzenie w bazie centralnej. W tej sytuacji lokalny użytkownik nie jest w stanie zmienić procesu poprzez zmianę ustawień w systemie.

Która opcja lepsza?

Decyzję, czy dany proces będzie ustandaryzowany tylko poprzez ustawienia, czy również poprzez funkcjonalność zapada już na etapie przygotowania Global Template, czyli w drugiej fazie projektu realizowanego zgodnie z metodyką NAV Global Standardization and Roll-out Methodology. To w tym momencie, zastanawiamy się razem z klientem nad najbardziej optymalnym zamodelowaniem danego procesu w globalnym systemie ERP. Rozważamy również, czy zostanie on wdrożony tylko poprzez ustawienia w lokalnych systemach, czy też proces zostanie wprowadzony „na sztywno” (poprzez funkcjonalność). W tym drugim wypadku uniemożliwiamy jakiekolwiek zmiany. Musimy sobie odpowiedzieć na pytanie czy osoby odpowiedzialne za procesy w oddziałach powinny mieć możliwość ich zmiany czy nie? Moim zdaniem, użytkownik, który ma większą możliwość „zepsucia” czegoś w systemie, będzie bardziej świadomy tego co robi. Po drugie, jeśli standaryzujemy proces „na sztywno”, czyli poprzez zmiany w funkcjonalności, blokujemy również pewną ilość opcji w systemie. Dlatego moim zdaniem lepszym rozwiązaniem jest wdrożenie procesu jedynie poprzez ustawienia.