Our MOMs have been getting out of hand with regards to levels of Subassembly. We buy most parts to the job, and receiving and kitting the parts has become laborious and confusing, even though Bartender spits out receipt labels that contain the subassembly number. We literally have hundreds of assemblies per job…
I am not an engineer, but I feel we can do something more towards designing efficiency and include material flow in the consideration on how to structure our MOMs. Is there anything in the Engineering philosophy that describe this; are there any golden rules or something like that that we seem to have forgotten? Has anyone got a designing style manual that enforces simplicity?
If the majority of your subassemblies are just being used as placeholders for kitted parts, phantom BOMs might be the solution.
If you’re unfamiliar with phantoms, they’re essentially the same as any other subassembly, except when the job is created, instead of showing as a subassembly, all of the materials are just pulled into the parent assembly and the subassembly part is not listed at all.
I have a degree in mechanical engineering, though (a) I’ve never really worked as an engineer, and (b) I don’t know that that education really helps here anyway. This seems more of a philosophy thing as you said already. Like a GAAP for engineering.
Funny, though, in my opinion, we have the opposite issue. Our main product (trucks) is done as a few hundred physical tasks but we only have a handful of subassemblies and I say we should have hundreds to match the physical world.
But we have an assembly line. It sounds like your world is less repetitive?
I mean, every order we build is custom to that customer. It may be a one-off or it could be 100 of the same truck, though they only want 20 per month, etc. So the assembly line varies daily but is also fundamentally the same thing every time.
To me, subassemblies would help us break our BOMs into more manageable chunks that would stand up to change better.
To you, maybe it’s like making a macro for a spreadsheet you will only use for 5 minutes and never look at again.
So, I know I am headed toward the cop-out answer of “it depends,” but I do also want to know what is that threshold of when you are too organized and when you aren’t organized enough.
My answer lies with the workers on the floor. Do they see their jobs as the same basic thing every day or not?
I think the workers often have a process map in their brains that the engineering department never tries to reverse-engineer. Engineers to try invent the wheel.
As a mechanical engineer also, I tend to want our mom to match what the worker is doing. I have spent most of my time working as a manufacturing engineer, so it definitely makes my preferences towards the production floor needs.
We have actually moved this way in the last year. Similar to Jason we build trailers instead of trucks and have multiple production lines. We did not have bill of operations and bill of materials that matched what production was actually doing and it made it hard to analyze where production was having problems. For example, we had three sub-assemblies as part of a parent assembly. All the hours were being logged on the parent so if the parent was high on hours, it was hard to determine what the actual cause was. We have also used phantom boms in some spots because it allows engineering the ability to create a “sub-assembly” for design purposes that is not actually a sub-assembly in production.
For us the move to having the proper sub-assemblies is looking like the right decision but has been very challenging to complete. We can see where it is going to benefit us in the aftermarket parts, shipping, receiving, purchasing and manufacturing departments. Finding the time to correct all our models and train the engineers the new way has been tough. The ones that have learned it love it. They fought it hard at first and now say it makes their jobs much easier.
At the end of the day, I think Jason is right though that it depends. How do your production areas run (line, cell…), how is your kitting and receiving setup, how does production know what is needed for the build, etc. For example, at a previous company we had labeled stackable steel bins for kitting jobs in the welding building. Shipping would receive the parts from other buildings then bring them to the kitting department. The kitting department would then add the received parts to the bins already created for the job, these were tracked on the traveler though not in there erp. For my current job we needed more detail, but we also had to have conversations of how far is too far. We have a lot of one-off on three of our production lines, so this also makes it easier for them to know what is needed for this specific unit.
One of the other things we did was map the flows of workers and parts. Doing this was pretty eye opening to some of the people as they didn’t realize how many inefficient moves existed. This was especially helpful with some of the production side as it allowed them to see that sometimes their methods were the problem, I don’t know how many times when I first got here, I heard this how I have done this for 20 years. As you watch a guy walk back and forth between a cabinet 15 times, climbing in and out of a jig, to make one assembly.
I often find myself on the fence when it comes to making sub-assemblies. Especially if they’re specifically made to make engineering’s job easier.
And extreme example would be that a specific bolt, flat washer and lock washer are used together when bolting the left widget half to the right widget half. I could make a sub-assy called SA-BLTWSH-005 consisting of:
(1) BOLT-001
(1) WSHR-FL-66
(1) WSHR-LK-03
Then just call out the SA-BLTWSH-005 Part wherever I needed those three together. Obviously you’d not want to make a job to just put washers on a bolt. The overhead of making the job, reporting qty’s and labor, closing etc… would be crazy.
This sub-assy would be okay if it is a Phantom (sorry that I forget the exact Epicor terminology), as it would just float the component parts up to the next level in the MOM.
As a electrical engineer, I too like the BOM’s to match drawings, to match work cells, to match test procedures, etc… But the software side of me sometimes gets carried away in breaking down the steps like a programmer making a “new function”. As an example, we have 50+ procedures for making a nearly Identical sensor. All 50 require potting the sensor, and include instructions how to do it. Now if we want to change the instructions for the potting portion, we have to update 50+ procedures.
My solution is to create a procedure that just specifies how to do the potting those 50+ assemblies require, and then reference my new potting procedure in the 50+ assembly procedures. Then any future changes (and there will be changes) can be done to just one procedure. The down side is that workers are not like computers and pushing and pulling the program counter to the stack to jump into and then back out of a subroutine, isn’t easy. Especially in a paper based documentation system. An electronic one, where the “sub-procedure” is automatically pulled into the main assembly procedure would be slick. But now I’ve got to maintain these links between main assembly procedures and the sub-procedures.
Our engineers say “we design it; we don’t care how you build it.”
But I firmly believe engineering should always (and basically only) think of the end goal. .
One thing I did appreciate in a college class I had was the principle of “Design for manufacturing.” (Can you design this part to be symmetrical? Then the supplier can’t make it backwards. And it can work as a left- or right-hand part. And you won’t accidentally miscount it at inventory…)
I see no reason the paperwork should be any different.
We started teaching it to our longest tenured engineer and he did not like it. Fast forward 3 months and he will tell you it got him hours back a week. The line he focusses on is the highest one-off line.
The best way I was able to make it happen was getting a second engineer working on the manufacturing side. We now had two people preaching the need.
There were enough times where something was designed, and the print would show the assembly at some later stage where it could not be attached properly any longer. Our biggest argument was if we spend a little time doing it right on the engineering side the longterm savings in manufacturing are worth it.
There are a lot of times we do something special for a customer and 6 months or 6 years later we are doing it again. Now your welder working on that line may be different, they may not remember that it needs to go on earlier, etc.
We want to keep the welders welding not trying to figure out how to build something because the information is unclear. Worst case scenario the welder doesn’t remember/ask questions to one of the manufacturing engineers and you’re doing 10 hrs rework by a welder, recutting parts, and getting a production line stuck.
Tack on manufacturing engineering time to figure out a fix and it gets really expensive really fast.
Our manufacturing class covered its importance really well. The problem was it was really only touched in that class, so it wasn’t reinforced well.
Now the company I interned (2 years) with while I was in school was a build to print shop. We had staff engineers who solely worked with customers on design for manufacturability. The number of times a customer came in with a super intricate design (expensive) for a simple feature was astonishing. They would quote the part with the crazy design and then with the suggested changes and the price would generally be cut by at least a quarter.
