What are the main differences between Operations Research in the academic world, in the enterprise world and in the government world?

Question

For anyone who's been on both sides of the fence: how does academic OR differ from OR in enterprises or governments?

Answer 1

Here are a few differences I have noticed. (I am mainly an academic, but also work part-time for a consulting company that specializes in OR and AI models for supply chain and other industries.)

Project Speed. The two environments operate on totally different timelines. For the most part, industry OR projects have specific deliverables with tight deadlines—weeks or months—while academic projects are much more open-ended and exploratory, with deadlines that are much longer—usually a year or more—if they exist at all. One reason for this is that academic research is conducted partly by students, so learning and training on the part of the researchers is an expected part of the process.

Focus on Exactness. Academic research requires a degree of rigor that is not nearly as common in industry. Even when we do research on heuristics and other approximate methods, academics try to be very careful about establishing bounds, testing thoroughly, comparing to "competing" approaches from the literature, etc. In industry, some degree of experimentation and comparison is common, but usually the focus is on finding an approach that seems to work well, in the timeframe needed.

Problems vs. Methods. Academic research is (sometimes, not always) driven by tools: We develop a new algorithm and we apply it to optimization problems to test it out, or we develop a new analytical model and seek case studies with which to validate it. In contrast, industry OR work is almost always driven by specific problems faced by the enterprise, using whatever methodological tools do the job. (An exception, of course, is at companies that produce solvers, network design software, etc.—obviously there is a significant focus there on methods.)

Industry practitioners do sometimes come to the table with a bias for a particular method ("build me a machine learning model to solve my XYZ problem") but in my opinion, part of the job of an OR practitioner is to figure out what is the right method, and, if necessary, to try to convince the client of the appropriateness of that method.

Answer 2

My experience, as a former phd in an academic context, post doc in a semi-industrial/semi-academic context and now working for an APS editor, is the following:

When working on academic problems one will typically work on well defined problems. Even though those problems will be (very) difficult they will typically not involve a lot of side constraints.

On the other hand in the industrial world the problems tend to be much less well defined. It will typically take you a couple of rounds of presenting a solution to the end users and getting remarks to figure out that you were missing parts of the problem definition. This will typically lead to adding quite some extra constraints (which can have the side effect of bringing the approach originally developed to its knees).

In my experience something else that differs between academic OR and industrial OR is the number of constraints that are actually treated as soft constraints. In the typical projects in which I am working more than half of the constraints can be turned into soft-constraints. This stems from the fact that otherwise half of the instances would be considered infeasible if all constraints were treated as hard constraints. To the end user only knowing that the instance is infeasible is not useful (she must still come up with a solution), while having a solution minimally violating some constraints can constitute a good basis to take some actions to make the solution feasible (by delaying some orders, hiring temporary workforce, ...).

Another difference has to do with building the trust of the user in the optimization result. When using an heuristic approach, no matter how good the solution provided is, if users can easily see a way to improve it, it can completely destroy their trust in the system (even if they would never have been able to come up with a solution as good starting from scratch). Ideally one should run some local search as a post processing making sure that any « easy » local modifications have been tried out before presenting a solution to the end user.

My last point concerns the complexity of the objective functions. I have already encountered for a vehicle routing problem the case where the document detailing how the cost of a route was invoiced was spanning over more than 30 pages. I have never encountered anything similar in an academic context.

Answer 3

One difference I did not see mentioned in earlier responses: moving targets. In academe, we tend to start out with a well-delineated (if perhaps overly simple) problem, and we stick with that problem. In the real world, the problem you think you are given and the problem you ultimately (hopefully) solve may not be the same. As models evolve and test cases are run, you may encounter overlooked constraints, additional criteria not mentioned the first time around and so forth.

Answer 4

Just to add one more point to what @LarrySnyder610 said above about specific problem-driven projects of enterprises:

Since many of industry OR problems are driven by specific use cases, some of the simplifying assumptions in academic projects are not acceptable. I don't mean the solutions to those simplified (academic) models are not applicable, but they may only serve as a starting point for developing more tailored solutions (one may even say this is one of those areas that there is a gap between academia and industry: the closeness of the assumptions of the models in the two worlds!)

Answer 5

TL;DR version

For vehicle routing problems (which is a subset of OR), academic works focus on getting the best possible solution cost for overly simplified problems, industry focuses on getting workable solutions to much more complex problems.

Long version

I can't comment on wider OR but I can comment on vehicle routing problems. I've worked as a CS postdoc and now I develop a commercial solver for the dynamic vehicle routing problem (see odllive.com).

