Planning Maintenance Around the Operation
Knowing that an asset needed attention did not answer when it should be taken out of service.
Asset condition was only part of the decision. Teams also needed dependencies, production demand, alternative capacity, planned work and an available intervention window.
At Cognite, I explored bringing maintenance and operational information together so people could reason about when intervention made sense—not only whether equipment needed work.
DESIGN EXPLORATION / PROTOTYPING
Asset health was only one input.
- Asset condition
- Production demand
- Upstream / downstream dependencies
- Maintenance window
- Alternative capacity
- Existing planned work
When can intervention happen with acceptable operational impact?
Maintenance urgency and maintenance timing were related, but different decisions.
The right technical action could still disrupt the operation.
Maintenance asks
What condition is the asset in? What work is required? What happens if intervention is delayed?
“This asset needs attention.”
Operations asks
What depends on it? Is another path available? What demand exists? What else is offline?
“Can the operation absorb the disruption?”
Both perspectives needed the same picture. Taking one asset offline could affect upstream work, downstream processes, throughput, scheduled work and safety constraints.
Asset state makes more sense inside system state.
Condition → Consequence → Window → Intervention
- ConditionWhat does the asset evidence say?
- ConsequenceWhat depends on its availability?
- WindowWhen can the operation tolerate work?
- InterventionWhat action and coordination are needed?
Different time horizons · not a production status model
- Immediate
- Urgent investigation or action; safety requirements govern the response.
- Near-term
- Work is needed soon, with some scheduling flexibility.
- Planned
- Coordinate with a known window or other scheduled work.
- Monitor
- Observe the condition while intervention is not yet warranted.
Conceptual distinctions, not validated thresholds, failure predictions or advice to defer urgent intervention.
Detailed workflow · plan an intervention
- Notice a maintenance need or concerning condition.
- Inspect the evidence and urgency.
- Examine dependent processes, assets and work.
- Assess the consequence of unavailability.
- Review demand, shutdowns, planned work and alternative capacity.
- Compare the risk of acting now with the risk of waiting.
- Coordinate a plan or escalate to the accountable teams.
- Use maintenance and subsequent performance as future evidence.
Generalized planning workflow. Engineering judgment, safety requirements and operating constraints determine what is actually permissible.
Where technical need and operational tolerance overlap.
| Planning moment | Asset / maintenance context | Operating context | Question to resolve |
|---|---|---|---|
| Now | A deterioration pattern needs investigation. | Demand is high; alternative capacity is limited. | Does urgency require action despite disruption? |
| Possible window | Work might align with an existing plan. | Lower demand and an alternate path may be available. | Can Engineering and Operations validate this opportunity? |
| Later | The risk of waiting could increase. | Availability may become less predictable. | How much scheduling flexibility remains? |
A useful interface exposes the intersection of need and opportunity. It does not manufacture certainty about failure risk or safe downtime.
Bring context into the maintenance decision.
- Do not isolate the asset. Show what it participates in.
- Separate urgency from flexibility. “Needs maintenance” does not automatically mean “take offline now.”
- Make dependencies inspectable. Show consequence before commitment.
- Connect planned work. Let teams reason across schedules rather than separate silos.
- Preserve accountable judgment. Organize the risk; do not pretend it disappears.
Evidence → decision → tradeoff
Evidence: maintenance decisions needed demand, dependencies, planned work and available windows in addition to condition.
Decision: explore one planning flow connecting technical need and operational context.
Tradeoff: better context depends on data quality and integration across systems.
Direction: help people reason about the consequence of intervention, not just read maintenance status.
Prototype the relationships, not just the screens.
Original exploration
Industrial maintenance problem → customer/domain investigation → dependency and timing framing → workflow exploration → design prototyping → customer/engineering discussion.
Conservative lifecycle framing; exact tools and delivery stages still need artifact verification.
How I would prototype it today
Asset + dependency model → AI-assisted scenario exploration → coded planning timeline → interactive availability and consequence states → test intervention scenarios earlier.
A proposed current approach, not a claim that this coded planning system already exists.
The pattern returned at Target.
- Cognite
- Asset condition + production dependencies + maintenance window
- Target
- Equipment condition + Material Flow + operating demand + intervention runway
Different projects and operating environments. The recurring question remained: what needs attention, and when can the surrounding operation tolerate it?
Reality check · a clearer decision is not a risk-free decision
What design could clarify
Condition, dependencies, intervention consequences, planning windows, scheduled work and shared understanding between Operations and Maintenance.
What the system still depended on
Reliable condition data, failure risk, safety requirements, production forecasts, redundancy, maintenance duration, parts and people, engineering judgment and operating constraints.
A better interface could expose the tradeoff. It could not make it risk-free.
DESIGN EXPLORATION / PROTOTYPING · No implemented planning platform, optimized schedule or measured maintenance result is claimed.
From asset condition to intervention timing.
- Establish condition.
- Understand urgency and flexibility.
- Map dependencies.
- Assess operational consequence.
- Find viable windows.
- Compare the risk of acting and waiting.
- Coordinate the larger operating plan.
Useful anywhere technical maintenance must coexist with a live operation.