ProAlert CMMS Executive Overview

Executive Summary

ProAlert CMMS is a full computerized maintenance management system - work orders, preventive maintenance, parts inventory, purchasing, inspections, and reliability analytics - built inside the same platform that already watches the production floor in real time. It is licensed as a module of ProAlert Core and shares one database, one asset registry, one login, and one mobile app with the andon and OEE system your operators already use.

The one-sentence pitch

Most plants bolt a standalone CMMS onto their operation and re-key downtime into it after the fact. ProAlert's CMMS is fed by the downtime itself - the moment an operator pulls the andon cord, the maintenance record has already started.

For a Maintenance Department this means:

No transcription layer

Andon calls convert to work orders with the failure mode, asset, and downtime clock already attached
Downtime hours on failure records are computed from the call itself, not estimated later
Temporary fixes automatically carry a follow-up work order, tracked until the permanent repair is verified

Decisions from real data

MTBF / MTTR, downtime cost, and repeat-failure detection run on measured events, not hand-entered logs
Repair-vs-replace and asset cost trending use the same cost data that the production side already reports against
Every work order execution is captured step by step, building the evidence base for template improvement

Less time managing the system

Role templates bundle a job's permissions once - adding a technician is one assignment, not a permission tree built from scratch for every user
Work orders that close within normal time and expected parts route straight to Closed; a supervisor reviews the exceptions, not the whole queue
Reorder points can auto-issue a purchase order inside a configured dollar cap, or simply queue it for a buyer to approve

The Maintenance Loop

Everything in the CMMS hangs off one closed loop. Work is detected (or scheduled), dispatched, executed against a controlled procedure, closed with accountability, analyzed for reliability, and fed back into better procedures and better plans.

Detect Andon call, inspection, meter, PM schedule

Dispatch Work order, priority, assignment, approval

Execute Tasks, parts, labor, photos, timers

Close Signature, notes, auto-logged hours

Analyze MTBF, cost, repeat failures, RCA

Improve Template revisions, PM tuning, kaizen

Why the loop closes here and not in a binder

Because detection, execution, and analysis live in one system, the Improve step has evidence: which steps crews skip and why, which steps they add mid-job, how long each step really takes, and which assets fail repeatedly. Standalone CMMS packages ask supervisors to reconstruct this; ProAlert records it as it happens.

Two Roads Into the Loop

Work enters this loop by two different roads, and the CMMS treats both as first-class - there is no separate "real" system with a PM module attached as an afterthought.

Reactive: Downtime-Triggered

Something breaks and an operator raises an andon call. The call is the Detect step - it carries the asset, the failure mode, and a downtime clock that is already running. Dispatch is immediate, and the work order inherits everything the call captured.

Claimed by a responder or assigned to a responding team
Downtime hours are measured by the call, not estimated after the fact
Feeds MTBF / MTTR and repeat-failure detection directly

Preventive: Schedule-Triggered

Time or meter usage crosses a threshold and a PM work order generates automatically - Detect happens overnight, with no one watching for it. Its task list is pulled from a reusable template instead of being typed out again, and the work order is assigned to a crew.

Assignable to an individual or a team; within a team work order, each task can be claimed and signed off by a different technician
Who closed which task is visible afterward, so the work is distributed rather than shouldered by whoever grabbed the work order first
Feeds the same PM compliance and asset cost history as reactive work

Same loop, two on-ramps

Dispatch, Execute, Close, Analyze, and Improve run identically regardless of how the work entered the loop. A PM task and a downtime repair post to the same failure and cost history, so reliability analytics never have to reconcile "the reactive system" against "the PM system" - there is only one system.

A Day in Maintenance

The fastest way to understand the package is to follow one shift from the Maintenance Department's chair. Because many teams already run a standalone CMMS today, each step also notes what the same moment typically looks like there - the workflows translate directly; what changes is where the data originates.

1

07:00 - Start at the board. The CMMS Dashboard and Kanban board show open work orders by status and priority; the Planning Board shows what is scheduled against which crew. Today's PM work orders were generated automatically overnight from time-based schedules and meter readings.

In a typical standalone CMMS: the morning starts the same way - a work order list and a request queue. The difference is what feeds the board: in ProAlert it is the same system that watched every line overnight, so the board already knows about the 2 a.m. stoppage without anyone submitting a request.

2

08:14 - An andon call becomes a work order. An operator raises a downtime call on Line 2. Maintenance responds through the same system, and on closure the call converts to a corrective work order carrying the asset, the failure mode, the cause, and the measured downtime. Nothing is re-typed. If the tech applied a temporary fix, a follow-up work order is created automatically and tracked until the permanent repair lands.

