Dynamics AX 2012 w produkcji - możliwości, ryzyka i migracja

W wielu polskich firmach produkcyjnych system ERP pracuje przez kilkanaście lat, a jego wymiana nie jest prostą podmianą programu. Microsoft Dynamics AX 2012 nadal można spotkać w zakładach przemysłowych, centrach dystrybucyjnych i grupach kapitałowych, dlatego wyjaśniam, do czego służy ten system, jakie ma mocne strony, gdzie pojawiają się ryzyka oraz co w 2026 roku zrobić z istniejącą instalacją.

Czym jest Dynamics AX 2012 i gdzie znajduje zastosowanie

Dynamics AX 2012 to klasyczny, rozbudowany system ERP firmy Microsoft. Łączy dane finansowe i operacyjne w jednym środowisku, dzięki czemu zamówienie klienta może zostać powiązane ze stanem magazynowym, planem produkcji, zakupem surowców, fakturą i wynikiem finansowym. Dla przedsiębiorstwa oznacza to mniej ręcznego przepisywania danych i lepszą kontrolę nad przepływem informacji.

W polskich firmach system najczęściej obsługuje finanse, księgowość, logistykę, sprzedaż, zakupy, magazyny i produkcję. Nie jest to narzędzie przeznaczone wyłącznie dla korporacji, ale jego wdrożenie ma sens przede wszystkim tam, gdzie procesów jest dużo, występują różne oddziały lub spółki, a dane muszą być kontrolowane według jednolitych zasad.

W zakładzie produkcyjnym rozwiązanie może prowadzić kartoteki materiałowe, marszruty technologiczne, zlecenia produkcyjne, zapotrzebowanie na komponenty i rozliczenie kosztu wytworzenia. Szczególnie przydatne jest połączenie planowania materiałowego z magazynem. Gdy zapasy spadają poniżej ustalonego poziomu, system może wskazać potrzebę zakupu albo uwzględnić ją w planie produkcji.

Trzeba jednak odróżnić centralną platformę ERP od systemów działających bezpośrednio na hali. AX 2012 nie zastępuje automatyki przemysłowej, sterowników PLC ani systemu MES, czyli rozwiązania nadzorującego wykonanie produkcji w czasie rzeczywistym. Może natomiast wymieniać z nimi dane, na przykład o zleceniach, zużyciu materiałów, ilości wykonanych sztuk i przestojach.

Moduły, które mają największe znaczenie w przemyśle

Największą wartością tego rozwiązania nie jest pojedynczy moduł, lecz spójność danych między działami. Produkcja, magazyn, zakupy i księgowość pracują na wspólnych kartotekach oraz dokumentach. To właśnie ten element decyduje o jakości raportowania, a nie sama liczba dostępnych funkcji.

Produkcja i planowanie materiałowe

Moduł produkcyjny pozwala definiować struktury produktów, operacje technologiczne, zasoby oraz czasy wykonania. Planowanie potrzeb materiałowych, często określane skrótem MRP, analizuje zapotrzebowanie wynikające z zamówień, prognoz i zleceń produkcyjnych. Wynikiem mogą być propozycje zakupów, przesunięć magazynowych albo uruchomienia kolejnych zleceń.

W praktyce największą różnicę robi jakość danych wejściowych. Nieaktualna struktura produktu, błędny czas dostawy lub nieprawidłowy stan minimalny potrafią wygenerować plan, który wygląda profesjonalnie, ale prowadzi do braków materiałowych. Dlatego przed rozbudową raportów sprawdziłbym najpierw kartoteki, jednostki miary, czasy technologiczne i reguły uzupełniania zapasów.

Magazyn, logistyka i zakupy

System obsługuje przyjęcia, wydania, przesunięcia, rezerwacje i inwentaryzację. W zależności od konfiguracji można zarządzać lokalizacjami magazynowymi, partiami, numerami seryjnymi oraz śledzeniem materiału od zakupu do wysyłki do klienta.

Dla przemysłu ważna jest identyfikowalność. Jeżeli partia surowca okaże się wadliwa, przedsiębiorstwo powinno móc ustalić, w których wyrobach została wykorzystana i do których odbiorców trafiły te produkty. AX 2012 może taki ślad zapewnić, ale tylko wtedy, gdy pracownicy konsekwentnie rejestrują partie i numery seryjne. Sam system nie naprawi obchodzenia procedur.

Finanse i kontrola kosztów

Moduły finansowe pozwalają prowadzić księgę główną, należności, zobowiązania, środki trwałe, budżety i rozliczenia między jednostkami. Dla grup kapitałowych istotna jest możliwość pracy z wieloma firmami, walutami i strukturami organizacyjnymi.

W przedsiębiorstwie produkcyjnym finanse mogą analizować nie tylko sprzedaż, lecz także koszt materiałów, robocizny, pracy maszyn i odchyleń produkcyjnych. To daje podstawę do sprawdzenia, czy marża spada przez ceny zakupu, wydłużone przezbrojenia, braki jakościowe czy niewłaściwe normy zużycia.

