mail@mabbaz.com Abu Dhabi, UAE

Total Productive Maintenance · Reliability · Maintenance Strategy

The 8 Pillars of Total Productive Maintenance (TPM)

Most explanations of the eight pillars of TPM are a list with a diagram. A list will not help you implement anything. This guide takes each of the eight pillars in turn and asks the four questions that actually matter: what does it mean in practice, what does it look like when it is working, what is the first practical step, and how does it fail. It also gives you a realistic order of adoption, because trying to start all eight at once is the classic way to kill a TPM programme in its first year.

Muhammad Abbas September 27, 2026 ~22 min read

The eight pillars of Total Productive Maintenance are the most reproduced diagram in maintenance improvement and one of the least understood. Almost every version online names them, draws them as columns holding up a roof labelled with some aspiration, and stops. But the pillars are not a taxonomy to memorise. They are eight distinct organisational disciplines, each with its own owner, working routine, evidence that it is functioning, and characteristic way of collapsing. Treating them as a checklist is how programmes end up with eight half-built columns and nothing standing on them. This guide treats each pillar as a piece of work.

The message up front: the eight pillars describe a mature TPM organisation, not a project plan. Nobody builds eight pillars simultaneously and survives. What works is sequencing: establish the housekeeping foundation, get autonomous and planned maintenance working together in a pilot area, add focused improvement as the problem-solving engine, then extend outward as the earlier pillars start generating their own demand for the later ones.

1. What the pillars are, and why the list you find varies

Total Productive Maintenance originated in Japanese manufacturing and is stewarded by the Japan Institute of Plant Maintenance , which runs the TPM Awards (a site assessment scheme) and a TPM Specialist certification for individuals. The pillar structure grew out of that body of practice rather than a standards committee, and that origin explains something readers find confusing: the eight pillars are a widely shared convention, not a normatively fixed list.

It is worth being precise about the documentation position, because a lot of published material gets it wrong. There is no ISO standard for TPM. The nearest reference document is PAS 1918:2022, "Total productive maintenance (TPM). Implementing key performance indicators. Guide", published by BSI at JIPM's request. A PAS is a Publicly Available Specification: not an ISO standard, not a British Standard, and a guide to implementing KPIs rather than a specification of the pillar structure. So "TPM certified to ISO" is not a thing. A site can hold a JIPM TPM Award and an individual can hold a JIPM certification, but neither is ISO certification.

Because the convention is a convention, the naming and the ordering genuinely differ between sources. Focused improvement appears as continuous improvement or Kobetsu Kaizen. Early equipment management appears as development management, initial phase management or early equipment design. TPM in administration appears as office TPM or support-function TPM. Safety, health and environment is eighth in one diagram and fourth in another, and some versions add a ninth pillar for energy or the supply chain. None of these variants is wrong; they are dialects of the same model. The eight worked through here are the set most conventionally cited, with the Japanese names where they are in common use:

  • Autonomous maintenance (Jishu Hozen)
  • Planned maintenance
  • Quality maintenance (Hinshitsu Hozen)
  • Focused improvement (Kobetsu Kaizen)
  • Early equipment management
  • Training and education
  • Safety, health and environment
  • TPM in administration

This article is the depth treatment. For how TPM fits alongside the other maintenance strategies, where it came from, and how it relates to reliability-centred maintenance and preventive maintenance programmes generally, see the complete guide to Total Productive Maintenance, which names the pillars and defers the detail to this page.

Do not argue about the list

Steering groups can spend two meetings debating whether safety is pillar seven or pillar four. That debate produces nothing. What matters is that each of the eight areas has a named owner, a routine, and a way of showing it is functioning. If your site calls focused improvement something else, fine. If nobody owns it, that is the actual problem.

2. 5S: the foundation beneath the pillars, not one of them

Almost every pillar diagram shows a base course under the eight columns, and in most versions that base is 5S: sort, set in order, shine, standardise, sustain. Why it is drawn as the foundation rather than as a pillar is not a decorative distinction. A pillar is an ongoing discipline with its own objective. 5S is a precondition. Its function in a TPM context is to make deviation visible. You cannot see an oil leak on a floor that is already stained, notice a missing spanner in a toolbox that was never organised, or tell that a gauge is reading outside its normal band if no normal band is marked. Autonomous maintenance, the pillar that asks operators to detect early abnormality, is close to impossible where abnormality and normality look the same. 5S creates the contrast.

