Maintenance Management Software Requirements Checklist

Define the maintenance outcome before selecting CMMS features

Maintenance management software—often called a computerized maintenance management system or CMMS—can coordinate assets, requests, work orders, plans, inspections, labor, parts, vendors, downtime, costs, and evidence. The right boundary differs for a factory, vehicle fleet, property portfolio, hospital campus, hotel group, utility, school district, or field-service company. Begin with the physical operation and the failure the organization needs to reduce, not a generic feature grid.

Map the work from an observation or request through triage, planning, authorization, scheduling, safe access, execution, testing, return to service, cost capture, and follow-up. Include an urgent failure, repeat defect, missing part, absent technician, unsafe condition, wrong asset, network outage, vendor delay, incomplete inspection, and work that uncovers a larger problem. A system that supports only clean planned work will be abandoned during the events when dependable records matter most.

Choose measurable operating outcomes such as reducing overdue critical work, finding recurring failures, improving schedule compliance, preserving inspection evidence, controlling spare-part shortages, shortening service interruptions, or making asset history trustworthy. Avoid promising that software alone will eliminate downtime or create a maintenance culture. The outcome needs a baseline, definition, owner, data source, and review period.

Establish the asset-management boundary

Asset management is broader than maintenance software. ISO 55000:2024 provides vocabulary, principles, and an overview for managing value from assets across an organization. A CMMS may support parts of that system, but it does not decide investment strategy, risk appetite, safety obligations, lifecycle policy, or accountability. Document which decisions remain in finance, operations, engineering, safety, procurement, enterprise asset management, building automation, fleet, or other systems.

Name the source of truth for asset identity, accounting value, location, configuration, condition, maintenance history, documents, and operational state. These may not be the same system. If an enterprise asset register owns financial identity while the CMMS owns maintainable components and work history, preserve their identifiers and reconciliation rules rather than forcing both concerns into one record.

Define the first rollout boundary by site, asset class, team, or maintenance process. A focused release with reliable history is more useful than an organization-wide asset list that no one owns. Identify who can create, approve, merge, relocate, deactivate, and dispose of assets, and what evidence is required for each transition.

Model assets as related records, not one flat equipment list

Represent organization, site, campus, building, floor, room, area, system, asset, maintainable component, linear segment, vehicle, tool, meter, sensor, location, and storage position according to the operation. Separate functional location from physical asset. A pump can be replaced while the pumping function remains; a vehicle can move between depots; a portable instrument may support many assets.

Use stable internal identifiers and preserve manufacturer, serial, registration, barcode, tag, financial, legacy, and integration identifiers as typed aliases. Names and local labels change. Store make, model, class, criticality, commissioning, warranty, ownership, service responsibility, status, parent relationship, and permitted locations as structured data where they drive decisions.

Time-bound relationships. When a motor moves, a tenant changes, a fleet unit transfers, or a component is replaced, prior work must retain the location and configuration that existed when it occurred. Prevent circular hierarchies and unexplained duplicates. Support a governed merge or correction process that preserves references and audit history instead of deleting the less accurate record.

Build an asset registry people can maintain

Decide the minimum data required before an asset can receive work and the additional data required before it enters a preventive plan. Requiring every possible field on day one encourages fabricated values; allowing an empty name-only record produces unusable analysis. Apply completeness rules by asset class and lifecycle state.

Provide controlled imports, label generation, scanning, duplicate detection, photo and document capture, and field verification. Record the source, verifier, date, and confidence for imported or inferred attributes. A barcode scan proves an identifier was read; it does not prove the tag remains attached to the correct physical asset.

Assign data stewardship by site or asset family. Surface missing criticality, unknown location, expired warranty, absent responsible team, broken hierarchy, and unresolved duplicate identifiers as work queues. Asset data quality should have owners and correction paths, not just a dashboard percentage.

Define criticality with consequences and dependencies

Criticality should reflect consequences and operating context, not a subjective red-yellow-green label. Consider safety, environment, service continuity, product or customer impact, regulatory commitments, redundancy, repair time, part availability, cost, and dependencies. Record the method, inputs, reviewer, effective date, and rationale so priorities can be explained and revisited.

