Cross-Functional Workflows: How Modern Ops Teams Stop Re-Building the Same Reports Across Departments

Most of the ops leaders we talk to are tired of the same conversation. Someone in a leadership meeting asks for a number: pipeline coverage, net retention, marketing-influenced revenue, support load by segment. Four different teams produce four different answers. Each one is technically correct inside its own tool. None of them match.

That's duplicated reporting in the wild. And that, right there, is the actual problem. It isn't that anyone needs a fancier dashboard. It's that the same report keeps getting rebuilt, slightly differently, in every department, because no one has shared, governed access to the same data.

The instinct is to fix this with more dashboards or another BI seat. The pattern we keep seeing is that the real fix is structural. Modern ops teams don't need more one-off views. They need governed, reusable data workflows that let every department work from shared, trusted datasets, while still respecting who's allowed to see what.

This piece is about why that shift is happening, why it's harder than it sounds, and what a workable version of it looks like.

A note on the research. The data and quotes in this piece come from publicly available sources, including MuleSoft's 2024 Connectivity Benchmark Report, Workday's 2026 Harris Poll research, IDC, Gartner, Harvard Business Review, AWS, Microsoft, and Databricks. Each claim is linked inline.

The data silo problem is bigger than people think

Data silos get talked about a lot, usually in vague terms. The numbers underneath are more striking.

MuleSoft's 2024 Connectivity Benchmark Report, based on a survey of 1,050 CIOs and IT decision-makers, found that on average only an estimated 28% of applications inside a company are actually connected. The same report shows that 81% of IT leaders say data silos hinder digital transformation, and 95% say integration issues are impeding AI adoption. That last number is the one that should make ops leaders pay attention. The "AI strategy" your CEO keeps talking about lives or dies on whether teams can get to clean, shared data.

The silo problem reaches well beyond IT, and the pattern is older than the AI hype cycle. Back in 2016, Harvard Business Review made the same point in plainer language: "The biggest obstacle to using advanced data analysis isn't skill base or technology; it's plain old access to the data." What's changed in the decade since is the cost of that barrier. Today, disconnected data doesn't just slow reporting. It limits how much you can automate, how usable your AI investments are, and how aligned cross-functional decisions can get. Most business users still know exactly what they want to ask. They just can't reach the tables that would let them answer it.

So they do the next best thing. They export. Paste into a sheet. Join it manually. End up with a version of the truth that belongs to their team only. And there's where duplicate reporting starts.

The hidden cost shows up as "human middleware"

When you look at how ops teams actually spend their week, the cost of all that exporting and reconciling is enormous, even if no one labels it as "duplicated reporting."

Workday's 2026 research with Harris Poll surveyed 6,100 AI users across finance, HR, IT, and operations at organizations with 500+ employees. They found that 82% of employees spend significant time acting as translators, copying and pasting information between systems, and 77% say their work requires them to reconcile conflicting data from different tools. Workday's framing is sharp: people have become "the human middleware between disconnected AI systems."

What does that actually cost? Mostly it costs people. The cost looks like an analyst stitching together a weekly board number from four different exports. It looks like a CS ops lead manually reconciling churn between the support tool and the CRM. And it looks like the leadership meeting where everyone spends 20 minutes debating whose version of the number is right.

And it's not just enterprise. A Zapier survey of 1,000 U.S. SMB knowledge workers (2021) found that 76% spend one to three hours a day moving data from one place to another. The figure is older and vendor-sourced, but the pattern hasn't changed.

The thesis is simple: every hour someone spends being human glue between systems is an hour they aren't spending on the actual job. Multiply that across an org chart and you start to see why ops leaders feel like they're running fast and getting nowhere.

How much of your team's week, honestly, goes into stitching together data that should already be joined? For most teams I talk to, the answer is far more than they'd put on a slide.

Dashboards are the output, not the workflow

Here's where it's tempting to swerve into anti-dashboard territory. I won't. Dashboards are great. They aren't the problem.

