Statutory Inspections Under the Factories Act: Asset Records That Satisfy the Inspector

Status is a control, not a progress label

A work order status should answer three questions: what decision has been made, who owns the next action, and which fields or transactions are now allowed. If it only changes the colour of a dashboard tile, it is decoration.

There is no universal nine-status standard. Products use different names and combine different stages. IBM Maximo, for example, documents Waiting for Approval, Approved, Waiting to be Scheduled, Waiting for Materials, Waiting for Plant Conditions, In Progress, Completed, Closed and Cancelled. SAP exposes milestones including Created, Released, Main Work Completed, Technically Completed and Business Completed. The useful design is therefore not a copy of one vendor's codes. It is a small operational model with explicit entry and exit rules.

The nine statuses below are a practical canonical lifecycle. Map the native codes in your CMMS or EAM to them for cross-site reporting; do not force every site to rename its system.

The nine-status lifecycle

Status	What it means	Minimum evidence before moving on	Owner of the next move
1. Draft	A record exists, but has not entered the controlled queue	Asset or location, short description, source	Requester or planner
2. Requested	The need is submitted and awaiting triage	Reported time, requester, symptom, operational impact	Supervisor or helpdesk
3. Approved	The work is valid, in scope and assigned a priority	Priority rationale, work type, responsibility, target date	Planner
4. Planned	The job is ready in method and resources	Job steps, craft, estimated hours, parts, permits, isolations	Scheduler
5. Scheduled	A crew and execution window are committed	Scheduled start, assigned labour, material availability	Supervisor or technician
6. In Progress	Physical work has started	Actual start, attending technician, initial condition	Technician
7. On Hold	Work has stopped for a named constraint	Hold reason, responsible party, next review date	Named constraint owner
8. Completed	Physical work is finished and technical history submitted	Actual labour, parts, readings, action, failure data, downtime	Supervisor or reliability reviewer
9. Closed	Technical and commercial checks are complete; the record is history	Completion review, follow-on work, cost and reservation reconciliation	Authorised closer

Cancelled is a terminal outcome, not a stage. It should be reachable only before physical work starts, require a reason code, and remain reportable. Rejected and duplicate requests are also outcomes of triage. Treating them as ordinary lifecycle stages distorts cycle-time reporting because they never had an execution path.

1–3: Draft, Requested and Approved

Draft is useful where a mobile user may save an incomplete record or an integration creates a shell before enrichment. It should not count in backlog, SLA response or demand reporting. Requested is the first controlled state: the clock starts, the record cannot quietly disappear, and triage has an owner.

Approval is not permission to start an unprepared job. It means the request is genuine, in scope and prioritised against a defined consequence matrix. The approval gate should resolve duplicates, warranty responsibility, landlord-versus-tenant scope and whether the record is actually maintenance. A request for a new installation may be a project; a comfort complaint may be an operating adjustment.

Do not ask requesters to diagnose failure modes. They can reliably describe symptoms: leaking, noisy, stopped, hot, intermittent. Diagnosis belongs after inspection. Forcing a failure code at request time produces confident fiction that survives into history.

4–5: Planned and Scheduled are different

Planned means ready to execute: the scope is understood, method is safe, skills and duration are estimated, parts are identified, and access, permits and isolations are known. Scheduled means that ready work has been placed into a dated labour window.

Combining the two hides the constraint. A job can be fully planned but unscheduled because capacity is unavailable. It can also appear on next Tuesday's schedule while lacking a bearing, permit or isolation plan. Calling both states “Assigned” makes schedule compliance impossible to interpret.

Material availability belongs as a condition or hold reason rather than an uncontrolled free-text note. IBM Maximo makes the distinction explicit with Waiting for Materials and Waiting for Plant Conditions. Whether these are separate statuses or reason codes under On Hold depends on reporting needs, but the cause must be structured.

6: In Progress — the first place data quality dies

