Engineering BOM's vs Supply Chain BOM's 2

[LONDONDERRY]

Greetings-
I'm getting into a heat debate with my company's supply chain (s/c) department on BOM structure and ECO workflow and using Agile PLM for managment
Typical scenerio is I've been tasked with a design project. I complete the design in solidworks, then using Agile I create the BOMs, load in the pdf drawings, and make a product tree. I take great care in making sure the BOM's callouts assembly drawing and 3d CAd model match perfectly.
Next I send it out for review, using Agile again. Engineering manager reviews the documentation (basically rubber stamping it). Then supply chain reviews it and comments they want the entire documentation package restrucutred to suit their needs, basically they want either a flat level BOM, or restructure parts from one BOM to another. In addtion, they ask to remove assembly drawings becasue they only care about the detail drawings. I asked my manager about this and he said, because its easier for them to order parts if everything is flat level. But it make a mess for engineering

There are a host of issues going theat route, first off to restructure Agile BOM's means I have to reconfigure the 3d model and assembly drawings, which is labo intense. Secondly, I have sub assembly designs that are used in mnay other design with the 3d model and Agile BOM's. Its come to a Mexican stand off, where s/c will not release designs unless its restructured and I don't have the time or desire to redesign a project.
My arguement has been..So I'll design a prodcut send it out for preliminary review to s/c and then have to redesign it again.
So my question how to deal with something like this?

Regards
F

 

[KENAT]

Can your ERP system or whatever not handle 'phantom levels' as we call it here (SAP).

In this case the engineering documentation (model & drawing) exists but from a an ERP bom level gets 'phantomed' so that it is flattened out.

We've had this debate too about config control etc. wanting flat BOM's but from a product documentation point of view that becomes a nightmare for various reasons.

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[LONDONDERRY]

Ya I know what you're talking about in SAP, not sure if Agile PLM can do that, I'll have to ask. So far my manager is on my side, mostly becasue if I have to restructure the documentation set, we have to charge our external customers my labour rate and time.
My company hired me 9 -10 mnths ago, before that they where without a mechanical engineer for over 2 yearts, so supply chain ran the show on doc control. Now that I'm on board I'm not well liked by that group.

 

[MikeHalloran]

I lost that battle two decades ago, on our last paper- based project.

We saved a lot of money by not producing assembly drawings.
We compensated, and then some, by producing detailed Manufacturing Instructions for our first JIT line.

The product was a huge success, so it wasn't our last JIT line.

When you are on the other side of the learning curve, you will realize that the BOM in the computer should be flat. It could contain 'level' numbers, which are just another field on which to sort, in order to help organize a greenbar printout of the whole thing.

You will also come to realize that there is not just one logical way to structure or indent a BOM. In addition to the way you think of your product, and of the assemblies it may share with other products, you will eventually want:
- a BOM or equivalent for each JIT station.
- a BOM for each service FRU, necessarily different from your internal assembly BOMs because of the packaging and labeling material.
- a BOM for each assembly you might use in other products, if for no other reason than to flag a group of parts that have to be checked against another product's requirements when changed.
All of these various BOMs can, and probably should, exist only in the ERP computer; there is no value to be gained by producing a 'drawing' style BOM for anything.


You might as well give up fighting the BORG, er, S/C department; resistance is futile.

Besides, you will need all your reserves of energy to repair the damage they will do to your strongest and most critical vendor relationships.






Mike Halloran
Pembroke Pines, FL, USA

 

[LONDONDERRY]

Hi Mike-
Not sure I agreee with your statement conpletely, well except the Borg spart. I've ran into cases where a I did a flat level design and then turned out that parts of that design where mushroomed onto other projects. So back peddling to group parts together into a sub assembly and placing that on other designs solved that problem.
In my experience design/ engineering BOm have always butt with manufacturing BOM's,where design flow is not the same as order of assembly. In those cases, I've leasrned to structure BOM accordingly to manufacturing. S/c is anther issues, flat level BOM's based on ordering is a mess for doc control ..
S/C has has cause collateral damage with our vendors..

 

