Part of Operational Readiness

Maintenance Readiness for day-one execution.

The maintenance team should not have to build the maintenance system while the plant is starting.

Shivaan Asset Management helps owners turn project engineering information into an executable, governed maintenance system: assets structured, risks understood, strategies approved, work prepared, spares available and CMMS/EAM data ready for use.

Discuss your Maintenance Readiness scope See the readiness workstreams

Part of Operational Readiness

Everything needed to maintain the assets after handover.

Maintenance Readiness is the coordinated work required to prepare maintenance before operations takes ownership of the asset.

It connects engineering design, equipment information, reliability analysis, maintenance tasks, materials, systems, people and governance. The objective is practical: when the asset enters service, the maintenance team can identify it, understand its risk, plan the right work, find the right parts, record failures consistently, and improve the strategy using information it can trust.

It is not a single FMECA workshop, a PM build or a CMMS load. Those are connected parts of one system, and the value is lost at the joins between them.

The difference is visible in the first weeks of operation.

Nobody declares a plant not maintenance ready. It shows up instead as a pattern of small delays that all trace back to the same missing preparation.

Not fully ready

Planners search project folders for task information.
Technicians receive generic or incomplete job plans.
PMs are copied from OEM manuals without an operating-context review.
Critical spares are expedited after the first failure.
Failure history defaults to free text.
Different systems describe the same asset differently.
Engineers spend ramp-up time fixing master data.
Strategy changes are not controlled.

Maintenance ready

Approved tasks are already in the work system.
Critical assets and safety obligations are clear.
BOMs and support arrangements exist before they are needed.
Failures are recorded against controlled structures.
Reporting rolls up by asset class, system, site and consequence.
Standards, ownership and change control survive handover.
Early-life learning feeds back into the strategy.

A maintenance system is only as strong as the handoffs between its parts.

Ten workstreams, delivered together or individually. Most programmes can name who owns each one. Far fewer can name who owns the conversion between them.

Asset scope and information requirements

Establish what must be maintained, and what information the owner needs to maintain it.

Deliverables can include

Asset register requirements and validation
Asset class and type structures
Functional location and asset hierarchy
Maintainable item and component boundaries
Naming conventions and technical attributes
Document and data handover requirements
Equipment and vendor data completeness checks

Outcome

Every downstream maintenance decision is attached to a clear asset boundary and a controlled identity.

Criticality, risk and compliance

Concentrate effort where failure matters most.

Deliverables can include

Asset criticality methodology and assessment
Safety, environmental, production, cost and service consequences
Statutory and regulatory maintenance requirements
Safety-critical equipment identification
Risk-based prioritisation of readiness work
Criticality-to-planning and spares rules

Outcome

The project knows which assets, work and materials need the highest assurance before start-up.

Maintenance and reliability strategy

Define what maintenance is required, and why.

Deliverables can include

FMEA and FMECA
RCM where consequence and complexity justify it
Preventive, predictive and condition-based task selection
Inspection requirements, task intervals and triggers
Failure-finding tasks
Operating-context assumptions
Statutory and compliance tasks
OEM recommendation review, rather than automatic copying

Outcome

Every maintenance task traces back to a failure risk, an operating context or a clear external requirement.

Reliability and system analysis

Answer the questions task-level analysis cannot reach.

Deliverables can include

RAM analysis and availability modelling
Reliability Block Diagrams for redundancy and configuration
Fault Tree Analysis for combinations leading to a defined top event
Life data and Weibull analysis where credible data exists
Maintainability analysis and repair-time assumptions
Critical spares modelling
System bottleneck and vulnerability analysis

Outcome

Design, redundancy, support and maintenance decisions carry the right level of quantitative or logical analysis behind them.

Hazard, operability and maintainability interfaces

Keep maintenance requirements inside the project risk and safety studies, not beside them.

Deliverables can include

HAZID participation
HAZOP and CHAZOP support
Maintainability and access review
Isolation and safe-maintenance requirements
Safety-critical maintenance inputs
Proof-test and functional-test requirements
Links between hazards, safeguards and maintenance obligations

Outcome

Critical safeguards and maintenance-dependent controls end up with executable requirements, not just study actions.

Executable maintenance work

Turn approved strategy into work a planner and a technician can actually use.

Deliverables can include

Maintenance plans and PM records
Task lists, job plans and routes
Work instructions and inspection sheets
Labour and trade requirements, estimated durations
Tooling and access requirements
Permits and isolation inputs
Initial maintenance schedule and start-up work packs
Preservation maintenance where required

Outcome

Strategy moves out of analysis and into controlled execution.

Materials, spares and support

Make the planned work physically possible.

Deliverables can include

Equipment bills of material
Critical spares analysis
Commissioning and start-up spares
Insurance and capital spares where relevant
Repairable and rotable strategy
Lead-time and obsolescence review
Vendor and service agreements
Special tools and test equipment
Storage and preservation requirements

Outcome

A critical task is not delayed because the material or specialist support behind it was never prepared.

CMMS/EAM and master-data readiness

Make sure the maintenance system can hold and execute the design.

Deliverables can include

Technical object and hierarchy design
Asset classification and attributes
Maintenance plan and task data, job plans, BOM data
Failure codes and failure-reporting structures
Measurement points and counters where required
Planning fields and work centres
Load sheets, migration support and data-quality validation
Reporting and roll-up structures
Cutover and freeze rules

Outcome

The client receives load-ready structures, not a set of engineering spreadsheets that still need interpreting.

Work management and organisation

Prepare the people and the process that will run the system.