So a site starting TPM with 5S is not delaying the real work; it is doing the step that makes the real work detectable. The opposite error is running 5S as a standalone tidiness campaign with audits and scores, never connected to abnormality detection. If 5S is not feeding the pillars, it has become housekeeping with paperwork.

3. Autonomous maintenance (Jishu Hozen)

What it actually means. Autonomous maintenance transfers a defined and deliberately bounded set of equipment care tasks to the operators who run the equipment every shift: cleaning, lubrication, tightening, basic inspection, and above all the early detection and reporting of abnormality. The logic is that the operator is in front of the machine for eight hours and the technician for twenty minutes a month, so the operator is the better sensor. Autonomous does not mean unsupervised or self-taught. It means the operating team owns the routine, working to standards maintenance helped write and to competency levels maintenance verified.

What it looks like when it is working. Operators carry out a short, timed daily routine using a standard posted at the machine, not filed in a binder. Lubrication and inspection points are physically marked, often colour-coded, with transparent guards or windows fitted so points that used to require dismantling can be checked by eye. Operators raise abnormality tags for conditions they cannot correct themselves, and those tags flow into the maintenance backlog and get closed. The tell is the shape of the incoming work: a healthy pillar produces a steady stream of small, early, low-consequence findings. A site with no operator-raised findings is not a site with no abnormalities.

The first practical step. Pick one machine or one small line, not the whole plant, and run an initial deep clean with operators and technicians working together. That single activity exposes hidden defects, establishes the baseline condition you will maintain, produces the first tag list, and puts operators and technicians in the same space arguing productively about what the machine needs. From that event, write the first operator standard with the operators who will use it.

How autonomous maintenance fails

Three ways, in order of frequency. It is read as cost reduction, with tasks pushed onto operators to justify fewer technicians, no training and no time allowance, and abandoned within months amid justified resistance. The scope creeps beyond operator competence into work needing technician skill or isolation, and someone gets hurt or breaks something expensive. Or operators raise tags diligently for a few weeks, nothing gets fixed, and they stop. That third one is the quiet failure, and it is fatal: you have taught your best sensors that reporting is pointless.

4. Planned maintenance

What it actually means. Planned maintenance is the maintenance department's own pillar: a proactive, scheduled, evidence-based regime that shifts technician workload from responding to breakdowns toward executing planned work. It covers task content, intervals, supporting spares, scheduling discipline, and the failure history that tells you whether any of it works. Within TPM it is the structural counterpart to autonomous maintenance: as operators absorb routine care, technicians are freed for the analytical work that actually improves reliability.

What it looks like when it is working. Planned work is scheduled ahead against real resource capacity rather than issued hopefully. Schedule compliance is measured honestly, so you can see both what was completed and what was deferred and why. Failure history is coded consistently enough to support analysis. Task content is reviewed and pruned, not only added to, and intervals move on evidence. Spares are staged before the job rather than chased during it. Critically, work arriving from the autonomous maintenance pillar sits in the same backlog as everything else, prioritised on the same basis.

The first practical step. Get an accurate asset register for the pilot area and a defensible criticality ranking on it, then audit the existing PM content against the assets that matter. On most sites that review finds three things at once: critical assets with no coverage, trivial assets carrying monthly routines nobody reads, and task instructions too vague to execute consistently. Fixing that content is worth more than adding new routines. The mechanics of PM content and intervals are in the complete guide to preventive maintenance, the measurement side in PM KPIs and schedule compliance, and the ranking discipline in equipment criticality analysis. The formal task-selection logic deciding what preventive work is appropriate per failure mode is reliability-centred maintenance, which sits inside this pillar rather than competing with it.

How it fails. The dominant failure is volume mistaken for maturity: routines are added until the schedule is physically undeliverable, compliance drops, technicians sign off work they did not fully do, and the data becomes worse than useless because it is confidently wrong. The second is building planned maintenance in isolation from autonomous maintenance, so operators and technicians duplicate some checks and both assume the other is covering the rest. The third is a records problem, where the work is genuinely done but coded so poorly that no analysis is possible, which means the pillar can never demonstrate its own value and is first to be cut when budgets tighten.

