Don’t Digitize Chaos — Fix It First
Ahmed Rezika, SimpleWays OU
Posted 8/5/2025
Digital maintenance promises speed, insight, and control. But what happens when the foundation it builds on — your asset data, your workflows, your program logic — is already in disarray? You can start by the taking the Maintenance Structure Assessment here or read through and use the printed copy below.
HBR calls it the “acceleration trap”:[1] when companies rush to implement tech without aligning people and process, complexity multiplies instead of shrinking. The same applies in maintenance. Drop a CMMS or EAM into an unstructured environment, and all you’ve done is digitize the dysfunction.
It’s a classic systems lesson — and a psychological one too. Research from organizational psychologist Dr. Robert Sutton warns that “bad systems beat good people every time.”[2] Left unchecked, disorganized data, unclear roles, and legacy habits create a kind of operational entropy. It’s Murphy’s Law for maintenance: whatever is undocumented, disconnected, or outdated will eventually cause failure. The original Classic Murphy’s Law: If anything can go wrong, it will.[7]
Worse, most apps rely on your existing asset data to get started. If your hierarchy is clean, asset tags are consistent, and locations make sense — you’re off to a flying start. But if your system is a patchwork of half-filled fields and tribal knowledge, the tech won’t save you. You’ll need to stop, structure, and sometimes rebuild — manually — before anything useful can be automated.
Yes, some modern apps offer shortcuts. They let you loosely associate work orders to free-text equipment or skip the full asset tree. It feels agile. But that flexibility is a double-edged sword: you get a fast start, but limit your long-term insight and control. Poorly bound assets mean poor traceability, which means less value from reporting, planning, and AI insights down the line.
So before you plug into the latest digital tool-set, ask yourself: is your data ready to be trusted, reused, and scaled? If not, don’t rush the integration — fix the foundation. Because in maintenance, structure isn’t a bottleneck. It’s the runway.
That’s why in this article, we’ll go beyond slogans and dive into practical, boots-on-the-ground assessment methods to eliminate chaos before it spreads into your systems. We’ll explore how to treat your process like source code, how to digitize with discipline, and how smart tools can help you clean, structure, and validate your asset data long before you hit “go” on a big system roll-out. Whether you’re working off a whiteboard, a legacy CMMS, or preparing for an enterprise-wide transformation, the principles are the same: clarify first, then connect.Because no tool will do the thinking for you — but the right foundation will let every tool think with you.
Stating the problem: The Real Root of Maintenance Chaos
We often hear the complaints: “It’s not working.” “The app is no good.” But what if the app isn’t the problem? What if, by digitizing an ineffective process, we’re simply scaling dysfunction instead of solving the underlying issues?
Technology is a powerful enabler—but only when it serves a robust, well-designed process. Too often, organizations race to adopt new maintenance software or apps in hopes of instant improvement. However, without first fixing operational chaos and redesigning broken workflows, digitization merely speeds up and magnifies poor practices. In the words of one industry observer, “A CMMS by itself won’t fix maintenance problems that plague a facility. Implementing software without a real plan is a massive mistake that can kill a project on arrival”. More on that here.
Many maintenance programs—manual or digital—fail not because of the technology or the app, but because they simply codify and automate existing bad habits. When organizations digitize paper-based or ad-hoc processes without process reengineering, everything from data inconsistency to communication breakdowns becomes harder to identify and more costly to correct.
The Danger of Scaling Dysfunction: Real-World Examples
This pattern is evident in Computerized Maintenance Management System (CMMS) implementations. Studies by Mackinsey show that : “In fact, two out of three large programs regularly exceed initial budgets, miss schedule estimates, and underdeliver against business objectives and benefits, often by significant margins.”[4] Those failures are not attributed to technology limitations, but to poor planning, undefined workflows, and lack of stakeholder involvement. Common pitfalls include:
- No clear maintenance goals or KPIs defined prior to software rollout.
- Lack of training or post-implementation support for frontline teams.
- Ignoring day-to-day user feedback and neglecting to adapt the tool to actual needs.
- Failing to address cultural resistance or clarify ownership of new digital processes.
Imagine When Bad Habits Go Digital
Consider a manufacturing facility that moved maintenance logs from paper to a CMMS without first formalizing asset lists, maintenance schedules, or failure codes. The result was a digitized backlog of inconsistent, incomplete records that made root-cause analysis even harder than before. Similarly, a chemical plant suffered a fatal incident in part because its maintenance management system failed to require and track scheduled hose changes—illustrating that absent or weak processes, not lack of technology, undermined safety outcomes.
Lessons Learned
Before investing in maintenance apps or new systems, organizations must:
- Standardize and document maintenance processes.
- Define clear objectives and success criteria for any digital transformation project.
- Involve stakeholders at every level to ensure buy-in.
- Address process gaps before introducing technology.
Digitizing chaos does not produce order—it simply makes chaos harder to unwind. Fixing the process must come first.
Stating The Solution: Process is the Source Code of the magical Box Model
“Apps are front-ends. Your real backend? The maintenance program.”
Imagine a black box — a classic systems thinking metaphor. You feed it clean inputs, and like magic, you get predictable, valuable outputs. That’s how apps are supposed to work. But in maintenance, the real magic doesn’t happen in the interface. It happens in the logic inside the box — the strategy, discipline, and decision-making that sit beneath the screen. That’s your source code. And when it’s messy, no app can make it run smoothly.
This is what we’ll call the Box Model: a simple mental model for understanding how maintenance programs — just like software systems — rely on structured logic, consistent inputs, and modular thinking to function. When chaos seeps in (ambiguous work requests, incomplete asset data, skipped inspections), it doesn’t just pollute the input — it breaks the entire chain, from decision-making to results. The box stops being magic. It starts being unpredictable.
As systems theorist Dr. Donella Meadows[3] famously wrote:
“A system is more than the sum of its parts; it is the product of their interactions.”
When the interactions — the process logic — are flawed, the outputs will be too, no matter how slick the tool.
Your Process is Code — So Write It That Way
Think like a software architect:
- Clear input types: good asset data, standardized job plans, condition monitoring signals
- Deterministic logic: rules for prioritization, escalation, scheduling
- Clean output: work orders, reports, backlog views that tell the truth
Every maintenance process has business logic behind it — and much of it mirrors traditional software design. Your P-F curves are the “if-then” statements for asset degradation. Your FMEAs are decision trees in disguise. And your planning workflows? That’s procedural logic with loops and conditions.
When we ignore this structure and try to patch in tools later, it’s like building an app without writing any code. The UI might look fine — for a while — but it won’t scale, won’t integrate, and won’t adapt when complexity hits.
Want Modularity? Start with Standards.
In software, modularity allows a system to be broken into manageable, reusable parts. In maintenance, it looks like:
- A standardized asset hierarchy (ISO 14224 is a great guide)[5] -will be detailed below-
- Clearly defined task types and job steps – will come in a later article –
- Repeatable planning logic that can be used across lines or plants
McKinsey also reinforces this in its guide to digital transformation in operations[6]:
“Modular, standards-based processes reduce implementation friction and increase reuse across sites.”
This modular thinking pays off when you need to connect your process to tech. With structured inputs and logic, you can start plugging in automation tools — AI-powered planners, mobile apps, even predictive analytics — with far less friction. You’ve written clean source code. Now it’s just a matter of picking the right interface.
Summary Quote: “Before you design the interface, design the logic. Because what good is an app that clicks cleanly, but thinks chaotically?”
Implement The Solution: Digitize with Discipline — At the Gemba
“When you digitize chaos, you just get faster chaos.”
“Your screen should reflect the shop floor — not distort it.”
In Thinking in Systems (published posthumously in 2008), Donella Meadows wrote:
“Systems often surprise us because our mental models of them are vastly simplified… The leverage point is not where we push hardest — but where the structure allows small pushes to have big effects.”
???? Source: Thinking in Systems: A Primer (Meadows, 2008)
That principle is just as true on a production line as it is in global economics. In maintenance, apps are leverage points — but only when the underlying system is built for them. Too often, companies install digital tools hoping they’ll clean up the mess. Instead, they accelerate dysfunction, turning vague job plans, undefined priorities, and missing asset data into high-speed, low-trust chaos.
Over-configurable systems — sprawling ERPs, feature-bloated CMMS platforms — often fall into this trap. They offer hundreds of switches and custom fields, but no clarity on the work behind them. So instead of modeling reality, they begin to distort it. The system reflects ideal workflows that no one follows, and the shop floor becomes a theater of compliance instead of a center of insight.
Discipline Before Digital Maintenance
This is why we return to the Box Model:
Apps should enhance what’s already working, not try to rescue what isn’t.
If the internal logic of your maintenance program — the source code — is solid, then digital tools can become true force multipliers. But if you feed confusion into the system, the only thing that grows is noise.
So when do you bring in an app?
You’ve got two options:
- Use the app as a structured cleanup tool. Some tools — especially modern, AI-augmented ones — can help surface duplicate assets, cluster similar work requests, or flag inconsistencies in task durations. In this case, the app is your onboarding assistant, helping you bring order into the box.
- Or start by purifying your box model. Build discipline offline or in low-friction tools — whiteboards, spreadsheets, even analog kanbans. Then, when the logic is sound and the language is shared, move to digital. In this case, the app becomes a scaling mechanism, not a repair patch.
LLMs at the Gemba
This is where large language models (LLMs) — like GPT — offer something radically different. They don’t demand perfection. They embed themselves within messy, human workflows. A planner can paste a backlog into a Google Sheet, and an LLM can instantly:
- Summarize overdue work
- Suggest asset tagging corrections
- Spot repeated failures on the same equipment
The point isn’t complexity. It’s context. The best digital tools don’t replace your process — they follow it. They respect the Gemba. They understand that real work is fuzzy, interrupt-driven, and layered, and they quietly assist without adding drag.
As Meadows taught:
“The purpose of a system is what it does.”
A maintenance system that produces rework, confusion, or reporting theater — is working. It’s just working toward the wrong goal.
In Short: “Digitization is a mirror. If the reflection looks broken, fix the source — not the screen.”
Field Guide: Preparing Your Maintenance Program for Digital Tools
“You don’t plug into power until the wiring is safe.”
Before you digitize, I recommend this checklist to audit your box model — and prepare it to scale with any app, system, or AI support you choose later. You don’t need a new tool. You need a starting point. Start with the Asset Hierarchy Self-Assessment Checklist — or use the interactive Google Form version to walk your team through it from here: https://simpleways.life/maintenance-structure-assessment/
1. Clarify the Input: Get Your Data Ready
- Asset hierarchy is standardized
“Structure is the skeleton of reliability.”
- Asset Registry Exists and Is Current
- Master list of physical assets is documented
- Assets are uniquely identifiable (no duplicates, no gaps)
- Includes mobile, fixed, critical, and utility equipment
- Unified Naming Convention Is Applied
- Standardized format (e.g., [Plant]-[System]-[Equipment Type]-[ID])
- No inconsistent abbreviations or free-text entries
- Follows a documented naming policy used by all departments
- Asset Tags Are Physical and Digital
- Physical tags match system IDs (barcodes or QR codes ideal)
- Technicians can identify assets in the field with minimal lookup
- Tags are scannable and map directly to CMMS entries
- Hierarchical Structure Is Logical and Complete
- Assets are nested by system > subsystem > component
- Matches ISO 14224 [5], RDS-PP, or a site-specific logic
- Can trace a failure from component to system level
- Parent-Child Relationships Are Clear
- Relationships reflect actual mechanical, electrical, or process connections
- Enables correct roll-up for downtime, cost, and failure analysis
- No assets floating without a parent (or incorrectly grouped)
- Master list of physical assets is documented
- Criticality rankings are assigned and justified
- Failure modes and causes are defined for key assets
- Locations and naming conventions are consistent
- Work requests follow a structured format (problem–cause–remedy)
“An AI can find patterns — but only if you feed it clean ingredients.”
2. Tighten the Logic: Audit the Process Rules
- Work order types and priorities are clearly defined and consistently used
- Scheduling rules exist — and are followed (preventive vs. reactive balance)
- Backlog limits and planning windows are understood by all
- Escalation paths are mapped and agreed upon (who handles what, when?)
- CMMS fields match actual planning logic (not just what IT configured)
“If you can’t describe your logic on paper, your app won’t understand it either.”
3. Structure the Output: Define What Success Looks Like
- Reports are tied to decisions — not just compliance
- KPIs reflect actual behavior (e.g., MTTR, % planned work)
- Failure data is used — not just logged
- Planners and supervisors can interpret dashboards and take action
“Good output should feel like a control panel — not a spreadsheet graveyard.”
4. Test at the Gemba: Walk It Before You Wire It
- Run a mock workflow (from request to closeout) on paper or in a Sheet
- Validate that every digital step reflects what actually happens
- Ask technicians: ‘Does this screen help or get in the way?’
- Pilot any app in one area before scaling — and document lessons learned
“Apps should earn their place. If they don’t improve the real work, they’re just noise.”
“Short Question” at the end: What’s the one area that needs the most urgent cleanup in your asset hierarchy?
In Short: “A great app doesn’t replace discipline — it rewards it.”
Once you’ve got a clean box model, your tools don’t have to guess. They guide, learn, and scale. That’s the foundation where real transformation happens — not from code, but from clarity.
Conclusion: The Discipline Is the App
“No app will tell you what good maintenance looks like. But your good process can teach the app what to do.”
Technology doesn’t define your maintenance program — it reflects it.
The best apps don’t save failing programs. They amplify disciplined ones. When your process has structure, logic, and clarity, it becomes the very thing that teaches your tools how to behave — not the other way around. And in that sense, the process is the app. It’s the part that defines what data matters, what actions come next, and what “good” actually looks like.
So before you chase platforms, features, or dashboards, ask yourself:
Have we written our source code?
Have we designed the logic, agreed on the inputs, and clarified the outputs?
If not, you don’t need a new tool. You need a starting point to a clean process.
Start with the Asset Hierarchy Self-Assessment Checklist — or use the interactive Google Form version to walk your team through it from here: https://simpleways.life/maintenance-structure-assessment/
These aren’t just forms. They’re leverage points — “small steps that unlock big shifts”, as systems thinker Donella Meadows would remind us.
Because once the process is clean, you can plug in anything:
- Apps
- APIs
- AI
- Dashboards
- Mobile tools
And it will all just click — because the thinking is already done.
The next frontier? AI that learns from well-structured programs and helps improve weak ones — not by replacing planners or engineers, but by amplifying their discipline at scale.
And when that happens, you’ll know what to feed it. Because you built the box. You designed the system. You fixed the chaos — before you digitized it.
Must-Know Jargon
GEMBA: Japanese for “the real place.” In maintenance, it’s the shop floor, the control room, the line — wherever the actual work happens. Gemba reminds us: if your digital tool doesn’t work at the Gemba, it doesn’t work.
P-F Curve: A predictive maintenance model that charts the time between Potential Failure (P) and Functional Failure (F). Your detection and intervention strategies should live between those two points. Think of it as the early warning radar for asset health.
FMEA (Failure Modes and Effects Analysis): A structured way to identify how something might fail, what the impact would be, and how to prevent it. Like a bug triage for assets. Core to risk-based maintenance and design thinking.
Backlog: The list of all approved maintenance work that hasn’t been done yet. A healthy backlog = ~2–4 weeks of planned work. Too low = no plan. Too high = buried in breakdowns.
Planned vs. Reactive Ratio: A key performance indicator (KPI) showing how much of your maintenance is proactive (planned) vs. firefighting (reactive). Good programs aim for 70%+ planned. Bad ones spend their days in triage.
References
1. Bruch, Heike, and Jochen I. Menges. “The Acceleration Trap.” Harvard Business Review, April 2010, pp. 80–85.
2. Sutton, Robert I. Good Boss, Bad Boss: How to Be the Best… and Learn from the Worst. Business Plus, 2010.
3. Donella Meadows, 1941-2001, Leverage Points: Places to Intervene in a System.
4. Managing large technology programs in the digital era, Nov 25, 2020. McKinsey & Company.
5. ISO 14224:2016 Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment, This publication was last reviewed and confirmed in 2022. Therefore this version remains current.
6. McKinsey & Company – Industry 4.0, Capturing value at Scale in Discrete Manufacturing, July 2019.
7. Carnegie Mellon University’s curated list of Murphy’s Laws.
Related Articles
Facilities Management Technology for 2023
10 Things Your Management Needs to Know Now
30-60-90 Day Plan for New Maintenance Managers
Unlocking Growth: Overcoming the 6 Tech Roadblocks to Scale Your FM Services
Why Online Oil Quality Monitoring is a Best Practice for Reliability Programs
