Let me try to restate this to see if I got the message...
You have some sort of assembly or tool setup and you make products that have some but not all parts in common. There is a time of refit when you change from one product to another. You want to minimize the time of the refit and hoped that Access might help you determine the optimum.
I have to say I don't have an immediate insight into how to do that kind of optimization. It SEEMS to be some variant of a queueing theory problem (of the "non-equal processor" variety), but it has been years since I dabbled in that particular discipline.
Others here MIGHT have personal experience in this field, but please don't be surprised if you don't get a lot of responses.
Here is the harsh reality of Access. I call these my "Old Programmer's Rules."
1. If you can't do it on paper, you can't do it in Access. Meaning - Access is dumber than a box of rocks. If you don't have a good paper design of your process, a "road map" for lack of a better term, you aren't ready to use Access. You have to know the design of your intended database so well that there is no question as to how to implement it, and that means if you don't know how to work this out on paper then you will not succeed using Access.
2. Access won't tell you anything you didn't tell it first. (or at least tell it HOW to tell you.) - Meaning: It is all about inputs and outputs. You need to know what you need to get out of your application AND what inputs it will take to let Access optimize things for you.
Access is an ORGANIZING tool. You can use the tool to compute anything you know how to compute. And there's the catch. If you don't know how to compute it, NO computer language or tool will make a difference.
Here, then, is the question: Can you write a step-by-step procedure on paper telling you how to determine this answer? Because that is step number one of how to make this happen - and that step is the same for EVERY problem in ANY computer language or tool environment.