So what is? A dashboard is only trustworthy if the data behind it is current, governed, reusable, and understood the same way across teams. Without that, a dashboard is just a nicer-looking version of the same disagreement.

Gartner has been blunt about this: self-service analytics initiatives often fail because of governance, trust, scalability, and adoption challenges. Their guidance to teams trying to clean up sprawling self-service environments includes minimizing duplication, which is the same advice you'd give someone whose spice rack has six jars of cumin in it. Databricks' own lakehouse principles put it even more directly: "Don't create copies of a dataset with business processes relying on these different copies."

Translation: it's fine for finance to have a dashboard. It's fine for marketing to have a dashboard. It is not fine for finance and marketing to be running off two different copies of "the customer table" that quietly disagree on definitions and refresh on different schedules. That's the configuration that produces those painful leadership meetings.

Access without governance is chaos. Governance without access is a bottleneck.

This is the line I keep coming back to, and it's the heart of why most "let's just share more data" initiatives stall.

So why do companies under-share data when everyone agrees they shouldn't? Not because they're careless. They under-share because sharing is genuinely risky when access controls aren't clear. So the safe move becomes the local move: build your own copy, in your own tool, with your own permissions. Multiply that decision across departments and you get the situation we started with: five teams, five reports, none of them aligned.

The good news is that the architectural answer to this has converged. AWS, Microsoft, and Databricks all describe roughly the same shape.

AWS frames governance as helping "the right people and applications securely find, access, and share the right data when needed," with an emphasis on limiting copies and redundant transformation. Their companion service, AWS Lake Formation, provides centrally managed fine-grained permissions so teams can share data with confidence. Databricks' definition of data democratization is one of the cleanest in the industry: "the right people can see the right data at the right time and for the right purpose." Microsoft's Purview platform is built around the same idea, with role-based access, business-context discovery, and analytics access through a shared layer.

What these all have in common is the rejection of two extremes:

• "Centralize everything and let everyone see everything." This is what makes security teams sweat at night. It also doesn't actually help business teams, because they still can't tell which version of a number is the canonical one.
• "Lock everything down and route requests through a central team." This is what creates the bottleneck that drove teams to build their own copies in the first place.

The mature pattern sits between them: a shared layer of trusted, well-defined data assets, with fine-grained access controls that decide what each viewer actually sees. One dataset, shared. Each view, personal. And governance is what makes the sharing safe.

What the old workflow vs. the new workflow looks like

It helps to make this concrete. At a glance:

And in practice:

The old workflow. A VP asks for a weekly customer health number. Marketing exports activity data from HubSpot. Sales exports pipeline from the CRM. CS exports usage and ticket data from support tools. Finance exports billing. Then someone, usually an ops person who didn't sign up for this, joins it all in Excel, normalizes the customer IDs by hand, debates with another ops person about which definition of "active" to use, and ships a deck on Friday. Next week, every step happens again. Sometimes the numbers from this week and last week don't line up, and no one is sure why.

The new workflow. There is one cleaned, shared customer dataset, refreshed automatically, that combines CRM, billing, support, and usage. Each team uses the same source. Marketing sees the columns they're allowed to see. CS sees customer-level detail. Finance sees billing-grade fields. The CEO sees everything. Dashboards refresh on their own. Follow-up questions get asked against the same trusted layer. And the conversation in the leadership meeting becomes about what to do, not about whose number is right.

There's the shift, in plain terms. It isn't glamorous. It's a quieter, more reliable operating model.

What this means for ops leaders, practically

If you're a COO, RevOps lead, CS ops lead, or finance ops lead reading this, here's the short version of what to push on.

First, stop treating duplicated reporting as a labor problem. You won't outrun it by hiring more analysts or buying another BI seat. It's an operating-model problem about who owns what data, how it's defined, and who's allowed to see it.

Second, invest in shared, governed datasets before you invest in more dashboards. A dashboard built on a shaky foundation just spreads the disagreement further. A dashboard built on a governed, well-defined dataset becomes a trustworthy decision system.

