I work for an Engineer-to-Order company evaluating a move from 100% parts-on-the-fly to Part master. Current state:
All subcomponents, materials, and operations are loaded into a single job’s MoM
No MRP
No multi-job / linked jobs
Quoting is comfortable with the flexibility of parts-on-the-fly and assumes Part master will mean significantly more work. My hunch is that the right DMT process could make it a wash up front and easier on the back end, but I want to validate that before I make the case.
I believe I have the workflow of Part Creation → Revision Creation → Engineering Workbench working.
Where I’m stuck is job creation. To get lower-level jobs for Make Direct subcomponents, the path I’ve found is:
Job Entry → top-level job → mark material Make Direct → firm the resulting jobs in Planning Workbench
That appears to need repeating for every BoM level, which is more work than what we do today.
Questions:
Is that the right process for multi-level job creation without MRP?
Does this actually require MRP to be practical?
Is there something in Engineering Workbench that makes this easier?
I guess my first question is… Do you NEED independent lower-level jobs?
A large BOM with multi-level assemblies, each with their own materials and operations, can all be performed on a single job. The routings (travelers) will print by assembly number sequence. Each subassembly doesn’t need its own “job” in the system.
For context… we make capital equipment. Hundreds of assembly sequences on a single job.
When we create the methods for each part, all manufactured components are marked “Pull as Assembly” and “View as Assembly”. This pulls every part’s full method into the parent job as a sub-assembly. All of our methods are built as if we are going to make every sub-assembly on the parent job. “Pull” & “View” are our default. Only “purchased” parts are “material parts” by default.
Our planners may “massage” the parent job manually. For example, we may have some of the sub-assemblies already complete, in inventory. In this case, we don’t need to make them from scratch this time. So, they will delete the sub-assembly from the parent job and add the part back into the job as a “material part”. Then we can just issue the material parts from stock instead of making them (this time).
Similarly, we may decide to purchase a sub-assembly from an outside vendor (due to current time or resource constraints). In this case, again, the planner would delete that subassembly on the job and add it back in as a material part and mark it “Purchase Direct”.
Again, these are not METHOD decisions (in our mindset). These are JOB/PLANNER decisions. Today, with THIS job, due to our backlog, staffing, resource load etc… we decide whether to make or buy. Next time we make this sub-assembly, that decision may go the other way.
But the default (for us) is to always assume we’re making each part on each job.
We rarely, if ever, have to worry about the “Make Direct” link between jobs.
In either case, job management (planner) is a tedious and important role.
Thank you much for this. This is huge for us… and seems to almost make it easier and more orderly than duplicating jobs. Plus, you have a control MOM to hold to for machining standards.
Follow up after having some weekend shower thoughts.
If you make alterations to the job, like moving a part to be subcontract complete or adding in time that was estimated short, is there a way to copy that revised BOM to a revision? Or would they be revisions at the sub-component level?
You make changes to the method and want to save that as a different “revision” for Part A… OR… an “alternate method” for that part.
Create your second revision (or alternate method). Then in EWB, you would “get Details from Job”. That pulls the altered method from job 1000 into that part’s new revision (or alt. method).
Changes made in this manner are for Part A’s method. They should not impact the base methods for subassemblies.
If you WANTED to update method for a subassembly. I think you can do the same thing. You could create a new revision for the subassembly part (Part B?)… and I THINK you can still get details from job 1000, and it will only update the method for Part B, not Part A.
Do you run Global Scheduling at all with this setup? MRP? Just trying to figure out how to optimize our scheduling side of things with the large singular jobs—some seem to think multi-job is best for running these programs, but was not sure if that is the case.
Upside with MRP is that if it sees the demand from the Sales Order or top level job, it will automatically generate the necessary (and only the necessary) jobs to fulfill demand. Then you go into Job Status and firm up and print out everything in one go.
Those are two distinct things. MRP will generate jobs and PO’s to supply your demand. It will roughly time these things based on your capacity (assuming you even set up finite capacity), but it’s not a scheduler.
Global Scheduling will order jobs based on the require date, but won’t create any missing jobs.
Typically, you’ll start using MRP before you take a stab at implementing global scheduling.
Thanks for the insight. I am familiar with the difference— I am trying to figure out how viable they are to run with large singular jobs with numerous sub-assemblies as David listed above.
I figured multi-job links would be best suited for MRP. Global Scheduling I would assume is the better route to go with the large MoMs, but depending on how often it’s used it could lead to our paper dispatches being outdated rather frequently.
Direct links are best when you’re building to order. They’re more cumbersome when, say, you’re building a large batch of some subassembly that will get fed into smaller higher-level jobs at some point. That’s how a lot of our parts are. SubAsm A is best when built in large qtys 1-4 times a year due to high setup time. It gets fed into parts B & C which ship monthly…usually. So Part A is make to stock and MRP generates a new job as new orders are entered.
MRP doesn’t really care which route you take. It will generate jobs as needed.
Global scheduling is about managing large numbers of resources in a changing environment. It’s not really about MoM complexity so much as total number of ops and machines across all jobs. We’ve got plenty of jobs that flow through, maybe, 1 strategic resource. That is to say, a resource group that is booked out far into the future so when we run a job now that might mean telling another customer they’re going to be late.
GS is, IMO, a lot easier to manage than manually moving blocks around on the scheduling board. It does mean you have to be very explicit about what jobs are and are not important to the org.
That last point I am thinking about a lot. If you have large jobs that span several months, GS will help reshuffle things if new hot priorities are added. Having jobs of that size shifting around could be detrimental to timelines if your inputs are not setup correctly. I am thinking that could be the route to go in.
Appreciate you helping me through this. Currently on a road to set standards in place for what was the “wild west”.
When deciding which (or both) of MRP and GS to use, first of all define what you want the outcome to be. When you come to the office in the morning, what do you want to see, how do need it presented (to whoever needs to accept/approve/modify), and what are the parameters those people need to properly accept/approve/modify? Answering those questions FIRST will go a long way towards helping you set up both MRP and GS.
And even above that, the 80/20 (or even hopefully 90/10) rule applies. DON’T set them up to solve for edge cases.