4 ms·

The data is squeaky clean, accounting-like data. Getting it to right format is a few lines of R. What he says is too difficult is putting in place all the right

by blahi 10y ago

The data is squeaky clean, accounting-like data. Getting it to right format is a few lines of R. What he says is too difficult is putting in place all the right constraints. He says that it is very easy to miss a necessary constraint and this will obviously blow up your solution. How can I examine the solution to make sure it would be valid? The data consists of tens/hundreds of thousands of line items which compete for the same budget and need to meet some (fairly simple) metrics. Line items have a hidden dependency between them, so presumably the solver can scrap some items which will in turn make others (possibly the ones with the best metrics) tank too.

ColinWright 10y ago
Now I'm less surprised. If you don't know all the constraints, explicitly and up front as part of your data, then it will be difficult. How is it being done now? How close to optimal is the current version/solution? The constraints form part of your data, and it sounds like they are not squeaky clean. With all computer optimisation, you need to make your data clean, clear, and complete. This can sometimes be done by simply trying it and seeing what the obvious flaws are in the proposed solutions, sometimes that's infeasible.
- blahi 10y ago
  People examine data manually in reports currently. If an item turns a profit, leave it, no yield optimization. If it's in the red, stop it. If it's around break-even, schedule it for examination to see if you can turn it green. No idea how close to optimal it is. I'd imagine not at all.
  - ColinWright 10y ago
    OK, I'm looking in from the outside, and I know all too well how these sorts of situations arise. However, it sounds to me a lot like the managers have largely lost control of the situation, and they are limping along doing the best they can with a system that has evolved from something system into a monster. That happens. The challenge is how to make it better. Thinking of it like software, there are no unit tests, and touching anything runs the risk of breaking everything. The usual way to proceed is to find a small section that you can write tests for, and then gradually transform into something you understand. The equivalent here might be to find a small collection of items that are largely independent of the rest of the product line, and see if you can bring that under control. However, I don't know your context, and I do appreciate that wholesale changes might well be risky. The question is, can you even make a start on a small section? If not, all is lost and the system will limp along as is. But if progress is desirable, maybe there is a way to start. Given that your senior colleague has actually spoken with you about this, maybe you can open that conversation, proposing it as a gradual way to make the system more efficient, profitable, and to reduce the existing risks. Again, on the political side, make sure they don't feel threatened, bring them on board as a partner, make it clear that you want to learn from them, and couch it all in terms of reducing risk to the company in return for a small outlay in time and effort. See it as an opportunity for you to learn, them to gain credit, and the company to become stronger. These are my thoughts - you must adapt them to your context.