[truckandbus]

I've seen this handled two ways-

1) let supply chain create their own BoMs - run an engineerng BoM (eBoM) and a production BoM (pBoM. it allows for easier changes to part and labour routings, switching from in-house to out-of-house builds, etc. Many drawbacks though - high chance of loosing the design integrity either in the creation of the pBoM or in cut-in-management. Benefit is that after a few years production learns that maintaining BoMs is a pain in the butt.

2) document the BoM structure requirments prior to starting the project. It is baffling that you got as far as you did in the release process when your boss knew the end product wouldn't meet the internal customer's needs. If the agreed upon BoM structure requirements don't meet the needs of supply chain then they need to redefine the requirement to you - change of scope --> rebaseline project schedule

 

[LONDONDERRY]

T/B-
Supply chain is starting to create their own BOM's, but realize that its a pain in the butt. They are pushing back wanting engineering to restructure the BOM's in Agile PLM to their needs. I think the reason for this is becasue we didn't have a mechaical engineer for a long time so s/c ran things the way they felt best, but now that I'm on board...

I've explain that its not simply moving line items from on BOM to another, becasue I would have to revamp the 3d model and assembly drawing to have the documentation match up. Either its falling on deaf ears or ignorance to the fact on the amuont of work engineering has to do. The ace up our sleeves is, okay will restructure it, but we'll have to charge the customer engineering time. Our company is customer based, meaning that for every task it done is billed to out external customers.

 

[MikeHalloran]

Driving a PLM system is not engineering.

Restructuring a BOM is barely engineering, and it's really Manufacturing Engrg, not Design. ... and it's a symptom of Piss Poor Management, for not working out this shit before anyone put any effort into it.

You should bill the SCM clowns for your time working for them directly. It is NOT the customer's responsibility to pay for your internal inefficiencies, and if they do find out how screwed up you are, they won't be customers for long.

You should deliver to your internal customers a flat BOM. Let them figure out how to structure it, restructure it, and manage it.

Once you've documented what the end product should look like, it's someone else's job to figure out how to make it.


Mike Halloran
Pembroke Pines, FL, USA

 

[LONDONDERRY]

Hi Mike-
Driving a PLM system is CM (config management) responsibility, not engineering; engineers are contributors, SCM are consumers. We present the engineering data if SCM or manufacturing wants to restructure a BOM for their use we let them. I refuse to spend time restructuring, BOM's and drawings. Doiing this solves their problems but makes a mess on engineering side

 

[MikeHalloran]

That's where you're losing money; restructuring the SW model and regenerating the drawings so that the SW BOM structure reflects whatever assembly process is in play at the moment.

THAT'S INSANE.


On a JIT line, production workers _never_ see the engineering documents. They see only Manufacturing Instructions, which are maintained only by the Manufacturing Engineers. ... and note that the 'master' version of the MI is the markup actually used at each workstation, not the computer file used to generate it. That way, production changes take place instantly, and Engineering never hears about them unless there's a huge screwup, and Engineering never gets involved with minor changes to the process.

The problem is that maintaining Manufacturing Instructions or equivalent is a real, substantial expense that should be borne by Production. ... but you've been flimflammed into doing it for them, so they look incredibly productive even when they aren't. ... worse, by doing their job, you are not doing yours, and are looking incredibly unproductive.

You need to get that crap under control right now.




Mike Halloran
Pembroke Pines, FL, USA

 

[LONDONDERRY]

