On Monday morning, the dashboard looks reassuring.

PM compliance is high. Planned-work percentage is above target. Backlog weeks sit inside the acceptable band. The EAM rolls up neat charts and tidy tables, all of it quietly promising that maintenance is under control.

Then you walk the units.

Job plans are thin or generic. Drawings don't match the field. Techs are working from memory and a personal notebook. Supervisors are juggling constraints that never show up in the system: scaffolds, permits, access, contractor limits. Some work is getting done that never appears in the EAM. Some sits in the EAM and never really gets done.

Both realities are true at once. The digital one and the physical one. And the complexity lives in the gap between them.

Let me say the obvious first. Modern EAM and CMMS platforms are powerful, and I'm not arguing against them.

At their best, they centralize work orders, PM schedules, and asset records. They run standardized workflows for planning, approval, and execution. They capture history and parts usage. They feed dashboards for backlog, PM compliance, planned-work percentage, and schedule adherence. For a multi-site organization especially, that single system of record is essential. It's how you get shared data definitions and the ability to compare performance across facilities at all.

The problem isn't that the tools exist. The problem starts when leaders mistake a consistent digital picture for a complete and accurate one. Those are not the same thing.

An EAM is only as trustworthy as the assumptions buried under its data.

Most systems quietly assume the work orders represent real work, the status fields reflect real progress, the job plans are accurate in scope and steps and duration, the asset hierarchy and criticalities are correct, and the failure codes and close-out comments capture what actually happened. When those assumptions hold, the dashboard is a genuine tool for managing complexity. It makes invisible patterns visible.

When those assumptions are weak, the same dashboard becomes a mirage. It shows order where there's chaos and signals health where the plant is carrying real hidden risk. That's the illusion of control: the quiet belief that because something is tidy in the EAM, it's under control in the field. It isn't the system lying to you. It's the system faithfully reflecting data that stopped matching reality a while ago.

A lot of the complexity that decides whether execution goes smoothly never lands in the EAM at all.

Every one of those is hidden complexity. Leave it uncaptured and the digital plant drifts further and further from the real one.

Bad data isn't an IT problem. It's a complexity problem, and it has a price.

When asset records, job plans, and history can't be trusted, planners do one of two things, and both hurt. They under-scope, writing a thin job and hoping, or they over-scope, throwing everything at it just in case. Meanwhile the KPIs quietly stop meaning anything. Planned versus reactive, PM compliance, backlog weeks all wobble because the classifications underneath them are inconsistent or gamed. And the smartest people on site stop trusting the system entirely and rebuild their own offline spreadsheets, which fragments the picture even more.

The best-practice guidance on this is boringly consistent. Clean up asset and maintenance data and productivity goes up, because you've cut the rework and the surprises. Better data lowers complexity at the sharp end. Bad data does the opposite. It turns every plan into a guess.

The answer isn't to throw out the EAM. It's to use it the way it was meant to be used. As a tool, not an oracle.

A complexity-aware approach treats the system as something that has to be grounded in field reality on a regular basis, a reflection of where the organization actually is rather than where the ideal process says it should be, and a place where the critical data earns attention before the cosmetic data. In practice that means focusing first on asset hierarchy and criticality, job plans for high-impact work, history quality on the systems that matter, and honest, consistent definitions of "planned," "reactive," and "completed." The goal isn't perfect data everywhere. It's usable accuracy where it counts.

From there, a few moves shrink the gap fast. Run targeted data-quality campaigns one unit or system at a time instead of boiling the ocean. Send planners, supervisors, and key techs to walk the plant together and reconcile what the system says against what they see, capturing every "we never do it that way" moment and fixing the record. Align the KPI definitions with real work, because if condition-based work is logged as reactive, your metrics will lie to you. And make it easy and expected for crews to feed what they learned back into the job plans and asset records, because if the system can't accept nuance, people quit offering it. This interface between system and field is exactly where execution-focused work lives, and it's a lot of what we do during events: making sure the plans, the histories, and the constraints actually match the messy reality on the ground.

EAM and CMMS platforms are essential. They can also create one of the most dangerous illusions in maintenance: that because things look neat in a system, they're under control in the plant.

If you're dealing with real complexity, prettier dashboards aren't the priority. Tighter alignment between what the system says and what the field knows is. When that alignment is high, complexity becomes visible and you can manage it. When it's low, complexity hides, and hidden complexity is the kind that hurts.

Next in the series, we shift from systems to people. Because skills, turnover, informal habits, and shadow processes create their own layer of complexity, and that's the one no software will ever manage for you.