An asset with a standby unit may still be critical if both share power, cooling, control, or a scarce spare. A low-cost component can stop an expensive system. Represent upstream and downstream dependencies where they materially affect planning. Avoid building an unrestricted network graph unless people will own and use those relationships.

Use criticality to influence approval, response, planning depth, preventive strategy, inspection frequency, spares, escalation, and reporting. Do not let one score automatically override a newly observed hazard or operational judgment. Give authorized people a visible, reasoned override and review exceptional use.

Separate requests, notifications, defects, and work orders

A request reports a need; a defect describes an observed condition; a work order authorizes and records action. Keep them related but distinct. Several requests can refer to one defect, one defect can produce several work orders, and a work order can uncover additional defects. Collapsing everything into a ticket makes history and backlog unreliable.

For requests, capture requester, time, location, asset if known, observed condition, impact, urgency evidence, safety concern, media, contact preference, and access constraints. Let nontechnical requesters describe what they see without forcing them to diagnose a failure code. Triage should confirm the asset and condition, identify duplicates, set priority, route responsibility, and communicate what happens next.

Prevent closing a request merely because it became a work order. Define completion communication, requester verification where appropriate, and how a reopened concern relates to earlier work. Protect personal and sensitive location information so a requester can follow permitted status without seeing restricted maintenance or security details.

Design a controlled work-order lifecycle

Define states such as draft, requested, approved, planned, waiting, ready, scheduled, assigned, in progress, paused, completed, technically reviewed, returned to service, closed, cancelled, and reopened according to the organization. State names matter less than explicit entry criteria, authority, required evidence, and downstream effects.

Separate priority, target date, schedule, operational status, and work-order state. An urgent order can wait safely for an isolation window; a scheduled job can become blocked by a missing part; field work can be complete while a supervisor review remains open. One status field cannot represent all of these facts without losing meaning.

Record every consequential transition with actor, time, reason, prior state, and relevant evidence. Define cancellation, duplicate, no-fault-found, deferred, and abandoned behavior. Reopening should preserve the first completion and explain the new condition rather than rewriting the original history.

Standardize job plans without hiding actual work

A job plan can define scope, steps, estimated duration, skills, crew size, permits, hazards, isolation references, tools, parts, documents, measurements, acceptance criteria, and follow-up. Version plans and preserve the version used by each order. Changing the current plan must not alter historical work.

Allow planners to adapt a plan for the specific asset and condition through governed additions or exclusions. Record what differed and why. If technicians routinely bypass a step, investigate the plan or workflow instead of training people to enter false confirmations. A checkbox is evidence of an action only when the instruction, actor, time, and context are meaningful.

Separate work instructions from safety procedures, manufacturer documents, drawings, and permits. Link approved versions and make their authority clear. Do not copy safety-critical content into an uncontrolled text field that can drift from the organization’s approved procedure.

Generate preventive work from explicit rules

Preventive maintenance may be triggered by calendar, operating hours, distance, cycles, throughput, condition, season, inspection result, warranty, regulation, or a combination. Store trigger source, interval, tolerance, lead time, reset behavior, next due basis, and plan version. A schedule based on last completion differs from one anchored to a fixed calendar or meter threshold.

Define late, early, skipped, suspended, and catch-up behavior. Completing work early should not always pull the next due date forward; missing several cycles should not always generate several identical orders. When an asset is out of service, relocated, sold, under project work, or awaiting a part, the plan needs a controlled disposition rather than silent deletion.

For each generated order, retain the plan and trigger evidence. Reconcile missing or duplicate generation after outages and configuration changes. Test daylight-saving changes, leap dates, meter rollover, corrected readings, replaced components, and a plan activated after its theoretical due date.

Support predictive and condition-based maintenance responsibly

Condition monitoring can use inspection results, vibration, temperature, oil analysis, electrical measurements, control-system events, usage, or derived health indicators. Define the source, asset mapping, unit, sampling, calibration, quality, expected range, freshness, and retention. Preserve raw or authoritative references where a derived recommendation may be challenged.

A threshold or model output should usually create a reviewable alert or recommendation with evidence, not autonomously remove equipment from service. Identify the rule or model version, inputs, confidence or uncertainty where meaningful, reviewer action, and outcome. Monitor false positives, missed failures, sensor drift, and changes in operating regime.