In my opinion, academics and practitioners in industry have two different goals when they tackle vehicle routing problems - for academics this is to publish papers, for industry this is to make it work for the customer. Academic studies on vehicle routing (with a few notable exceptions), therefore tend to focus on simpler problems where their chosen optimisation method/problem formulation etc. can have provably better results, which makes it suitable for publication. Finding best new solutions for the standard VRP benchmarks (e.g. Solomon etc) is one way of showing you're getting better results (ignoring the problem that computers get more powerful every year). As a result, there is a strong focus on improving existing benchmarks on known simple problems, so you can compare your work to previous works and demonstrate it worthy of publication.

The kind of VRP problems in industry tend to be a lot more complex, involving many different side-constraints. Implementing a VRP optimisation algorithm that can handle this kind of complexity is beyond the scale of most academic VRP research projects (it's certainly more work than would be involved in a single PhD thesis). So it's not that feasible for academic studies to handle this amount of problem complexity and it's not beneficial either - if they implement an algorithm that could handle the kind of rich problem variants you find in industry, it arguably makes it harder to get published as there's no prior benchmarks for these type of rich problems.

In industry you can't use a simpler version of the problem you're trying to solve, instead you just have to make it work - so you have to implement these more complex problem formulations. As a result, the focus is much more on getting a working solver for the problem, not getting the absolute best possible solution for a simpler version of the problem. Correctly formulating the objective functions to reflect the client's preferences is far more important than a marginal gain in your transport costs (which let's not forget, are only an estimate).

Possibly the most commonly studied academic problem formulation is the vehicle routing problem with time windows (VRPTW). This does match-up reasonably well to the real-world case of distribution from a single depot, and therefore represents a 'best case' of translating an academic problem to the real-world. Even for this though, in the real-world you might need soft time windows, you'd need to consider road-network travel times, rush hour effects, multi-depot setups, non-homogeneous vehicles, work breaks, as well as driver preference in-terms of the geographic area they'd cover (minimal travel solutions from a central depot create petal shaped routes but drivers usually prefer to work in a compact geographic area). Most of these side constraints have actually been considered in academic works, but not all together in a single work.

For more complex problem variants the disconnect between academia and industry becomes worse. Consider dynamic and stochastic vehicle routing problems (i.e. realtime routing problems where probability of future jobs is fed into the optimisation algorithm somehow). Several papers on dynamic and stochastic vehicle routing problems assume that you can decide the next job to dispatch to a vehicle one-at-a-time, and before each dispatch you run a set of parallel vehicle routing problems, where each problem includes the current known jobs and a random sample of possible future jobs. The most commonly found job-vehicle combination that should be served next is then dispatched (i.e. you decide that job 31 should be dispatched to vehicle 7, and then you re-run another set of parallel vehicle routing problems). This works as an academic solution but (in my opinion) is unlikely to be workable in the real-world. For larger problems - e.g. optimising an UberEats type restaurant delivery service in a large city - the optimisation algorithm would not be able to keep up with the number of new jobs, when you consider that parallel optimisation runs are required between each job dispatch. Communication delays with drivers would also make matter worse. In my opinion, for dynamic and stochastic VRPs only a solver that can provide the next dispatches for all vehicles at once, and not the next dispatch for only one vehicle out of the entire fleet, are workable. This hasn't been addressed in an academic paper I'm aware of.

Answer 6

I only have first-hand experience of the government side, which limits my ability to compare, but since none of the other answers discuss that side of things it may be useful to have an answer from that perspective.

Caveat: "government" is a large and complex beast with many different faces. My experience comes from working in a statistical agency; somebody working in military logistics, electoral districting, or urban planning may have wildly different experiences to mine, even though we're all "government". I am speaking only for my own experience here.

The biggest OR problem that I've worked on required reconciling conflicting data sources for economic data. Every economic transaction has a buyer and a seller; when you collect data from both buyer and seller sides, inevitably they don't tell quite the same story, even though theoretically they should be identical. Multiply that by hundreds of products, a hundred or so economic sectors, two different ways of valuing every transaction, and several years of history, and it ends up becoming quite a complex system.

To cut a long story short, in terms of the OR problem, this boils down to:

• A quadratic continuous problem, with linear constraints.
• Some non-linear constraints which can be dealt with by constructing linear approximations, and iterating the QP a few times.
• A LIP stage required for controlled rounding (output integer values while maintaining additive consistency - avoid the problem of 0.3 + 0.3 + 0.4 = 1 rounding to 0 + 0 + 0 = 1.)

