January 2026 / Estimated reading time: 4–5 minutes
Author: Glenn Gardner (Sr Director, Sourcing Acumen)
For more than two decades, solver technology has been inseparable from eSourcing. Every sourcing event – whether simple or complex – has relied on a solver embedded within an eSourcing platform to evaluate bids, apply constraints, and recommend awards. The question has never been whether a solver exists. The question has been what that solver was designed to handle.
Historically, solvers were built with a narrow intent. Some were optimized for speed and simplicity, supporting straightforward sourcing events with limited constraints. Others were engineered for deep optimization, capable of solving highly interdependent, scenario-driven sourcing problems, but often at the cost of usability and adoption. As a result, organizations did not suffer from “bad” solvers. They suffered from solvers that were each confined to a specific slice of sourcing complexity.
This paper is not about choosing the right solver vendor. It is about understanding how modern solver design is changing what a single eSourcing platform can and should support.
I. The Historical Model: One Solver, One Job
In early generations of eSourcing, solver technology followed a simple rule: match the solver to the event type.
Basic solvers were embedded into enterprise sourcing suites and designed to support high-volume, low-complexity events. They handled price-led decisions, simple constraints, and predefined scenarios efficiently. These solvers enabled broad adoption and fast execution across indirect spend and routine sourcing categories.
Advanced solvers emerged to address a different problem entirely. As sourcing events grew more complex – introducing bundled bids, network-level interdependencies, and conflicting objectives – basic solvers reached their limits. Advanced solvers applied combinatorial optimization techniques to uncover solutions that could not be modeled manually. However, these tools often require specialized expertise, extensive setup, and longer event cycles.
The result was a clear but rigid divide: basic solvers for everyday sourcing, advanced solvers for only the most complex events.
II. The Real Constraint Was Not Power It Was Range
This separation was never about solver capability alone. Early, advanced solvers were mathematically powerful but difficult to use and hard to scale across the organization. As a result, optimization was treated as a specialist activity reserved for categories such as global logistics, packaging, or MRO.
Meanwhile, sourcing events of moderate complexity – regional transportation, bundled services, facilities management, staffing – were often forced into basic solver models that could not fully represent trade-offs or interdependencies. Value was not lost because the solver was inadequate, but because the solver was not designed to stretch beyond its original scope.
In effect, sourcing teams were selecting solvers based on usability constraints rather than sourcing reality.
III. Complexity Is a Continuum, Not a Switch
Historically, solver capability aligned not only to sourcing complexity, but also to sourcing timing. Advanced solvers were typically reserved for planned, on-cycle sourcing events, where time, data, and specialist resources were available. Off-cycle sourcing – triggered by market shifts, disruptions, or emerging opportunities – prioritized speed over optimization and was often executed outside formal solver environments.
Modern solver design removes this tradeoff. By allowing solver depth to scale dynamically, the same sourcing platform can support both on-cycle and off-cycle sourcing decisions. Optimization is no longer constrained by calendar timing, but activated by sourcing need.
Together, elastic solver design and market-driven timing allow sourcing to evolve from a periodic event into a continuous capability.
Sourcing complexity does not begin at “advanced” and end at “basic.” It exists along a continuum.
At one end are simple events where specifications are clear, and interdependencies are minimal. At the other end are complex, scenario-driven events where every award decision affects multiple outcomes. Between these extremes lies a broad middle ground where trade-offs exist, but full-scale network optimization is not always required.
Historically, this middle ground was underserved. It fell between solver categories – too complex for basic solvers to handle cleanly, yet not complex enough to justify the overhead of traditional advanced optimization tools. These medium-complexity events represent the largest share of enterprise sourcing activity and, historically, the largest source of unrealized value.
- The Shift: Solver Design Catches Up to Sourcing Reality
Modern solver technology has changed this dynamic.
This evolution introduces solver elasticity – the ability for solver depth to expand or contract based on the sourcing problem being addressed. Rather than forcing buyers to choose between speed and sophistication, elastic solver designs adapt to the event, enabling fast execution for simple sourcing, selective optimization for medium-complexity scenarios, and full combinatorial power when interdependencies demand it.
Advances in computing power, solver automation, and user experience design have removed many of the barriers that once limited optimization to niche use cases. Today’s solvers no longer need to be classified as “basic” or “advanced” tools. Instead, they can adapt solver depth dynamically based on event complexity.
This means a single solver architecture can support fast, guided execution for simple sourcing events, introduce selective optimization for medium-complexity scenarios, and apply full combinatorial optimization when interdependencies demand it.
- The New Target State: One Solver, Broad Coverage
The strategic goal for modern eSourcing is no longer to deploy multiple solver technologies for different event types. The goal is to adopt platforms where solver capability scales naturally with sourcing complexity.
In this model, solvers are not chosen based on category labels. They are activated based on sourcing demands. Buyers do not switch tools as complexity increases – the solver expands with the problem.
This approach allows organizations to drive broader adoption of optimization across medium-complexity categories, maintain simplicity and speed for routine sourcing, unlock advanced optimization without specialist dependency, and apply consistent sourcing processes across the full spend portfolio.
Conclusion
Solver technology has always been central to eSourcing. What has changed is not the importance of the solver, but the expectations placed upon it.
Modern solvers are no longer defined by whether they are basic or advanced. They are defined by their ability to support a wide range of sourcing scenarios within a single platform.
The future of eSourcing belongs to solver designs that expand coverage, not complexity – enabling organizations to source simple, medium, and complex categories with confidence, consistency, and scale. Organizations that continue to segment sourcing by solver type will struggle to scale their optimization efforts. Those that adopt elastic solver architectures will be positioned to source continuously on-cycle and off-cycle without friction.
Hopefully, you enjoyed this paper, and as always, feel free to share your feedback
