Quantum computing is coming. How to reduce expensive guesswork to build business value now

In financial services, for example, Deloitte Consulting LLP’s quantum-inspired tensor network models are applied to fraud, compliance, and risk modeling. These approaches have demonstrated meaningful improvements in pattern recognition and predictive modeling while supporting more efficient analysis of large, complex data sets.¹ They may also offer advantages over some traditional techniques for financial risk modeling, including techniques like Monte Carlo, for situations involving high-dimensional data, interconnected risk factors, or computationally intensive simulations.²

When applied to the right problems, results like these are possible because quantum-inspired approaches do three things at once:

• Deliver near-term value for problems that today’s computers struggle to calculate and teams can empirically test;
• Build talent readiness by allowing employees to “peer under the hood” of quantum-inspired techniques and start learning the way quantum computers operate; and,
• Build organizational readiness by establishing the evaluation standards and delivery workflows that quantum approaches will run on when the hardware matures.

Promising use cases should be evaluated through a staged investment process: four steps that build on proven results before the next commitment is made, ending with an explicit decision to scale the pilot, explore alternative approaches, or stop. Over time, this approach moves organizations from reactive experimentation toward decisions grounded in measured evidence.

The four steps of the quantum readiness framework are:

Step 1. Make the impact testable.

Identify one high-stakes business decision where better analysis could change the outcome and where there are possible quantum-inspired methods that could address it. For example, how to route a fleet more efficiently, how to allocate inventory across locations, or how to detect fraud before it scales. Define the specific metric that would move if the problem were solved (for example, cost per mile, inventory turnover, false positive rates); name the person accountable for acting on the result; and document the assumptions that must hold for the approach to deliver value (e.g., total cost of ownership limits, governance dependencies). Capture this information as your impact thesis on a single page, including explicit criteria for sufficient outcomes, so the team has a shared understanding of the targets.

What “done” looks like: A one‑page impact thesis that defines the decision, the metric, the owner, and the go or no-go criteria, plus a short list of assumptions that must hold, and one or two candidate use cases to test against it.

Avoid: Vague aspirations (“be quantum‑ready”), novelty-chasing, and leaving implicit assumptions about data quality, stakeholder alignment, or technical feasibility undocumented.

Step 2. Qualify the problem with quantum-inspired methods.

Using the candidate use case(s) from Step 1, run structured tests against your actual business data, for example, dispatch records, transaction history, or sensor logs, to determine whether quantum-inspired methods outperform what your current tools deliver. This requires translating your business problem into a mathematical formulation that quantum-inspired algorithms can work with. This is often the most technically demanding part of the process and where having the right expertise can matter most. “The hardest part is not choosing the solver; it is translating a messy real-world problem into a well-defined mathematical formulation,” says Steve Gibson, an executive with experience in quantum software optimization and commercialization.

Some organizations will have data science or machine learning teams that can take this on while others may need to engage a specialized partner or vendor to help them start. Whichever path fits your organization, the objective is the same: test under real operating conditions—using your data as it actually exists, within the time constraints your operations require—and in compliance with your regulatory and internal policies, so results reflect what the approach can actually deliver in production rather than in a controlled experiment.

What “done” looks like: A qualification memo summarizing what was tested, how it performed against your classical baseline, and what the results mean for the business; a clear readout showing the performance gap between current and quantum-inspired methods, measured against the metric defined in Step 1; and a concrete plan for moving from test to production, including what data and system requirements need to be met and what oversight and controls apply.

Avoid: Running tests on hypothetical or cleaned-up data that doesn’t reflect real operating conditions; pursuing solutions that solve the immediate problem but lock you into a classical architecture (data pipelines and workflows, for example) that can’t be extended to support quantum approaches later.

Step 3. Define success as outputs that drive action.

Technical performance only creates business value if outputs are trusted and acted upon. A quantum-inspired model that stakeholders don’t understand, that isn’t integrated into existing workflows, or that lacks clear ownership is likely to become shelfware, regardless of how well it performs technically. Step 3 is about closing that gap. For each use case, define how the model’s output will be explained to the people who need to act on it, in plain language and not technical terms. Map how that output connects to an existing decision point or workflow, for example, a daily dispatch meeting, a weekly risk review, or a real-time alert system. Ownership defined in Step 1 becomes operational, whereby the decision owner is now responsible for ensuring outputs are reviewed, understood, and acted upon within a defined timeframe. Establish guardrails for when human judgment should override the model. Then track whether behavior changes; not just whether the code ran, but whether its output influenced real decisions and delivered measurable results.

What “done” looks like: A map of how each output connects to a specific workflow or decision point, a lightweight RACI matrix (tracking who is responsible, accountable, consulted, informed) that defines who acts on outputs and who governs exceptions, and an outcome scorecard that tracks whether the capability is being used and whether it is delivering the business results in Step 1.

Avoid: Improving technical model performance without a clear process for how outputs will inform decisions in production, who owns the outcome, and how insights will drive action.

Step 4. Build a durable capability via a quantum center of excellence.

While described here as Step 4, this capability should begin as early as Step 1 and evolve over time as priority use cases are tested, refined, and scaled. The objective is to create a center of excellence to make quantum and quantum-inspired delivery repeatable and scalable without over-investing in specialized talent before business value is proven. Organizations should start lean: a founding team of three to four people is likely sufficient, typically data scientists or engineers already within the organization paired with Ph.D.-level specialists in computational physics, mathematics, or computer science. Additional quantum computing expertise can be developed through targeted training or sourced through a specialized vendor or partner depending on how the organization wants to invest.

The quantum center of excellence starts with a narrow mandate: running and evaluating quantum and quantum-inspired tests, maintaining the data and technical standards that keep results valid and comparable, and serving as the internal point of contact for quantum and quantum-inspired work. As business value is demonstrated, the center expands its scope, taking on governance of enterprise standards for data, security, model validation, model risk management, and integration across deployments. It also develops reusable tools and templates that reduce rework and improve consistency as the program scales. Demonstrate the center’s value by embedding the team into one or two live engagements where its standards and ways of working can be applied, tested, and refined under real operating conditions before being rolled out more broadly.

What “done” looks like: A center-of-excellence charter that defines the team’s initial scope and how that scope will expand as business value is proven; a reference architecture and guardrails for quantum and quantum-inspired deployments; a use-case intake rubric that helps business teams self-assess fit before engaging the center; a shared library of reusable tools and templates that improve speed and consistency across engagements.

Avoid: Defining the quantum center of excellence’s mandate too broadly too soon, creating a bottleneck that slows down the business teams it aims to serve; excessive hiring and training ahead of demonstrated business demand; developing governance standards in the abstract that never materialize in actual workflows, office tools, and delivery patterns.