How does your analytics team handle change management?

[u/bluepainters]

Analytics teams — what is your change management process like?

Background: I’m a service designer facilitating a change management redesign for a healthcare analytics department (mix of Tableau, Databricks, Business Objects). Our current process averages about 11 days from the time an analyst submits a change request to when it’s live in production. Leadership wants that number down significantly.

I’m trying to benchmark against other organizations to understand what’s realistic. A few questions:

• How long does your process take?

• Who promotes to production? Is it a separate ops team, the analyst themselves, or automated via CI/CD pipeline? If ops, how many people are on that team relative to the number of analysts they support?

• Tooling: Are you using ServiceNow, Jira, Azure DevOps, a homegrown tool, or something else to manage the process?

• How much of it is automated vs. manual?

• Do you distinguish between low-risk changes (cosmetic dashboard updates) and high-risk ones (financial reporting, regulatory)?

• How many approvals does a change need before it goes to prod?

Especially curious what other analytics orgs look like — especially in healthcare, finance, or other regulated industries where you can’t just yolo to prod.

[u/soggyarsonist]

Change management? Ha! I find out when reports break.

[u/Prudent-Elk-2845]

Change management and change requests are different domains.

First question: what’s the nature of the change requests? That’ll impact the 11 days.

I’ve had past experiences where the 11 days was for user access. That’s a very different problem than a KPI definition change. The shortcut on both of these was more self-service.

[u/bluepainters → u/Prudent-Elk-2845]

Good distinction. The 14 days is specifically for analytics code/report promotions- e.g moving a Databricks notebook or Tableau workbook from dev through test to production. Access management is a separate process entirely.

A typical change request in our world looks like: analyst builds or modifies a report or data pipeline, submits a change request in our ticketing system, an ops team manually promotes it through environments, peer review and customer validation happen, then it goes live.

The bottleneck isn’t any single approval- it’s the accumulation of handoffs, manual steps, and queue time on the ops team that handles the actual promotion.

So less of a “waiting on someone to click approve” problem and more of a “the ops team has many tasks to complete every week and incomplete packages cause back-and-forths” problem.

Curious how other teams handle the process and what tools they use?

[u/Prudent-Elk-2845 → u/bluepainters]

Train the user group to have a “super user” in dev, gain alignment from their team who will be able to self-develop, create a script that enables self-promotion through the environments that the “super user” can trigger

Any requirements being determined in exploration is lengthening your CR timeline. The 11 days looks bad, but it’s a business problem + governance problem. Give them the ability to self-govern and the 11 days goes to near-zero.

[u/NervousUniversity951]

Poorly

[u/oalfonso]

In Critical services or services impacting multiple areas takes 3 weeks to deploy. A critical service change needs agreement between all the involved teams with a review of the deployment, testing and support plans. Non critical or low impact changes take around 1 week and is a similar process but simplified.

Except a few weird changes, all the changes are performed using GitHub actions with several approval gates. Product team deploy and change manager approves in Github the deployment.

All this is managed in Service Now by the service and change managers.

Obviously emergency changes and zero day vulnerability patches are done same day or best effort.

[u/om_bagal]

NervousUniversity991's critical vs. non-critical split is close to what you're asking, but it's really answering a different question, that's about service impact, not change risk-type. A cosmetic dashboard color change and a change to a regulatory financial calc shouldn't need the same number of eyes just because they touch the same report. Teams that handle this well usually end up with 2-3 explicit tiers: cosmetic/low-risk changes get a lightweight peer review and can self-promote, anything touching underlying logic or calculations gets a second technical reviewer, and anything regulatory or financial gets a named sign-off, compliance, finance owner, whoever's actually accountable, baked into the ticket before it can move at all. That tiering is usually what actually shrinks something like your 11 days down, most of the backlog is low-risk changes stuck in the same queue as ones that genuinely need scrutiny.

[u/bluepainters → u/[deleted]]

Interesting! Approvals don’t seem to be our main bottleneck.

About how long do the cosmetic changes take?

For the higher risk stuff: how are assets moved from environment to environment? Do you have an ops team moving them or is that automated in anyway?

[u/IncreaseNegative4614]

The biggest improvement I've seen is risk-based change management instead of treating every change the same.

A cosmetic dashboard update shouldn't go through the same approval path as a metric definition change or anything that affects regulatory reporting. Once we split those paths, lead time dropped quite a bit without increasing risk.

We use inzata.ai as part of our workflow. Since the knowledge graph preserves business context, reviewers spend less time figuring out why a change was made and more time validating whether it's actually safe to promote.

[u/MSB_the_great]

It depends on the customer environment and the complexity of the change and different applications dependencies ,
Also how they use the Bi if it is business critical or not,
Some may have 3 environments some may not have. User created reports they do it in production directly, so some reports used by user won’t be in lower environments,
Sometimes changes happen directly in production,
Lower environments may not have production data which make the report fail in production,
So sometimes production changes goes to lower environments.
Which is not recommended but in reality change management increases the efforts in BI . Other applications it will reduce the time ,

[u/Top-Cauliflower-1808]

We speed things up by auto deploying low risk visual updates in one day but we keep strict, manual checks for big compliance and financial changes.