What to Do After Your Analytics Maturity Assessment Comes Back Mediocre

A mediocre analytics maturity score is not a failing grade. It is a diagnosis, and like any diagnosis, it only helps if someone reads the details instead of just the headline number. Most companies that take one of these assessments land somewhere in the middle, and the Alteryx/IIA assessment puts the average score at 2.2 out of 4 stages. Mediocre is not the exception. It is the norm.

In practice, that score usually maps to what the Alteryx/IIA framework calls Stage 2, "Localized Analytics," or the low end of Stage 3, "Analytic Aspirations." Translation: the company uses reports, people believe analytics matters, but the company doesn't yet operate like one that runs on data. Nobody fell asleep at the wheel to get here. A score like this rarely means one big thing broke. It usually means several smaller things are broken at once: data that's hard to reach, a team stretched too thin, tooling that doesn't fit the workflow, governance that exists on paper only.

A systematic review published by Springer in January 2025 counted 38 distinct maturity models in the academic literature, split across three approaches: organization-oriented, technology-oriented, and data-oriented. That's worth sitting with for a second. It means two different assessments can look at the exact same company and hand back two different diagnoses, depending on which dimensions they weight. So the number itself isn't the useful part. The gap report underneath it is.

Most teams fall into the trap of treating a mediocre score as a technology problem, because tooling is the most visible, most purchasable piece of the puzzle. Buy the tool, fix the score, right? Except the research consensus says otherwise. Technology only pays off when data quality, people skills, and process improve alongside it. Buy the tool without fixing the rest, and the score barely moves.

Why staying in the middle compounds over time

Alteryx/IIA research shows that over a 10-year period, Stage 2 organizations trail Stage 4 organizations by nearly 4.8x in operating income and 6x in revenue. Not a rounding error. A different business trajectory entirely.

Why does the gap widen instead of holding steady? Because analytics capability acts as a multiplier on everything else the business does. Sales, product, marketing, operations, each function performs better when it can see clearly and act quickly on what it sees. A company stuck in the middle isn't just missing out on better dashboards. It's compounding a disadvantage across every function analytics touches, quarter after quarter, while more mature competitors pull further ahead.

The IIA's correlation study backs this up with breadth, not just a single flashy statistic: maturity correlated strongly with performance across 57 of 68 performance metrics measured. That's not one headline number. That's a pattern showing up almost everywhere researchers looked.

There's a quieter cost too, one that doesn't show up on a balance sheet right away. Mediocre maturity usually means engineering and data teams spend their days answering one-off report requests instead of doing the strategic work they were hired for. Ask any data engineer how they feel about being a human API for spreadsheet exports. That drain isn't just inefficient. It's a retention risk. Good engineers leave jobs where they feel like a ticket queue.

None of this requires a company-wide transformation to start fixing. It requires figuring out which dimension is actually the binding constraint right now, and starting there.

How to read your gap report before touching the action plan

Not every weak dimension deserves equal attention, and that's the first thing to accept before building any action plan. The BARC GAP-Assessment framework breaks maturity into five areas: Strategy and Culture, Business, Data Architecture, Technology, and Organization and Processes. Most companies scoring in the middle will find two or three of these dragging the rest down, not all five equally.

The TDWI Analytics Maturity Model Assessment frames the same exercise a little differently: where have you been, where are you now, and where do you still need to go, benchmarked against the practices of more mature companies. Different framing, same underlying task, figure out the shape of the gap before deciding how to close it.

Here's a practical way to read the report: rank every dimension from lowest score to highest. Now resist the urge to start with the lowest one. That's counterintuitive, but think about it this way, the lowest score isn't automatically the right starting point. Look instead for the dimension whose improvement unlocks the most other dimensions.

Data access is a good example of this cascade. If non-technical teams can't reach data on their own, self-serve analytics is dead on arrival. That keeps every analytics request routed through engineers, which keeps the skills gap wide, because nobody outside the data team ever gets reps interpreting data themselves. Fix access first, and something interesting happens: demand for skills training and governance follows naturally, because now people actually need it.

Culture and strategy gaps are the slowest to shift and need executive sponsorship to move at all. Worth noting in the report. Not worth leading with in a bottom-up plan that needs early wins to build momentum.

Technology gaps are the opposite: fastest to fix, and for that exact reason, the most likely to get overinvested in. Buying a new BI tool before fixing data quality or access architecture doesn't solve the problem. It just relocates the bottleneck to a more expensive address.

The output of this whole exercise should be short: one or two dimensions where focused effort over the next quarter unblocks the most value downstream. Not five workstreams. One or two.

The data access gap: getting non-technical teams to answers without routing everything through engineering