All in all, I think we had about 100k variables with ~ 1m constraints, 80% of which get eliminated in presolve. Gurobi solves the iterated QP in about 60 seconds, and the LIP stage in a few minutes.

I doubt the OR aspects of this problem would be remotely challenging to anybody who's done an OR-focussed degree, and much of this had already been done by statistical agencies overseas using similar methods on similar problems. (I think the implementation of non-linear constraints was novel within that particular context?) Most of the work for me and my team lay elsewhere, e.g.:

• Persuading my colleagues in our econometric team that an OR-based solution was a good idea. (Full credit to them: they were very supportive of this project and receptive to change, but it's not something they were familiar with, so I needed to show them what it could do.)
• Understanding the (quite complex) economic theory that underpins the problem.
• Compiling client requirements to identify the required constraints. (All up, there are about 100 constraint statements in the problem definition.)
• Distinguishing between hard constraints and soft constraints.
• Identifying constraints that would be inconvenient to implement as specified ("this thing can't be negative three years running") and negotiating substitutes that were better suited to the optimisation framework ("total for any three consecutive years can't be negative").
• Identifying constraints which weren't actually necessary, because they related to some aspect of the old process that no longer needed to be enforced.
• Identifying exceptions to the specified constraints (you can't usually sell a negative value of something... except when you can).
• Talking to our overseas colleagues about the approaches they'd taken, to learn from their experiences and identify areas where we might be able to improve.
• Translating "adjust this data for consistency, while making as little change as possible to the economic story" into a cost function.
• Establishing a method for weighting that cost function that is intuitive for an economist without an OR background.
• Debugging various issues with the inputs, and establishing necessary quality checks for inputs.
• Checking the outputs and quantifying the effects of this method on the economic time series. (Economists really, really hate having to issue revisions to published economic data!)
• Developing diagnostics to answer questions like "why did that value change so much?"
• Training my clients and team members on how to use this system and how to debug things like infeasibility errors.
• Admin overhead: project management etc.
• Liaising with our IT department, first on obtaining OR software appropriate to the job, and and then on ensuring that the final product satisfies corporate IT policy.

I expect people in industry will find many of those issues familiar.

Aside from that project, most of the OR that I've worked on has ended up being basic LIPs. Again, the tough part of the job is usually in establishing requirements and in liaising with other areas, not in the OR theory. We have a lot of problems that can benefit from an OR approach, but people often don't realise that OR can help them, so part of my work is in sniffing out opportunities to use these tools.

One thing that is a point of difference between us and (much of) industry is that we operate in a high-security IT environment that makes it slow to get access to new software. The input and output data are confidential, which prevents us from just sending big problems off to a cloud provider. When we have collaborated with people with industry/academic backgrounds, they've often found this quite frustrating - no, you can't just download your favourite software.

Another possible point of difference is that my agency doesn't have permanent "OR expert" positions. Staff will rotate in and out of OR-related areas every few years, so we end up with a wide mix of experience but nobody gets to focus just on OR, and our knowledge tends to be more ad-hoc and pragmatically-oriented than you might expect from somebody who's done a degree in it. Likewise, most of us don't have formal OR training; I think one of my co-workers studied it in undergrad many years ago, I've done one course on Coursera, the rest has been largely on-the-job.

Answer 7

For having spent 10 years in Academia/OR and 20 years in the industry side of the force, I noticed that one difference is often the incremental aspect of the problem you have to solve in the industry.

Imagine you want to schedule bus drivers for a city bus transit system. Most of the academic work is based on a global optimization question, with an objective function - like minimizing the number of agents - and demand satisfying constraints together with HR constraints or usage/preference constraints.

In the industry you never solve from scratch, or very rarely. So you start from a solution (the one of last year or last month) and you want to slightly (to be defined) tweak it so that it respects new constraints or reach new goals. For instance one stop is added or a concert on Friday has to be covered. And you want it fast without perturbating too much (to be defined) the initial solution.

Mathematically speaking, it's not necessarily more complex, but it forces to approach the metrics differently.

Answer 8

Something that has really become interesting to me is the creation of software in both of these contexts. Specifically as an end user of a commercial solver.

In academia often code is written to solve a specific problem or explore potential solutions. This perhaps affords the ability to do more fundamental work. Like the exploration of how solvers work or detailed tuning. These implementations tend to be orientated around "running" a model.

In industry the goal can be to write reusable software which takes some kind of input data and then generates models which are then solved. The solution is then transformed into some kind of output format. Most of this is either delivered through customized software or on top of existing solutions for example GIS tools.