In a typical standalone CMMS: the operator or supervisor submits a work request through the portal and maintenance triages it into a work order; the downtime duration is whatever gets keyed in afterward. In ProAlert the call is the request - and the downtime clock is measured, not remembered.

3

09:30 - Execution on the tablet. The assigned tech opens the work order on the rugged tablet: step-by-step tasks from the pinned procedure template, reference photos and videos on each step, required PPE flagged, safety-critical steps badged. They start the timer, complete steps, attach photos of the finished repair, log parts straight from the storeroom catalog, and skip a step that does not apply - with a mandatory reason the system records for later analysis. A step the procedure missed? They add it on the spot, and that addition is captured too.

In a typical standalone CMMS: technicians work from task lists and attached SOPs in the mobile app, but the mobile experience is inconsistent about what it renders - some fields show, some don't, so crews fall back to a desktop or a coworker to confirm status. ProAlert's execution surface is the same native app operators already carry for andon, not a separate mobile layer with its own quirks. It also adds version-controlled procedures with per-step reference media, step-level timing, and captured deviations - the raw material for improving the procedure itself.

4

13:45 - Parts pull the supply chain. The parts used decrement stock in the storeroom. Inventory that crosses its reorder point feeds the parts forecast; the buyer sees it on the Purchasing Dashboard, floats an RFQ to vendors or cuts a purchase order through the configured approval chain, and receipts land back into stock with full transaction history. Barcode labels print on demand for the bin location and, where practical, for the part itself.

In a typical standalone CMMS: parts, purchasing, and vendors live there too - this workflow translates nearly one-for-one. The gain is that consumption ties back to the same asset and cost model that production already reports against. A reorder point can also be configured to auto-issue the PO to a preferred vendor inside a dollar cap, instead of waiting for someone to notice stock is low.

5

15:20 - Close with accountability. The work order closes with completion notes, adjustable labor hours pre-filled from the timer, and a signature. Labor cost books against the asset automatically using craft and labor-type rates.

In a typical standalone CMMS: close-out is familiar. What changes is that labor hours arrive pre-filled from a server-tracked work timer instead of being estimated at the end of the day.

6

16:00 - The numbers move. The failure record updates MTBF and MTTR for the asset. The downtime cost model prices the morning's event. If this is the third bearing failure this quarter, repeat-failure detection flags it and an RCA or FMEA can be opened from the same screen - or the issue is promoted into AFMDS as an owned problem with an escalation clock. Because the technician's actions were already captured step by step during execution, that root-cause paperwork starts largely pre-populated instead of being reconstructed from memory days later.

In a typical standalone CMMS: reliability metrics are only as good as the downtime and failure data someone entered, and an extended-downtime write-up is built after the fact from whatever the tech remembers. In ProAlert, MTBF / MTTR and downtime cost run on the measured event stream, repeat failures escalate into the plant's daily management loop automatically, and the write-up is mostly already there.

7

16:45 - The exception queue, not the inbox. A plant running dozens of work orders a week does not need every one of them read top to bottom to close it out. Work orders that finished in normal time with expected parts usage have already routed to Closed on their own. What lands in the supervisor's queue is the short list: a repair that ran well outside its normal duration, parts consumed that don't match the failure mode, or a third failure on the same asset this quarter - with an optional AI-generated summary by work cell to catch up on at a glance.

In a typical standalone CMMS: a supervisor closing out eighty to a hundred work orders a week is, in practice, rubber-stamping most of them just to keep the queue moving - time that doesn't go toward the handful that actually need a second look. ProAlert's queue is built to manage the exception, not re-review the routine.

8

17:00 - Before clocking out, a personal shift summary. A tech pulls up everything they closed that shift - work orders, time spent on each, parts used - and shares it, for example by email, without retyping anything. It is a read of the same execution data already logged against each work order, not a new report someone has to compile by hand. A supervisor can drill into the same data by person, crew, or date range to see response times and workload without waiting on anyone's write-up.

In a typical standalone CMMS: nothing pulls this together automatically, so a tech (or a supervisor, on their behalf) writes it up separately, restating information the system already has. In ProAlert, the summary is just a read of the day's own records.

Capability Map

The CMMS license activates a family of modules that share the platform's asset registry, user roles, and localization (English, German, Spanish, French).

