Migracja danych z IFS do SAP i innych systemów ERP
Niezależna praktyka IFS · Migracja danych z IFS Dane z IFS opisane pole po polu, gotowe dla konsultanta SAP lub innego nowego ERP Konsultant, który ładuje nowy…
Czytaj dalejWybierz swój język
Wybierz swój język
Niezależna praktyka IFS · Migracja danych z IFS Dane z IFS opisane pole po polu, gotowe dla konsultanta SAP lub innego nowego ERP Konsultant, który ładuje nowy…
Czytaj dalej
Wykorzystanie Smart Data Manager do przekształcenia chaosu systemów spuścizny w uporządkowane zasoby gotowe do audytu.
W wersji 25R2 migracja danych ewoluowała z technicznego „zadania w tle” do nadzorowanego procesu biznesowego. Dzięki ulepszonemu narzędziu **Data Migration Manager (DMM)**, IFS Cloud oferuje teraz standaryzowane, kontenerowe podejście do przenoszenia danych, znacząco ograniczając zależność od zawodnych, niestandardowych skryptów PL/SQL.
Kluczową innowacją w 25R2 jest dojrzałość rozwiązania Smart Data Manager. W przeciwieństwie do starszych narzędzi migracyjnych, które przesyłały dane bezpośrednio do tabel produkcyjnych, Smart Data Manager wykorzystuje rygorystyczną metodologię „Stagingu” (warstwy przejściowej). Gwarantuje to, że żadne dane nie trafią do systemu głównego, dopóki nie przejdą rygorystycznych reguł walidacji zdefiniowanych przez biznes, a nie tylko dział IT.
Wersja 25R2 pozwala na tworzenie izolowanych „Projektów Migracyjnych” (kontenerów). Możesz ładować dane z plików Excel, CSV lub zewnętrznych baz danych SQL do tych kontenerów bez wpływu na środowisko produkcyjne. Umożliwia to testowanie iteracyjne – możesz czyścić i ładować kontener 50 razy, nie tworząc „śmieci” w rzeczywistych danych podstawowych (Master Data).
Narzędzie do mapowania w 25R2 zapewnia wizualny interfejs do mapowania pól z systemów spuścizny na pola IFS Cloud.
Nowość w 25R2 Auto-mapowanie: System wykorzystuje logikę rozmytą (fuzzy logic), aby sugerować mapowania na podstawie nagłówków kolumn, co przyspiesza wstępną konfigurację nawet o 40%.
System przeprowadza sprawdzenie „Danych Podstawowych” przed załadowaniem. Na przykład, jeśli próbujesz zmigrować zamówienie klienta, Smart Data Manager weryfikuje, czy ID Klienta, Część Sprzedażowa i Waluta już istnieją w środowisku docelowym. Jeśli nie, konkretna linia zostaje oznaczona jako „Błąd”, podczas gdy poprawne linie są procesowane dalej.
Zadania migracyjne zbudowane w 25R2 są trwałe. W przeciwieństwie do jednorazowych skryptów, te kontenery migracyjne mogą być ponownie wykorzystane przy przyszłych fuzjach i przejęciach (dołączanie nowych spółek) lub przy masowych aktualizacjach, zapewniając zwrot z inwestycji w mapowanie danych długo po starcie systemu.
Nie próbuj używać starych skryptów „FNDMIG” z wersji IFS Applications 9/10 bezpośrednio w IFS Cloud 25R2. Struktury API i punkty końcowe REST uległy zmianie. 25R2 wymaga korzystania z Kontenerów Wdrożeniowych dla zachowania stabilności.
Niezależna praktyka IFS · Migracja danych z IFS
Konsultant, który ładuje nowy system ERP, zmapuje tylko to, co rozumie, a baza IFS to lata klientów, dostawców i artykułów, z duplikatami i z polami, których znaczenie istnieje wyłącznie w konfiguracji Twojego IFS. Gdy eksport przychodzi bez tego wyjaśnienia, każdy import próbny zwraca listę pytań, a termin przełączenia się przesuwa. Wyciągam dane z IFS tylko do odczytu, opisuję każde pole, wskazuję duplikaty i podejrzane rekordy, wspieram Twoich użytkowników w czyszczeniu i poprawiam eksport po każdym imporcie próbnym. Mapowanie i ładowanie robi konsultant systemu docelowego.
Umów 30-minutową rozmowę techniczną Czego potrzebuję na start
Zakres konsultanta IFS kończy się na opisanym pliku eksportu. Wszystko, co dzieje się z danymi po wyjściu z IFS, od mapowania na szablony systemu docelowego po import końcowy, należy do konsultanta ds. migracji w systemie docelowym, a czyszczenie merytoryczne do Twoich użytkowników. Pracują trzy strony: Twoi użytkownicy, konsultant IFS i konsultant systemu docelowego.
| W moim zakresie (konsultant IFS) | Poza moim zakresem (konsultant systemu docelowego i użytkownicy klienta) |
|---|---|
| Powtarzalne skrypty eksportu z IFS | Mapowanie moich plików na szablony systemu docelowego |
| Pliki Excel z opisem pochodzenia każdego pola | Transformacja danych do formatu systemu docelowego |
| Wskazanie duplikatów i podejrzanych danych | Import próbny i końcowy do systemu docelowego |
| Konsultacje z użytkownikami i z konsultantem systemu docelowego | Czyszczenie i akceptacja danych (klient) |
| Zmiany eksportu po imporcie próbnym | Konfiguracja i walidacja w systemie docelowym |
Decyzje o scaleniu lub wykluczeniu rekordu podejmują Twoi użytkownicy. Ja wskazuję podejrzane dane i tłumaczę, co każde pole oznacza w IFS.
Plik eksportu jest umową między IFS a systemem docelowym, bo jego format jest stały, każde pole ma opis, a każda zmiana przechodzi przez zapisany, wersjonowany log. Działają cztery zasady.
Dane płyną w jednym kierunku: IFS, potem pliki eksportu w Excelu z opisem pól i flagami, potem czyszczenie przez Twoich użytkowników, potem mapowanie i import przez konsultanta systemu docelowego. IFS jest tylko odczytywany. Twoi użytkownicy czyszczą dane w wyeksportowanych plikach, a zmianę mechanizmu eksportu wprowadzam w skrypcie. Rozwiązanie działa z IFS Cloud i z lokalnymi wersjami IFS Applications. Kanał odczytu danych zależy od wersji i modelu hostingu, i uzgadniamy go w kroku 1.
Migracja danych z IFS ma pięć kroków, a każdy kończy się punktem kontrolnym, który trzeba spełnić przed następnym krokiem. Krok 1 wykonujemy raz na starcie. Kroki 2 do 5 powtarzamy w cyklach migracyjnych, aż import do systemu docelowego przejdzie bez błędów.
| Krok | Co się dzieje | Punkt kontrolny | Produkty |
|---|---|---|---|
| 1. Zakres i harmonogram | Ustalam z osobami kontaktowymi, jakie dane eksportuję i do kiedy. Kontakty: sprzedaż, finanse, projekt i system docelowy, obiekty danych w zakresie, kryteria selekcji, terminy cykli uzgodnione z konsultantem systemu docelowego. | Zakres zatwierdzony | Lista kontaktów, rejestr obiektów danych, kryteria selekcji, harmonogram cykli, dostęp do danych IFS, plan konsultacji, log pytań i decyzji |
| 2. Eksport z IFS | Wyciągam dane skryptami, które mogę uruchamiać wielokrotnie, i przekazuję je w Excelu: jeden plik na obiekt danych, opis każdego pola, flagi podejrzanych duplikatów i braków, ten sam skrypt w każdym cyklu. | Pliki przekazane | Skrypty eksportu, pliki Excel, podejrzane rekordy, słownik pól |
| 3. Weryfikacja i czyszczenie | Użytkownicy weryfikują pliki, a ja wyjaśniam każde pole: usuwają i scalają duplikaty, uzupełniają braki, poprawiają błędy i decydują, czy rekord migrujemy, czy pomijamy. | Dane zaakceptowane | Wyczyszczone pliki, lista scaleń, lista wykluczeń, pytania do źródła, akceptacja obszaru |
| 4. Mapowanie i import | Tłumaczę pola na sesjach z konsultantem systemu docelowego, który je mapuje i wykonuje import próbny. Format mojego pliku zostaje bez zmian. Pytania i nowe potrzeby wracają do mnie. | Import próbny wykonany | Przekazanie plików, notatki z konsultacji, log pytań strony docelowej, wynik importu próbnego |
| 5. Poprawki i odbiór | Zmieniam mechanizm eksportu według tego, co pokazał import, aż dane trafią do systemu docelowego bez błędów. Ponowny eksport na aktualnych danych, czyszczenie tylko nowych rekordów, eksport końcowy w oknie przełączenia. | Dane w systemie docelowym | Pliki końcowe, nowa wersja skryptów, uzgodnienie rekordów, protokół odbioru |
Migracja z IFS przebiega w trzech cyklach eksport-import przed startem systemu docelowego: import próbny, pełny wolumen i przebieg końcowy. Każdy cykl powtarza kroki 2 do 5 tym samym skryptem na aktualnych danych. Harmonogram jest orientacyjny, a liczbę cykli i terminy importów uzgadniamy z konsultantem systemu docelowego w kroku 1.
Po każdym cyklu uzgadniamy cztery liczby między IFS, plikiem po czyszczeniu i systemem docelowym:
Liczby się zgadzają albo wiemy dlaczego. Cykl z niewyjaśnioną różnicą nie jest zamknięty.
Pętla zwrotna jest normalną częścią procesu. Po imporcie próbnym konsultant systemu docelowego zgłasza pytania, braki i nowe potrzeby. Modyfikuję skrypt, a nie plik ręcznie, uruchamiam eksport ponownie na aktualnych danych, a Twoi użytkownicy czyszczą tylko różnicę. Każdy przebieg jest powtarzalny: ten sam skrypt, aktualne dane, przewidywalny wynik.
Domyślny zakres eksportu to nic, a każdy obiekt danych dodajemy świadomie, z kryterium selekcji. Dane podstawowe (master data) są w zakresie na pewno, a resztę ustalamy na warsztacie zakresu. Tabela pokazuje zakres wstępny z przykładowymi kryteriami.
| Obiekt danych (obszar) | Przykładowe kryterium selekcji |
|---|---|
| Klienci (sprzedaż) | Zakup w ostatnich 5 latach |
| Dostawcy (finanse) | Faktura lub zamówienie w ostatnich N latach |
| Artykuły (sprzedaż) | Ruch lub zapas w wybranym okresie |
| Projekty (projekt) | Projekty otwarte i w realizacji |
| Salda otwarte (finanse) | Do decyzji: migracja czy wprowadzenie ręczne |
Duplikaty wskazuję już przy eksporcie, więc użytkownicy trafiają na nie na początku czyszczenia, a nie po pierwszym imporcie. Na każdy obiekt danych przypada jeden skrypt, uruchamiany tyle razy, ile wymagają cykle. Słownik poniżej 20 pozycji szybciej wprowadzić ręcznie w systemie docelowym niż migrować.
Konsultacje to osobna pozycja w planie i w wycenie, bo wyjaśnianie pochodzenia danych zabiera czas, którego nie obejmuje sam eksport. Są dwa rodzaje: z konsultantem systemu docelowego o znaczeniu pól i pytaniach po imporcie oraz z Twoimi użytkownikami o pochodzeniu danych i wsparciu przy czyszczeniu. Odbywają się po eksporcie i po każdym imporcie próbnym, według logu pytań, w stałym terminie w tygodniu. Liczbę godzin określamy po warsztacie zakresu, gdy znane są obiekty i kryteria.
Pięć ryzyk opóźnia migrację danych z IFS, a każde ma przeciwdziałanie wpisane w plan. Ryzyka przeglądamy na każdym spotkaniu statusowym.
| Ryzyko | Przeciwdziałanie |
|---|---|
| Niejasny zakres danych | Zakres i kryteria zatwierdzone w kroku 1 |
| Brak dostępności osób klienta | Nazwane osoby i terminy w harmonogramie |
| Czyszczenie dłuższe niż plan | Duplikaty wskazane już przy eksporcie |
| Nowe potrzeby systemu docelowego po imporcie | Powtarzalne skrypty i kolejny cykl w planie |
| Niedoszacowane konsultacje | Czas na konsultacje jako osobna pozycja |
Przed startem eksportu potrzebuję pięciu kontaktów, a namiary na osoby kontaktowe i na konsultanta systemu docelowego są warunkiem rozpoczęcia kroku 1.
Z osobami z obszarów uzgadniam zakres eksportu i sposób czyszczenia danych. Z konsultantem systemu docelowego: terminy cykli i przekazanie plików. Pięć ustaleń zapada, zanim powstanie pierwszy skrypt:
Lista kontaktów, rejestr obiektów danych i log pytań i decyzji to dokumenty robocze tego procesu. Jak prowadzić takie dokumenty w całym projekcie IFS, opisuje sekcja Dokumenty wdrożeniowe.
Tak. Ekstrakcja z IFS wygląda tak samo dla każdego systemu ERP, bo dostarczam stały format pliku z opisem każdego pola, a mapowanie na szablony systemu docelowego robi jego konsultant. SAP jest na tej stronie przykładem roboczym; kroki, pliki i punkty kontrolne nie zmieniają się razem z systemem docelowym.
Nie. IFS jest tylko odczytywany, nic w nim nie jest instalowane ani zmieniane. Poprawki robimy w wyeksportowanych plikach podczas czyszczenia albo w skrypcie eksportu, gdy zmienia się mechanizm. Proces działa z IFS Cloud i z lokalnymi wersjami IFS Applications, a kanał odczytu uzgadniamy dla danej wersji w kroku 1.
Nie. Mapowanie na szablony SAP, transformacja do formatu SAP, import próbny i końcowy oraz konfiguracja i walidacja w SAP należą do konsultanta SAP ds. migracji. Konsultant IFS dostarcza skrypty eksportu, pliki Excel z opisem pól, wskazane duplikaty i podejrzane dane, konsultacje oraz zmiany eksportu po każdym imporcie próbnym.
Migracja danych z IFS zakłada trzy cykle eksport-import przed startem systemu docelowego: import próbny, pełny wolumen i przebieg końcowy w oknie przełączenia. Dokładną liczbę cykli i terminy importów uzgadniamy w kroku 1 z konsultantem systemu docelowego, a cykle powtarzamy, aż import przejdzie bez błędów.
Po każdym cyklu uzgadniamy cztery liczby: rekordy w IFS według kryteriów selekcji, duplikaty scalone, rekordy wykluczone z uzasadnieniem i rekordy w systemie docelowym po imporcie. Liczby się zgadzają albo różnica jest wyjaśniona, a cykl z niewyjaśnioną różnicą nie jest zamknięty.
Zakres migracji danych z IFS zaczyna się od zera, a każdy obiekt dodajemy z kryterium selekcji, na przykład klienci z zakupem w ostatnich 5 latach, dostawcy z fakturą lub zamówieniem w ostatnich N latach, artykuły z ruchem lub zapasem w wybranym okresie, projekty otwarte i w realizacji. Słowniki poniżej 20 pozycji wprowadza się ręcznie w systemie docelowym, a salda otwarte rozstrzygamy osobno: migracja albo wprowadzenie ręczne.
Migracja do IFS Cloud to osobny temat, z własnymi narzędziami i kolejnością ładowania. Jeśli przechodzisz na IFS Cloud, zobacz sekcję migracji danych w marketplace.
Dariusz Myśliwiec: niezależny konsultant IFS, 18 lat na IFS (Apps 7.5–10 i IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Siedziba w Krakowie, praca zdalna w całej Europie i na świecie. Rozmawiasz z konsultantem, który pisze skrypty eksportu i tłumaczy pola Twoim użytkownikom.
Wybrani klienci IFS: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB. SAP is a registered trademark of SAP SE; this practice is not affiliated with SAP SE.
Następny krok to warsztat zakresu i harmonogramu: kontakty ze sprzedaży, finansów, projektu i konsultant systemu docelowego, obiekty danych z kryteriami selekcji oraz harmonogram cykli uzgodniony z konsultantem systemu docelowego. Bez prezentacji sprzedażowej. Rozmawiasz z konsultantem, który buduje eksport.
Umów 30-minutową rozmowę techniczną Zobacz Dokumenty wdrożeniowe
Oblicz zwrot z inwestycji