Sprzedaż, projekty i obsługa zamówień

System może prowadzić oferty, zamówienia klientów, dostawy i fakturowanie. W firmach realizujących kontrakty przydatne bywają także funkcje projektowe, które pozwalają przypisywać koszty, przychody, roboczogodziny i zakupy do konkretnego przedsięwzięcia.

To rozwiązanie dobrze pasuje do organizacji, w których sprzedaż nie kończy się na wysłaniu gotowego towaru. Przykładem może być producent maszyn, który musi kontrolować projekt, zakup podzespołów, produkcję, instalację i serwis. W takim modelu wspólna ewidencja ogranicza ryzyko, że koszty pozostaną rozproszone w arkuszach kalkulacyjnych.

Określenie „AX 2012” obejmuje kilka wydań. To ważne, ponieważ możliwości aktualizacji, poziom poprawek i dostępna dokumentacja zależą od konkretnej wersji oraz zainstalowanych aktualizacji zbiorczych.

W dokumentacji technicznej często pojawiają się skróty CU, AOS i X++. CU oznacza cumulative update, czyli zbiorczy pakiet poprawek, AOS to warstwa serwerowa obsługująca logikę aplikacji, a X++ jest językiem używanym do rozszerzania systemu. Bez znajomości tych elementów trudno rzetelnie ocenić, czy konkretna instalacja jest gotowa do migracji.

Najczęstszy błąd polega na utożsamianiu wersji programu z datą jego wdrożenia. Dwie firmy mogą korzystać z R3, ale jedna mieć uporządkowany kod i regularnie testowaną kopię zapasową, a druga posiadać wiele nieudokumentowanych modyfikacji. Z punktu widzenia ryzyka IT są to zupełnie różne sytuacje.

Czy można nadal bezpiecznie używać tego systemu

Technicznie tak, ale nie należy mylić dalszego działania z dalszym wsparciem producenta. Według informacji Microsoft Learn wsparcie podstawowej wersji i R2 zakończyło się 12 kwietnia 2022 roku, natomiast dla R3 rozszerzone wsparcie zakończyło się 10 stycznia 2023 roku. W 2026 roku żadna z tych wersji nie jest już objęta standardowym cyklem poprawek bezpieczeństwa firmy Microsoft.

To nie oznacza automatycznie, że trzeba wyłączyć system następnego dnia. Oznacza natomiast, że odpowiedzialność za ryzyko rośnie. Trzeba kontrolować serwery, system operacyjny, bazę SQL, konta uprzywilejowane, połączenia z innymi aplikacjami i procedury odtwarzania po awarii.

Przed pozostawieniem starej instalacji oceniłbym co najmniej:

• kopie zapasowe, w tym regularne testy odtworzenia, a nie tylko sprawdzanie, czy zadanie backupu zakończyło się bez błędu,
• integracje z bankami, sklepem internetowym, systemem WMS, MES, EDI i urządzeniami na produkcji,
• uprawnienia użytkowników oraz konta byłych pracowników i dostawców,
• stan dokumentacji dotyczącej modyfikacji, interfejsów i zadań cyklicznych,
• zależności infrastrukturalne, czyli wersje Windows Server, SQL Server, sterowników i narzędzi raportowych.

Największym zagrożeniem często nie jest sam wiek aplikacji, lecz brak wiedzy o tym, jak została skonfigurowana. Jeżeli tylko jedna osoba wie, jak działa import zamówień albo jak odtworzyć środowisko testowe, firma ma pojedynczy punkt awarii. W takim przypadku uporządkowanie dokumentacji może dać szybszy efekt niż kolejny raport zarządczy.

Modernizacja i migracja do Dynamics 365

Dla większości organizacji utrzymujących ten system docelowym kierunkiem jest migracja do aplikacji finansowych i operacyjnych Dynamics 365, przede wszystkim Dynamics 365 Finance oraz Dynamics 365 Supply Chain Management. Nie jest to jednak aktualizacja wykonywana jednym przyciskiem. To projekt obejmujący analizę procesów, kodu, danych, integracji i pracy użytkowników.

Obecnie wspierana ścieżka migracji prowadzi z AX 2012 R2 lub R3. Jeżeli firma korzysta z wersji bazowej, najpierw musi sprawdzić możliwość przejścia do jednej z tych edycji. Microsoft wskazuje także ograniczenia dotyczące niektórych przestarzałych funkcji, między innymi wirtualnych firm i partycji danych, dlatego przed decyzją trzeba uruchomić analizę modernizacyjną.

Przeczytaj również: MRP i ERP w produkcji - jak połączyć planowanie z działaniem

Jak przygotować projekt

