Ditto.
@timshuwy I’m not sure if you want to hear stories of why people don’t use it, but until you say stop, I’ll share my thoughts.
Our main product
We are ETO. We make trucks; our max has been 10 a day. Scheduling (in the generic sense of the word) is certainly important to us, but we’re not talking minutes here.
Also, and this is big, we do a “slotted” schedule. If we plan on 10 a day, we may leave gaps to fit someone in, or we have a likely order that’s not confirmed or signed off yet, but we may reserve the spots for a loyal customer. And we redo the schedule weekly.
And if the GM says we are building 10 today, we will build 10. Even if that goes past 4:30 PM.
I can’t see how we could do a slotted ETO schedule outside of what we do now, which is:
- Set placeholder dates on the Project table
- Replicate those dates onto the Sales Order Release’s Req Date
a. And MRP makes unfirm jobs tied to the orders, driving demand in time - Set a UD field on Project that is a sequence integer, to sort the units within a single day
a. Implied: One truck = one project = one order line = one order release. No exceptions. - And the “schedule” that everyone looks at is a BAQ that combines all that into something coherent.
I’d love a more integrated way to do a slotted schedule.
Smaller parts we make
We have a weld shop to make a few key components of the truck. We used to make much more, but now we outsource nearly all. For those, the scheduling cascades from the aforementioned MRP jobs. The parts have lot sizes, etc. But we don’t “schedule” those in any fancy way, like based on capacity, etc. We need the parts to build the trucks, so we’ll make the parts by the time they are needed. End of story.
We use “receive time” as a simple hack to establish how long (in days) it takes us to make a part. It’s been accurate enough to give those jobs a start and end date that align with reality.