Asset Lifecycle Management

A machine on your floor doesn't stop being an asset the day it's commissioned — it moves through nine different states over its life, and somewhere between "installed by the OEM's technician in 2019" and "third breakdown this month" most plants lose the thread. The AMC lapsed in March, nobody renewed it, and the ₹4 lakh spindle repair in June came out of the maintenance budget instead of the vendor's. Asset Lifecycle Management in AssetAI keeps the acquisition record, the coverage status, and the cost-and-failure history against the same asset, so that question has an answer before the breakdown, not after.

The nine stages, and why status matters

Every asset in AssetAI carries one of nine statuses at any time: Draft, Active, Idle, Under Maintenance, Breakdown, Standby, Decommissioned, Retired, Scrapped. This isn't a cosmetic label — it's what the rest of the system reasons against. A machine in Breakdown feeds differently into your OEE numbers than one that's Idle by plan; a Retired asset stops generating PM schedules but keeps its full history for audit. If you're not sure why this level of granularity matters, our glossary page on what a CMMS actually does walks through it in plain terms.

Two honest boundaries here: Scrapped and Retired are statuses, not financial events. AssetAI does not run depreciation schedules, does not calculate book value, and does not integrate with fixed-asset accounting — that's your ERP's job. We also don't capture disposal or sale value when an asset is scrapped. If your finance team needs the asset off the books, that's a separate conversation with a separate system.

Acquisition data, in one place

Every asset carries its own acquisition record — PO number and date, purchase date, purchase cost, currency, supplier and reference, year of manufacture, and installation date. This matters more than it sounds like on a first read, because installation date is what the Repair/Review/Replace verdict ages the asset from, and purchase cost is what flows into your approval workflow.

• When a new asset is entered in Draft, it automatically raises an approval request carrying the purchase cost — so a ₹12 lakh CNC purchase doesn't get silently activated without sign-off.
• PO and supplier reference stay attached to the asset permanently, useful when a warranty claim needs the original paperwork three years later.
• Year of manufacture and installation date are distinct fields, which matters for imported machinery that sat in a bonded warehouse for eight months before commissioning.

Warranty and AMC, tracked the way they actually lapse

This is where most spreadsheets fail quietly. AssetAI computes coverage state live, with a fixed order of precedence: in warranty first, then under AMC, then expired, then no coverage recorded at all. So if a machine is inside both its OEM warranty and a vendor AMC, the system tells you it's in warranty — the more protective cover — rather than showing you two contradictory rows.

AMC contracts sit on the asset with their own detail: whether AMC applies, its cost, vendor, start and end dates, and a schedule — monthly, quarterly, half-yearly or yearly. Warranty length is derived in months, so you're not manually recalculating "installed March, 24-month warranty, expires when."

A daily sweep at 06:15 checks every asset's warranty and AMC expiry against a configurable window and raises a warning with a message that doesn't mince words: "Renew or plan for chargeable repairs." That window defaults to 30 days ahead, but you can tighten or loosen it per company — a 40-machine unit with a single AMC vendor might want 45 days' notice given how long renewal approvals take; a plant with dozens of overlapping contracts might prefer 15.

• Validation blocks nonsense dates — a warranty or AMC end date has to fall on or after its start date, so a typo doesn't create a contract that expired before it began.
• Coverage state is always computed fresh, not stored and forgotten, so it's accurate the day you look, not the day someone last updated a spreadsheet.

Whole-life cost and the Repair/Review/Replace call

The History screen on each asset holds the numbers that actually justify a capital decision: MTBF, MTTR, availability, year-to-date downtime, and cumulative work-order cost. Read together, these tell you whether a machine is a manageable nuisance or a slow-motion money pit — the kind of distinction that's easy to feel in your gut on the shop floor but hard to defend in a budget meeting without the data behind it.

AssetAI turns that data into a verdict — Repair, Review, or Replace — computed per asset. The logic ages the asset from its installation date, and once it crosses ten years, that adds directly to the replace score alongside the cost and reliability figures. It's a starting point for the conversation with your plant head, not a purchase order — but it's a far better starting point than "this machine feels old." For plants building out a broader reliability programme, this pairs naturally with the thinking behind TPM and with the OEE metrics most Indian manufacturing plants already track in some form.