Deliverables can include

Work management process and roles
Planning and scheduling requirements
Defect and backlog management
Shutdown interfaces
Maintenance organisation and role clarity
Competence and training needs
Contractor and specialist support model
Maintenance facilities, workshops and tooling readiness
Document control and change management

Outcome

The system has accountable users and a repeatable way of working.

Assurance, handover and early-life support

Prove readiness rather than assume it.

Deliverables can include

Readiness criteria and gate reviews
Workstream status and evidence register
CMMS/EAM data validation and sample work-order testing
Spare and BOM verification
Training completion and system access checks
Open-item risk review
Handover dossier
Early-life strategy refinement after first failures and inspections
Governance transfer into the operating organisation

Outcome

Readiness is evidenced, residual risk is visible, and ownership transfers deliberately.

Good analysis has to survive the trip into the CMMS.

Engineering intent is most often lost between strategy development, master data, planning and field execution, because each step is delivered by a different team in a different format with no controlled conversion between them.

Asset classification
Hierarchy and maintainable items
Criticality
Functions and failure modes
Maintenance strategy
Tasks and job plans
BOMs and spares
CMMS/EAM records
Field execution and failure reporting
Review and improvement

Shivaan Asset Management can carry both the technical analysis and the conversion work that makes the outcome usable downstream, with standards and governance carried through the whole chain rather than re-established at each step.

Greenfield and major brownfield projects are the best opportunity to set a classification and taxonomy the organisation can keep using after handover, including the definitions and change rules, not just a spreadsheet of names.

Use the method the decision actually needs.

The objective is not to apply every reliability technique to every asset. We select the analysis depth according to consequence, complexity, operating context, available information and the decision that has to be made.

FMEA and FMECA for structured failure understanding
RCM where consequence and complexity justify deeper task-selection logic
RAM and RBD for system reliability, capacity, availability and redundancy questions
FTA for combinations of events leading to a defined top event
HAZID and HAZOP interfaces where safety studies create maintenance obligations
Maintainability and life data analysis where the decision and the data support it

Depth where it adds value. Simplicity where it does not.

We do not apply every reliability method to every asset simply because it exists.
We do not treat OEM recommendations as the final maintenance strategy without considering operating context and consequence.
We do not call a spreadsheet CMMS ready when the client still has to redesign the structure before loading it.
We do not create a taxonomy without ownership and change rules.
We do not treat handover as complete while critical gaps remain invisible or unowned.

Project delivery also has to align with your technical requirements, legal obligations, operating philosophy and applicable engineering requirements. Those belong in the delivery scope, not on a marketing page.

Use us for the whole build, or where your team needs depth.

Five ways to engage. Most programmes start with the first and expand once the gaps are known and sized.

Maintenance Readiness assessment

An independent gap assessment against the readiness workstreams, with a risk-ranked action plan, the evidence behind each finding and a recommended close-out sequence.

Best when a gate is approaching and the honest position is unclear.

Engineering foundation package

Asset structure, criticality, FMECA and RCM, reliability studies, and the maintenance strategy that comes out of them.

Best when the engineering has to be right before anything is built on it.

CMMS/EAM readiness package

Master data, PM and task conversion, BOMs, failure codes, data standards, load-ready outputs and implementation support.

Best when the analysis exists but the system cannot yet use it.

Full maintenance-readiness build

Integrated engineering, work, materials, systems, people, governance and handover assurance across all ten workstreams.

Best for a greenfield build or a major expansion with no incumbent capability.

Owner-team augmentation

Specialist reliability, maintenance, asset-information or readiness resources embedded into your wider programme.

Best when the plan is sound and the constraint is capacity or depth.

Standardisation can be accelerated without making the project depend on a platform.

Where reusable engineering libraries and structured automation genuinely help, parts of asset-library, maintenance-strategy, task-bundling and failure-code standardisation can be supported using Nexaan, a separate asset performance management platform. The consulting scope stays independent of the software, and your data, approval rules and CMMS/EAM requirements remain the governing project requirements.

Frequently asked questions

Is Maintenance Readiness only for greenfield projects?

No. The same discipline applies to expansions, recommissioning, brownfield upgrades, major new equipment, site integrations and CMMS/EAM changes. The scope is adapted to what already exists and what has to change.

Is Maintenance Readiness the same as maintenance strategy development?

No. Maintenance strategy is one workstream of ten. Maintenance Readiness also covers the asset structure, CMMS/EAM records, materials, work processes, people, governance and assurance required to execute that strategy.

Do all assets need RCM?

No. The analysis should be proportionate to risk and complexity. Some assets need a structured FMEA or FMECA and a task review; others justify full RCM or system-level RAM, RBD and FTA work. Applying the deepest method everywhere costs time without improving the decision.

What is the biggest early decision?

Define the asset and information structure early. If classification, hierarchy, maintainable boundaries and owner data requirements are unclear, every downstream workstream spends its time reconciling the same ambiguity.

Can you produce load-ready CMMS/EAM data?

Yes, where your system rules and templates are defined. The scope can include system-specific structures, load sheets, validation and implementation support, rather than stopping at engineering spreadsheets.

When should Maintenance Readiness start?

Early enough that the asset and information structure can still influence engineering deliverables and vendor data requirements. Starting after construction is possible, but it turns design decisions into rework.

Start with the readiness gap, not a generic scope.

We can review what is already in place, identify what has to be complete for your next project gate, and structure a scope around the actual gaps: from one technical workstream to the complete maintenance-readiness build.

Discuss your Maintenance Readiness requirements See a readiness project