Skonsolidowany system ERP

Realizowane przez nas globalne wdrożenia systemu ERP Microsoft Dynamics NAV (Navision) obejmują przygotowanie tzw. Global Template, który jest następnie wdrażany w poszczególnych oddziałach. Ponieważ system będzie wykorzystywany w różnych krajach, dlatego z reguły wymaga również lokalnej warstwy językowej. Niektórzy z naszych klientów międzynarodowych jako grupowy standard przyjęli system Microsoft Dynamics NAV wyłącznie w języku angielskim. Takie międzynarodowe podejście zastosowała np. firma Starco. W jej przypadku problem języków lokalnych nie występuje. Oczywiście niekiedy wersje językowe są jednak wymagane przez klientów.

Problem z wersjami językowymi modyfikacji systemu ERP

Dodanie języka lokalnego do standardowej wersji systemu ERP Microsoft Dynamics NAV nie jest szczególnym wyzwaniem. Jeśli dla danego kraju jest dostępna lokalna wersja systemu, wówczas język jest po prostu dodawany do bazy jako część lokalnej funkcjonalności. Nieco bardziej problematyczne jest jednak lokalizowanie modyfikacji. Global Template oprócz międzynarodowej wersji Microsoft Dynamics NAV W1, jest wzbogacany o szereg modułów i funkcjonalności, które firma międzynarodowa uznaje za potrzebne w swoich oddziałach. Moduły (add-ony) mają często tylko kilka wersji językowych – przygotowanych dla krajów, gdzie dany moduł został wcześniej wdrożony. Z kolei funkcjonalności przygotowane przez partnera Navision na potrzeby globalnego projektu mają pierwotnie tylko angielską wersję językową.

Jakie mamy zatem opcje lokalizacji globalnego, skonsolidowanego systemu ERP?

Naszym zdaniem najbardziej optymalną finansowo i funkcjonalnie opcją jest dodawanie dostępnej lokalnej warstwy językowej do standardowej wersji systemu oraz pozostawienie wszelkich modułów i dobudowanych funkcjonalności w wersji angielskiej. Zastosowaliśmy takie rozwiązanie w jednym z realizowanych przez nas projektów międzynarodowych i wydaje się ono najlepsze. Wdrożenie wyłącznie angielskiej wersji może bardzo utrudniać oswojenie się z systemem ERP Microsoft Dynamics NAV, jeśli użytkownicy korzystali wcześniej z innego systemu ERP. Oczywiście jest to również problem w sytuacji, gdy globalny, skonsolidowany system ERP ma zostać wdrożony w dużej ilości krajów, w których użytkownicy końcowi słabo znają angielski.

Co w sytuacji kiedy niezbędne jest również tłumaczenie wszelkich modyfikacji systemu?

Realizowaliśmy również projekty międzynarodowe, w których funkcjonalność zbudowana od podstaw (na potrzeby klienta) stanowiła znaczną część funkcjonalności całego skonsolidowanego systemu ERP. Było tak w przypadku firmy logistycznej – OT Logistics, gdzie przygotowaliśmy rozległą funkcjonalność do planowania transportu w Microsoft Dynamics NAV. Jej tłumaczenie było więc niezbędne. Jako polski partner przygotowaliśmy wersję angielską i polską. Aby przygotować wersję niemiecką wygenerowaliśmy z systemu arkusz ze wszystkimi dodanymi do standardowej wersji systemu frazami oraz wyrażeniami. Projekt zakładał bowiem budowę rozległego modułu do planowania transportu. Arkusz przekazaliśmy użytkownikom kluczowym z niemieckich oddziałów firmy, którzy samodzielnie przetłumaczyli pola z angielskiego na niemiecki. W tłumaczeniu wspierało ich niemieckie biuro tłumaczeń. Po przetłumaczeniu plik Excel został zaimportowany do Microsoft Dynamics NAV i niemiecka wersja była gotowa. Moim zdaniem w sytuacji, kiedy również modyfikacje Microsoft Dynamics NAV muszą być w systemie przetłumaczone na lokalny język, wówczas użytkownicy kluczowi, znający swoją branżę są w stanie wziąć na siebie lokalizację aplikacji – oczywiście przy naszej asyście.

Zarządzanie wieloma językami w globalnym projekcie ERP

