Can Operations Research applications scale?

Question

What do I mean by scaling?

Let's say you developed a software for an operations research application for an industry client. Now you want to make a product out of this and sell it for other clients.

They all may share the same basic problem. However in my experience each new client has probably new additional constraints/different data landscapes, which require much overhead for each new customer.

On the contrast for example selling a solver (like Gurobi, Cplex, ...) can scale pretty good, because new customers do not necessarily create large overhead.

So the question is can we build software for Operations Research applications that scale and if yes how and are there examples that achieved this?

Answer 1

Yes we can, depending on the context and objective, and several companies are successful at doing it with hundreds of customers across the globe. An important disclaimer here is how specific problems you want your solution be able to solve. There's a tradeoff between developing general OR software vs. doing consulting or creating custom-made models that might only apply for a specific context¹ and most likely need work adapting for another case.

Some examples of general OR software with some problem-specific capabilities (for common constraints and models needed by organizations, like scheduling or routing) are:

1. Google OR-Tools has several specific modelling capabilities implemented, such as routing, scheduling, network flows and bin packing.
2. IBM CPLEX Optimization Studio provides the ability to model specific constraints useful for applications, such as precedence constraints or sequence constraints.

While there are lots of examples for problem-specific, software, especially vehicle routing:

1. Llamasoft sells a couple of solutions for the supply chain (simulation, capacity planning, demand modeling among others).
2. Optibus provides planning and scheduling capabilities for mass transit.

There will always be a sort of 80-20 situation here, where if you want to model all the context of a real-world process, you might need to extend these APIs - which may be impossible for proprietary software - or create your code from scratch (instead of using a prepackaged software). For example, you might want to route in a periodic sense, or coupling several days instead of daily, or according to additional rules, and that's a feature not all commercial routing software will have. There's certainly relevance on how much the different companies invest in R&D teams, customer support and implementation consulting. Or if you develop a staff scheduling solution for a specific industry, it's almost certain that you'll need to adapt, or activate/deactivate a set of constraints or parameters, just because of legislation or contract dynamics. That's certainly an interesting conversation about software design and modularity to keep in mind.

---

¹ Like many case studies on Operations Research practice published in INFORMS Journal on Applied Analytics, formerly known as Interfaces.