Key Points
- A plantwide sensor deployment can be limited by the operating model that receives the diagnosis. While diagnostics are critical, the operating model must be able to account for the full range of what it receives.
- Criticality assessment turns a coverage map into a triage plan, because whatever gets instrumented is what the team will be sorting every week.
- Manual confirmation is a delimiter on a program's real capacity, since it runs at the speed of the qualified personnel rather than at the speed of the sensor count.
- A successful pilot often validates the technology while just as often leaving the operating model untested, which is why scaling must account for the plant’s entire workflow.
From forty to nine hundred assets
After the pilot finished, the deployment was approved, and expansion from forty assets pushed the capability out to nine hundred. Yet, somewhere in the two weeks that follow, in a meeting about something else entirely, someone asks who is actually going to look at all of it and report on how it’s going now.
The room goes quiet. Not because a bad answer is just waiting to be said aloud, but because at forty the answer was obvious enough that nobody had ever needed to say it out loud. It was going great. But the silence in the room at that moment is the most useful signal the program will receive that year.
Failing to scale happens so much more than people realize. More than 70% of companies investing in advanced analytics, AI, or digital solutions never move immediately past the first pilot phase to full scale deployment. But the reasons why rarely have anything to do with the technology working. It worked in the pilot, and the technology continues to work at scale too. What doesn’t automatically scale, though, is the operation (operational architecture) receiving what the technology produces.
There is usually one more question sitting underneath the pilot, and it deserves a straightforward look. Some version of these questions is in the back of everyone’s minds: are we sure we picked the right hardware and software? They’re fair questions at this stage. And those choices matter enormously, though not mainly for the reason people assume.
The significance of the question is not so much in the hardware’s detection success, but in the relationship between the range the hardware captures that the software receives, what the software does with those signals, and how they determine the shape of every workflow you are about to design.
If a diagnosis arrives as a raw anomaly, interpretation becomes a role you have to staff. If it arrives as a named failure mode with severity and evidence attached, triage is a different job requiring different people. If findings do not flow into the maintenance platform your plant already runs, you have created a parallel system, and with it a weekly reconciliation meeting nobody scheduled.
Even accounting for the scope of what you get is noteworthy here. For example, a motor-driven asset can fail mechanically, and it can fail electrically. And often those are the same failure observed at two points in its progression.
Both domains belong in a plantwide program.
The reason most programs watch only one is not a technology gap, since electrical signature analysis is decades old and well understood. It is a deployment and diagnostics gap.
The rest of this article assumes both are in scope, as best practice suggests they should be.
What follows examines what plantwide deployment asks of an operation rather than of its equipment, what has to be decided before the first sensor goes on, and why the answer differs depending on where you are starting from. Part 1 is for teams deploying predictive maintenance sensors at scale for the first time. Part 2 is for teams expanding from a successful pilot. They are different problems, and both are worth reading, because each one calls out things the other often unquestioningly assumes.
Part 1. Deploying Predictive Maintenance Sensors Plantwide for the First Time
A plantwide-first deployment will likely be designed on assumptions, and those assumptions come from the program you currently run.
All your current habits (Confirmation habits, prioritization habits, and execution habits) will scale along with increased sensor count during a plantwide deployment. You’ll often find that each operational process or procedure that has been working well will quickly become the makeup of constraints you need to deal with across the plant.
If you’re going to scale plantwide, then you need to know what the operational bottlenecks are going to be. Yes, you want good sensors. Yes, you want good coverage and capture range. But these are just the beginning of your challenges. If you don’t address the following operations, your challenges will drown you after deployment, not give you the competitive edge you’re probably looking for.
Coverage decisions are prioritization decisions
The first instinct on a plantwide deployment is to treat coverage as a map. That map is full of which assets, which areas, how many receivers, and what gets left out. It’s not that such framing is wrong, but that it is incomplete. If using this map-based approach, the same lists that fill the map will surely be the same lists that determine what your team will be triaging every week for the next several years.
However, criticality analysis is the process that carries you out of such triage. And fortunately, most reliability teams already accept and use it. For instance, ISO 17359 recommends assessing criticality across all machines specifically to produce a prioritized list of what belongs in a condition monitoring program and what does not. Furthermore, it should be paired with failure mode analysis to identify which faults are worth measuring for in the first place.
The second-order effect is what matters most, as the criticality tier functions as a pre-agreed severity threshold and a pre-agreed response expectation.
Settle it before deployment and the first month of alerts arrives already sorted, with the team knowing which findings interrupt a shift and which wait for the next planned window. If you wait to settle it afterward, you will be sorting under pressure, with production asking why nobody flagged the asset that just stopped. Knowing where to act first is a decision made months before the alert, not in the moment it arrives.
How does the diagnosis get turned into a decision?
Every program has a step between a finding and a work order. A condition gets flagged, and before labor and parts get committed, someone has to be confident enough to commit them. In many operations, especially those who haven’t adopted certain technologies, that means a qualified person forms an opinion, often after walking out to the asset with a handheld.
This step is prudent and close to universal under those conditions. However, it also runs at the speed of the person performing it. Which means the number of assets a program can genuinely act on equals that person's available hours, not the number of assets instrumented. Scaling sensors without changing the confirmation model gets you coverage but doesn’t give you capacity.
To drive this point home, it’s worth figuring out how many of last quarter's findings were acted on without anyone first going to the machine. The resulting number, rather than the instrumented count, could be thought of as the effective size of your program.
Hiring does not close the gap between these two numbers. While expertise is scarce, industry projections point to that scarcity margin widening rather than narrowing over the next decade, with as many as 1.9 million manufacturing roles potentially going unfilled through 2033.
But what closes the gap is deciding in advance which findings require human confirmation and which do not, and then requiring that the system arrive at its conclusion with the reasoning attached. A diagnosis that names the fault and shows its work lets a reliability engineer accept it or overrule it. An anomaly that only says something changed essentially makes them start over.
This is the reliability engineer's decision to make and their exposure if it goes unmade. It is the plant manager who will eventually ask why nine hundred instrumented assets produced sixty interventions.
What needs to change at the point of work?
A diagnosis that does not become work has not entered your operating model. It is an observation sitting in a system.
The pattern to avoid is easy to describe and surprisingly common. Findings live in the monitoring platform. Work orders live in the maintenance platform. A person moves items between them.
At forty assets, that person is a coordinator doing a small weekly task. At nine hundred, that person is the bottleneck, and within a quarter there is a spreadsheet nobody planned for that has quietly become the actual system of record.
The other half of this decision is adoption, because it is the same question seen from the floor. Technicians use what sits in the flow of work they already do. Anything requiring a second application gets used at the rate people remember to open it, which means the program's real throughput is its system adoption rate rather than its detection rate.
Management may be tempted to think this is a discipline problem, but it’s not. The people still running paper logs are not careless, they’re busy. The tool that gets them done faster is the tool that gets used.
What indicates your program is working in an advantageous way?
A work order closes when the task is done. What it records is the action taken, not the outcome produced. Whether the fault actually cleared is a different question, and only the asset's behavior afterward can answer it.
Two things follow, and both get worse with scale. Repeat failures enter the record as new events rather than as returns, which quietly corrupts the failure history the program exists to build. And a program that cannot demonstrate its predictions were correct arrives at its budget review with a story instead of evidence.
So verification itself is also a workflow. Someone owns it, it has a trigger, and it has a place in the record. Building that into failure lifecycle management before deployment costs a paragraph in a plan. Building it in year two means reconstructing it from work orders that were never written to answer the question. Closing the loop after the repair is what turns a monitoring program into a learning one.
Part 2. Scaling Sensor Coverage from a Pilot to the Whole Plant
Most pilots only prove the technology. But it also needs to prove the operating model. At scale, the operating model is what carries the program’s load.
If you already ran a pilot, you are in a different position, and the temptation is to treat scaling as arithmetic. It is not. This part is an audit rather than a design exercise. The questions from Part 1 still apply, but you have data to answer them with.
This part will proceed as if your pilot proved the new technology, but didn’t take into account the operating model to the degree it should have.
What did the pilot prove?
A well-run technology-based pilot establishes real findings. That the sensors survive your environment. That the data is clean enough to work with. That faults get caught early enough to make a difference. Often there is a specific catch, a bearing or a winding, that paid for the program in one afternoon and made the scale conversation possible at all.
Every one of those is a finding about detection.
The operating model, though, was never tested, because it was never stressed. One person could hold the entire picture in their head. Triage happened in a conversation on the way to lunch. The weekly export into a spreadsheet took twenty minutes, and nobody thought of it as a process. None of that was wrong, per se, as it was all an operation appropriate to the same scale the detection pilot was under.
Of course, this also points to the pilot's most valuable output, which isn’t the detection. It’s the record of what your operation actually did with a diagnosis, and how long it took from the finding to the work being done. Most teams have that data sitting in their pilot and have never looked at it as a measurement, nor considered it a reflection of the labor and operations rather than of the technology.
What difference did the asset population make?
Pilots select the assets they select for good reasons. Teams pick equipment they can validate against, which means accessible, well-understood, mid-speed rotating machines with known histories and someone on staff who knows their quirks. That is the correct way to run a pilot.
It also means the confidence a pilot produces is a property of that population rather than of the technique. It is worth listing the twenty assets whose failure would cost you the most and checking how many of them resemble anything that was in the pilot.
Plantwide includes machines the pilot did not.
- Slow-speed shafts, where the energy from an early-stage fault sits close enough to the background that ultrasonic sensing carries the detection an accelerometer alone will miss
- Intermittent duty, where a fixed sampling schedule has a real chance of measuring a stationary machine and reporting that everything is fine
- Hazardous locations, which constrain what hardware is permitted at all
- Older equipment, with no data interface, no documentation, and a nameplate nobody can read
Each of those is a different confidence number. Several are a different sensing approach entirely. And lower confidence means more findings that require someone to go confirm them, which lands directly on the constraint from Part 1.
Did anyone notice the work the pilot produced?
Every pilot runs on manual effort that exists only because the pilot is small. The weekly export. The triage that happened in a hallway. The one experienced person who looked at everything, because at that scale looking at everything was still possible.
None of it appeared on the pilot's cost line. It was absorbed into jobs people already had, which is precisely why it stayed invisible. It becomes visible when it gets multiplied, and by then it is the program's running cost rather than a line item anyone approved.
There is a short exercise worth doing before the scale decision. Write down every step in the current workflow that a person performs by hand, from the moment a finding appears to the moment the work is verified. Mark each one as automated at scale, staffed at scale, or eliminated.
There is no fourth column. A step left unmarked has been assigned to the second one by default, usually to whoever is already carrying the most.
Why standardization can be a deliverable
If this plant is one site among several, the scale decision changes character again. What the organization can use is not your catches. It is comparability.
Asset naming, hierarchy structure, criticality definitions, failure coding, and severity thresholds either match across sites or they do not. If they do not, nothing rolls up. Two plants reporting different planned maintenance percentage figures may be measuring different things, and that usually surfaces for the first time when the numbers are already on a slide in front of someone asking why one site is outperforming the other. Data collection standardization is unglamorous work that pays at exactly this moment.
It is worth framing as opportunity rather than overhead. Standardization is the point where a local rollout becomes something the organization has a reason to fund again, and seeing the whole operation on one screen is only possible once every site describes its assets the same way. The site that standardizes first generally sets the standard everyone else adopts.
A Short Readiness Check
Four questions that should be answerable from records you already have.
- How many of last quarter's findings were acted on without anyone first going to the asset?
- When a finding arrives on a machine nobody has a strong opinion about, who decides what happens next?
- Where does a diagnosis become work, and how many hands touch it on the way?
- What was your repeat failure rate last quarter, and can anyone pull it up without building a report first?
If any of these cannot be answered, that is the finding. It is not a failure of the program. It is a description of the operating model you are about to multiply.
How Tractian Approaches Plantwide Readiness
Sensing is the fast part of a plantwide program. The operating model is what determines whether any of it turns into decisions.
Those readiness questions are the ones Tractian was built around. Tractian’s core wireless multimodal sensors and predictive maintenance software are a world-class hardware-software combo. But what makes Tractian so special is that it is designed specifically for enterprise-ready deployments, at scale, without adding reciprocal headcount, to align with operational workflows matched to the technology.
Deployment as a criticality decision
Sensors mount in minutes, with no cabling, no machine modification, and no dependency on plant IT, communicating through a cellular receiver rather than onto the plant network.
That matters less as a specification than as a constraint removed. When installation cost and network reach stop driving the coverage map.
Watch how the map gets drawn from criticality instead.
Diagnosis instead of anomaly
Findings arrive as diagnoses rather than anomalies. Each one names a failure mode, carries a severity and a progression state, and comes with the evidence chain that produced it, so an engineer can accept the conclusion or overrule it on technical grounds rather than on trust.
Prioritization is weighted by asset criticality, which means severity and consequence arrive already combined. This is the capability that changes the confirmation arithmetic, because a conclusion you can audit is a conclusion you do not have to rebuild. For the cases that warrant it, the same evidence supports root cause work rather than sending the team back to raw data.
Both sensing domains land on the same asset record. Machine monitoring and electrical monitoring feed one analytics environment and one fault classification layer, so an electrical cause and its mechanical consequence appear as the same event rather than as two reports someone correlates later.
Execution and verification in one loop
Diagnosis flows into execution rather than beside it. Severity, recommended action, and context move into the maintenance platform the plant already runs, natively or through open integrations, so no parallel system appears, and technicians stay in the interface they already know. The mobile experience works offline, because throughput is adoption.
The loop closes after the repair through Post-Op Validation. Post-repair signal confirms whether the fault actually cleared, which is what gives the failure history its accuracy and gives the program something to bring to a review.
Deployment is supported in the field rather than through a ticket queue. Certified reliability professionals handle installation and training on-site, which matters most during the stretch when a rollout moves from one plant to the next.
Learn more about Tractian's plantwide condition monitoring deployment to see how high-quality, decision-grade IoT data transforms your program into AI-powered closed-loop maintenance execution workflows.
FAQs about Deploying Predictive Maintenance Sensors Plantwide
How many assets should we put predictive maintenance sensors on first?
Start from a criticality assessment rather than a target number. The right first group is the set of assets whose failure carries the highest consequence and that your team has the capacity to triage every week. Coverage that exceeds triage capacity produces a queue, not protection.
Do we need both vibration and electrical sensors for a plantwide deployment?
Best practice includes both, because a motor-driven asset fails mechanically and electrically and the two are often the same failure at different stages. Monitoring one domain well is still a legitimate starting point and far better than monitoring neither. Plan the architecture for both even if the rollout is phased.
How long does a plantwide predictive maintenance sensor deployment take?
Installation itself is fast, often minutes per sensor. The timeline is driven by site count, sequencing, and how long each site takes to reach a working triage routine. For a multi-site operation, expect the full rollout to be measured in months rather than weeks, with partial value arriving well before the last site goes live.
What has to change in our maintenance workflow before we scale sensors plantwide?
Four things need owners before the first alert. Who triages, where a diagnosis becomes a work order, which findings require physical confirmation, and who verifies that a repair actually cleared the fault. Any of those left undefined becomes a bottleneck at scale.
Does a successful pilot mean we are ready to deploy plantwide?
Not on its own. A pilot proves the technology works on your equipment. It does not prove your operating model scales, because at pilot volume the manual steps holding the process together are still small enough to stay invisible.
Who should own alert triage once sensors are deployed across the whole plant?
Ownership usually sits with a reliability engineer or reliability lead, but the more consequential decision is whether triage routes through one person. A single reviewer is workable at pilot scale and becomes the program's capacity ceiling at plant scale.
