The pallet arrived on a Tuesday. The goods receipt did not, because the item number it should be booked against does not exist yet. The new item setup request has been sitting in a purchasing queue for twelve days, behind a price negotiation and someone's vacation. So the forklift driver parks the pallet in the corner of the receiving area, the warehouse books it against a dummy item to get it off the dock report, and the physical inventory now disagrees with the system by one pallet of something the system has never heard of.
Nobody designed this process to take three weeks. Nobody designed it at all, which is the problem. Creating an item looks like data entry, one form and a save button, and if a single person knew every field that would be the end of it. But the record that makes a product purchasable, receivable, sellable, and invoiceable is stitched together from slices that four or five departments own, and the stitching is what takes the time.
One record, five owners
Purchasing owns the supplier, the purchase price, and the order unit. Logistics owns the weights, the dimensions, and the unit of measure conversions. Finance owns the tax classification and the valuation class. Sales owns the descriptions, the sales unit, and the price list entries. In regulated industries quality owns a slice too. Each slice exists because a different transaction needs it: you cannot receive without the logistics data, cannot invoice without the finance data, cannot put it in a webshop without the sales data.
Add up the actual work and it is unimpressive: a few minutes per department, well under an hour for the whole record. The three weeks come from everything between the work. The request travels as an email thread or a ticket, each department waits for the previous one to finish before starting, and every handoff parks the request in a queue where it waits for someone to notice it. The lead time of a new item is queue time wearing a process costume.
Where item onboarding breaks
A slow process would be survivable if it were only slow. It is not, because the people waiting on it have deadlines, and a process that ignores deadlines gets worked around.
The rush item
An order has to ship today, so someone creates the item with whatever they know and defaults for the rest: conversion factor 1, catch-all category, tax code copied from a similar item. The order ships, which is exactly the problem. The workaround worked, nobody goes back, and the record spends years miscounting stock and misfiling spend.
The relay nobody can see
The request moves between departments as an email thread or a ticket that only its current holder can see. The requester has no idea whether it is with purchasing, logistics, or lost. Day 12 arrives and the honest answer to where is my item is that somebody would have to go ask around.
The form that asks everyone everything
The creation form shows all 120 fields to a requester who knows six of them. They guess at the rest, leave defaults where guessing feels risky, or abandon the form and send an email instead. A form built for the whole record punishes the one person who actually wants to start it.
The duplicate born from a pending request
Requests in flight are invisible to search, so a second person requests the same product a week later and both sail through. Now there are two item numbers for one product, each with a partial record, and the duplicate check that runs on active items never saw either of them.
The item that went live incomplete
Nothing gates go-live on completeness, so the record becomes orderable the moment purchasing finishes their slice. The first sales order hits it at 2 a.m. and fails on a missing tax classification. Or worse, it does not fail, and the invoice goes out with a tax code nobody chose.
The rush item is the one that does lasting damage. Every default that nobody went back to change becomes somebody else's incident months later: the conversion factor of 1 that orders twelve times too much, the catch-all category that swallows a third of your spend, the duplicate that splits a purchase history in two. The real cost of a slow creation process is the workarounds, not the waiting.
Rules that cut the lead time
Start by splitting intake from enrichment. The requester knows perhaps six things: what the product is, who supplies it, roughly what it costs, why it is needed. Take those six things, create the record the same day, and give it an honest status. The item now exists, it shows up when the next person searches for it, and the pallet has something to be received against. The other hundred fields are enrichment, and they are not the requester's problem.
Then stop running the enrichment as a relay. Finance does not need the pallet dimensions before entering a tax code, and sales does not need the purchase price before writing a description, so there is no reason those steps should wait on each other. Run them in parallel and the lead time collapses from the sum of the steps to the slowest single step. The one real dependency worth respecting is the product category, because the category decides which attributes the record needs at all, which is why it belongs in the intake fields rather than at the end.
Gate transactions, not the record. One big active flag forces a false choice: either the item is blocked for everyone until everything is filled, or it is open for everything the moment it exists. Neither matches reality. A record that has logistics data but no sales data can safely be received and counted; it just cannot be sold. Statuses per purpose, checked when the transaction happens, let the record earn capabilities as its slices complete, the same way a record moves through the rest of the master data lifecycle.
And give the rush its own lane instead of pretending it will not happen. Orders will always land for products that do not exist yet, and the choice is between a governed fast path and an ungoverned one. Governed means the expedited item goes live with its defaults, but the missing fields turn into a task with an owner, a worklist someone reviews, and an age limit that escalates a three-week-old rush item instead of letting it settle in. The ungoverned version is the same item with no follow-up, which is how every rush item works today.
If you are coming off MDS
Microsoft MDS never had a real answer for item onboarding. Business rules could mark a member invalid, but they could not route work to anyone, so the process ran in email around the tool. The Excel add-in made it worse in the politest way possible: anyone with access could paste a new member straight into the entity, complete with whatever their spreadsheet happened to contain, and MDS would accept it without a single question about who still owed which fields.
If you are migrating off MDS, resist the urge to rebuild the email relay in a new system. The migration is the one moment the process is on the table: who owns which slice, what intake actually requires, which transactions should be gated on what. Moving the data takes a project. Moving the three-week lead time along with it would be a shame.
Common questions
What is new item setup in master data management?
The process of building a complete, transactable product record: purchasing data, logistics data such as weights and units of measure, financial data such as tax and valuation classes, and sales data such as descriptions and prices. Each slice is owned by a different department, which makes it a cross-department workflow, not a data entry task.
Why does creating a new item take so long?
The departments fill in their slices one after another, and the request spends most of its life waiting in queues between them. Data entry per department is minutes of work. The weeks come from handoffs that live in email and tickets, where nobody can see where the request is stuck.
Should incomplete items be allowed into the system?
Yes, with gates per transaction type instead of one big active flag. A record with only the intake fields can exist, show up in pending-item searches, and receive goods. It cannot be sold until the sales slice is complete. Blocking creation entirely just pushes people toward booking against a dummy item.
How do you speed it up without losing data quality?
Split intake from enrichment so the record exists on day one, let departments enrich in parallel, derive required fields from the product category so each department sees only what applies, and give the rush path a governed shape: the item goes live, but the missing fields become a task with an owner and an age limit.
Make item creation a process you can see
Primentra puts changeset-based approvals in front of new items, so a pending record is visible from the moment it is requested instead of buried in an inbox, and the audit trail shows who added which slice and when. It runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial is long enough to run your real item creation process through it and time the difference.