The transition to In Progress should be triggered by arrival at the asset or the first physical task, not by dispatch and not by a supervisor bulk-starting the morning's list. It establishes the actual start time and identifies who attended.

This is where the first data loss occurs because consumption happens faster than administration. A technician takes another filter from the van, receives help from an electrician for forty minutes, changes the repair method and observes that the unit was already unavailable. If labour, materials, readings and downtime are deferred until the end of the shift, detail is reconstructed from memory or omitted.

The answer is not a longer completion form. Capture actuals at the point they occur:

• start, pause and resume timestamps from the mobile job;
• parts issued or scanned against the work order, including van stock;
• meter readings with units and acceptable ranges;
• photos tied to a defined step, not dumped into a general attachment list;
• additional labour booked by the person who supplied it;
• follow-on defects raised as linked work, rather than buried in notes.

A work order left In Progress overnight must mean one of two things: work genuinely continues, or the record is wrong. If access, materials, production or a permit blocks the job, move it to On Hold and name the constraint.

7: On Hold needs a clock and an owner

On Hold is usually where overdue work goes to become invisible. A useful hold state requires three fields: a reason code, the person or team responsible for clearing it, and a review date. “Pending” and “Other” are not reason codes.

Separate clock treatment from operational truth. An SLA may legitimately pause for denied access or customer authorisation while continuing for a missing internal spare. That is a contractual calculation based on the hold reason; it should not change the factual timestamps. Never overwrite elapsed time to make compliance look better.

Report hold ageing by reason and owner. A queue dominated by Waiting for Material is a planning or supply problem. One dominated by Access Required is a scheduling and stakeholder problem. A single On Hold count diagnoses neither.

8: Completed — the second place data quality dies

Completed should mean the physical task is finished and the technical record is ready for review. It is not the same as Closed. IBM describes Completed as the point at which physical work is finished, while Closed finalises the order, removes unused inventory reservations and turns it into history. SAP similarly distinguishes technical completion from business completion.

The second—and larger—data loss happens here. The technician is under pressure to reach the next job, so the close-out becomes “checked and fixed”. That sentence cannot support reliability analysis, warranty recovery, repeat-failure investigation, spares forecasting or maintenance strategy.

For corrective work, require structured answers to four different questions:

1. What was observed? The symptom or condition as found.
2. What failed? The maintainable item or component.
3. How did it fail? The failure mode: leak, seizure, open circuit, drift, blockage.
4. Why did it fail? The cause, where evidence supports one. “Unknown” is more honest than a guessed cause.

Also capture action taken, actual labour and materials, service-restored time, downtime, readings after work, and whether follow-on work is required. ISO 14224:2016 provides the underlying discipline: equipment, failure and maintenance data, including cause, consequence, action, resources used and downtime, in a standardised format. It is industry-specific, but the data-quality principle travels well.

Do not make every field mandatory for every job. A statutory inspection, lubrication task and breakdown repair need different completion schemas. Conditional forms by work type improve completeness and reduce meaningless values entered only to satisfy validation.

9: Closed is a review gate

Closure is the point of no casual editing. An authorised reviewer checks that the correct asset was used, completion codes are coherent, follow-on defects have linked orders, unused reservations are released, service entries or contractor costs are reconciled, and any required customer acceptance is attached.

This should be a risk-based control. Automatically close low-risk routine work that passes validation. Sample completed work by technician and work type. Route safety-critical, statutory, high-cost and repeat-failure jobs for explicit review. Making a supervisor manually close every filter change creates a rubber stamp; reviewing none exports bad data directly into the asset history.

If history must be corrected later, keep an audit trail showing the original value, revised value, reason, person and timestamp. Silent edits destroy trust in every reliability metric downstream.

The controls that make the lifecycle auditable