Area	What the Maintenance Department gets
Work Orders	Full lifecycle: request, configurable approval chains, priority and type classification, assignment, scheduling, execution, signature close-out. Kanban board and Planning Board views. Multi-asset work orders for jobs that span equipment. Comments, photo/video capture, and a continuous work timer with pause/resume across web and mobile. Work orders can be assigned to an individual or to a team / craft group, so response-time and workload metrics roll up by person or by crew. Within a team work order, individual tasks can be claimed and signed off by different technicians, so a PM crew's contribution is visible task by task, not just at the work-order level.
Exception-Based Review	Work orders that close within normal time and expected parts usage route straight to Closed. Duration outliers, unexpected parts, and repeat failures surface for supervisor review, with optional AI-generated summary reports by work cell.
Procedure Templates	Versioned, approval-controlled work procedures with ordered steps, instructions, reference media, PPE call-outs, and step classification (safety-critical, quality-significant). Work orders pin the exact version in force, so history is always interpretable.
Preventive Maintenance	Time-based and usage-based schedules (meters and meter readings), automatic daily work-order generation, task and parts kitting per schedule.
Assets & Locations	ISO 14224-aligned asset register with criticality ratings, financials, component structure, and barcode identity; region / site / location tree; asset transfers with a full audit trail - serial number, usage hours where the asset is metered, and current holder - across locations and sites; tool crib checkout.
Parts & Inventory	Parts catalog with categories and supplier links, storeroom stock with full transaction ledger, demand forecasting with reorder points and preferred-vendor selection, and ZPL barcode label printing for parts, bins, and storerooms - printed on demand to the nearest configured printer.
Purchasing	RFQ-to-award workflow with vendor quotes, purchase orders with configurable approval levels - including a dollar-cap approval hierarchy so routine reorders can auto-issue below a threshold and route upward above it - and receipts, vendor master, purchasing KPI dashboard, internal invoicing.
Inspections	Reusable inspection checklists, conducted on web or tablet, with automatic triggers (for example at planned-downtime end or on production count) and automatic follow-up work orders on failure.
Reliability & Failure Analysis	Failure mode / cause / remedy catalog per asset, failure records with measured downtime, MTBF / MTTR, downtime cost, repeat-failure detection, repair-vs-replace calculator, asset cost trending, FMEA worksheets, and structured root cause analysis - building a failure-mode-to-parts history as a byproduct of normal use.
Temporary Fixes	First-class record for interim repairs with per-shift operator acknowledgement on the line, admin oversight, and enforced follow-up work orders to permanent resolution.
Labor & Crafts	Craft and skill assignment per technician, labor rate types, and automatic labor logging from work timers. Because every minute is already logged against a work order and a technician, self-service shift summaries and manager drill-downs by person, crew, or date range come from that same data - nothing to compile by hand.
User Roles & Permissions	Reusable role templates (for example Tech I, Tech II, Planner, Supervisor) bundle the right permission set once. Assigning a technician to a role is a single action instead of building a permission tree from scratch for every new hire.
Kaizen	Continuous-improvement idea pipeline with categories, review states, and incentive tracking - raisable from the floor, including directly from a downtime call.
Quality & Compliance	Nonconformance reports (NCR) with disposition workflow, CAPA change requests, ISO 55001 asset-management module (policies, objectives, SAMPs, risk register, audits), and airworthiness directive tracking for aviation environments.

How the CMMS Is Woven into ProAlert

This is the section that separates ProAlert CMMS from a standalone package. The integration is not an interface file or a nightly sync - it is shared tables, shared services, and shared screens. Nine seams matter most to a Maintenance Department:

1. One asset, two views

Every CMMS asset can be linked to its production twin - the same machine that the andon board, OEE engine, and EdgeSense cycle counters watch. Maintenance sees the asset's reliability and cost picture; production sees its status and throughput; both are the same record underneath. No duplicate asset masters, no reconciliation project.

2. Downtime calls become work orders

When an andon call closes, it can convert directly into a corrective work order that inherits the asset, failure mode, cause, remedy, and the responder's notes. The failure record behind it carries downtime hours measured by the call clock, which is what makes the reliability numbers trustworthy.

3. Temporary fixes cannot hide

A tech who applies an interim repair records it as a Temporary Fix. Operators on the affected asset acknowledge it every shift, and the system generates and tracks the follow-up work order until the permanent repair is verified. The band-aid stays visible to production and maintenance alike until it is gone.

4. Production events trigger inspections

Inspection triggers listen to the production side: the end of a planned-downtime window or a production quantity threshold can automatically launch an inspection, and a failed inspection automatically raises a follow-up work order. Condition-based maintenance without a clipboard.