Do not market ordinary thresholds as artificial intelligence. When statistical or machine-learning models are justified, define the decision they support, training and validation data, operating limits, human authority, monitoring, fallback, and retirement process. Maintenance history is often biased by what was recorded, which assets failed visibly, and which technicians used the system consistently.

Plan work by constraints, not just calendar slots

Scheduling should consider asset availability, production or occupancy windows, priority, due dates, dependencies, skills, certifications, crew, shifts, travel, permits, contractors, tools, parts, expected duration, and access. Show why work is not ready. A drag-and-drop calendar cannot resolve a missing isolation plan or an unavailable calibrated instrument.

Allow planners to compare scenarios and preserve the approved schedule baseline where useful. Distinguish assigned from acknowledged and scheduled from actually started. Notify affected operations and customers according to service impact, but avoid notification storms when planners adjust tentative work.

For route-based or distributed work, account for location, opening windows, travel, vehicle capacity, connectivity, and emergency insertions. Optimization should expose important assumptions and allow authorized overrides. A mathematically shorter route may violate customer commitments, skill pairing, part pickup, or safety constraints absent from map data.

Match people, skills, and authorization

Model team, trade, skill, qualification, certification, site authorization, asset class, work type, effective dates, shift, and supervisor where required. A job title does not prove current authorization for a particular procedure or hazardous task. Preserve the rule and evidence used when the system permits an assignment.

Limit exposure of personnel information. Planners may need to know that a person is qualified and available without seeing unrelated training, medical, disciplinary, or employment records. Define the owning workforce or learning system, synchronization frequency, outage behavior, and correction process.

Support crew assignments, handover, relief, vendor personnel, and work performed on behalf of another person without shared accounts. Record performer, recorder, reviewer, and approver separately when those roles differ. Emergency access should be time-bound, visible, justified, and reviewed.

Make mobile field work resilient

Technicians need asset identification, request context, instructions, hazards, permits, history, parts, tools, contacts, measurements, notes, media, and next actions without navigating a desktop application on a small screen. Design for gloves, glare, noise, weather, shared vehicles, camera permissions, scanning, interrupted attention, and limited bandwidth.

Define which tasks must continue offline. Cache only authorized assignments and necessary reference data; protect local information; show freshness and synchronization state; queue durable events; and prevent a tap from being interpreted as success before the server confirms it. Handle device restart, low storage, clock drift, expired credentials, duplicate submission, and an order changed by the planner while offline.

Conflicts need business rules. A technician can record work against the earlier plan while a supervisor changes priority; two people can consume the same scarce part; an asset can be moved while an inspection is pending. Preserve both events, explain the conflict, and route correction instead of silently selecting the newest timestamp.

Capture readings, inspections, and evidence precisely

For each measurement, define name, unit, source, method, expected type, range, precision, asset point, plan version, and behavior outside limits. Keep observed value, normalized value, evaluation, and specification distinct. Never discard an out-of-range reading because it appears inconvenient; preserve it and route verification or escalation.

Inspection items may be pass/fail, condition scale, numeric reading, choice, count, text, image, signature, or attachment. Define when not-applicable is permitted and require a reason. A photograph can support evidence but rarely proves the entire condition; record who captured it, when, against which asset and step, and how access is controlled.

Use conditional follow-up carefully. A failed check can create a defect, hold, escalation, or additional work according to approved policy. Prevent loops and duplicate orders when an offline device retries. Keep the original result even after retest or correction.

Keep safety authority outside an ordinary completion button

Maintenance software can coordinate permits, hazards, isolation references, responsible roles, verification evidence, and work status, but it should not replace physical energy-isolation controls or qualified safety procedures. In the United States, OSHA 29 CFR 1910.147 establishes requirements for controlling hazardous energy during covered servicing and maintenance. Applicability and obligations depend on the work and jurisdiction; qualified safety and legal professionals must define the organization’s program.

Model authorized and affected roles, procedure version, asset and energy sources, locks or tags where recorded, group responsibility, shift transfer, verification, and release evidence according to the approved program. Do not let a remote software action imply that stored energy is physically controlled. An electronic permit, sensor state, or work-order status is not itself an energy-isolating device.

