Prezentacja przedstawia zagadnienie związane z i upgrade’em i re-implementacją starszych wersji sytemu Dynamics NAV do najnowszej wersji Microsoft Dynamics 365 Business Central.

2. Sytuacja
zastana
•Firma handlowa
•Wdrożony system Dynamics NAV
w 2014 wersja NAV 2013 R2, build
36366, klient RTC.
•Zmodyfikowane i nowe obiekty
Typ obiektu Nowe obiekty
Obiekty Std
Zmodyfikowane
Razem
Codeunit 15 25 40
Page 75 90 165
Query 5 0 5
Report 30 10 40
Table 20 50 70
XMLPort 10 10 20
Menusuite 0 1 1
Razem 155 186 341

3. Sytuacja
docelowa
• Uruchomiony Dynamics 365 Business
Central 365 w wersji on-premise
• Wersja środowiska zgodna z
najnowszą wydaną lokalizacją PL
(aktualnie Build 25924)
• Podstawowy klient: WebClient
(RTC nie będzie rozwijany w kolejnych
wersjach)
• Wykonany upgrade wraz
z kastomizacją dodatkowych
funkcjonalności

4. Istotne uwarunkowania upgrade-u z
wersji
Dynamics NAV 2013 do
Dynamics 365 Business Central
• Brak technicznej możliwości upgrade-u bezpośredniego z
wersji Dynamics NAV 2013 R2 do wersji MS Business
Central 365 dlatego wymagane jest ścieżka
• Dynamics NAV 2013 R2 -> Dynamics NAV 2018 -> MS
Business Central 365
• Upgrade kodu oraz migracji
• Upgrade bazowego kodu C/AL versus konwersja istniejącego
rozwiązania na Extensions (metoda zalecana przez
Microsoft).

5. Zakładając przejście na Extensions należy wykonać następujące
kroki:
Przeniesienie struktur danych klienta (nowe tabele i nowe pola na tabelach
standardowych) do wersji NAV2018 z modułem PL.
Wykonanie upgradu danych standardowych.
Wykonanie upgradu danych lokalizacji PL (uwaga! Moduł PL w wersji 2018
ma mniej funkcjonalności w stosunku do poprzednich wersji).
Upgrade istniejących struktur danych i modyfikacji do finalnej wersji
Business Central 365 on-premise (modyfikacje kodu C/AL.).
Wykonanie upgradu danych standardowych.
Wykonanie upgradu danych lokalizacji PL.
Porównanie wersji bazowej (Cronus) z wersją zmodyfikowaną i
identyfikacja różnic.
Konwersja zmian do kodu AL, czyli zamiana istniejących zmian na
Extensions.
Na dzień dzisiejszy moduł PL pozostaje jako zmiana kodu C/AL., więc
otrzymujemy instalację hybrydową (część zmian w C/AL., część w AL.).
Dostosowanie Page do domyślnego użycia WebClienta (wcześniej
domyślną wersją był klient RTC, są różnice w prezentacji danych i
interfejsie użytkownika).
Migracja danych klienta do struktur Extensions.
Konfiguracja istniejących funkcjonalności oraz ewentualna rekonfiguracja
istniejących.

6. FORTHEBUSINESSESOFTOMORROW
Wymagania biznesowe firmy
klienta
Przeniesienie dużej części
kastomizacji (setup + zmiany
programistyczne) ze starego
systemu do nowego
Okres realizacji projektu:
lipiec – październik 2019
Modyfikacja istniejącej części
kastomizacji tj. modyfikacja
procesów logistycznych,
wdrożenie windykacji należności,
etc.
Implementacja nowych
funkcjonalności tj. raporty,
interfejsy, zarządzanie
magazynem

7. FORTHEBUSINESSESOFTOMORROW
Jak rozumiemy re-implementacje
oraz upgrade?
Re-implementacja
wdrożenie nowych lub/ i modyfikacja
istniejących funkcjonalności w istniejącej lub
nowej bazy danych w Dynamics NAV.
Re-implementacja może być realizowana w
warunkach zmiany dostawcy oraz
podniesienia wersji systemu.
Upgrade
Projekt przeniesienia istniejących
funkcjonalności ze starego systemu do
nowego.
Upgrade może być realizowany w
warunkach zmiany dostawcy.

8. FORTHEBUSINESSESOFTOMORROW Dylemat. Potencjalne scenariusze -
Re-implementacja czy upgrade?
Upgrade.
Wykonanie najpierw upgrade-u systemu a w
drugim kroku wdrożenie nowych
funkcjonalności.
Re-implementacja.
Wykonanie w ramach jednego projektu
informatycznego zarówno upgrade-u jak
też modyfikacji aktualnie
wykorzystywanych oraz nowych
funkcjonalności.