5. Maintenance work plugs into daily management (AFMDS)

ProAlert's daily management spine turns recurring gaps - excessive downtime, repeat failures, missed targets - into owned Problems with due dates and escalation clocks. Work orders link to those problems as their corrective actions, so plant leadership sees maintenance work in the same accountability loop as safety, quality, and delivery.

6. Cost models share one source of truth

Downtime cost, asset cost trending, die-changeover analysis, and the repair-vs-replace calculator all price maintenance against the same operating-cost and production data that the OEE side already reports. When the CFO asks what a failure costs, maintenance and production quote the same number.

7. The review queue works for the supervisor, not the other way around

A high-volume shop can generate dozens of work orders a week, and reading every one top to bottom just to close it out becomes a job of its own. ProAlert routes work orders that finish in normal time with expected parts usage straight to Closed. Only the exceptions - a repair that ran well outside its normal duration, parts that don't match the failure mode, a third failure on the same asset this quarter - surface for a supervisor to look at, with an optional AI-generated summary by work cell to catch up on at a glance.

8. One inventory, every site

Parts and tools borrowed between assets, lines, or facilities are recorded as asset transfers with a full audit trail - serial number, usage hours where the asset is metered, and which site currently holds it. A multi-site operation can see stock and outstanding loans across every plant instead of working from whatever one storeroom happens to know.

9. Patterns are visible because the data isn't scattered

Every machine, line, station, and area reports into the same failure, cost, and execution history. That single pool is what makes it possible to notice that a bearing failure on Line 3 matches a pattern on Line 7, or that a task every crew adds to a template on one line is missing from the same PM everywhere else. Split across separate systems per line or per plant, that pattern is invisible - there is no query that can see across the silos to find it. See Living Documentation & RIX for where this is headed.

The standalone-CMMS contrast

Most standalone CMMS platforms are capable systems in their own right, and many offer an integration hub or an open API that can connect production systems to them. The architectural difference is that in a standalone-CMMS world each of the nine seams above is an integration project - something to scope, build, and maintain - and downtime figures, failure data, and asset registries still reconcile across two systems. In ProAlert they are one system: the seam is a database relationship, not a connector.

CMMS Terminology Crosswalk

For a team that already knows a standalone CMMS, nothing in ProAlert CMMS requires unlearning - every major concept has a direct counterpart. This crosswalk lines up the vocabulary term for term and notes what changes beyond the name.

In a typical standalone CMMS	In ProAlert	What changes
Work request (portal / guest request)	Andon call	The request is raised at the machine on the same system that runs the line's status board. It carries a measured downtime clock, responder tracking, and an escalation chain - and it converts to a work order with the failure data attached.
Work order	Work order	Same concept, same lifecycle. Adds pinned procedure versions, per-step execution capture (timers, skips with reasons, steps added in the field), and signature close-out.
Every work order reviewed to close it out	Exception-based review	Work orders that finish within normal time and expected parts usage route straight to Closed on their own. A supervisor's queue holds the outliers - unusual duration, unexpected parts, repeat failures - instead of the whole week's volume.
PM (date / meter / event triggers)	Scheduled Maintenance + Meters	Equivalent scheduling. Production events can additionally trigger inspections directly (end of planned downtime, production counts), with failed inspections raising follow-up work orders automatically.
Task lists / attached SOPs, importable task groups	Work Templates	Same convenience - pull a reusable task list into a work order instead of typing it out - but the template is a versioned, approval-controlled document. Every work order records exactly which version it ran, and execution history accumulates against it.
PM assigned to a team; who-closed-what tracked informally	Team assignment with per-task sign-off	A PM - or any work order - can be assigned to a team. Each task inside it is claimed and signed off by whichever technician does it, so workload distribution and task-level accountability are native, not something a supervisor tracks by memory.
Compiling a daily activity summary by hand	Self-service shift summary	A technician can pull up everything they closed that shift - work orders, time spent, parts used - and share it, for example by email, without retyping anything. It is a read of the same execution data already logged against each work order, and a supervisor can drill into the same data by person, crew, or date range.
Assets & hierarchy	CMMS assets + locations, linked to live production assets	One registry serves maintenance and production. The CMMS asset is joined to the machine the OEE and andon system watches - no second asset list to keep in sync.
Part / asset moves tracked manually, if at all	Asset transfers with an audit trail	A transfer between assets, locations, or sites is a recorded event - serial number, usage hours where metered, and current holder - so a multi-site network can see what was borrowed from where and whether it came back.
Parts & supplies, purchasing	Inventory, RFQ / PO, vendors	Near one-for-one: storerooms, stock ledger, reorder forecasting, RFQ-to-PO with approval chains, receipts. Adds barcode / ZPL label printing for bins and parts.
Reorder point noticed, PO cut manually	Auto-replenishment with approval caps	A reorder point can be configured to auto-issue a purchase order to a preferred vendor inside a dollar cap, or simply queue it on a buyer's dashboard for a one-click approval - the plant decides which parts get which treatment.
System roles built per user (for example Read-only, Coordinator)	Role templates	A role bundles the right permission set once - Tech I, Planner, Supervisor, and so on. Bringing on a new technician is assigning a role, not rebuilding a permission tree from scratch.
Mobile app	ProAlert mobile app	One app for the whole floor: the same tablet the operators use for andon carries the maintenance work orders, inspections, and push notifications - a native app built on the platform's own data, not a separate mobile experience layered on top.
Status and field changes behind a small expand-triangle	Direct-select controls	Common changes - status, assignment, classification - are a normal dropdown or inline control right where you're looking, not a value tucked behind a tiny disclosure triangle that takes a precise click to open. It is a small thing once; across dozens of changes a shift, it is friction a crew feels all day.
Integration hub / open API	Not needed for the production floor	Andon, OEE, downtime, and CMMS share one database, so floor-to-CMMS integration is not a project to build or maintain. (An API remains available for ERP and external systems.)
AI insights	Reliability analytics today, RIX on the roadmap	MTBF / MTTR, downtime cost, and repeat-failure detection are delivered and run on measured events. RIX - evidence-backed procedure improvement and, eventually, suggested-parts recommendations from step-level execution history - is the roadmap layer, and the data it needs is being captured with every work order today.