5. Quality maintenance (Hinshitsu Hozen)

What it actually means. Quality maintenance is the pillar most often skipped and most often misexplained, usually because people assume it means maintaining quality records. It does not. It means establishing and then controlling the equipment conditions under which the process cannot produce a defect. Defects are not random events; they are consequences of equipment conditions drifting outside the band in which good output is guaranteed. Identify the equipment parameters that govern quality, define their acceptable range and hold them inside it, and you move from detecting defects to preventing them.

What it looks like when it is working. For each significant defect type, somebody can point to the specific equipment conditions that cause it: this alignment, that clamping force, this temperature, that clearance. Those conditions have defined ranges and are checked on a routine, often by the operator as part of autonomous maintenance. Trend data on the conditions is watched rather than only the defect rate, because the condition moves first. Recurring defects get a causal investigation rather than a rework loop. The mature version produces a documented map from defect type to equipment condition to control method, and that map is the pillar's real asset.

The first practical step. Take your most persistent recurring defect on the pilot line and trace it back to equipment condition rather than to operator behaviour or material variation, the two default explanations. This is where structured analysis earns its place: the techniques in root cause analysis methods are the right toolkit, and where you work forward from equipment to the defects it could cause, FMEA is the natural method. One defect traced properly to a controllable condition teaches more about this pillar than any training material.

How it fails. It gets absorbed into the quality department as an inspection exercise, which is precisely what it is meant to replace. If the output is more inspection points, tighter sampling and better defect reporting, the pillar has been inverted: those are detection activities, and the pillar exists to remove the need for them. The second failure is attempting it before equipment condition is stable. On a machine whose baseline condition is unknown you cannot define the conditions under which it produces good output, because it has no consistent state to define. That is the strongest argument for sequencing quality maintenance after autonomous and planned maintenance rather than alongside them.

6. Focused improvement (Kobetsu Kaizen)

What it actually means. Focused improvement is the deliberate, project-based elimination of specific identified losses by small cross-functional teams. The word focused is doing real work there: this is not general continuous improvement or a suggestion scheme. It is naming a specific loss, quantifying it, chartering a small team with the right mix of operator, technician and engineering knowledge, giving them a bounded timeframe, and requiring a measured result. It is the problem-solving engine the other pillars feed with problems.

What it looks like when it is working. There is a visible, prioritised loss list, and the teams running at any time are working from the top of it rather than on whatever is annoying somebody. Teams are small, mixed-function and time-bounded, each with a defined before-state measurement and an after-state measurement reported against it. Improvements that work are standardised, meaning the new condition is written into the operator standard or the PM task so it does not decay. Teams disband on completion instead of becoming permanent committees. And the loss list is refreshed from real data, much of it arriving from autonomous maintenance tags, planned maintenance failure history and quality maintenance defect analysis.

The first practical step. Quantify your losses before chartering anything. In TPM practice equipment losses are conventionally grouped under Overall Equipment Effectiveness, and the availability, performance and quality components are how you decide which loss to attack first. The standards position matters here: OEE is defined in ISO 22400-2:2014 (currently under revision), but that definition diverges from Nakajima's original TPM formulation and practitioners compute it inconsistently. So use OEE to rank your own losses against your own baseline and be cautious comparing your figure to anyone else's. The full treatment is in OEE explained; for this pillar you only need a loss ranking you believe.

How focused improvement fails

It stops being focused. Too many teams run at once so none has the attention it needs, or teams are chartered on losses nobody measured so success cannot be demonstrated, or a team persists for a year and becomes a standing meeting. The subtler failure is the missing standardisation step: a team fixes something, everyone celebrates, nobody writes the new condition into the operator standard or PM task, and a year later the loss has quietly returned. Improvement that is not standardised is temporary by construction.

7. Early equipment management

What it actually means. Early equipment management pushes maintainability and reliability requirements upstream into specification, design, procurement, installation and commissioning, so new assets arrive without the problems you spent years fixing on the old ones. The underlying observation is uncomfortable: a large share of the maintenance burden on any asset was decided before it was delivered, by people optimising capital cost with no access to the maintenance history of the previous machine.