Hi Mike-
The more I hear about your proposed solution the more intriguing its sounds.
So here is a more detailed issues
The company I work for is most s/w based we have three major facilities in the US. Engineering in GA, supply chain in mid-west (IA) and manufacturing rocky mountain (ND) area. Manufacturing is a small group of 3 people not a big manufacturing floor like you might be in. All three of these locations where separate companies before mergers, so a lot of warring camps. ND was using PLM and corporate (GA) wants to use this at all locations; there's has been a lot of pushback by supply chain to use this. GA uses PLM and its pretty easy. Typically our business model is as such
Customer (state government) send us a rfq its assigned to a PM (project manager) PM goes to engineering manager who response to PM with engineering efforts and time for a design. PM give engineering project code access so we can allocate our time to a specific customer.
Engineering design product, has design review with PM, s/c, manufacturing, CM and engineering manager. Next detail and assembly drawings are created. I structure a BOM in PLM, and link in the detail drawings in PDF format. BTW we assign our internal p/n's for everything. finally, we let manufacturing draft the assembly instructions to add this in.
It goes to an ECO release, manufacturing, CM, eng. manager, and supply chain review documentation. Then this is where everything breaks down, everyone approved the ECO except s/c they sit on the ECO for weeks and weeks with the following issues:
* We don't like the way the documentation is structured, redo it, even though manufacturing does have issues with it.
* The BOM lists a bunch of detail drawings and OTS components (fasteners, hardware) who gets what? Note: engineering lists manufactures for OTS, but for made parts s/c can go to any machine shop they have an account setup.
* S/c says we just want one number to place an order for the whole design usually top level. The big problem is we don't have a contract manufacture, parts are bought across multiple vendors and this confuses s/c. So what they do is send one vendor every drawing and expect a finished product. Vendor pushes back with " hey we don't have the ability to do that type of fabrication". Basically what they're dong is to suckering in a vendor in hopes of them saying "..ya we can handle most of that" once that happens the vendor is on the hook and engineering hears future complaints from the vendor about s/c

So what I've observed is this:
1. Our ECO process stinks and I'm going to ask if s/c be pulled out of the review process.
2. S/c does understand engineering documentation. In most cases they don't bother looking through the BOM's or drawings, they just want a top level number and a one stop shop to place an order with. In the past I had to tell them where to go to buy OTS and machine parts. My boss came down on me and said, "you're doing their job! we list vendors for OTS parts, and they can go to any machine shop they have an account setup with!"
Because of these issues, the ECO does get approved for weeks and weeks and the customer suffers because of our inefficiencies and PM has to bear the brunt of customer complaints. So deliverable are late not in weeks but months and months and months.

While I'm starting to understand why a flat level BOM might make sense for s/c it will require them to structure it. I doubt they will want to do or understand how to do this, as engineering (me) would have to whole their hand the entire time.

Does all this make better sense now?

 

[MikeHalloran]

Yes, the picture is coming into focus.

Your s/c operation seems to interpret their primary function as snookering other people into doing their work. No organization needs parasites like that.

They should have been fired for irresponsibility and incompetence already.

See to it.
Fire all the Supply Chain Managers.
Replace them with experienced Buyers.
You might as well close their location while you're at it.

You do need a top assembly number, for one product packed and ready to ship, so your sales people and your customers have a single number to order, and so you can structure various BOMs down from there.



I thought I had it tough at my last job, having to walk across the street to talk to our machinists. What could possibly go wrong with an operation spread out over three states?

You need to buy an airplane for the Chief, so he can get there quicker to yell at his minions in person. Maybe you need a Chief who yells more. He should already be spitting mad about what's going on now. Tell him it's okay to express his displeasure verbally; it comes with the job.




Mike Halloran
Pembroke Pines, FL, USA

 

[LONDONDERRY]

ARE YOU HIRING?

 

[RHarp]

Wow! Reading all of this thread. I see your company needs a massive cleaning up of procedures and practices. I agree that there are too many approvers in your ECO process. I wouldn't even consider envolving Manufacturing or SC into the ECO approval process. Let them have it after it is released. Manufacturing does not need to write work flows until you have a completely engineered product, and SC is not doing their job at all. If you are ordering a complete product from a vendor, then your client should be getting it from said vendor, and cut your company out entirely, to avoid the mark up.
Sounds like poor practices, and worse management.