W trakcie implementacji Global Template w oddziale (czyli w trakcie roll-outu) dochodzi do łączenia (merge) standardowego obiektu Microsoft Dynamics NAV ze zmodyfikowanym obiektem, wchodzącym w skład Global Template. Eksportujemy więc dany obiekt z lokalnej standardowej wersji Microsoft Dynamics NAV, eksportujemy również ten sam obiekt z Global Template i łączymy je (merge).
Po połączeniu obiektów skonsolidowany system ERP (Szablon globalny) zostaje wzbogacony o nową wersję językową. To z kolei oznacza, że w trakcie globalnego roll-outu systemu nie możemy dodawać lokalnie nowych języków. Każdy nowy język musi być dodany do bazy Global Template i następnie wdrożony we wszystkich krajach, gdzie system już pracuje. Tylko takie podejście gwarantuje, że obiekty w lokalnych bazach danych nie będą się od siebie różnić. Powoduje to ogromne problemy z zarządzaniem językami. Jeśli natomiast przyjmiemy założenie, że w każdej lokalnej bazie danych mamy jedynie dwie wersje językowe (angielską i lokalną) i zakładamy, że obiekty różnią się od siebie, wówczas mamy dużo więcej pracy przy zarządzaniu obiektami.

Zarządzanie wielojęzycznością w Microsoft Dynamics NAV (Navision)
Generalnie rzecz ujmując Microsoft Dynamics NAV nie jest dobrze przygotowany do obsługi wielojęzyczności. Wynika to ze sposobu zaimplementowania warstwy językowej w wersji Navision 3.0. Przed tą wersją system Navision był jednojęzyczny. Obiekty w każdej wersji lokalnej miały własne lokalne nazwy (np. po angielsku tabela G/L Entry, Zapis K/G itd.). Od wersji 3.0 obiekty w systemie są w języku angielskim niezależnie od lokalnej wersji. Dostępne jest jednak również pole, w którym możliwe jest dodanie tłumaczenia. Przez dość długi czas możliwe było dodanie 5 takich wersji językowych. Na dodanie szóstej brakowało niekiedy miejsca. Od wersji Microsoft Dynamics NAV 2013 tych możliwych języków jest 13. Nie mniej problem cały czas nie jest definitywnie rozwiązany. Moim zdaniem dobrym wyjściem byłoby usunięcie tłumaczeń ze struktury obiektu do osobnej struktury, którą moglibyśmy nazwać tłumaczeniem.

Portal B2B?

Osobnym, wartym rozważenia rozwiązaniem jest Portal B2B. Dostarczamy to rozwiązanie oparte na silniku Joomla!, które komunikuje się z systemem ERP Microsoft Dynamics NAV (Navision) poprzez usługi sieci web (web-serwisy). Dzięki portalowi mamy możliwość udostępnienia użytkownikowi dostępu do danych w systemie oraz wprowadzania danych do systemu korzystając z zewnętrznej aplikacji. Jeśli wersje językowe dla użytkowników końcowych zostaną dodane wyłącznie na tym poziomie, wówczas można mówić o pewnym rozwiązaniu problemu wielojęzyczności. Jest to jednak rozwiązanie, które można zastosować w przypadku firm, gdzie duża grupa pracowników będzie korzystała ze ściśle określonej funkcjonalności.

Zarządzanie obiektami przy podnoszeniu wersji Global Template w trakcie globalnego roll-outu systemu ERP

Tak jak pisałem, jeśli założymy, że wszystkie firmy mają różne obiekty na poziomie warstwy językowej, wówczas pojawia się zadanie zarządzania zmianą oraz zarządzania obiektami. Wynikają one z faktu, iż faza globalnego roll-outu grupowego, skonsolidowanego systemu ERP, do wszystkich oddziałów, zajmuje dłuższy okres czasu, w zależności od ilości podmiotów oraz gotowości wewnątrz organizacji. Co za tym idzie w trakcie całego procesu mamy do czynienia ze zmianami wdrażanymi w Global Template. Oczywiście nie chodzi o jakieś gruntowne zmiany całego założenia. Występują natomiast żądania zmiany. Wynika to nie tylko z błędów w standardowym systemie, ale też z tego, że w ciągu trwania  globalnego roll-outu zmienia się też biznes i wymagania klientów. Dochodzi do tego jeszcze kwestia pewnej dowolności jeśli chodzi o zakres wdrożenia w oddziałach. Spotykaliśmy się z sytuacjami, w których dany oddział decydował się na wdrożenie tylko części grupowego, skonsolidowanego systemu ERP, a resztę zostawiał sobie na później. Mamy więc do czynienia z sytuacją, w której przez pewien okres wdrażamy Global Template w wersji 1, po jego modyfikacji kilka oddziałów ma wdrożoną wersję 2, a kilka następnych wersję 3. Może się zdarzyć, że w tym momencie grupa podejmie decyzję np. o wdrożeniu we wszystkich krajach EDI, który będzie należało dodać do Global Template. Taki proces będzie wymagał uaktualnienia jego wersji we wszystkich krajach – wyrównania wersji.