The design team changed 14 parts last month. Purchase heard about 9 of them. Here’s what the other 5 cost an EV supplier in Hosur.
On the second Monday of March, stores at a motor-controller plant in Hosur issued 600 aluminium heat sinks to the assembly line. The drawing had switched to a copper-insert design three weeks earlier. The BOM in SAP hadn’t.
The line built 220 controllers before a quality inspector caught it. Rework, scrap and an air-freight shipment to save the customer’s dispatch date came to about ₹14 lakh.
Nobody did anything wrong. The design engineer released the change in NX on time. The ERP team updated the BOM the day the email reached them. It reached them 19 days later.
Every manufacturer runs two bills of materials, whether it calls them that or not. The engineering BOM (EBOM) is what design says the product is. The manufacturing BOM (MBOM) is what the plant needs to build it.
The MBOM has the same parts, plus everything design never draws. Thread-locker, packaging, labels. Sub-assemblies grouped by station. The alternate supplier’s part that purchase approved last quarter.
At a 200 to 800 person supplier, the EBOM usually lives in CAD and an Excel export. The MBOM lives in SAP, Tally or a home-grown ERP. Between them sits a planning engineer with two monitors, retyping.
That engineer is the integration. When they’re on leave, so is your BOM accuracy.
A design change crosses three handoffs before it reaches the shop floor, and each one waits for a person.
At the Hosur plant, step one took a day. Step two waited 11 days in a planner’s queue behind a new customer programme. Step three took another week, because the ERP item code for the copper insert didn’t exist yet and purchase had to create it.
A new EV programme can throw 30 to 50 changes a month at this chain. When a single change can wait three weeks, some of them will land late. Some won’t land at all.
The ₹14 lakh incident got noticed because it was loud. The quiet costs are bigger.
When the plant’s operations head asked finance to trace six months of losses back to BOM errors, the list looked like this:
| Cost line | Six months | What happened |
|---|---|---|
| Rework and scrap | ₹31 lakh | Parts built to an old revision |
| Obsolete stock | ₹18 lakh | POs raised for parts design had already dropped |
| Expedite freight | ₹9 lakh | Air shipments to cover late dispatches |
| Planner time | ₹4 lakh | About 120 hours a month spent reconciling BOMs |
| Total | ₹62 lakh |
None of it appeared as a single line in the P&L. It sat inside scrap, inventory and logistics, where everyone assumed it was normal.
There’s a second cost that doesn’t fit in a table. The plant’s largest export customer had started asking for part-level traceability on every shipment. With two BOMs that disagreed, the plant couldn’t prove which revision went into which controller.
Keep both BOMs in one system, linked line to line, so a design change flags every MBOM line it touches before anyone builds against it.
The plant started with process, not software. Three rules went on the wall of the planning office:
The rules were obvious. Following them with Excel and email wasn’t possible, which is why they’d never stuck.
Indishtech’s team moved both BOMs into Siemens Teamcenter. Design keeps releasing in NX, and the EBOM builds itself from the CAD structure. Planners build the MBOM in Teamcenter’s manufacturing planning module, where each line stays linked to its EBOM source. When design revises a part, every linked MBOM line turns amber until a planner accepts or adjusts it.
The change workflow became three steps with named owners and a 48-hour target at each: design review, planning review, release. Released MBOMs flow to SAP through Teamcenter Gateway for SAP, which creates or updates item codes and BOMs without anyone retyping them.
The heavy lifting sat in the data, not the configuration. The team cleaned and migrated 11,400 part records, mapped drawing numbers to SAP item codes, and found 1,300 duplicates on the way. Forty users across design, planning, purchase and stores were trained over two weeks, on their own parts.
The rollout took seven months, including a month of running the old and new process side by side on one product line.
The plant measured the same numbers for five months after go-live.
| Metric | Before | After |
|---|---|---|
| Design release to ERP update | 19 days | 2 days |
| BOM accuracy (MBOM vs released EBOM, monthly audit) | 91% | 99.6% |
| Wrong-revision issues to the line | 4 a month | 0 in five months |
| Planner hours spent reconciling BOMs | 120 a month | 25 a month |
| BOM-related losses (six-month run rate) | ₹62 lakh | ₹9 lakh |
The planner who used to retype BOMs now spends that time on line balancing for the next programme. The export customer’s traceability audit passed on the first visit.
No. A team of 10 to 30 engineers can start with the change workflow and a linked EBOM, and add ERP integration later.
Teamcenter X, the cloud version, runs without servers on site and suits plants that don’t have a PLM administrator. The three rules work at any size. Fix the process first and the software has something to enforce.
Pick one engineering change from last month and trace it. Note the date design released it, the date ERP reflected it, and every inbox it sat in between. If the gap is more than a week, the losses in that table are probably already in your numbers.
If you’d rather not trace it alone, send us one recent ECO. Indishtech’s PLM consultants will walk it from release to shop floor with your team in a 60-minute call, and show you where the days go. Book the call.