Pamar 10y ago
Well, you will have to actually write code to create the constraints starting from the line items. This may optionally require a DSL to represents the line items and their relationships. One question: assuming you manage to write an LP-backed solution, this will replace what? Manual inspection of the budget? Nothing at all? Some other kind of cross-reporting?
- blahi 10y ago
  A ton of reporting and manual inspection. I imagine it would increase the ROI significantly too. Currently if it's green, it's good. I think there are spots which would be better for us if more budget is allocated there. DSLs are WAY over my head though.
  - Pamar 10y ago
    What if you started by "zooming out" so that the variables (and constraints) are limited and manageable in a semi-manual way (i.e. you can put together a high-level model with http://scpsolver.org/ http://scpsolver.org/) and try to understand if there is anything that stands out and then try to decompose that? (Note: this is not how LP is supposed to work - you do not "optimize" the whole by iteratively optimize subsets, but it could give you a better understanding of the process, and maybe also get some low-hanging fruit to motivate you and your colleagues to go forward).
garethrees 10y ago
The concern about missing necessary constraints seems reasonable, but then how does the current budgeting process avoid the same concern? Perhaps it does so by changing in small steps, so that each period's budget is similar enough to the previous period's budget (which was known to have worked reasonably well) that the differences can be analyzed and the consequences understood. So something you might try, is to locate the current budget in your linear system and then find a nearby point that improves the objective function. It should then be simple to explain the proposed improvement ("move $A from B to C and $D from E to F and the objective function goes up by $G") and not too complex to examine it for missing constraints ("hang on, you can't reduce B by $A because the supplier has a minimum order"). The idea is that instead of using linear optimization to replace the current budgeting process (which is risky), to use it to generate proposals for submission to the current budgeting process, and to capture the constraints that are revealed when proposals are rejected. (But note also that it's quite likely that a real objective function will be nonlinear due to economies of scale, in which case linear optimization methods won't suffice.)
- blahi 10y ago
  Things like minimum orders are obvious enough that I will manage to figure them out. My colleague's concern (and I see his point) is about what happens when the solver says "stop selling coffee machines", but when we stop, consumables drop off a cliff and consumables is where we make the profit.
  - ColinWright 10y ago
    So there's a missing constraint that M >= S/1000 or similar, where M=machines and S=supplies. And yes, that is an issue that needs to be considered. Over 10s or 100s of thousands of items that becomes difficult, but it's still the case that the system you describe now is not really under control. But perhaps your senior colleague is right, and that's just the way it has to be. However, one person's time spent investigating this properly might be money well spent.
    - blahi 10y ago

by blahi 10y ago

ColinWright 10y ago

Now I'm less surprised. If you don't know all the constraints, explicitly and up front as part of your data, then it will be difficult. How is it being done now? How close to optimal is the current version/solution? The constraints form part of your data, and it sounds like they are not squeaky clean. With all computer optimisation, you need to make your data clean, clear, and complete. This can sometimes be done by simply trying it and seeing what the obvious flaws are in the proposed solutions, sometimes that's infeasible.

blahi 10y ago
People examine data manually in reports currently. If an item turns a profit, leave it, no yield optimization. If it's in the red, stop it. If it's around break-even, schedule it for examination to see if you can turn it green. No idea how close to optimal it is. I'd imagine not at all.
- ColinWright 10y ago
  OK, I'm looking in from the outside, and I know all too well how these sorts of situations arise. However, it sounds to me a lot like the managers have largely lost control of the situation, and they are limping along doing the best they can with a system that has evolved from something system into a monster. That happens. The challenge is how to make it better. Thinking of it like software, there are no unit tests, and touching anything runs the risk of breaking everything. The usual way to proceed is to find a small section that you can write tests for, and then gradually transform into something you understand. The equivalent here might be to find a small collection of items that are largely independent of the rest of the product line, and see if you can bring that under control. However, I don't know your context, and I do appreciate that wholesale changes might well be risky. The question is, can you even make a start on a small section? If not, all is lost and the system will limp along as is. But if progress is desirable, maybe there is a way to start. Given that your senior colleague has actually spoken with you about this, maybe you can open that conversation, proposing it as a gradual way to make the system more efficient, profitable, and to reduce the existing risks. Again, on the political side, make sure they don't feel threatened, bring them on board as a partner, make it clear that you want to learn from them, and couch it all in terms of reducing risk to the company in return for a small outlay in time and effort. See it as an opportunity for you to learn, them to gain credit, and the company to become stronger. These are my thoughts - you must adapt them to your context.

Pamar 10y ago

Well, you will have to actually write code to create the constraints starting from the line items. This may optionally require a DSL to represents the line items and their relationships. One question: assuming you manage to write an LP-backed solution, this will replace what? Manual inspection of the budget? Nothing at all? Some other kind of cross-reporting?

blahi 10y ago
A ton of reporting and manual inspection. I imagine it would increase the ROI significantly too. Currently if it's green, it's good. I think there are spots which would be better for us if more budget is allocated there. DSLs are WAY over my head though.
- Pamar 10y ago
  What if you started by "zooming out" so that the variables (and constraints) are limited and manageable in a semi-manual way (i.e. you can put together a high-level model with http://scpsolver.org/ http://scpsolver.org/) and try to understand if there is anything that stands out and then try to decompose that? (Note: this is not how LP is supposed to work - you do not "optimize" the whole by iteratively optimize subsets, but it could give you a better understanding of the process, and maybe also get some low-hanging fruit to motivate you and your colleagues to go forward).

garethrees 10y ago

The concern about missing necessary constraints seems reasonable, but then how does the current budgeting process avoid the same concern? Perhaps it does so by changing in small steps, so that each period's budget is similar enough to the previous period's budget (which was known to have worked reasonably well) that the differences can be analyzed and the consequences understood. So something you might try, is to locate the current budget in your linear system and then find a nearby point that improves the objective function. It should then be simple to explain the proposed improvement ("move $A from B to C and $D from E to F and the objective function goes up by $G") and not too complex to examine it for missing constraints ("hang on, you can't reduce B by $A because the supplier has a minimum order"). The idea is that instead of using linear optimization to replace the current budgeting process (which is risky), to use it to generate proposals for submission to the current budgeting process, and to capture the constraints that are revealed when proposals are rejected. (But note also that it's quite likely that a real objective function will be nonlinear due to economies of scale, in which case linear optimization methods won't suffice.)

blahi 10y ago
Things like minimum orders are obvious enough that I will manage to figure them out. My colleague's concern (and I see his point) is about what happens when the solver says "stop selling coffee machines", but when we stop, consumables drop off a cliff and consumables is where we make the profit.
- ColinWright 10y ago
  So there's a missing constraint that M >= S/1000 or similar, where M=machines and S=supplies. And yes, that is an issue that needs to be considered. Over 10s or 100s of thousands of items that becomes difficult, but it's still the case that the system you describe now is not really under control. But perhaps your senior colleague is right, and that's just the way it has to be. However, one person's time spent investigating this properly might be money well spent.
  - blahi 10y ago