What happens when an asset is retired or deleted

Decommissioned, Retired, and Scrapped are lifecycle stops, not deletions. The asset's BOM, skill requirements, and full history stay intact even after it leaves active service — useful when an auditor asks about a machine that was scrapped two years ago, or when a similar unit gets bought and you want its predecessor's failure history for reference.

If an asset record is deleted outright, it goes to Trash rather than disappearing — it can be restored, and nothing about its BOM, skills, or history is lost in the process. Every change to an asset, from a status flip to an AMC renewal, is written to an activity log, which matters when a plant runs multiple shifts, contract labour, and technicians who speak three different languages on the same floor — nobody has to reconstruct who changed what from memory.

Two things this module deliberately doesn't attempt: it has no capex-request workflow and no asset-transfer-between-plants process built in — if you run a multi-plant group needing that, worth confirming with us directly before assuming it's covered. And it doesn't model leased or rented equipment; the entire structure assumes assets your company owns outright.

Where this fits

Lifecycle Management doesn't replace your Asset Registry or your Criticality Assessment — it sits underneath them, holding the acquisition and coverage facts those modules assume are already correct. See how it connects to the rest of the platform on /features, check what plants like yours are running it for on /use-cases, or look at /industries for sector-specific detail. If you'd rather see it against your own asset list than read another page about it, book a demo and bring your worst AMC horror story.

From draft to scrapped, every asset moves through nine defined stages — Draft, Active, Idle, Under Maintenance, Breakdown, Standby, Decommissioned, Retired, Scrapped — and AssetAI treats each transition as a recorded event, not just a label change on a dashboard.

The Nine Stages, and Why Draft Isn't Just a Placeholder

Most CMMS tools let you flip an asset's status without asking why. AssetAI ties the Draft stage into the approval engine: when a new asset is created, its purchase cost is automatically carried into an approval request, so acquisition spend gets sign-off before the asset ever reaches Active. This closes a common gap in Indian plant operations, where equipment is often commissioned and running well before the paperwork catches up.

Later transitions matter just as much:

• Idle and Standby distinguish planned non-use from unplanned availability, which keeps utilisation reporting honest — a distinction that also feeds directly into OEE calculations.
• Breakdown and Under Maintenance separate diagnosis time from repair time, sharpening MTTR at the asset level.
• Decommissioned, Retired and Scrapped mark the end of active service, though AssetAI does not capture disposal or sale value at this point — these remain status flags, not accounting events.

What AssetAI Deliberately Leaves Out

A lifecycle module can try to be a fixed-asset ledger, a leasing system and a capex workflow all at once — and end up doing none of it well. AssetAI stays focused on maintenance and reliability data:

• No depreciation schedules or book-value tracking — that belongs in finance systems, not on the shop floor.
• No disposal or sale-value capture at Scrapped or Retired.
• No lease or rental asset handling.
• No capex request or inter-plant transfer workflow at present.

This keeps the asset record honest about what it's for: coverage, cost history, and condition — not accounting. Plants that need full fixed-asset accounting typically run that in parallel, with AssetAI feeding reliability and cost data across via the record itself, and can review the full scope on /features before deciding what to run where.

Validation and the Audit Trail

Lifecycle data is only useful if it can't be quietly overwritten. AssetAI enforces basic sequencing rules — a warranty end date can't precede its start, and the same applies to AMC contracts — so a mistyped date doesn't silently break the coverage-state calculation. Every change to an asset, from a stage transition to an edited PO reference, is activity-logged, and deleted assets go to Trash rather than disappearing outright: BOM, skills and history are preserved and the asset can be restored intact.

This matters more in Indian manufacturing than the paperwork suggests. Multi-shift plants with long-lived, often-refurbished equipment need a record that survives staff turnover and audits alike — a requirement several ISO standards reference directly, and one covered in more detail on our standards page. If you want to see how this plays out against your own asset register, book a demo.