The honest one-liner

A standalone CMMS manages maintenance next to the operation and connects to it through integrations. ProAlert manages maintenance inside the operation - the work order is built from the same record that justifies the downtime in the first place.

Mobile Execution

Maintenance work happens at the machine, not at a desk, so the execution surface is the ProAlert mobile app on rugged Android tablets (iOS and Windows are also supported). The same app operators use for andon serves the maintenance crew:

Work Orders

My-work list, full detail, start / pause / complete with server-tracked time

Task-by-Task

Step instructions with reference media, per-step timers, skip-with-reason, add-a-step in the field

Evidence Capture

Photos and short videos attached to the exact step they document

Parts & Labor

Log parts from the catalog, labor hours pre-filled from the timer

Inspections

Conduct checklists at the asset; failed items raise follow-up work

Push & Live Updates

Assignment notifications and real-time status over SignalR and Firebase push

Complete-at-desk

Techs who prefer to finish paperwork at a workstation can pause the timer at the machine and complete the close-out on the web - the timer, tasks, and evidence follow them across devices.

On the roadmap: location-aware assist

Because the mobile app already knows which asset a technician is standing at, the same data can drive location-aware suggestions - relevant work orders, parts, and repair history surfaced as a tech approaches a work center, and eventually hands-free capture through a wearable device. Neither is built yet; both are a natural extension of data the platform already has.

Living Documentation & RIX

Most CMMS procedures are written once and rot quietly. ProAlert treats a procedure as living documentation, and the plumbing for that is already in place today:

Immutable versions. Procedure templates are versioned with a draft / review / active lifecycle. Every work order pins the exact version it ran against, forever.
An execution event log. As crews work, the system records structured events: work order created (with a context snapshot of shift, operator, and asset state), steps skipped with the reason given, and steps added in the field that the template lacked.
Honest deviations. Any step - including required ones - can be skipped, but only with a mandatory reason. Deviations become data instead of secrets.
A parts-history index. Every work order already records which parts resolved which failure mode. That pairing is the raw material for RIX to eventually surface the parts most often used for a given failure - a suggestion that a technician can accept, swap, or ignore, not an autopilot order.
One data set across the whole fleet. Every machine, line, station, and area executes work orders into the same tables. None of that history is scoped to a single asset - which is what makes comparing across the fleet possible in the first place.

RIX is the analysis layer this feeds. Its principle is "RIX suggests, humans approve": by reading execution histories across many runs, it will propose evidence-backed template changes - drop the step everyone skips, add the step every crew performs anyway, reorder, re-time, re-flag. An accepted proposal becomes a new approved template version, so procedures converge on what the work actually is.

