Why Backlogs Persist After AIM Software Rollout

Most operators don’t have a problem with asset integrity management software (AIM). They have a software adoption problem, and from the outside, the two look identical.

A plant manager sees this as inspection backlogs and overdue circuits that nobody can fully explain. For the CFO, it’s capital the organization already spent on a capability it isn’t using to capacity. And for whoever owns process safety, it’s the harder question: if the tool exists specifically to prevent loss of primary containment, and the team quietly bypasses parts of it, that gap doesn’t show up on a dashboard. It shows up during an audit, or after an incident.

The software adoption gap is the difference between what a platform can do and what a team actually uses it for. It shows up once implementation technically finishes, training wraps up, and day-to-day operation takes over. The software works. The gap is in how much of it the team actually uses, and whether anyone can explain the parts it skips..

Heavy industry runs on platforms bought to manage asset integrity, reliability, or functional safety. Sometimes it’s one integrated system, sometimes several point tools stitched together. Whichever it is, the pattern afterward tends to look the same: roll it out, train the initial users, move on.

Two years later, inspectors are recording findings in the tool, but thickness measurement data still lives in spreadsheets. Risk-based inspection covers the full equipment population, but inspection intervals still follow the old time-based schedule. Nobody planned this. It just accumulated, one workaround at a time.

The usual response is to treat it as a features problem: we’re only using 6 of 10 modules, so let’s turn on the rest. That’s usually the wrong diagnosis. In the maturity assessments we run across these deployments, the gap rarely comes down to which features you’ve turned on. It comes down to how the already-active features are used, and whether anyone can explain why the team uses them that way.

That’s also why fixing it rarely takes new spending It takes finding out which part of an already-purchased capability the team isn’t using as intended, which is a different question than which modules are switched on.

That distinction matters because of what’s at stake.Software that’s technically compliant but practically ignored isn’t a smaller risk than software you don’t have. It’s a risk nobody is watching.

This is the assessment Cenosco runs for facilities using IMS (Integrity Management System). It doesn’t start with a feature checklist. It starts with structured interviews with the people who touch the workflow daily: integrity engineers, reliability engineers, corrosion engineers, maintenance planners.

The interviewer maps where the process actually breaks down, often in the handoff after an inspection, when a finding sits waiting for someone to pick it up and decide what happens next.

Our assessors score each process area coming out of those interviews on two axes: a maturity rating (1–3, how well the team currently performs the activity) and a weight factor (1–3, how critical that activity is to IMS’s core value).Multiply the two and you get a weighted score per criterion. Roll those up and you get an overall maturity index, a percentage that reflects adoption against what IMS can actually do, not against a generic industry benchmark.

Master data maturity, for example, comes down to whether someone has fully populated the asset hierarchy (Site, Plant, Unit, Functional Location, Equipment) and correctly interfaced it with the CMMS. Other categories get scored against similarly concrete questions: are inspection schedules actually tracked for governance, or do they drift unmanaged? Are thickness measurements being recorded in IMS at all, or still captured on paper and typed up later? Do RBI (Risk-Based Inspection) results feed directly into Schedule intervals, or do they sit as a separate output nobody acts on? Are Integrity Operating Windows well defined and actively monitored, or defined once and forgotten?

Every other process category in IMS depends on that foundation, whether the workflow sitting on top of it is inspection planning, reliability strategy, or safety lifecycle management. A facility that scores well here usually set the hierarchy up once during implementation and never had reason to touch it again. That’s why it’s often the strongest category on the chart, not evidence the rest of the assessment doesn’t matter.

The output is normally a radar chart across IMS process categories: CMMS interface, inspection and corrective action, corrosion management, risk-based inspection, reliability strategy, business process governance. It shows at a glance where a facility is strong and where it isn’t.

From there, our findings turn into specific configuration work inside IMS: dashboards that need rebuilding, dynamic forms that should replace paper checklists, schedules that should trigger automated notifications instead of relying on someone to remember to check.

This runs on the same logic as Cenosco’s five-level digital maturity framework, which we’ve covered separately. The assessment here is the instrument that shows where a given process area actually sits on that curve, rather than where the organization assumes it sits.

In one Cenosco assessment, a facility had implemented risk-based inspection across its entire population of static equipment in IMS. That alone put them ahead of most peers. But inspectors kept following the old time-based intervals anyway. The schedules were technically in IMS, but they still weren’t risk-driven.

The mechanism behind RBI in IMS is simple enough to state plainly. A Susceptibility to Failure rating and a Consequence of Failure rating combine into a criticality score. That score sets the Interval Factor, and the Interval Factor sets the Maximum Inspection Interval. Pitch the consequence rating too high, and the calculated interval comes out shorter than the facility thinks is realistic, so inspectors go back to the schedule they already trust.

That’s what happened here. The facility’s consequence assessments were conservative enough that RBI’s recommended intervals looked too aggressive to act on, so the team ran RBI in parallel with the time-based process it was supposed to replace, rather than letting it replace that process. The fix wasn’t more RBI training. It was recalibrating the consequence model so the tool’s output matched operational reality, which happens to be a documented requirement of the methodology itself: keep the consequence analysis simple and realistic, not maximally conservative. Once they corrected that assumption, the facility could use its own RBI results directly.

Not using a risk-based method because its results feel too aggressive isn’t a software problem. It’s a consequence-assessment problem, and our assessment is what tells you which one you’re actually looking at.

Running the assessment as a two-hour demo bolted onto an unrelated site visit doesn’t produce much. It needs preparation and real engagement from both sides:

The deliverable isn’t the radar chart. It’s a prioritized list of actions that match what the facility actually needs: closing specific data quality gaps in IMS (thickness data quality driving circuits into overdue status shows up often), building internal training matrices so new engineers stop learning the system by trial and error, defining business processes where none currently exist, and, where it applies, follow-up like biannual workshops or a technical assurance review of a specific program.

Where a facility’s own processes are thin or inconsistent, the fix isn’t always building something from scratch. Cenosco maintains a documented, role-by-role process framework for each discipline that shows how operators are should use IMS end to end, and adopting it is often faster than building one alone. None of this holds, though, without a plan to follow up. Treating the assessment as the start of a cycle, rather than a one-off audit, is what makes the difference.

If your integrity, reliability, or safety team has been running IMS for a while and isn’t sure whether the gap between installed and adopted is costing time, data quality, or trust in your own risk models, a Cenosco maturity assessment answers that with evidence instead of guesswork. The software isn’t the risk here. The unmonitored gap between what you paid for and what you’re actually using is invisible and it tends to stay invisible until an audit, an incident, or a regulator finds it first.