Separate maintenance completion, safety release, quality acceptance, and operational return to service. These may require different people and evidence. Test a shift change, group work, a worker leaving unexpectedly, a failed verification, a changed scope, lost connectivity, and an asset that remains unsafe after the repair is technically complete.

Control spare parts and repairable components

Represent item, manufacturer part, approved substitute, stockkeeping unit, lot or serial where needed, unit, storeroom, bin, on-hand, reserved, issued, returned, repaired, quarantined, obsolete, and reorder policy. Keep financial inventory ownership and maintenance availability aligned through explicit integration or an agreed source of truth.

Reserve parts against planned work without making all stock unavailable indefinitely. Record issue, return, consumption, transfer, adjustment, and failure with actor, time, asset, work order, quantity, and unit. A retry must not issue the same part twice. Handle partial packages, core returns, repairable spares, kits, consignment, vendor-managed stock, and emergency withdrawal.

For substitutions, consider fit, form, function, configuration, safety, warranty, quality, and engineering approval—not just similar text. Preserve which part was actually installed and the component history it replaced. Use failure and consumption history to inform stocking, while recognizing that incomplete work-order records can distort demand.

Coordinate purchasing and vendor work

Define the boundary between maintenance demand and procurement. A CMMS may create a requisition or service request while an enterprise system owns suppliers, purchase orders, receipts, invoices, tax, and financial controls. Exchange stable identifiers and statuses; do not allow each system to invent a separate order lifecycle without reconciliation.

For vendors, record organization, service category, qualifications, insurance or contract evidence where authorized, sites, contacts, access requirements, rate or agreement reference, work assignment, deliverables, communication, and performance. Limit vendors to their work, permitted assets, necessary documents, and approved time window.

Support estimates, approval limits, arrival, check-in, escort, work evidence, acceptance, dispute, and invoice matching without exposing unrelated site or personnel information. Define what happens when the vendor completes work outside the portal, sends a revised invoice, replaces personnel, or needs emergency access while an integration is unavailable.

Integrate operational and enterprise systems with reconciliation

Inventory ERP, finance, procurement, inventory, HR, learning, identity, building automation, fleet telematics, geographic information, production, condition monitoring, document, and analytics interfaces. For each, define owner, identifier, direction, timing, authentication, schema, units, statuses, idempotency, retries, correction, and operational support.

Treat every consequential exchange as a business transaction. A work-order completion can update asset status, inventory, cost, and operational availability. Preserve the request, response, correlation identifier, provider status, and reconciliation outcome. A timeout must not cause duplicate consumption or an asset to be released differently in two systems.

Provide exception queues for unknown assets, invalid accounts, closed periods, rejected quantities, expired qualifications, unmapped failure codes, unavailable providers, and conflicting statuses. Assign owners and escalation. Integration health is not merely HTTP uptime; it is whether intended business events reached the correct system once and were accepted with the expected meaning.

Protect operational technology connections

A CMMS may consume meter readings, alarms, runtime, condition data, or equipment state from operational technology. It may also send approved requests or configuration to intermediary systems. Document trust zones, data flows, protocols, remote access, service accounts, gateways, dependencies, and the physical consequence of an incorrect or delayed exchange.

NIST SP 800-82 Revision 3 addresses OT security while considering performance, reliability, and safety requirements. Apply controls with operations, automation, safety, and security owners. Segment networks, minimize pathways, constrain service identities, use controlled remote access, monitor appropriately, manage change, and plan recovery without applying an IT pattern that disrupts a legacy or real-time system.

An ordinary web application should not directly become a safety or deterministic control system because a device exposes an interface. For any permitted command, define allowlist, asset mapping, range, sequence, approval, timeout, acknowledgment, independent safeguard, and safe failure. Test stale, duplicated, delayed, reordered, and unauthorized commands.

Define downtime and return to service consistently

Separate asset condition, operational availability, maintenance state, service impact, and observed equipment signal. An asset can be available but not scheduled, repaired but awaiting safety release, operating with a limitation, or unavailable because a dependent utility failed. One green/red field cannot represent this honestly.