What it looks like when it is working. Maintenance and operations have a real, scheduled voice in specification, not a courtesy review of a decided design. A standing lessons-learned list from existing assets is genuinely consulted when specifying a replacement: access dimensions, lubrication point placement, guard removal time, spares commonality, control system openness, isolation arrangement. Commissioning includes a maintainability check and a formal handover of asset data, spares list, PM content and documentation, and the project is not closed until that handover is complete. The strongest indicator is a flatter start-up curve: fewer early-life failures and less of the first-year firefighting most sites accept as inevitable.

The first practical step. Start the lessons-learned register now, from the assets you already run, before any new procurement is in flight. Ask the technicians who maintain your worst machine what they would demand be different if it were bought again, and write it in specification language. That register, kept honestly, is the pillar in embryo and costs nothing but the conversation. The other cheap step is adding a data and documentation handover gate to the next project's completion criteria.

How it fails. Commonly on organisational boundaries. Capital projects sit under engineering or projects, are measured on schedule and capital cost, and are closed and disbanded before the operating cost consequences appear; maintenance input is invited late, treated as a wish list and traded away in value engineering. The second failure is the register that exists but is never consulted, because bringing it to the specification meeting is nobody's job. The third is the handover signed off with the asset data promised to follow later, which is to say never. This pillar needs a governance change rather than a technique, which is why it is the one most often left in the diagram and never built.

8. Training and education

What it actually means. Training and education builds and verifies the competence every other pillar depends on. It is structural rather than a delivery function: its job is to know what skills the site needs, who holds them and at what level, close the gaps and verify the closure. It covers operator equipment-care skill, technician diagnostic and analytical skill, and, often forgotten, supervisory and management understanding of what TPM asks of them.

What it looks like when it is working. There is a current rather than historical skills matrix, mapping the competencies each role needs against the people who hold them, at defined levels rather than yes or no. Development is planned from the gaps and tied to what the pillars require next: if autonomous maintenance is about to extend to a new line, the operator competence is built before the extension. Competence is verified by demonstration at the equipment, not by attendance. Much of the delivery is internal, technicians teaching operators and experienced operators teaching new ones, which is cheaper and more effective than external courses. JIPM's TPM Specialist certification is one recognised personal credential for those going deeper, though it is an individual award scheme and not a site-level or ISO certification.

The first practical step. Build the skills matrix for the pilot area only, and build it honestly, which means accepting it will look worse than the organisation chart implies. Then close the single competence gap most constraining the pillar you are currently trying to advance. A whole-site matrix built as a documentation exercise will be out of date before it is finished and will change nothing.

How it fails. It becomes a training-hours metric: courses delivered and hours consumed are reported, nobody measures whether capability on the floor changed, and the number rises every year while the equipment does not improve. The second failure is training delivered far ahead of application, so a classroom module run six months before the pilot starts is largely forgotten by the time it is needed. The third is training operators and technicians while leaving supervisors and middle managers untrained, which reliably produces the situation where the people asked to do the work understand it and the people controlling their time do not.

9. Safety, health and environment

What it actually means. As a TPM pillar, safety, health and environment is the organisational discipline of ensuring that the changes the other pillars make do not create new risk, and of pursuing the elimination of hazardous and environmentally damaging conditions as an improvement objective in its own right. It sits inside TPM because TPM changes who does what to equipment. Operators take on tasks they did not previously perform, guards get opened for inspection, cleaning happens on running machines unless somebody stops it. Each is a real change in risk exposure and each needs assessing rather than assuming.

One qualification, stated once. Statutory health, safety and environmental duties are jurisdictional and vary substantially between countries and often within them. Nothing in this pillar substitutes for the legal duties applying to your site; the competent party for that determination is your own EHS function working from the law where you operate. What follows is what the TPM pillar covers organisationally, not a statement of what any law requires.

