Przejdź do treści
Karlsberg

Studium przypadku · Browarnictwo · SAP → BC → S/4HANA

Dane klientów i BOM-y przy przejściu z SAP na Navision, dostarczone przez jednego specjalistę zamiast pięciu.

Karlsberg, niemiecki browar zatrudniający około 1100 osób i działający w kilku krajach europejskich, zaangażował Visehub bezpośrednio jako niezależnego eksperta od przygotowania danych dla najbardziej złożonych obszarów danych przy zmianie ERP. Partner wdrożeniowy skonfigurował Navision i załadował końcowe pliki; Visehub odpowiadał za wszystko od ekstrakcji do czystych plików.

5 → 1
ekwiwalent etatów (FTE) wykonany przez jednego specjalistę Visehub
1,5 roku
iteracyjne dostawy przez DEV, QA, UAT i PROD
2 programy
SAP → Navision od 2021; dziś Business Central + SAP ECC → S/4HANA
DE → FR
reguły z niemieckiej spółki wykorzystane ponownie we Francji

01 · Wyniki

Co z tego wyszło.

  • Pracę szacowaną na około pięć pełnych etatów wykonał jeden specjalista Visehub nadzorujący narzędzie
  • Spójne, kompletne dane klientów i BOM-y — mniejsze ryzyko operacyjne po go-live
  • Jeden powtarzalny proces przez DEV, QA, UAT i PROD oraz dla kolejnych spółek — od niemieckiej spółki matki po ponowne użycie we francuskiej jednostce
  • Około 1,5 roku, w synchronizacji z wdrożeniem Navision, od startu projektu w 2021 roku

“Visehub has been a reliable and competent partner by our side. A simple briefing combined with a deadline was enough to receive a high-quality result on time.”

Jonah Back, Team Lead ERP & End-to-End Business Processes, Karlsberg
A teraz · trzy fale do S/4HANA

Ten sam klient konsoliduje dwa systemy ERP w jednym SAP S/4HANA — najpierw Microsoft Dynamics 365 Business Central, potem SAP ECC — i jest pierwszym produkcyjnym użytkownikiem vise FieldMap.

Dane podstawowe
Klient, dostawca, materiał i zestawienia materiałowe — zdeduplikowane i scalone z obu systemów źródłowych; mapowanie przygotowane przez AI, każdy wiersz zatwierdzony przez konsultanta.
Dane transakcyjne, dodane na prośbę Karlsberga
Pozycje otwarte klientów i dostawców, salda kont księgi głównej i stany na miejscach składowania z numerami partii dla każdej spółki w fali — wyekstrahowane i przekształcone tym samym zautomatyzowanym procesem zamiast ręcznie.
Narzędzia
vise FieldMap do mapowania, vise DMW do ekstrakcji, walidacji i plików ładowania, vise LoV-MAP do list wartości.

02 · Wyzwanie

Wyzwanie.

  • Zmiana ERP z powodu kosztówKarlsberg przeniósł swój główny ERP z SAP na Microsoft Navision, żeby obniżyć koszty utrzymania i licencji. System docelowy był celowo prostszy niż SAP; dane i tak musiały dotrzeć kompletne i spójne.
  • Dwa trudne obiektyDane klientów i BOM-y miały w SAP najwięcej struktury i logiki biznesowej — i niosły największe ryzyko przy przejściu.
  • Rozproszeni, zdublowani klienciRekordy klientów były rozproszone po kilku systemach i zdublowane nawet w ramach jednego — często różniły się spacją albo przecinkiem.
  • Transformacja, nie kopiaRole klienta w SAP, takie jak płatnik i odbiorca towaru, musiały stać się właściwymi strukturami w Navision, a logika zależała od wartości określonych pól.
  • Brak wolnych zasobówZespół znał swoje dane, ale nie miał mocy przerobowych, specjalistycznej wiedzy ani narzędzi, żeby zdążyć w harmonogramie projektu — DEV, QA, UAT i PROD.

03 · Co zrobiliśmy

Co zrobiliśmy.

  1. 01Warsztaty analityczneZ partnerem wdrożeniowym — o wymaganiach technicznych Navision i mapowaniach pól; z zespołem Karlsberga — o regułach biznesowych, kryteriach czyszczenia, logice deduplikacji i walidacji.
  2. 02Ekstrakcja i konsolidacjaAutomatyczne pobieranie danych z kilku źródłowych systemów SAP, potem pierwsza konsolidacja do jednego zbioru roboczego.
  3. 03Czyszczenie i deduplikacjaReguły standaryzacji formatów i dopasowanie, które wyłapuje duplikaty mimo różnic w zapisie, tworząc golden record dla każdego klienta.
  4. 04Logika transformacjiReguły w vise DMW, które na podstawie jednego kluczowego pola decydowały, jak tworzyć i przypisywać w Navision role i atrybuty klienta.
  5. 05Powtarzalna automatyzacjaRaz zdefiniowany proces działał na żądanie dla każdego cyklu testowego, środowiska i spółki — bez ręcznego powtarzania.

Szablony Visehub były zbudowane z myślą o migracjach do SAP; ten projekt szedł w drugą stronę, z SAP do Navision. Rozwiązanie zostało przygotowane na miarę — a jego elementy nadają się dziś do ponownego użycia przy przejściach z SAP do Navision.

Podobne przejście przed Państwem?

Dane podstawowe klientów lub dostawców to typowy obiekt na start. Trzydzieści dni, Państwa dane, działający projekt.

Zacznij 30-dniowy PoC SAP ↔ Business Central