Breaking Down the Wall Between Analytics and Operations: A Practical Guide to Convergence

Sponsored by InterSystems.

Suppose a chemical plant runs an analytics system that tracks wear patterns on its pumps and predicts when maintenance is due. But sensor data is only fed into the system every four hours. At 2:00 p.m., a pump starts to vibrate, a clear sign of impending failure. The operations team does not find out until the 6:00 p.m. analytics report. By 7:30 p.m., the pump has failed and the entire production line is down. Unplanned emergency maintenance costs many times more than scheduled upkeep, and the downtime delays deliveries. The business problem is value decay: analytical insight loses value when it cannot be converted into action within the operational decision window.

Now suppose the plant runs continuous analytics on that sensor data. The team catches the warning signs in real time and schedules maintenance the same afternoon. The pump keeps running, costs stay predictable, and deliveries arrive on time.

This is how converged workflows close the gap between knowing and doing. They enable analytical signals, including forecasts, models, and rules, to reliably drive operational actions. And they do so fast enough to capture opportunities and minimize risks in dynamic markets. This article explores the key elements of converged workflows, identifies the five most common obstacles, and offers a practical playbook to overcome them.

What Convergence Actually Means

For decades, organizations have maintained distinct operational and analytical systems.

• Operational systems include ERP, POS, CRM, supply chain, and e-commerce applications that execute transactions and automate business processes on databases.

• Analytical systems include BI tools and machine learning applications that generate insights as they process data in data warehouses or lakehouses.

Organizations have connected these two types of systems with extract, transform, and load (ETL) or ELT pipelines that deliver data copies from operational to analytical systems on a periodic basis, perhaps every few hours or minutes. This works when decisions can wait. But it fails when value decays quickly, for example, when retailers must spot fraud before processing a transaction, or when the cost of data movement becomes prohibitive.

Converged workflows solve the problems of time and cost. They bring analytics, decision logic, and AI closer to operational data, transactional workloads, and business context so that actions can be taken as part of business processes. In practice, converged workflows fall on a spectrum that ranges from decision support to guided automation and autonomous orchestration.

• Decision support. Systems recommend, and humans approve.

• Guided automation. Systems execute within guardrails and escalate exceptions to humans.

• Autonomous orchestration. Systems coordinate decisions and actions end to end. Humans monitor and intervene to handle anomalies.

Five Obstacles to Converged Workflows

Five obstacles stand in the way of converged workflows: data fragmentation, ETL-first architecture, governance gaps, immature automation, and a lack of business service-level agreements.

1. Data Fragmentation

When data is copied across silos, every copy adds latency in the form of refresh cycles and risk in the form of drift or inconsistent definitions. AI trained on stale or mismatched copies produces outputs that cannot be trusted, which becomes dangerous when those outputs trigger actions.

2. ETL-First Architecture

ETL was designed to protect production systems from analytical workloads. But the trade-off is lost time: the freshest “analytics-ready” data is always at least one pipeline behind reality. For time-sensitive use cases, that delay can block business.

3. Governance Gaps

Separate teams and tools mean inconsistent access, lineage, and quality rules between operational and analytical environments. If AI consumes data with unclear provenance or controls, automation becomes brittle and risky.

4. Rushed Automation

Organizations incur significant risks if they jump from manual decisions to full agentic autonomy. Without a staged path, trust and safety checks are either overbuilt, which reduces business value, or underbuilt, which creates governance risks.

5. Lack of Business SLAs

Latency numbers do not matter unless they map to outcomes. The key business metrics center on time to decision and cost per decision. Without that framing, teams cannot make smart trade-offs.

Five Design Principles

Organizations can overcome these obstacles with five design principles: establish a unified data layer, bring analytics to the data, unify governance end to end, follow a mature automation roadmap, and measure performance in business terms.

1. Establish a Unified Data Layer

IT and data teams should establish a consistent access layer so that operational applications and analytics and AI tools share consistent governance controls. This helps organizations fix quality once instead of debugging dozens of copies.

2. Bring Analytics to the Data

Teams should embrace inline data execution for time-sensitive workloads, for example, with zero-copy converged databases. Data warehouses or lakehouses can add value for standalone analytics projects. But ETL should not be the default for every decision loop.

3. Unify Governance End to End

Define enterprise-wide governance policies and enforce them with consistent quality rules, lineage, and access controls across both operational and analytical use cases. Automation requires governance that survives the last mile into execution.

4. Follow a Mature Automation Roadmap

It is critical to automate in progressive stages. Start with decision support, then introduce guided automation with explicit guardrails, including thresholds, confidence scores, and exception queues. Finally, expand toward orchestration as observability and trust mature.

5. Measure Performance in Business Terms

Define the decision window for each use case: How long does an analytical signal remain valuable before the opportunity is lost or the risk materializes? From there, set target time to decision and cost per decision. Benchmark against the current state and track improvement as a KPI, not as an infrastructure vanity metric.

Conclusion

Convergence is not a product you install. It is a shift in how data, governance, and decisions connect to execution.

So how do data and IT leaders get started? Pick a workflow where latency hurts, such as pricing, replenishment, fraud, or service. Define an acceptable time to decision, and identify the handoff where insight becomes “someone else’s problem.” That seam is where convergence starts.

For a deeper treatment of the operating model, architecture, governance, and automation principles behind these workflows, read the BARC report Agentic AI and Operations: An Executive Guide to Converged Workflows, also commissioned by InterSystems.