Master data isn't glamorous. That's why it breaks your ERP.
Nobody brags about a well-governed item table. But it's the first thing that blows up when an implementation is rushed. Three early signs your master data is about to cost you.
Most Dynamics 365 implementations don't fail because of the software. They fail because of what got poured into it: an item catalog thrown together in a hurry, inconsistent units of measure, and BOMs nobody validated against shop-floor reality.
The bill arrives later
Bad master data doesn't fail on go-live day. It fails three months later, when MRP plans against dirty data and suddenly there are purchase orders nobody understands. By then the consultant is gone and the cost is yours.
Three early signs
- Improvised units of measure. If "box", "BOX" and "bx" coexist in the same column, the problem isn't cosmetic. It's arithmetic.
- Ownerless BOMs. A BOM nobody reviews is an assumption dressed up as data. In a regulated environment, that assumption is an audit finding.
- Migration with no validation rules. If the migration plan has no explicit validation phase, you don't have a plan. You have a hope.
What I do differently
I treat master data as what it is: the layer every other layer depends on. Validation rules before migrating, clear owners per domain, and a BOM review against real production instead of against someone's spreadsheet.
Clean data goes unnoticed. Dirty data shows up in every report, forever.
If your implementation feels fragile just under the surface, it's almost always here. And it can almost always be fixed without starting over.