The catalogue is the project
Distribution rollouts run over for three reasons, and the first is always the same. Here is how to tell whether it will happen to you, before you sign.
Vendors like to talk about implementation in weeks. What actually determines the number is not the software. It is the state of your product data, and you can assess that this afternoon without talking to anybody.
What clean actually means
Every distributor believes their catalogue is roughly fine, because it is fine for the purpose it serves: your team knows what the codes mean. A trade portal has a harder requirement, because it puts that data in front of a customer with nobody standing next to it to explain.
- One code per product, the same code everywhere. Duplicates created for a one-off order are the most common problem.
- A pack structure a buyer can act on. Case of what, how many, at what unit price. "CTN" is not a pack size.
- A name that means something to the person buying, not only to the person picking.
- An image. Not for every line on day one, but for the lines that sell: an unillustrated grid converts badly.
- Where you sell food, allergen and specification documents attached to the product rather than in a folder somebody emails on request.
The audit
Export your item master and answer these on the actual file rather than from memory:
- How many active lines are there, and how many would you actually put in front of a customer?
- How many have a pack size in a structured field rather than buried in the description?
- How many have an image?
- How many are duplicates, near-duplicates, or lines nobody has ordered in two years?
- Which field says a line is sellable online, and does anybody maintain it?
That last one matters more than it sounds. Most ERPs have somewhere to flag a product as sellable, and in most businesses it was set during an implementation years ago and never touched. If it is stale, your first catalogue import puts products you stopped supplying in front of customers.
If the honest answer to "how many have an image" is a small number, that is your project plan. Not a reason to delay, but the thing to resource, and it is work only you can do.
The other two
The second reason rollouts run over is pricing rules that live in somebody's head. Almost every distributor has an account whose price is "what we always charge them". Writing those down is real work and no software can invent them.
The third is an ERP connection scoped optimistically. "It has an API" and "it has an API that will tell us what this customer pays for this product" are different sentences, and the gap between them is where quarters go.
All three are knowable before anybody signs anything. An implementation that goes badly almost never does so for a surprising reason.