At Stage 2 or 3, data is usually locked behind SQL, or behind one analyst who fields every request that comes in. Product, sales, marketing, support, none of them can get an answer without asking someone else to get it for them.

Self-service BI is the category built to solve exactly this: it lets anyone, not just the data specialists, access, analyze, and visualize data without waiting on IT to run a report. Sounds simple. It rarely is, and the reason has nothing to do with how the buttons are laid out.

"No-code" just hides the code behind a friendlier interface. The real failure shows up when two people ask the same question and get two different answers, because no one enforced a shared definition of the metric in the first place. That's not a tooling problem. That's a governance problem wearing a tooling costume.

What actually makes self-serve work in practice:

A shared metric layer. Revenue, churn, active users, whatever matters most, needs one governed definition that holds steady across every dashboard and every query. "Churn" should mean exactly one thing, everywhere, every time. Permissioned access, not shared logins. Row-level permissions so each team sees what it needs and nothing more. Less friction to log in. Single sign-on and direct connections to the databases teams already use, Postgres, MySQL, Snowflake, BigQuery, rather than a new system layered awkwardly on top. Templates instead of blank canvases. Non-technical users do better starting from a prebuilt report than staring at an empty screen wondering where to click first. A feedback loop. Something that captures the questions people can't answer, so the data team knows exactly which gaps to close next.

Adoption tends to follow proximity, not features. A tool people have to remember to visit twice a month loses out to one that surfaces answers inside Slack, Teams, or whatever AI assistant the team already has open all day. The best setup usually splits the difference: a full workbench for the data team, and a lighter, simpler interface for everyone else that still produces work someone can audit later.

And the payoff for engineering isn't small. Once non-technical teams can self-serve safely, engineers stop fielding routine report requests and get their time back for governance and the harder, more strategic work they were actually hired to do.

The tooling gap: connecting the right BI tool to your data without over-engineering the stack

Mediocre scorers tend to land in one of two spots: no BI tool at all, or an enterprise platform that's underused because it demands more upkeep from the data team than the team can realistically give it.

Three platforms dominate the enterprise conversation: Power BI from Microsoft, and two other major players in the space. The tradeoffs between them are real, real enough that picking wrong can cost a mid-sized team hundreds of thousands of dollars over the life of a deployment. One shorthand that captures the differences fairly well: accessibility versus creativity versus control.

Power BI starts at $10 per user per month for Power BI Pro, which puts a 50-user team somewhere around $6,000 to $12,000 a year, all-in. It plugs directly into Excel, Teams, SharePoint, and Microsoft Fabric, which makes it a natural fit for companies already living in the Microsoft ecosystem. Reading a report in Power BI is easy for almost anyone. Building one is a different story, it still requires understanding database concepts, even with the Excel-like syntax wrapped around it. DAX, the formula language used for calculations inside the model, is genuinely different from SQL in syntax, in paradigm, and in purpose, not just a rebrand of it. Power BI's natural-language Copilot feature requires paid Microsoft Fabric capacity or Power BI Premium, a separate line item on the invoice, though Microsoft lowered the capacity threshold needed to access it during 2025, making it reachable for more teams than before.

Other major BI platforms follow a similar pattern: strong at what they're built for, but each with a licensing model and a technical learning curve that scales up fast for bigger teams, and each capable of quietly recreating the exact analyst bottleneck a company was trying to escape, if the modeling work still has to route through a small group of specialists.

For companies around the 100-person mark that don't need, or want, a full enterprise BI stack, lightweight database-native tools are worth a serious look. These connect straight into the Postgres, MySQL, or other database a company already runs, and surface dashboards, saved queries, and editable data views without asking engineering to become a full-time internal-tools shop. They offer the same row-level permissioned self-serve access, minus the heavier modeling overhead that comes with the bigger platforms.

Total cost of ownership rarely matches the sticker price. Implementation, training, and migration can multiply the initial licensing cost several times over across three years. Picking the wrong platform and having to migrate again eighteen months later is a documented, repeated pattern, not a rare bad-luck story.

The infrastructure gap: safely connecting your BI layer to production data

The dangerous version of this story isn't "connected a BI tool to production data." It's connecting with superuser credentials, no query timeout, over a port anyone on the internet can reach. That's how a routine dashboard turns into an incident.

Four mitigations make a direct connection to production safe enough for early self-serve work:

A dedicated read-only role, scoped to specific schemas, with no shared app credentials. A statement timeout of around 30 seconds is a reasonable starting point for interactive dashboards. If a query genuinely needs longer than that, it belongs on a replica or a warehouse, not on production. TLS through an allowlist, not a publicly reachable endpoint. Masked or excluded PII columns at the role level, before anyone gets access, not after someone notices a problem.