Transition	Control that matters
Draft → Requested	Required identification and reported timestamp
Requested → Approved	Scope, duplicate and priority check
Approved → Planned	Job plan and resource readiness
Planned → Scheduled	Committed labour window and constraint check
Scheduled → In Progress	Actual start by the attending worker
In Progress → On Hold	Structured constraint, owner and review date
In Progress → Completed	Work-type-specific technical close-out
Completed → Closed	Risk-based quality and cost review

Measure transition quality, not just the number of jobs in each status. Useful controls include the share of jobs started before approval, scheduled without a complete plan, completed with no actual labour or parts, closed with free-text-only failure data, held past their review date, and reopened within 30 days.

Cycle time should be split by state. One average from request to close cannot tell whether delay sits in approval, planning, scheduling, execution, constraint clearance or review.

A practical 30-day move from WhatsApp to governed maintenance

Do not begin by banning the existing group. That removes the channel technicians trust before the replacement has proved it can carry the work. Begin by observing one week of real messages. Classify breakdown calls, inspection findings, parts requests, production follow-ups, approvals, shift handovers and general discussion. Identify which messages should have created a work order and which should remain conversation.

In week one, establish the asset and location list for one pilot area. Keep selection short enough for a technician to use on a phone. Add QR labels where they reduce search time. Define a small priority model with examples that production and maintenance interpret consistently. Decide who receives a request, who may approve urgent work and who owns unassigned items at each shift change.

In week two, configure the mobile request and work-order flow. The minimum request needs the asset or location, observed problem, time, reporter and optional photo or voice note. Planning fields can follow after triage. Technicians should see assigned work, safety requirements, known history and required parts without opening several screens. Where connectivity is unreliable, test offline capture and later synchronisation in the actual plant.

In week three, route notifications back to the familiar channel without making chat the record. A new critical request can generate a link in the maintenance group. Status changes can notify the requester or production owner. Replies that contain important evidence must be added to the work order rather than left inside the conversation. Supervisors should review requests with no asset, owner or response before the end of each shift.

In week four, compare the governed flow with the original message traffic. Measure missed requests, duplicate calls, time to acknowledgement, time waiting for approval or parts, completion evidence, repeat defects and the number of messages staff still use to discover status. Interview technicians and production users about friction. Remove unnecessary fields before adding more scope.

After the pilot, publish one simple rule: chat may alert people, but the work order authorises, tracks and closes maintenance. Expand area by area, retain champions on each shift and monitor whether contractors receive an equally usable route. Adoption is proven when people check the system for status instead of asking the group who is working on the fault.

FAQ

Must a work order have exactly nine statuses? No. Nine is a useful canonical reporting model, not a standard. A simple operation may combine Draft with Requested or Planned with Scheduled. Add a status only when it represents a real decision, changes ownership or controls what can happen next.

Should Waiting for Parts be its own status? Use a distinct status where material delay is operationally significant and someone manages that queue. Otherwise use On Hold with a mandatory reason. The important point is structured, owned and aged constraint data.

When should the SLA stop? According to the contract and the hold reason. Preserve factual timestamps, then calculate paused and unpaused duration separately. Do not let users manually change elapsed time.

Who should close the work order? The technician should submit technical completion. Closure can be automated for validated low-risk work and assigned to a supervisor, planner or contract administrator for exceptions and higher-risk work.

Where a system helps

Good workflow makes the right action easier at the moment it matters: mobile actuals during execution, a completion form that changes by work type, structured hold ownership, and a review queue driven by risk rather than volume. The result is not merely a cleaner dashboard. It is asset history reliable enough to change a PPM interval, challenge a repeat contractor failure or defend a replacement decision. See eAMS for asset management.

Related reading: What Is a CMMS? (KB-129) and What Is Planned Preventive Maintenance? (KB-130).

Sources

• IBM Maximo Manage, Work order statuses
• SAP S/4HANA, Maintenance Order Status
• ISO 14224:2016, Collection and exchange of reliability and maintenance data for equipment