9. FORTHEBUSINESSESOFTOMORROW Plusy i minusy scenariuszy
- Re-implementacja
• Klient po kilku latach pracy na systemie wie co mu się
podoba a co nie, jakie procesy są dobrze skonstruowane, a
które wymagają poprawy. dlatego idealnie by było
„problematyczne” procesy zaprojektować od nowa z
wykorzystaniem tej wiedzy oraz nowych standardowych
funkcjonalności systemu.
• Nowe standardowe funkcjonalności systemu mogą pozwolić
wyeliminować wykonane wcześniej zmiany
programistyczne.
• System po re-implementacji jest pozbawiony „śmieci” –
nieużywanych funkcjonalności, obiektów, kod może zostać
zoptymalizowany.
• System może być dostosowany do aktualnej wersji BC pod
względem GUI i użytych funkcjonalności.
• W przypadku BO startowa baza jest mała, co ma pozytywny
wpływ na wydajność systemu
• Klient musi być świadomy i zaangażować się w proces. Z
doświadczenia wiemy, że re-implementacje w dużej części
kończą się przeniesieniem tego co jest ze względu na
budżet projektu i termin go-live. Klientowi wygodniej jest
powiedzieć żeby przenieść funkcjonalność ukrytą pod
przyciskiem niż od nowa zgłębić się we wszystkie niuanse i
wyjątki takiej funkcjonalności i dodatkowo poświęcić czas na
pełne testy akceptacyjne.
• Ze strony firmy wdrażającej uczestniczyć muszą konsultanci
z dużym doświadczeniem, wiedzą dotyczącą nowych
funkcjonalności i technologii, aby móc zaproponować nową
funkcjonalność lub jej dostosowanie do standardowej
funkcjonalności, która mogła się pojawić w nowej wersji.
• Problematyczna jest migracja danych. Przy re-
implementacji procesów może być to wręcz niemożliwe,
jeżeli pojawią się dane, których się nie da zmapować.
Dlatego w tym przypadku lepiej jest robić uruchomienie w
oparciu o Bilans Otwarcia, natomiast klient często chce
zachować historyczne dane.

10. FORTHEBUSINESSESOFTOMORROW Plusy i minusy scenariuszy
- Upgrade
• Łatwiejszy proces z punktu widzenia technologicznego –
przenosimy istniejący kod na nową wersję. Problemy są
tylko w przypadku zmian w funkcjonalnościach lub
wycofaniu jakieś funkcjonalności przez Microsoft lub w
module PL.
• Sposób tańszy i szybszy – często z powodu dużych
ograniczeń czasowych (wymuszona data go-live) jest to
jedyny sposób którym da się osiągnąć cel w zamierzonym
czasie.
• Łatwiejsza adaptacja użytkownika do nowej wersji –
funkcjonalności działają w bardzo podobny sposób jak w
wersji sprzed upgrade-u.
• Możliwość pełnej migracji danych historycznych (chyba, że
w nowej wersji brakuje jakieś standardowej funkcjonalności
istniejącej we wcześniejszych wersjach).
• Przenoszone wszelkie „problematyczne” procesy, które nie
spełniają w pełni wymagań klienta.
• Przenoszone są wszystkie funkcje, więc również te, które
nie są już używane. Podczas życia systemu część
procesów staje się zbędna, ale zostaje przeniesiona i
komplikuje kod.
• Nie wykorzystujemy „nowinek technologicznych” nowych
wersji, proces może wykorzystywać przestarzałe
technologie, które dałoby się zastąpić czymś
wydajniejszym.

11. FORTHEBUSINESSESOFTOMORROW
Podsumowanie
Upgrade
Relatywnie szybki czas
realizacji projektu
Przeniesienie wszystkich
„dobrych i złych”
funkcjonalności do
nowego systemu
Nie duże zaangażowanie
grupy projektowej klienta
Niższy koszt na początku

12. FORTHEBUSINESSESOFTOMORROW
Podsumowanie
Re-implementacja
Dłuższy czas realizacji
projektu
Możliwość optymalizacji
aktualnie skastomizowanych
procesów
Duże zaangażowanie
grupy projektowej klienta
Wyższy koszt na
początku
Spójny proces wdrożenia nowych
funkcjonalności z wykorzystaniem
nowych standardowych
funkcjonalności, które pojawiły się BC
Możliwość eliminacji
nadmiarowych zmian
programistycznych

13. PROFESIONALŲ KOMANDADziękuję