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.
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.
Yeah, but that's the problem. There is no way to know all the relationships. This was an obvious one, there are a lot more subtle ones. In any case, the comments have been very helpful. A gradual implementation is the only sane way to go. Politics are not too big of an issue, if I can make a concise case and what's a better way to do it than a small project.
Documenting these relationships would potentially be a really, really valuable thing to do "going forward". It helps to make explicit things that are currently implicit, and possibly unknown. It then opens up the possibilities of making optimisations like using Linear Programming, but at the very least it reduces risk and helps to share knowledge.
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.