What it looks like when it is working. Every task carries a risk assessment before it is transferred, done with the people who will perform it. Isolation and energy-control requirements are explicit in every operator standard, and the boundary between what an operator may do and what requires a technician and a formal isolation is written down rather than negotiated in the moment. Near misses and unsafe conditions are raised through the same tag mechanism as equipment abnormalities, which is useful integration because one habit then serves both purposes. Environmental losses, leaks, waste, energy and water consumption, appear on the focused improvement loss list rather than sitting in a separate compliance stream. And the safety implications of an improvement are reviewed before it is standardised, not after somebody notices.

The first practical step. Before the first autonomous maintenance standard is issued, walk it task by task with the operators who will perform it and with your EHS function, marking explicitly which tasks may be done with the machine running, which require it stopped, and which require formal isolation and therefore a technician. That walkthrough takes an afternoon and prevents the most serious failure in TPM implementation.

How it fails. It arrives after the fact. Tasks are transferred on the reasonable-sounding basis that they are simple, the risk assessment is done retrospectively or not at all, and the boundary of operator authority is left to individual judgement under production pressure. The opposite over-correction is the pillar becoming a veto function that refuses every transfer, so autonomous maintenance never advances and TPM stalls. Both come from the same root: treating safety as a gate applied to a finished plan rather than as a discipline present while the plan is written.

10. TPM in administration

What it actually means. TPM in administration, sometimes called office TPM, applies the same loss-elimination logic to the administrative and support processes surrounding maintenance and production. A substantial part of the delay visible on the shop floor is generated in offices: requisitions that take weeks to become purchase orders, spares that exist in the system but cannot be found in the store, work orders waiting on an approval from somebody on leave, drawings nobody can locate, invoices blocking a supplier's next delivery. None of those is an equipment problem, and all of them lengthen downtime.

What it looks like when it is working. The processes that gate maintenance work are mapped end to end with real elapsed times measured rather than nominal ones. Procurement and stores are treated as part of the maintenance value stream and their cycle times sit on the loss list alongside equipment losses. Approval chains are reviewed for genuine value rather than accumulated caution. Master data quality, asset records, equipment hierarchies and spares catalogues, is somebody's explicit responsibility rather than everybody's occasional concern. Information is available where the work happens.

The first practical step. Time one process honestly, end to end. Take the requisition-to-receipt path for a routine maintenance spare and measure the actual elapsed time from the technician identifying the need to the part being in their hand, with waiting time recorded separately from working time. The gap between that figure and everyone's assumption is usually where the argument for this pillar lives. You do not need a mapping methodology to start; you need one measured process that is worse than people believed.

How it fails. Two ways. It is deferred indefinitely on the reasonable-sounding grounds that the equipment pillars come first, and never started. Or it is launched as 5S for offices, producing tidy desks, labelled cabinets and a scored audit while the multi-week purchase order cycle continues untouched. The second is worse, because it consumes credibility and delivers nothing. This pillar is about administrative cycle time and information availability, not office tidiness.

This is also the pillar where software genuinely matters, with limits worth being plain about. A maintenance management system removes a specific class of administrative loss: work requests visible without a phone call, approvals routed without paper, asset and spares records in one place, and the failure history the planned maintenance and focused improvement pillars need. What it does not do is fix an approval chain with six signatories or a stores function with inaccurate stock records; it will automate both faithfully and make them slightly faster. Map the process first, then decide what to systemise. The CMMS buyer's introduction covers what these systems do and do not do.

11. The eight pillars at a glance

The table below compresses the preceding sections into the four things worth remembering per pillar. The failure-mode column is the one I would re-read before chartering anything.