Record downtime start and end, detection, source, asset, affected service, reason, planned or unplanned classification, work relationship, correction, and lost-capacity method where used. Avoid forcing a final failure cause during the initial response. Support unknown followed by accountable classification.

Return to service should identify required tests, results, outstanding limitations, temporary repairs, permits, safety release, quality or engineering acceptance, operational handoff, and monitoring. Closing the work order must not automatically energize equipment or tell customers that service is restored unless authorized policy makes those states equivalent.

Build failure history that supports learning

Separate observed symptom, failed function, failure mode, affected component, mechanism, cause hypothesis, confirmed cause, remedy, and follow-up. Technicians should be able to record what they know without inventing a root cause to close an order. Use controlled codes with concise narrative and evidence; codes alone remove context, while unrestricted prose prevents reliable analysis.

Link repeat events without merging independent work. Support a formal investigation or corrective action when consequence or recurrence justifies it. Preserve evidence, contributors, decisions, actions, owners, due dates, effectiveness checks, and closure authority. Do not label every repair as root-cause analysis.

Analyze history with data completeness visible. A frequently failing asset may simply have better reporting; a vendor may appear faster because travel time is omitted; planned work may look effective because late tasks were cancelled. Show definitions, filters, missing data, and drill-down to source records.

Define maintenance metrics before building dashboards

Backlog, schedule compliance, preventive completion, mean time between failures, mean time to repair, availability, wrench time, repeat work, planned-to-unplanned ratio, maintenance cost, stockout, and downtime all require local definitions. State numerator, denominator, event boundaries, exclusions, time zone, asset population, owner, and definition version.

Do not compare teams or sites until their work-order discipline, asset boundary, calendars, and downtime definitions are compatible. Metrics can create harmful incentives: closing incomplete work, splitting orders, delaying failure start, or classifying corrective work as preventive. Pair measures and review behavior with practitioners.

Every dashboard should show freshness, incomplete records, late integrations, manual corrections, and whether values are operational estimates or reviewed reports. Provide drill-down from a number to the work, events, and exclusions that produced it. A polished trend without traceable definitions is not decision support.

Apply authorization, audit, privacy, and secure development

Define access by organization, site, area, asset class, team, assignment, work type, vendor, and action. Viewing asset status is different from changing criticality, approving work, editing a safety reference, issuing parts, changing a preventive plan, entering work for another person, releasing an asset, or exporting history.

Enforce authorization on trusted services for APIs, search, reports, background jobs, imports, exports, mobile synchronization, vendor portals, and support tools. Record consequential asset, plan, work, permit reference, part, vendor, permission, integration, and correction events without logging secrets or unnecessary sensitive content.

Use separated environments, managed secrets, reviewed deployment, dependency controls, backups, restore tests, monitoring, vulnerability handling, and incident procedures. The NIST Secure Software Development Framework provides a common language for secure development outcomes. Tailor implementation to risk, but do not postpone basic access control, recovery, or update ownership until after launch.

Make the system accessible in office and field contexts

Maintenance users may work with keyboards, touchscreens, phones, scanners, gloves, low vision, color-vision differences, limited movement, noisy environments, or temporary injury. Design status beyond color, visible focus, clear labels, large targets, readable zoom, meaningful errors, predictable navigation, and alternatives to drag-only interactions.

WCAG 2.2 offers testable, technology-independent success criteria for web content. Define the intended conformance target, supported devices and browsers, assistive-technology testing, and responsible content owners. Automated scanning can find some issues but cannot confirm that a technician can understand an isolation warning, recover an offline conflict, or complete an inspection in a meaningful sequence.

Accessibility also affects generated PDFs, attached manuals, photos, video, maps, signatures, and third-party components. Record limitations and provide equivalent workflows where possible. Legal obligations vary, but an inclusive product should be an explicit acceptance concern rather than a late cosmetic audit.

Migrate active work and history deliberately

Profile asset registers, hierarchies, locations, preventive plans, open requests, work orders, readings, parts, vendors, documents, meters, failure codes, labor, costs, and integrations. Identify duplicate assets, invalid identifiers, obsolete records, missing units, impossible dates, broken parent relationships, and spreadsheets maintained outside the nominal source.