At some point, a direct connection stops being enough. That point usually shows up as one of three signals: dashboards start refreshing on a schedule, more than a handful of people are running ad hoc queries, or analytics queries start appearing in slow-query logs during peak hours. Any of those means it's time for a read replica, a separate copy of the database that absorbs read traffic without touching the system serving actual customers. Most major hosted database platforms, including managed Postgres and MySQL services, support read replicas with their own read-only endpoint. Standard guidance from cloud providers points the same direction: business reporting queries belong on a replica, not on the production instance itself.

Worth noting, moving to a replica doesn't mean the guardrails disappear. Statement timeouts, lock timeouts, idle-in-transaction timeouts, concurrency limits, all of it still applies. A careless cross join is just as capable of burning through CPU, memory, or pushing replica lag on a replica as it is on production.

Some situations call for skipping production entirely and starting with a replica or a warehouse from day one:

• The largest tables already sit in the hundreds of millions or billions of rows.
• Reporting needs to join production data with billing, marketing, or product-analytics data from somewhere else.
• Compliance rules forbid analytics access to the production environment outright.
• Dozens of business users will be running unpredictable ad hoc queries.

A simple rule of thumb to carry forward: read replicas suit controlled operational reads and engineering analysis. Warehouses suit business analytics, cross-source reporting, and the kind of repeated self-serve questions that non-technical teams ask all day long.

The skills and governance gap: what tools alone cannot fix

Here's a familiar sequence: a company buys a BI tool, connects it to the data, and then adoption stalls anyway. Not because the tool is bad. Because users don't trust the numbers, or don't know which of the five dashboards someone built is the "real" one.

Trace that problem back far enough and it almost always lands in the same place: no shared metric definitions, no clear data ownership, and no training built for people who aren't data specialists.

None of that requires a formal governance program to start. Three things get it moving:

One agreed definition per metric that matters (revenue, churn, active users, open tickets), written down somewhere and visible inside the tool itself, not buried in a doc nobody opens. Named owners per data domain, people accountable when quality slips or a definition gets disputed. A simple way to flag a number that looks wrong. Even a Slack channel counts, as long as issues surface fast instead of quietly corrupting decisions for weeks.

Worth being clear about what the skills gap actually is, because it's often misdiagnosed. It's rarely a SQL gap. Most non-technical users will never write a query, and don't need to. What they need is enough data literacy to read a chart correctly, spot a misleading average, and know when a question is complicated enough to hand to the data team instead of guessing.

The Alteryx/IIA framework actually separates "Organizational Dynamics" and "Analytics Team Dynamics" out as their own dimensions. If those two came back lower than Data Maturity or Technology on a given company's report, that's a signal worth taking seriously: the next dollar belongs in education and culture, not in another tool.

One might argue tooling and governance should happen in sequence, tool first, governance later, once people are already using it. The evidence points the other way. Deploy a tool without governance and the result is shadow spreadsheets, competing dashboards, and the same trust problem from before, just with better formatting. Deploy governance without a tool and nothing operational changes at all. They need to move together.

How does anyone know it's working? Non-technical teams start finding answers on their own, without filing a ticket first. And somewhere in the background, the data team's backlog of report requests starts getting shorter instead of longer.

Sequencing the action plan: what to fix first when everything needs fixing

After a mediocre score, the instinct is to launch a transformation initiative that tackles every dimension at once. Resist that instinct. That's how a company ends up with a twelve-month roadmap that quietly stalls out around month three, once the initial enthusiasm runs into the reality of five simultaneous workstreams competing for the same handful of people.

A better frame: find the constraint. Fix it. Then find the next one.

• If data access is the constraint, meaning non-technical teams can't see the data at all, fix the connection architecture and permissions first. Nothing else on this list matters until data is actually reachable.
• If tooling is the constraint, meaning the data is accessible but there's no usable interface sitting on top of it, choose and deploy a BI layer sized to the team, not sized to what a much bigger company down the street is running.
• If infrastructure is the constraint, meaning access exists but it's unsafe or unstable at scale, put the read-only role, the timeouts, and the replica in place before opening access more broadly.
• If skills and governance are the constraint, meaning the tool and the data are both there but nobody trusts what they're looking at, fix the metric definitions and the ownership model before buying anything else.

That raises an obvious question: what if two or three of these are all tied for worst? Go back to the earlier test. Not which score is lowest, but which fix unlocks the most other progress. Almost every time, that points to data access first, because nothing downstream, not tooling, not skills, not governance, means much if the right people can't reach the data in the first place.

A mediocre score isn't an emergency. It's a map. The only real mistake is trying to walk every path on it at once.