Pillar What it owns First practical step Characteristic failure mode
Autonomous maintenance
Jishu Hozen
Operator-owned cleaning, lubrication, tightening, inspection and abnormality detection Joint operator and technician deep clean of one machine, then write the standard from what it exposed Tags raised, nothing fixed, reporting stops; or scope creeps past operator competence
Planned maintenance Proactive scheduled regime, task content, intervals, spares, schedule compliance, failure history Audit existing PM content against an accurate asset register and criticality ranking Volume mistaken for maturity: undeliverable schedule, sign-off without execution, corrupt data
Quality maintenance
Hinshitsu Hozen
The equipment conditions under which defects cannot be produced, and their control Trace one persistent recurring defect back to a controllable equipment condition Becomes an inspection and sampling exercise, which is the thing it exists to replace
Focused improvement
Kobetsu Kaizen
Project-based elimination of named, quantified losses by small cross-functional teams Quantify and rank the losses before chartering any team Too many teams, unmeasured baselines, and improvements never standardised so losses return
Early equipment management Maintainability and reliability requirements in specification, procurement, install and commissioning Start a lessons-learned register from the assets you already run Capital projects measured on cost and schedule trade maintenance input away; handover data never arrives
Training and education Skills the site needs, who holds them at what level, gap closure and verification Honest skills matrix for the pilot area, then close the one gap blocking the current pillar Training hours reported as the outcome; supervisors and middle managers left untrained
Safety, health and environment Risk of every task transfer and change, hazard and environmental-loss elimination as an objective Walk the first operator standard task by task with operators and EHS, marking isolation requirements Risk assessed retrospectively; or the pillar becomes a veto and autonomous maintenance never advances
TPM in administration Administrative cycle time, master data quality and information availability in support processes Measure the real elapsed requisition-to-receipt time for one routine spare Deferred indefinitely, or launched as office tidiness while the purchase cycle stays untouched

12. A realistic order of adoption

This is the section I would keep if you discarded the rest. The most reliable way to fail at TPM is to charter eight pillar teams in one launch, because the pillars are not independent workstreams. Several cannot function until an earlier one has produced something they need: quality maintenance needs the stable equipment condition that autonomous and planned maintenance produce, focused improvement needs a loss list that the operational pillars populate, and training and education needs to know what competence is required next, which only becomes clear once a pillar is advancing. Launched simultaneously, most of them idle visibly while consuming meeting time, and a programme that visibly idles loses its sponsorship.

The sequence below is advisory and assumes a single pilot area rather than a whole site. Treat the waves as overlapping rather than as gates, and treat the entry conditions as the real content: the wave numbers matter far less than not starting a pillar before the thing it depends on exists.

Wave What you start Why here Move on when
0. Foundation 5S in the pilot area, explicitly framed as making abnormality visible Nothing that depends on detecting deviation works in an environment where deviation is invisible An abnormal condition in the pilot area is obvious to a visitor, not just to an expert
1. The operating pair Autonomous maintenance and planned maintenance together, plus the safety walkthrough of every transferred task These two are mutually dependent: operators absorb routine care, technicians redeploy to proactive work. Starting either alone produces duplication or resentment Operator standards are in use, tags flow into the backlog and get closed, and planned work is scheduled against real capacity
2. The engine Focused improvement, fed by the loss data that wave 1 is now generating Chartering improvement teams before you have measured losses produces activity without direction. Wave 1 supplies the loss list Two or three teams have completed with measured before-and-after results, and the improvements were written into standards
3. Precision and upstream Quality maintenance, and early equipment management if a capital project is in sight Quality maintenance needs the stable equipment baseline wave 1 created. Early equipment management is timing-driven: start it when procurement is upcoming, not when the sequence says so Defect types are mapped to controllable equipment conditions; the lessons-learned register is being consulted in specification
4. The support structures TPM in administration, and training and education formalised site-wide Both have been running informally since wave 1. This is where they become structured, once you know what the pillars actually demand of them Administrative cycle times are measured and improving; the skills matrix drives development planning rather than recording it
5. Extension Replicate the whole pattern into the next area Replication of a working pattern is far cheaper than a fresh launch, and your internal trainers now exist Never finished. This is the operating state, not a phase

Two clarifications. Safety, health and environment has no wave of its own, deliberately: it has to be present from wave 1 onward, because wave 1 is where task transfer happens and task transfer is where risk changes. Putting safety in a later wave is the one sequencing error with genuine consequences. And early equipment management is placed loosely because it is driven by your capital calendar rather than by TPM maturity. If a major replacement is being specified next quarter, pull it forward whatever wave you are nominally in, because the opportunity does not return for the life of the asset.

The test for whether a pillar is ready to start

Ask what this pillar's first team would work on in its first week, and who specifically would be in the room. A genuine piece of work with named people means start it. If the answer is that they would define their scope and agree terms of reference, the pillar is not ready and you are about to create a committee.

