Nowa wersja systemu - upgrade czy re-implementacja
- 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