Some problem areas are relatively static and unchanging, some are volatile and dynamic. The approaches and tools used for solutions in the two areas are quite different. A static problem suits a strongly mathematical approach, where the structure is assumed constant, and various techniques - linear programming, specialised algorithms - may be used to find solutions. Most problems in industry are not of this long term stable type - either there is too much potential for structural change, or there is a continual daily flux of minor changes, making a static approach unsuitable for problems with a large short term varying component.
We can divide problems into the two types - some examples:
The eight queens problem - position eight queens on a chess board so they do not attack each other. The rules of chess don't change from day to day, so a technique can be devised which may be elegant and efficient, but does not need to be flexible.
The aircraft departure problem - devise a best sequence for departure of the planes ready for takeoff. The constraints among planes and on the runway are continually changing, so a dynamic technique is required. A solution which takes longer than about 10-15 seconds on each cycle is not a solution at all to the real problem.
These two problems are at extremes - the relevant rules of chess haven't changed in a thousand years, while a new aircraft might appear on the runway every minute.
Most industrial and asset allocation problems are much closer to the dynamic end than the static end, the existence of the organisation - whether airport or communications company - is in response to the long term need, what remains is the short term efficient use of its assets, and the planning for future expansion of those assets.
An analysis of a problem, which is then locked away in the combination of a data structure of an algorithm, is particularly bad when the topology of the problem can change, a new constraint being found from one aspect to another. This renders the algorithmic structure obsolete and, where an algorithm might take six months to devise, slows down the response of the real process to changes in the operating environment.