Majestic Safety Set the PIM Boundary Before the Purchase

Majestic Safety wrote the PIM boundary before it bought a system. The company supplies personal protective equipment and safety products in the Benelux, to large enterprises and to smaller businesses, with a wide range and customer-specific needs. PIMvendors used workshops and an architecture map to settle three decisions that usually get buried in a feature list: customer-specific pricing, long-tail products whose numbers had been created by hand in SAP, and whether the PIM should also act as a light PLM.

Client Introduction

Majestic Safety Products & Services supplies personal protective equipment and safety solutions in the Benelux. The range is wide, and a large part of the work is customer-specific. Buyers include large enterprises and smaller businesses.

The Challenge

Majestic was already looking at a PIM in the middle of its systems. The open decisions were practical. The team needed an implementation method, and a way to follow up after rollout so the project did not stop at go-live. Customer-specific prices had to work in e-commerce. A long-tail strategy depended on product numbers that had been created manually in SAP. Someone had to place light PLM work in the PIM or in another system. Until those calls were made, "where the PIM sits" was a slogan.

The Solution

PIMvendors ran structured workshops and mapped the architecture. The pricing options were walked through with the team. The long-tail approach was designed so it could grow without new product numbers being typed into SAP. On PLM, the advice was explicit: keep that function in the PIM, or place it in another system, and do not leave the question open. The PIM was then placed in an architecture the other applications can talk to.

The Results

Majestic has a blueprint for a PIM as the core of its digital setup. Complex product data, customer-specific pricing and the long-tail can be handled without leaning on the old SAP process for product numbers. The blueprint is the result. The software purchase comes after it.

The trade-off is scope. A PIM that also carries pricing logic and a light PLM looks simpler on a diagram and becomes the next system nobody can change. Leaving PLM, and part of the pricing, outside the PIM means a second system stays in the architecture on purpose.

That boundary is the piece another safety or technical wholesaler can reuse. Where ERP stops and PIM starts is the line Majestic was already crossing, because product numbers lived in SAP. PLM and PIM is the split the workshops made between engineering data and the PIM. The PIM implementation guide covers the method and the follow-up after rollout, which was an open question at the start. How to select a PIM is the comparison that is worth running only after pricing, long-tail and PLM have an owner.