Third, and this is the one I'd put the most weight on, treat access controls as a feature, not a chore. The reason teams under-share data isn't laziness or politics. It's risk. Strong row-level and column-level controls flip that calculus. They make it safe to give every department access to the same underlying tables, because each person only sees what they're allowed to see. Once that's true, the main reason to build local copies disappears, and a lot of the duplication you're trying to fix evaporates on its own. This is the lever, more than any dashboard tool.

Fourth, don't pretend AI fixes this on its own. IDC and MuleSoft keep arriving at the same conclusion: AI value depends on integrated, trusted data. Point an AI assistant at a fragmented data environment and you'll get confident, plausible, wrong answers. The path to useful AI workflows runs through the same shared-data work this article is about.

Where Querri fits

From the beginning, Querri has been built on a simple idea: everyone in a business should be able to work with data, not just the people who can write SQL. That's the mission. The real shift for a company isn't that one analyst gets faster. It's that a whole team can reach the data it needs, understand it the same way, and act on it together. That's when "data-driven" stops being a slide in a deck and starts being how the company actually operates.

That's why we built Querri for Teams, for the exact operating model this article describes: shared, governed, reusable. Anyone can put data in, anyone with permission can use it, and access, sharing, and audit stay governed from one place.

Underneath it sits the Library, and it's more than a shared folder of connected sources. It learns your business and organizes itself around the questions your teams actually ask, instead of the tables and schemas underneath them. The Librarian, our agent, handles the modeling, the definitions, and the joins a data team would otherwise build by hand, so you can get to trusted answers in days instead of standing up a warehouse over six months.

The part that matters most for the problem in this piece is simple: the Library keeps your definitions in one place. Whatever your business means by "active customer" or "net revenue," it gets defined once and reused everywhere, so when marketing, finance, and CS each ask their own question, they're all counting the same way. That's the whole difference between five reports that argue and one number people trust. And because a cleaned dataset from one analysis becomes a reusable source for the next, a single customer view can feed finance's churn model, CS's health score, and marketing's attribution.

The governance layer is what makes that safe at scale. Row-level and column-level security shows each viewer only the rows and columns they're allowed to see, and permissions can be configured without writing SQL. Dashboards re-execute per viewer, so sharing one dashboard with the whole company doesn't accidentally expose data to the wrong people. Groups, workspaces, audit logs, and delegated API keys sit underneath, so when you tell your CISO you're sharing more data across departments, you have an answer for how it's controlled.

The bigger story is the operating model, and the exciting part is that companies are starting to figure out what "data-driven" really looks like for whole teams. Most of what they own today was built for solo analysis or central data engineering, and those tools do their jobs well. The newer, more interesting work is what happens when a whole team can share a trusted foundation and stop redoing each other's work. That's the part we're most excited to help with.

If your team is stuck rebuilding the same report five different ways, the answer probably isn't another dashboard. It's a shared, governed foundation underneath the dashboards you already have.

It's the shift worth making in 2026.

Where to start, based on where you are

If your teams are exporting from four different SaaS tools to build one weekly number → Start by identifying the one or two business concepts (customer, account, deal, ticket) that everyone reports on differently. Build one shared, refreshed dataset for those first, before touching dashboards.

If your data is already centralized but every department still maintains its own copy → The fix is governance, not centralization. Add row-level and column-level access controls so it's safe to point every team at the canonical dataset.

If your CISO is the reason you can't share data more broadly → Bring them in early. Strong access controls and audit logs make wider sharing the safer option, not the riskier one. Frame the conversation as "more visibility, more control" instead of "more access."

If you're piloting AI tools and getting inconsistent answers → Fix the data layer before scaling the AI investment. AI on fragmented data produces confident, plausible, wrong answers, and erodes trust faster than no AI at all.

Frequently asked questions

This article reflects publicly available research as of May 2026. Statistics, vendor capabilities, and product features evolve, so verify current details with the original sources linked throughout before quoting them in your own work.