13. Why pillar programmes stall, across all eight

Each pillar has its own failure mode, covered above, but some patterns kill programmes regardless of which pillar they appear in, and they are structural rather than technical.

  • The pillar becomes a committee. A chair, a terms of reference, a monthly meeting and no work in progress is the commonest artefact of a failed launch. Pillars are work, and work has a current task and a named person doing it.
  • No time was allocated. Operators are asked to perform daily equipment care within an unchanged production target; technicians are asked to analyse while carrying the full breakdown load. The work does not happen, and it is recorded as cultural resistance rather than the arithmetic problem it is.
  • The loop does not close. Tags raised and nothing fixed. Teams delivering and nothing standardised. Lessons recorded and never consulted. The second time the loop fails, participation ends.
  • Activity measured instead of outcome. Tags raised, training hours, teams chartered, audits scored. All rise reliably while equipment performance stays flat, which is exactly why they are popular.
  • Middle management was not brought in, and the launch was site-wide. The supervisor controlling operator time was never included and reasonably prioritises this quarter's output. And eight pillars everywhere at once means no area gets the attention needed to produce the one visible success these programmes live or die on.
The honest limitation of the whole model

The eight-pillar structure was developed in and for repetitive manufacturing, with stable processes, identical equipment in quantity, and an operator permanently assigned to a machine. Several pillars depend on those conditions. In a facilities-management or distributed-asset environment there is often no operator to give autonomous maintenance to, and quality maintenance has no defect rate to control. The pillars still hold value there, but adopting the full structure verbatim because it is the canonical diagram is a mistake. Take the pillars whose preconditions you have, and be straightforward with your steering group about which ones you are not implementing and why. A four-pillar programme that works beats an eight-pillar programme that exists on a slide.

The idea to walk away with

The eight pillars describe what a mature TPM organisation looks like, arrived at by observation rather than design. They are not a sequence, a certification scheme or a project structure. As a portrait of a destination they are useful, because they tell you what has to be true when you are finished: operators detecting abnormality early, technicians doing proactive and analytical work, defects prevented by controlled equipment conditions, losses eliminated by small teams, new assets arriving maintainable, competence built deliberately, risk assessed as work changes, and administration not adding delay to any of it. As an implementation plan they are actively harmful, because eight simultaneous workstreams in one pilot area is not a programme, it is a meeting schedule. The pillars have dependencies and respecting them is most of the skill.

Final thoughts

If you are being asked to implement the eight pillars, the most useful thing you can do in the first week is refuse to launch all eight. Pick one area. Establish visible standard condition. Run the joint clean and let the tag list tell you what the equipment has been putting up with. Walk the first operator standard with EHS before anyone signs it. Fix what the tags reveal, visibly and quickly, because that is what buys you the second month. Then measure your losses and let the data charter your first improvement team rather than the loudest complaint.

That is a four-pillar programme at most, and it will outperform the eight-pillar version on every measure that matters. The rest are not being skipped; they are waiting until the earlier work creates a genuine need for them, at which point they start easily because the organisation can already see why they are required. The diagram with eight columns is a useful map of where this ends up. It was never a route.

Disclosure

Alongside advisory work I also build a CMMS and CAFM platform, so I have a commercial interest in this category. Nothing above is a recommendation for it, and no vendor named here has paid for inclusion or had any editorial input. Weigh the analysis accordingly.

Planning a TPM pillar rollout?

Independent advisory on pillar sequencing, autonomous and planned maintenance design, loss measurement and the maintenance data foundation the pillars depend on. 22+ years across utilities, oil and gas, manufacturing, government and facility operations.

Book a conversation

Related reading: Total Productive Maintenance: the complete guide, OEE explained, The complete guide to preventive maintenance, PM KPIs and schedule compliance, Equipment criticality analysis, Root cause analysis methods, FMEA guide, RCM introduction, CMMS buyer's introduction.

Muhammad Abbas

CMMS / CAFM Manager & Independent Advisor · 22+ years across enterprise CMMS, EAM, CAFM and ERP implementations in utilities, oil and gas, manufacturing, government and facility operations.

Work with me
MAbbaz.com
© MAbbaz.com