Choose what becomes active structured data, what remains in a searchable archive, what is summarized, and what requires correction before migration. Preserve source identifiers and provenance. Rehearse imports and reconcile counts by site, asset class, status, plan, open work, inventory, and representative history.

Plan coexistence and cutover. Prevent two systems from generating the same preventive orders or issuing the same parts. Define a freeze, delta migration, rollback, offline procedure, and ownership for work crossing the boundary. Verify permissions, mobile behavior, labels, scans, reports, integrations, backups, and return-to-service workflows before broad rollout.

Preserve ownership and operating continuity

The organization should control production accounts, domains, repositories, data stores, provider billing, and critical credentials wherever practical. Document setup, configuration, environments, deployment, monitoring, integrations, backup, restore, data export, mobile release, and incident response so another qualified team can operate the system.

Define support hours, severity, response, escalation, maintenance windows, dependency updates, provider changes, device support, storage growth, certificate renewal, and recovery targets. Budget hosting, database, file storage, maps, messages, identity, monitoring, scanning, analytics, and vendor APIs separately from development.

Require authorized, usable exports of assets, plans, work, readings, parts, documents, audit history, and configuration. Test a representative export and restore before accepting portability claims. Ownership of source code is insufficient when the organization cannot recover data or reproduce the service.

Compare buy, configure, integrate, and custom development

An established CMMS can be the best choice when the operation fits its model and the product provides acceptable security, mobile behavior, support, export, and integrations. Configuration may handle forms, states, plans, roles, and reports without custom code. Integration can keep specialist asset or work management while connecting the organization’s distinctive operational flow.

Custom development is more defensible when the workflow, offline environment, asset relationships, authorization, customer experience, or integration behavior is materially distinctive and valuable. It also creates responsibility for lifecycle maintenance. Compare multi-year licenses, implementation, migration, configuration, integration, customization, training, internal time, support, switching cost, and operational risk—not only first-year price.

Demonstrate difficult scenarios with representative data. Check export, API limits, mobile offline behavior, permission boundaries, audit history, accessibility, provider roadmap, and contract terms. A long feature list does not prove the system can preserve authority and evidence through your actual exceptions.

Use this checklist before approving maintenance software

Confirm that the proposal defines the operating outcome and system boundary; models asset hierarchy and history; assigns data ownership; records criticality; separates requests, defects, and work; controls lifecycle and plans; generates preventive work correctly; governs condition recommendations; schedules by constraints; verifies skills; works offline; preserves readings; respects safety authority; controls parts and vendors; reconciles integrations; protects OT; distinguishes downtime and release; supports failure learning; defines metrics; enforces access; meets accessibility needs; migrates safely; and preserves technical ownership.

Then rehearse a demanding event: a technician reports a vibration alarm against the wrong duplicate asset, a preventive order is already overdue, the required part is reserved elsewhere, a contractor’s qualification expired, the site network fails, the job expands into group hazardous-energy control across a shift change, a meter reading syncs twice, the repair passes technically but remains under safety review, the ERP posting times out, and operations requests an early restart. A strong design explains identity, state, authority, evidence, physical safety boundary, offline behavior, retry, reconciliation, and return to service at every step.

For the adjacent production boundary, review the manufacturing execution software requirements checklist. The custom software development service explains a discovery-to-delivery approach. Share your sites, asset classes, maintenance strategies, work volume, safety processes, parts, mobile environment, integrations, migration sources, and current failures through the project questionnaire, or use quick contact for a focused question.

Authoritative references

• ISO 55000:2024 Asset management — Vocabulary, overview and principles
• U.S. Department of Energy Operations & Maintenance Best Practices Guide
• OSHA 29 CFR 1910.147 Control of hazardous energy
• NIST SP 800-82 Revision 3 Guide to Operational Technology Security
• NIST Secure Software Development Framework
• W3C Web Content Accessibility Guidelines 2.2

Related software planning guides

• Manufacturing Production Tracking Implementation Roadmap
• Manufacturing Production Tracking Software Cost Guide
• Textile and Apparel Production Traceability Software Requirements