Capabilities Asset maintenance

Capability · Asset maintenance

Stop managing interventions alone.Manage asset reliability.

Connect criticality, preventive work, requests, work orders, skills, parts, downtime and feedback to decide at the right level.

A capability shaped by your flows, rules and field evidence.

Line failureActive scenario01SignalA critical asset stops with a known code.02DecisionQualify criticality, history, skill and part before assignment.03ProofDiagnosis, work order and technician ETA visible.04Active systemOTILA05Active systemMES
01 / 03Reduce time lost before intervention
Opportunistic preventiveActive scenario01SignalA line stops earlier than planned due to material shortage.02DecisionCompare ready work, duration, risk and parts availability.03ProofGrouped work and updated plan.04Active systemOTILA05Active systemERP
02 / 03Use a window without disrupting the plan
Service providerActive scenario01SignalA contracted asset needs specialist work.02DecisionShare scope, access, SLA, proof and service approval.03ProofService, parts, time and acceptance reconciled.04Active systemOTILA05Active systemPortail
03 / 03Control external work end to end
01 / 0302 / 0303 / 03
01

Controlled availability

Preventive work, failure and operating constraints share one calendar.

02

Prepared intervention

Skill, part, procedure, permit and window are qualified before dispatch.

03

Usable history

Cause, action, time, consumption and result are structured.

04

Visible risk

Criticality and trend guide priorities rather than request volume.

Decision framework

Connect promise, responsibility and proof.

CMMS becomes useful when each intervention supports a better decision about the asset, risk, part and maintenance plan.

Business logic

Decisions start with explicit rules.

Connected architecture

Clear responsibilities, from signal to proof.

OTILA GMAOCarries maintenanceERP / achatsCarries managementMES / exploitationCarries field contextWMSCarries parts

Gaps to eliminate

What weakens day-to-day decisions.

Each gap connects an observable situation to a business consequence. Diagnosis then verifies frequency, impact and cause.

01

Incomplete register

Equipment, subassembly, location and criticality are not aligned.

Unusable history
02

Calendar-only preventive

Plans ignore usage, condition or risk.

Over-maintenance or avoidable failure
03

Unprepared intervention

Technician, part or permit is missing at the critical moment.

Extended downtime
04

Poor feedback

Work order closes without cause, measurement or lasting action.

Recurring failures

Operational journey

A chain of decisions, not a stack of screens.

Each transition identifies the participant, responsible system and expected proof.

1

Criticality

Structure the asset base

Hierarchy, location, use, redundancy and impact are qualified.
Owner
OTILA / business
Proof
Validated asset and criticality
2

Prevent

Build the plan

Time, meter, condition and regulation trigger the right plans.
Owner
OTILA CMMS
Proof
Plan and next due dates
3

Prepare

Make work executable

Skill, availability, part, tooling, procedure and safety are brought together.
Owner
Maintenance planning
Proof
Work order ready to release
4

Intervene

Guide and prove

Diagnosis, time, action, measurement, photo and consumption are returned.
Owner
Technician / provider
Proof
Work and return to service
5

Improve reliability

Turn feedback into a decision

Recurrence, cause, cost and risk revise plan, stock or design.
Owner
Reliability / BI
Proof
Assigned lasting action

Decision lab

Change context. Follow what genuinely needs to happen.

These scenarios are illustrative: they show decision logic and responsibilities without claiming to simulate your actual outcomes.

Line failure

Reduce time lost before intervention

Signal

A critical asset stops with a known code.

Decision

Qualify criticality, history, skill and part before assignment.

Expected proof

Diagnosis, work order and technician ETA visible.

B‑AGILEdecision flowOTILA GMAOERP / achatsMES / exploitationWMS

Responsibility architecture

Unify the flow without pretending one system does everything.

The responsibilities below form a reference architecture to adapt to the existing IT landscape.

01

OTILA GMAO

Carries maintenance
Owns
Assets, plans, requests, WOs, parts and history
Publishes
Due dates, work and availability
02

ERP / achats

Carries management
Owns
Suppliers, orders, contracts, costs and fixed assets
Publishes
Commitment and valuation
03

MES / exploitation

Carries field context
Owns
State, meter, stop, production and window
Publishes
Event and availability
04

WMS

Carries parts
Owns
Stock, lot, location, reservation and movement
Publishes
Part availability

Actionable cockpit

Reliability & execution cockpit

Priorities combine criticality, risk, production, resource availability and feedback quality.

  • AvailabilityConnect maintenance to delivered service
  • MTTRTarget the phase extending downtime
  • On-time preventiveAvoid a flattering but useless rate
  • RecurrencePrioritise lasting improvement
Operational view · example
Availability01Required, available and unavailable time by cause
MTTR02Detection, waiting, diagnosis, repair and test
On-time preventive03Work completed within its risk window
Recurrence04Repeated failures by asset, cause and horizon
Incomplete registerCalendar-only preventiveUnprepared intervention
No value is a customer measurement. Illustrative functional example.

Success conditions

What must be true before automation.

01

Explicit scope

Activities, sites, participants, systems and boundaries are defined before any automation.

02

Named responsibilities

Each data item, rule, decision and exception has a business owner and responsible system.

03

Observable proof

An action is only treated as complete after verifiable feedback from the field or execution system.

04

Before / after measurement

A baseline, indicator, horizon and interpretation limits are agreed before the pilot.

Go further

Content to prepare a real discussion.

View all resources

Frequently asked questions

Decide with the right boundaries.

Must existing systems be replaced?

Not necessarily. Scoping distinguishes what should be retained, connected, extended or replaced based on value, risk and expected responsibility.

Can we start with a limited scope?

Yes. One flow, one site and a few critical decisions can test data, rules, interfaces and adoption before extension.

How is real time defined?

By the decision window. Each event must specify its source, frequency, acceptable age and degraded mode.

Are outcomes guaranteed?

No. Benefits are measured against an agreed baseline, scope and period; no generic percentage is promised.

How are exchanges secured?

Through suitable architecture, role-based rights, logging, retention rules and risk-proportionate monitoring.

Who approves business rules?

Named business owners, with IT and execution teams contributing; overrides remain traceable.

Your context first

Move from reactive maintenance to managed reliability.

Identify the decisions, data, responsibilities and pilot that will deliver observable value.

Talk to an expert All capabilities