That reading is not limited to one asset's history. Because every machine, line, station, and area feeds the same data set, RIX will eventually be able to compare across the fleet, not just up and down one procedure's runs. A failure pattern on a press in one area that quietly matches a pattern on a similar press somewhere else is the kind of correlation a single-asset view cannot surface - and a siloed system, where each line or plant keeps its own maintenance records, cannot surface it either, because there is no shared table to compare across. Finding that kind of pattern is what will let RIX suggest a PM schedule change before the third failure instead of after it, and propagate a best-performing crew's task order and timing to every other crew running the same job.

Where this stands

The template engine, versioning, approval workflow, and execution event capture are delivered. The RIX analyzer, its template proposal workflow, suggested-parts recommendations, and fleet-wide pattern detection are the roadmap - the data all of it needs is being banked with every work order executed today.

Standards Alignment

Standard	How the CMMS supports it
ISO 14224	Asset register structure and the failure mode / cause / remedy taxonomy follow the reliability-data standard, so failure data is analyzable and benchmarkable.
ISO 55001	Dedicated asset-management module: policies with acknowledgement, strategic asset management plans, objectives and measurements, risk register, audits, and management reviews.
ISO 9001	Nonconformance reports with disposition control, CAPA change requests, controlled procedure documents with versioning and approval, and audit-trail discipline (every record carries who and when).
Aviation (FAA AD)	Airworthiness directive tracking with per-asset compliance records for regulated fleets.

Glossary

Andon call	An operator-raised downtime or assistance request on the production floor - ProAlert Core's founding feature.
CMMS	Computerized maintenance management system - the umbrella term for the work order, PM, inventory, and reliability software this document describes.
Work order (WO)	The unit of maintenance work: tasks, parts, labor, media, timers, and sign-off against one or more assets.
Work template	A versioned, approval-controlled procedure. Each work order is generated from a specific version and stays pinned to it.
PM	Preventive maintenance - schedules by calendar time or meter usage that generate work orders automatically.
OEE	Overall Equipment Effectiveness - the Availability x Performance x Quality composite metric ProAlert's production side reports.
Temporary fix	A recorded interim repair with shift-by-shift operator acknowledgement and an enforced follow-up work order.
Failure record	A structured failure event (mode, cause, remedy, measured downtime) feeding MTBF / MTTR and cost analytics.
MTBF / MTTR	Mean time between failures / mean time to repair - the core reliability measures, computed from live event data.
RCA	Root cause analysis - a structured investigation into why a failure happened, opened from a failure record.
FMEA	Failure mode and effects analysis - a worksheet ranking failure modes by severity, occurrence, and detectability.
Exception-based review	Work orders that close within normal time and parts usage route straight to Closed; only outliers surface for supervisor review.
Role template	A reusable bundle of permissions for a job function (for example Tech I, Planner, Supervisor); assigning a person to a role is a single action.
Asset transfer	A recorded movement of an asset or part between locations or sites, with a full audit trail (serial number, usage hours, current holder).
RFQ	Request for quote - the first step of the purchasing workflow, sent to vendors before a purchase order is cut.
PO	Purchase order - the approved order sent to a vendor, tracked through receipt.
KPI	Key performance indicator - a tracked metric, such as on the purchasing dashboard, used to monitor performance over time.
ZPL	Zebra Programming Language - the format used to print barcode labels for parts, bins, and storerooms.
NCR	Nonconformance report - a quality record for product or process that fails to meet requirements, with a disposition workflow.
CAPA	Corrective and preventive action - a change request raised to fix a nonconformance's root cause and prevent recurrence.
PPE	Personal protective equipment - safety gear called out on procedure steps that require it.
AFMDS	ProAlert's automated daily management spine; maintenance work orders attach to its Problems as corrective actions.
RIX	The template-improvement analysis layer: reads execution histories, proposes evidence-backed procedure changes, humans approve.
API	Application programming interface - the integration point available for ERP and other external systems.
ERP	Enterprise resource planning - the external business system, covering accounting and procurement, that ProAlert's API can connect to for data exchange.
FAA AD	Federal Aviation Administration Airworthiness Directive - a regulatory compliance record tracked per asset for aviation environments.
EdgeSense	ProAlert's IoT device platform (cycle counting, sensors) that feeds usage data such as meter-style counts.

Going deeper

This document is the executive view. Per-screen guides for the CMMS module (work orders, preventive maintenance, inventory, purchasing) will follow as the module is rolled out, alongside detailed guides for related areas such as nonconformance reports and daily management (AFMDS).