1. Zidentyfikuj wersję i zakres systemu. Spisz moduły, firmy, lokalizacje, użytkowników, integracje, raporty oraz wszystkie modyfikacje.
2. Przeanalizuj kod i dane. Szczególnej uwagi wymagają rozszerzenia X++, stare interfejsy, nieużywane kartoteki i duże archiwa transakcji.
3. Wykonaj analizę dopasowania. Porównaj obecne procesy z funkcjami nowej platformy. Nie przenoś automatycznie każdego rozwiązania tylko dlatego, że działało w starej wersji.
4. Przygotuj środowisko testowe. Testy powinny objąć zamknięcie miesiąca, planowanie produkcji, przyjęcie materiału, reklamację, inwentaryzację i sytuacje awaryjne.
5. Zaplanuj migrację etapami. Najbezpieczniej rozdzielić przygotowanie danych, testy integracji, szkolenia, migrację właściwą i stabilizację po uruchomieniu.

Dane historyczne można w wielu scenariuszach przenieść, ale nie zawsze warto przenosić wszystko. Pełna historia ułatwia analizy i audyt, lecz zwiększa czas przygotowania oraz liczbę problemów z jakością danych. Ja zacząłbym od rozróżnienia informacji wymaganych prawnie, potrzebnych operacyjnie i przydatnych wyłącznie do sporadycznych analiz.

Kosztu migracji nie da się uczciwie wyliczyć na podstawie samej liczby użytkowników. Dużo większe znaczenie mają liczba spółek, poziom customizacji, liczba integracji, jakość danych i wymagania produkcji. Dwie firmy z podobną liczbą stanowisk mogą mieć projekty różniące się zakresem kilkukrotnie.

Co zrobić, jeśli migracja nie jest jeszcze możliwa

Nie każda firma może od razu rozpocząć duży projekt transformacji. Przyczyną może być budżet, brak zasobów, trwająca reorganizacja albo konieczność wcześniejszej wymiany systemu MES czy WMS. W takiej sytuacji rozsądny plan przejściowy powinien mieć określony termin i właściciela, a nie sprowadzać się do decyzji „zostawiamy, dopóki działa”.

Minimum bezpieczeństwa obejmuje odseparowanie środowiska, ograniczenie dostępu z sieci, aktualne kopie zapasowe, monitoring, test odtworzenia oraz spisaną procedurę awaryjną. Dobrze jest też zamrozić przypadkowe modyfikacje. Każda dodatkowa zmiana w starym kodzie zwiększa koszt późniejszej migracji i może utrudnić znalezienie źródła błędu.

W okresie przejściowym można porządkować dane podstawowe, usuwać nieużywane konta, opisywać integracje i archiwizować stare dokumenty. To praca mało efektowna, ale bardzo praktyczna. Dzięki niej projekt modernizacyjny zaczyna się od wiedzy o stanie faktycznym, a nie od zgadywania.

Nie rekomendowałbym natomiast budowania nowych, strategicznych procesów na tej platformie. Jeżeli firma uruchamia nową fabrykę, centralny magazyn lub sprzedaż cyfrową, lepiej sprawdzić docelową architekturę przed inwestowaniem w kolejne rozwiązania zależne od starego ERP.

Jak ocenić, czy instalacja jest gotowa do kolejnego kroku

Najlepsza decyzja nie wynika z samego wieku systemu. Powinna wynikać z porównania ryzyka dalszego utrzymania z kosztem i zakresem modernizacji. Stabilna instalacja z dobrze opisanymi procesami może dać firmie czas na przygotowanie, ale brak wsparcia, nieznane integracje i problemy z bezpieczeństwem powinny wyraźnie przyspieszyć działania.

• Jeżeli system obsługuje podstawowe procesy, lecz dokumentacja jest słaba, zacznij od inwentaryzacji i testu odtworzeniowego.
• Jeżeli firma korzysta z R2 lub R3 i ma dużo własnego kodu, wykonaj analizę migracyjną przed wyborem partnera.
• Jeżeli największym problemem są raporty, sprawdź najpierw jakość danych i integrację z narzędziem analitycznym, zamiast wymieniać cały ERP.
• Jeżeli system jest połączony z produkcją, zaplanuj osobne testy ciągłości działania hali i procesów magazynowych.
• Jeżeli nie ma osoby odpowiedzialnej za decyzję, projekt będzie stał w miejscu niezależnie od wybranej technologii.

AX 2012 pozostaje ważnym elementem historii wielu przedsiębiorstw i nadal może dostarczać wartości biznesowej, ale w 2026 roku nie powinien być traktowany jako perspektywiczna platforma rozwoju. Najrozsądniejsze podejście to zabezpieczyć działające środowisko, uporządkować dane i zależności, a potem przeprowadzić migrację na podstawie rzeczywistych procesów, nie katalogu funkcji. Taka kolejność ogranicza ryzyko kosztownej przeprowadzki i pozwala zachować to, co w organizacji faktycznie działa.