ERP migration: the work around the software

Context

A manufacturer running production, purchasing, stock and sales on an ageing ERP. The decision to replace it was made and the vendor was chosen. The risk sat in everything around the software: the servers it runs on, who is allowed to do what, and the data it starts with.

The vendor implements. I work between the company and the vendor: turning what the business needs into something the vendor can configure, checking what comes back - and saying so on either side when something won’t work.

What I do

Infrastructure. I designed the server set-up for the new ERP and the engineering data system (PDM) that feeds it: one virtualisation host, a database server shared by both systems, a separate application server for PDM. Two checks mattered more than sizing. The newest database version was ruled out because the PDM didn’t support it yet. And the licensing model changed because of the e-shop - customers ordering online count as users of the database.

Roles and permissions. A catalogue of around 30 roles mapped to real jobs, with a permission matrix and rules for assigning them - not copied from the old system. The key finding was in the defaults: in this ERP, a user without a role sees everything. So the first role every user gets is a baseline one that denies by default, and everything else is granted on top of it.

Master data. Item groups built from what engineering actually has in the PDM, and an item numbering scheme with a thin, stable prefix (make / buy / sell) and a plain counter - meaning stays in attributes, not in the number. Only active items move to the new system; the old database stays available for reading.

Workshops and open points. Full-day AS-IS workshops across planning, engineering, purchasing, warehouse, service and logistics, each turned into a structured record. Regular internal reviews of what the implementation hasn’t covered yet, so nothing is discovered at go-live.

Where it stands

The new system runs on a test database. I argued for a go-live date set by the bill-of-materials revision and the data cleanup, not by the calendar - a date that ignores both just moves the problems into the first year of operation.

Why it matters

Most problems that show up later in reports are created here: in master data, and in who is allowed to book what. Fixing them before the move is cheaper than fixing every report built on top of them.