As a Professional Engineer, I am aware of the arguments around who can be called an Engineer. In the USA, for example, an engineer is a train driver. In other parts of the Anglosphere, technicians or mechanics are routinely called engineers. The engineering profession objects to this apparent devaluation.
In the same vein, organisations like Opturion take issue with (what they see as) the misuse of the word 'optimisation'. For example, data visualisation is not 'optimisation'; data analytics (even predictive analytics) is not 'optimisation'; simulation is not 'optimisation'. So, like Humpty Dumpty in Through the Looking Glass, I have decided to define what I mean by 'optimisation' in a practical sense. I will focus on tactical or operational decisions; the day-to-day decisions that are taken when running a business. There are, of course, other decisions around product design, marketing, equipment purchase and so on, that are taken less often and over a longer time span. But let us, for now, focus on the day-to-day.
Decision-makers should be concerned with three things: compliance with statutory regulations and internal rules and policies; contractual requirements to provide goods and services to their customers; and the profitability of the operation. Put another way; the important issues are compliance, customer service and cost. Optimisation technology provides a solid basis to support such decisions.
Generally, regulation, rules, and customer service - on a day-to-day basis - are fixed and non-negotiable, and a decision that respects all of these is 'compliant'. But there is an almost infinite number of options when we consider the who, what, how, when and where questions, and some of these will be 'compliant', and each will have an associated cost. The trouble is that 'compliant' decisions can just as easily have a high cost than not. Consider a transport planning problem. We have some deliveries to make to customers within specified time windows. We want to deliver the correct item to each customer within the specified time, and we don't want to break any rules (speed limits, maximum working time, maximum weight on each truck, etc.) Still, after that, we can do pretty much anything. For example, how many trucks do we use? What deliveries does each truck make? In what order do they make them? What routes do they take?
The transport problem may seem simple, but there are millions (and sometimes billions) of different ways of achieving the objective, but only a few of them will be the most profitable. Also, the problem changes every day with different customers, different drivers, different traffic conditions, etc. While it is possible to learn good and bad ways to do things, the problem is just too complex, and changes too much, for a human decision-maker to fully comprehend and resolve in a reasonable time. This illustrates some tests of whether any form of optimisation is worth doing:
There must be a choice; otherwise, there is no decision to support.
There must be complexity; otherwise, the solution is obvious.
There must be change; otherwise, we can work out the best solution, once and for all.
I haven't yet come across an organisation that doesn't have choice, complexity and change, but there may be one out there, somewhere.
Comentários