Customer case · Brewing · SAP → Business Central
Customer and BOM data for an SAP-to-Navision move, delivered by one specialist instead of five.
Karlsberg, a German brewery with about 1,100 employees and operations in several European countries, engaged Visehub directly as the independent data-preparation expert for the most complex data areas of its ERP change. The implementation partner configured Navision and loaded the final files; Visehub owned everything from extraction to clean files.
- 5 → 1
- FTE-equivalent of work handled by one Visehub specialist
- 1.5 yrs
- iterative deliveries across DEV, QA, UAT and PROD
- 2 objects
- customer master and bills of materials
- DE → FR
- rules from the German entity reused in France
01 · Results
What came out of it.
- Work estimated at about five full-time people done by one Visehub specialist supervising the tool
- Consistent, complete customer and BOM data — less operational risk after go-live
- One repeatable process across DEV, QA, UAT and PROD, and across companies, starting with the German parent and reused for the French unit
- About 1.5 years, synchronised with the Navision implementation, since the project started in 2021
“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.”
The same customer is the first production user of vise FieldMap: material master data mapped from Microsoft Dynamics 365 Business Central to SAP S/4HANA, with AI-drafted field pairs and a consultant approving every line.
02 · The challenge
The challenge.
- Cost-driven ERP changeKarlsberg moved its main ERP from SAP to Microsoft Navision to cut maintenance and licence cost. The target was deliberately simpler than SAP; the data still had to arrive complete and consistent.
- Two hard objectsCustomer data and bills of materials carried the most structure and business logic in SAP, and the most risk in the move.
- Fragmented, duplicated customersCustomer records were spread across several systems and duplicated even within one — often differing by a space or a comma.
- Transformation, not copySAP customer roles such as payer and ship-to party had to become the right Navision structures, and the logic depended on the value of specific fields.
- No spare peopleThe team knew its data but did not have the capacity, the specialist know-how or the tooling to deliver within the project schedule — DEV, QA, UAT and PROD.
03 · What we did
What we did.
- 01Analytical workshopsWith the implementation partner on Navision’s technical requirements and field mappings; with Karlsberg’s team on business rules, cleansing criteria, deduplication logic and validation.
- 02Extraction and consolidationAutomated retrieval from several SAP source systems, then a first consolidation into one working set.
- 03Cleansing and deduplicationFormat-standardisation rules and matching that catches duplicates despite notation differences, producing a golden record per customer.
- 04Transformation logicRules in vise DMW that used one key field to decide how customer roles and attributes were created and assigned in Navision.
- 05Repeatable automationOnce defined, the process ran on demand for every test cycle, environment and company — no manual repetition.
Visehub’s templates were built for migrations into SAP; this project ran the other way, from SAP to Navision. The solution was tailor-made — and its components are now reusable for SAP-to-Navision moves.
Similar move ahead of you?
Customer or vendor master is the usual starting object. Thirty days, your data, a working project.