Equipment Management in the Post-Maintenance Era A New Alternative to Total Productive Maintenance (TPM)

1. 1Fix the goal first: write down that output and profit are set by equipment utilization, not availability. Availability, reliability (MTBF) and maintainability (MTTR) are inputs to that goal, not the goal.
2. 2Lay out the equipment's time and states as the source does (Figure 1.1: equipment time and states). Account for every hour in a state, so you can see where available time is not converted into productive time.
3. 3Build one indicator set for each piece of the construct, in the order the source uses: availability, reliability, maintainability, utilization. For each indicator define its purpose, its format and variation, and how it is presented. Safety indicators sit alongside them.
4. 4Put the four indicators for the same equipment on a single view. Read the utilization line against the availability line. A gap between them is time the equipment was available but not used, and maintenance metrics cannot explain it.
5. 5Trace each gap to its owner. In a functional setup, maintenance owns availability and operations owns utilization, so a gap between them often belongs to nobody. Name who closes it.
6. 6Add the process-side indicators that explain lost utilization: nonproductive downtime, labor productivity, and operational misses and error rates.
7. 7Check the failure pattern of the equipment (Figure 1.2) before choosing a response. Match the response to the pattern. Stable equipment suits classic maintenance management; fast-changing high-tech equipment needs a utilization-focused approach.
8. 8Review the structure. If the split between availability and utilization keeps producing gaps, consider a single owner for the whole equipment platform. The source describes this as platform ownership, covering utilization and development as well as keeping equipment operational.

The source's own case is organizational, not numeric, so this example uses placeholders instead of invented figures. In a traditional factory, the maintenance department reports availability and the operations department reports utilization. Suppose the availability report for a tool shows a strong figure, X%, while the utilization report shows a much lower figure, Y%. Maintenance considers its job done because the tool was available. Operations sees low output and cannot tell whether the cause is equipment or process. The source describes this pattern: because of the functional separation, the whole picture is not comprehended, and deficiency occurs in the overall equipment management process. Applying the construct, you lay both lines on one chart and itemize the X-minus-Y hours using the equipment states and the nonproductive downtime indicators. You then assign each category of lost hours to a named owner. The structural fix the source describes at leading high-tech companies is to merge these responsibilities under a platform owner, such as manufacturing engineering or equipment engineering services, who is accountable for utilization itself.

• If availability is high but utilization is low, stop improving MTBF and MTTR. Look at nonproductive downtime, process losses and operational misses instead.
• If two departments each report one half of the picture (availability versus utilization), assign a single owner for the gap between them before adding any new metric.
• If the equipment becomes obsolete before the end of its natural life, as in many high-tech settings, do not justify heavy life-extension effort with availability gains alone. Judge it by what it adds to utilization.
• If the equipment and environment are stable (building or traditional machinery maintenance), classic maintenance indicators on reliability, maintainability and availability are sufficient. Use them as they are.
• If an indicator cannot be tied to output or profit, treat it as a diagnostic and not as a target.

• Optimizing availability as the end goal: the maintenance report looks excellent while factory output does not move. The tell is a rising availability trend with a flat utilization trend.
• Reading each indicator in isolation: MTBF, MTTR and availability are reviewed in separate meetings. The tell is that no one can state the utilization consequence of a reliability or maintainability change.
• Gap with no owner: operations and maintenance each point to the other's metric. The tell is lost hours that appear in no one's report.
• Applying tactical fixes to a structural problem: TPM changed maintenance practices but left objectives and organization unchanged, so the function stayed optimized in isolation. The tell is better maintenance practice with the same overall results.
• Treating maintenance as a stable function in a fast-changing environment: the tell is a maintenance plan built around life extension for equipment that technology will make obsolete first.

• ▸Equipment / platform: name the tool or platform covered, including software and network elements if they belong to it.
• ▸Period: state the date range the figures cover.
• ▸Availability (%): enter the availability indicator as your company defines it.
• ▸Reliability (MTBF) and maintainability (MTTR): enter both values, using your own definitions and data.
• ▸Utilization (%): enter the utilization indicator for the same equipment and period.
• ▸Gap (availability minus utilization): calculate it and convert it to hours of available but unused time.
• ▸Gap causes: list the categories, such as nonproductive downtime, process losses and operational misses, with hours for each.
• ▸Owner per cause: name one accountable person or team for each category. 'Shared' is not an answer.
• ▸Action and review date: state one action to reduce the gap and the date you will re-measure it.

1. 1Write the definition into your reporting: utilization is the percentage of a specific period during which the equipment performs its intended function. Name the period (shift, week, quarter) and name the intended function (for example, manufacturing product). The source defines utilization over 'a specific time', so fix the denominator before you collect any data.
2. 2Separate utilization from the neighboring metrics, which are not interchangeable. Availability is the percentage of time the equipment is, or will be, in a condition to perform its function. Uptime percentage differs from availability: availability uses manufacturing time as the numerator, while uptime uses manufacturing time plus engineering time. Utilization measures what the equipment actually did. Keep four separate columns: safety, availability, reliability/maintainability, utilization.
3. 3Choose which utilization variant you report. The source names total utilization, operational utilization, and engineering utilization, and defers their exact formulas to its Chapter 6, which is not in your supplied material. Write each variant's numerator and denominator in one line on the report header and hold them fixed. Do not change definitions between periods.
4. 4Classify every hour of the period into mutually exclusive equipment time buckets, such as manufacturing time, engineering time, and downtime. Source the time from the equipment's state log rather than from operator recollection. Check that the buckets sum to the full period.
5. 5Calculate utilization for each piece of equipment, then roll up by tool group or platform. Report the trend next to availability so a gap between the two is visible. The source's logic is that maintenance optimizes availability, but only utilization determines the factory's output and profit.
6. 6Assign one owner for the whole utilization number. The source notes that operations typically owns utilization and maintenance owns availability, and that this split lets deficiencies slip through. Name a single accountable role, such as platform or equipment engineering, that carries both numbers. Leading high-tech firms have moved this way, merging maintenance into operations ('universal tech') or into equipment development ('platform ownership').
7. 7When utilization falls short of availability, trace the lost hours to time buckets, not to failures. Review them in the same meeting that reviews reliability (MTBF, MTBA) and maintainability (MTTR, MTTA) so the causes of lost time are examined together.
8. 8Review the number on a fixed cadence, and publish the definitions with it so any reader can recompute it.

The source gives no numeric utilization case, so this one is illustrative only; the numbers are hypothetical. It applies the source's definitions. A tool is scheduled for 100 hours in a week. The state log shows 70 hours of manufacturing time, 6 hours of engineering time, and 24 hours of downtime and idle. Per the source, uptime percentage uses manufacturing plus engineering time, so uptime is (70 + 6) / 100 = 76%. Availability uses manufacturing time alone as its numerator, so it is 70%. If the intended function is producing product, utilization is the share of the period spent doing that, so 70 of 100 hours is 70%. The 24 hours outside both buckets are where the output was lost, and that is what the source means by output and profit being determined by utilization. A maintenance-only view would see only the repair hours inside that 24. A utilization view asks about all of them. Under the source's organizational point, if operations owns the 70% and maintenance owns a separate availability figure, neither owns the 24 hours, so you assign one platform owner to both numbers.

• If the report shows only availability, MTBF, or MTTR, then add utilization; the source says maintenance indicators optimize availability while only utilization determines output and profit.
• If operations reports utilization and maintenance reports availability from different data, then move both under one owner and one time log; the functional separation hides the whole picture.
• If you are comparing 'availability' and 'uptime percentage' across sites, then check the numerators first: availability uses manufacturing time, uptime adds engineering time.
• If a utilization variant (total, operational, engineering) is quoted without its formula, then do not compare it with any other figure until the formula is stated.
• If utilization is below availability or below target, then break the lost hours down by time bucket before investing in more PM or maintenance staffing.

• Treating high availability as success. The tell: the maintenance dashboard is green while output and profit disappoint, and no one can say where the idle hours went.
• Splitting ownership between operations (utilization) and maintenance (availability). The tell: each group meets its own metric and blames the other when output misses the plan.
• Mixing definitions of availability and uptime percentage. The tell: two reports for the same tool and period show different percentages, and the difference equals the engineering time.
• Quoting 'utilization' without naming the variant, period, or intended function. The tell: the figure shifts when a new analyst or site produces it, with no change in operations.
• Rolling maintenance performance indicators into the utilization view and stopping at failure analysis. The tell: improvement actions all concern repair speed and PM schedules, and none address non-failure time losses.

• ▸Equipment / platform ID: name the tool or tool group measured.
• ▸Period and scheduled hours: state the exact start, end, and total hours in the denominator.
• ▸Intended function: write the one function that counts as productive (for example, manufacturing product).
• ▸Utilization variant: total, operational, or engineering; write its numerator and denominator in one line.
• ▸Manufacturing time (hrs): hours performing the intended function, from the equipment state log.
• ▸Engineering time (hrs): hours in engineering use, kept separate because uptime percentage adds it to manufacturing time.
• ▸Downtime and other non-productive hours: list each bucket and its hours; the buckets plus the two above must equal scheduled hours.
• ▸Utilization %, availability %, uptime %: compute all three from the buckets above, using the source's numerator definitions, and show the gaps.
• ▸Single accountable owner and top lost-time bucket: name one role for both utilization and availability, and the next action on the largest lost bucket.

1. 1Separate availability from utilization on paper. Availability is the share of time the equipment can perform its function. Utilization is what determines factory output and profit. Write both for each equipment type and stop treating one as a proxy for the other.
2. 2Find where ownership splits. In a functional setup, operations owns utilization and maintenance owns availability. Name the person accountable for each, and mark any gap where neither owns the equipment-to-output link.
3. 3Convert the downtime budget into hours. Take the availability target and multiply out the lost time. At TPM's 90% availability, a 7-day, 24-hour operation is off line 16.8 hours per week, about 2.5 hours per day. Compare that figure with your actual goal.
4. 4Set the availability goal by industry reality. The source states that semiconductor availability goals generally run 95% to 98%. TPM's 90% standard falls short of that. Check whether your PM and inspection time fits inside the allowed loss.
5. 5Rewrite the goals as process objectives. Replace maintenance-function goals (response time, waiting-for-parts time, maintenance cost) with goals tied to equipment output. Maintenance-method indicators measure the function, not the factory.
6. 6Weight the cost of idle capacity by equipment price. Under Rock's law, semiconductor equipment cost doubles about every 4 years, so each point of utilization lost costs more. Rank equipment by cost and put the largest improvement effort on the most expensive tools.
7. 7Review failure patterns per equipment type. Failure often has little connection to age, and once infancy failures are fixed, routine maintenance plays a minor role. Cut time-based PM where the failure pattern does not justify it, because that time is lost output.
8. 8Assign one platform owner per equipment platform. The owner covers capability development, support structures, methods and computerized systems, and is responsible for optimizing equipment output rather than only keeping equipment operational.

The source gives a TPM benchmark: 90% availability, 95% performance efficiency, 99% quality-part rate. Even if a factory hits all three, the equipment is still unavailable 10% of the time. In 7-day, 24-hour operation that is 16.8 hours per week, roughly 2.5 hours per day, taken for routine PM and inspections. A semiconductor fab with a 95% to 98% availability goal cannot accept this. At 95% the loss shrinks to about 8.4 hours per week (half of 16.8, by arithmetic from the source's 10% figure). At 98% it is about 3.4 hours. The gap is output that the TPM standard gives away, on equipment whose cost doubles about every 4 years. The fix the source points to is not more maintenance rigor. It is a process-level objective owned by an organization responsible for utilization as well as upkeep, which stops PM time being taken regularly and nonoptimally.

• If the equipment is expensive and technology-obsolescence cycles are short, then push for higher utilization and treat every non-productive hour as a direct profit loss.
• If a time-based PM interval has no link to the equipment's observed failure pattern, then shorten or drop it, since it consumes availability without reducing failures.
• If operations and maintenance report to different managers with different goals, then merge the goals into a shared process objective tied to output before adding any tools.
• If a goal such as 'zero breakdown' lowers overall availability because of the PM time it requires, then reject it and set the target on total availability instead.
• If a maintenance department's growth depends on more downtime, then do not use its workload or budget as a performance measure for the factory.

• Equating high availability with high output. The tell: availability reports look strong while output and profit stay flat, because utilization is not measured.
• Optimizing the maintenance function rather than the process. The tell: dashboards are full of response time, parts wait and maintenance cost, with no equipment output measure.
• Adopting TPM's 90% standard as a ceiling. The tell: scheduled PM consumes about 2.5 hours a day, and the target is 95-98% in your industry.
• Applying one failure assumption across the floor. The tell: age-based PM on machines whose failures are steady or driven by obsolescence rather than wear.
• Leaving a perverse incentive in place. The tell: the maintenance organization's budget and headcount grow with downtime, so it has no reason to eliminate it.

• ▸Equipment type: name the tool or platform being assessed.
• ▸Availability owner: name the person accountable for availability.
• ▸Utilization owner: name the person accountable for utilization; flag if it is a different person.
• ▸Target availability %: use the industry goal (for example, 95-98% in semiconductor).
• ▸Weekly hours offline allowed: compute (1 - target) x 168 for 7-day, 24-hour operation.
• ▸Weekly scheduled PM/inspection hours: enter actual planned downtime.
• ▸Observed failure pattern: infancy, steady, or age-related; decide whether time-based PM stays.
• ▸Equipment cost and replacement driver: enter cost and whether obsolescence or wear drives replacement.
• ▸Process objective: write one output-based goal replacing the maintenance-function goal.

1. 1Name the platform boundary first. The source defines a platform as everything associated with the equipment: tangible elements (network, facilities) and intangible ones (software, network connections). Write the boundary as an inventory of those items, because anything left off it stays orphaned in a functional department.
2. 2Map the current process as a functional setup. Record who owns utilization (operations) and who owns availability (maintenance), then mark where equipment development sits. The gaps between those owners are the deficiencies the source says the 'whole picture' misses. This is your before-picture, analogous to the book's Figure 9.1.
3. 3Merge maintenance with equipment development in one team rather than adding a coordinating layer. The source describes maintenance functions being 'merged with equipment development' under titles such as manufacturing engineering, equipment engineering services, or platform engineering. Choose the title, but make sure the department is accountable for utilization and development as well as maintenance.
4. 4Write the ownership charter as a list of responsibilities beyond keeping the equipment operational: equipment capability development, platform support structures, methodologies, a comprehensive computerized equipment management system, and a total solution for optimizing equipment output. Each item gets a named owner inside the platform team.
5. 5Set the objective at output, not availability. The source argues that only utilization determines output and profit, while maintenance optimizes availability. Replace availability-only targets with an output-oriented target for the platform team, and keep availability as a sub-measure.
6. 6Plan the whole lifecycle in the charter, including obsolescence. The source notes equipment often becomes obsolete from technology change well before its natural life. Require the team to hold an obsolescence view of its platform, not only a sustaining view.
7. 7Define the knowledge the owners need and train to it. The book devotes Table 9.1 to the platform owners' key knowledge requirements and Table 9.2 to training categories. Build your own requirements list from the charter in step 4, then assess people against it.
8. 8Migrate in the sequence the source's implementation chapter uses: environmental study, managerial preparedness, goal and value changes, psychosocial changes, technical changes, structural changes. Structure is last, so the reorganization announcement follows the preparation instead of replacing it.

The source's own example is a structural shift, so this walks through it. Under the traditional functional setup, operations is responsible for equipment utilization and maintenance for equipment availability. Each can do its job well while the overall equipment management process has deficiencies, because neither sees the whole picture. The source says the maintenance function is disappearing at leading high-tech companies, and one of the two routes is to merge it with equipment development in a department titled platform engineering, equipment engineering services, or manufacturing engineering. Applied to a single equipment platform, you pull the maintenance staff and the people who develop equipment capability into one team. You draw the boundary to include facilities, network, software, and network connections. You then hand that team the charter listed in the source: capability development, support structures, methodologies, the computerized equipment management system, and a total output-optimization solution. The before and after correspond to the book's Figures 9.1 and 9.2. What changes is that one accountable team owns the platform's output, not two functions each owning a piece of it. This is a structural illustration drawn from the passages. The book gives no performance numbers in the excerpts supplied, so none are claimed.

• If two departments each own a different metric on the same equipment (utilization vs. availability), then merge accountability into one platform team, because the source attributes the process deficiencies to this split.
• If the equipment environment is stable and the equipment is stable (building maintenance, machinery in traditional industries), then keep conventional maintenance management; the source says it is still suitable there and platform ownership targets fast-changing high-tech equipment.
• If an item is tied to the equipment (software, network connections, facilities) but has no named owner on the platform, then redraw the boundary or assign it before go-live, because the platform definition covers tangible and intangible elements.
• If technology change threatens to make the platform obsolete before its natural life, then the platform team, not a separate function, owns the obsolescence decision.
• If the reorganization is ready but the goals, values, and people changes are not, then delay the structural step, because the source puts structural changes last in the implementation sequence.

• Renaming the maintenance department 'platform engineering' without moving development or utilization accountability into it. The tell: the team's objectives still read as availability or PM compliance only.
• Drawing the platform boundary around the machine alone. The tell: software, network connections, or facilities issues bounce between teams and nobody inside the platform team owns them.
• Stopping at sustaining. The tell: no one on the team can state the obsolescence plan or the replacement trigger for the platform.
• Treating platform ownership as a tactical maintenance upgrade, like TPM, which changed practices but left objectives and structure alone. The tell: the practices improved but the org chart and goals are unchanged.
• Reorganizing first and preparing later. The tell: structure changes land before managerial readiness, goal and value alignment, and skill training, and the new owners lack the knowledge their role requires.

• ▸Platform name and boundary: list every tangible item (e.g., network, facilities) and intangible item (e.g., software, network connections) in scope.
• ▸Current functional owners: name who owns utilization, availability, and development today, and note the gaps between them.
• ▸Platform team name and members: record the merged team's title and which maintenance and development roles are in it.
• ▸Capability development owner: name who is accountable for developing equipment capability.
• ▸Support structure and methodology owner: name who owns support structures and methodologies.
• ▸Equipment management system owner: name who owns the computerized equipment management system for this platform.
• ▸Output objective: state the output-oriented target, with availability listed as a sub-measure.
• ▸Obsolescence view: give the technology-change risk and the trigger for planning replacement or retirement.
• ▸Knowledge and training gaps: list required owner knowledge and where current staff fall short.

1. 1Write one high-level objective for the whole equipment management process, and make it the charter for everyone involved. Tie it to corporate objectives and make it quantifiable. The source's model statement: achieve 90% equipment utilization through the provision of vigorous equipment platform services and support.
2. 2Widen the scope beyond availability. The source says the objective should cover customer satisfaction, equipment utilization, and equipment development, not only equipment availability. Test each goal by asking whether the user or the corporation would recognize it as their own goal.
3. 3Define the scope as the platform environment, not the machine. Include equipment utilization, equipment capability development, and sustaining equipment in all aspects (facilities, network, IT support). This removes the ownership gap in problems like equipment lockup, whose cause may be hardware, utilities, network, or software.
4. 4Demote the functional indicators. Availability, reliability, and maintainability (including MTBF and MTTR) receive less attention, and some may be phased out. Equipment changes so often that these averages never settle into a meaningful trend, and presenters spend their time explaining new tools, added machines, and upgrades. Stop reporting them as headline goals, or keep them as diagnostics only.
5. 5Cascade the process objective into department and job-level objectives. Job objectives follow the department's objectives. A maintenance engineer's goal (develop the PM system) and a technician's goal (perform PM per the procedures) have to be rewritten against the process outcome.
6. 6Phase the detailed goals in as the organization migrates. While maintenance still runs under its functional objectives, add one goal at a time: first owning the equipment purchase process, then certain engineering development tasks. Each new goal widens the scope until the department owns the entire equipment management process.
7. 7Declare the migration complete when all the added detailed goals are met. Add job-level goals so each employee's progress through the change can also be measured.

The source offers a model objective: achieve 90% equipment utilization through the provision of vigorous equipment platform services and support. Take a factory whose maintenance group reports availability, MTBF, and MTTR. Each report is dominated by explanations: a new tool, an added machine, an upgrade. Replace the headline goal with the 90% utilization statement, aligned with the corporate objective. Now an equipment lockup becomes the department's problem whatever its cause. Hardware, a utility shortfall, a network issue, or a software bug all count against the same utilization goal. Under the old setup, repair staff were released once the cause was judged unrelated to equipment, and groups pointed fingers at each other. Under the new charter, 'a robust platform environment', nobody can hand the problem off. Migration then runs in steps. While maintenance keeps its functional goals, a goal for owning the equipment purchase process is added first. A goal for certain engineering development tasks follows. When all detailed goals are met, the department owns the whole process.

• If a proposed goal can be met while the user's output is still lost, then it is a functional metric. Rewrite it around utilization or output.
• If an indicator's trend is dominated by explanations (new machine, upgrade, new tool), then demote or phase it out as a goal.
• If a problem's root cause is unclear (lockup from hardware, utilities, network, or software), then the equipment management group keeps ownership until the cause is found.
• If the department is still organized functionally, then phase in detailed goals one at a time (purchase ownership, then development tasks) rather than declaring a new charter all at once.
• If an objective cannot be quantified, then it is not ready to serve as the charter. Add a number, as in the 90% utilization example.

• Keeping availability as the headline goal while adding utilization on paper. The tell: reviews still open with availability, MTBF, and MTTR.
• Scoping goals to the equipment only. The tell: tickets bounce between equipment, facilities, IT, and software groups, and users are frustrated.
• Writing a vague charter with no number. The tell: no one can say whether the objective was met.
• Changing the department objective but not the job-level objectives. The tell: engineers and technicians still define success by PM schedules and task completion.
• Switching all goals at once instead of phasing them in. The tell: the department has a new charter but no ownership of purchasing or development, and cannot be measured against it.

• ▸Corporate objective: state the corporate-level goal this objective serves.
• ▸Process objective statement: one quantifiable sentence, e.g., 'Achieve __% equipment utilization through ___ platform services and support.'
• ▸Scope of platform environment: list equipment, facilities, network, IT support, and software covered.
• ▸Customer/user outcome: name the user need being served and how satisfaction will be judged.
• ▸Functional metrics demoted: list availability, reliability, maintainability, MTBF, and MTTR indicators and mark each 'diagnostic only' or 'phase out'.
• ▸Department objective: restate the charter in terms of the process outcome.
• ▸Job-level objectives: write one aligned goal each for engineers and technicians.
• ▸Phased detailed goals: list the order of added responsibilities (e.g., purchase process first, then development tasks) with target dates.
• ▸Completion test: state which met goals mean the migration is done.

1. 1Name one individual owner for each equipment platform. The passages define a platform as everything associated with the equipment, from tangible elements such as network and facilities to intangible ones such as software and network connections. List what falls inside each platform boundary before you assign anyone.
2. 2Match owner to platform complexity. Assign engineers to the more complicated and critical platforms and technicians to the less sophisticated ones. Engineers may own multiple platforms. Write the assignment down so no platform has two owners or none.
3. 3Give the owner the full lifecycle: engineering development, sustaining, and equipment transfer. The passages say owners are responsible for everything, complex or simple, associated with the platform they own. Do not split development from sustaining across people.
4. 4Set the owner's job objectives equal to the department's objectives, narrowed to that one platform. If every owner hits their platform objectives, the department hits its own. Check this sum before you finalize any objective.
5. 5Replace pooled responses with named responses. Under the maintenance setup, a pool of technicians works one downed machine, sometimes across shifts, and nobody answers for delays. Route each failure and each user complaint to the platform owner, who remains accountable even when others do the work.
6. 6Define the accountability trigger in advance. If a machine misses its performance goals or users are dissatisfied with service on a platform, the owner is the person who must act to improve their own performance. State this in the role description.
7. 7Remove the structural reasons ownership fails. The passages say splitting steps (acquisition, delivery, installation, acceptance, development, sustaining) across many functional groups leaves no clear ownership of any step or of whole-platform performance. Put the whole process under one platform engineering department, and have planning only tell owners when and how much equipment users need.
8. 8Track the result at the department level using the passages' indicators: headcount, downtime, scheduling, output, and employee morale.

The source contrasts two setups for the same problem, a machine that is down longer than it should be. Under the maintenance setup, a pool of repair technicians works the incident, and several may touch it, especially when the repair outlasts a shift. When the repair goes badly or runs long, no one can be named as responsible for the problem or the delay. At the departmental level, if certain equipment misses its performance goals, it is hard to tell whether the engineers or the technicians need to improve. Under platform ownership, each platform has a named owner. That owner holds objectives equal to the department's, scoped to the platform, and covers development, sustaining, and transfer. When the machine misses its goals or users are unhappy with service, the owner is the one who acts. The passages report that this structure shows up in headcount and downtime reductions and in improved scheduling, output, and morale across many high-tech implementation cases.

• If a platform's incidents are handled by a rotating pool, then name one owner and treat the pool as support, not as the accountable party.
• If a platform is complicated or critical, then assign an engineer. If it is less sophisticated, then assign a technician. If an engineer holds several platforms, then confirm each one still has a clear owner.
• If an owner's objectives do not add up to the department's objectives, then rewrite them. Scope them to the platform but keep them identical in kind.
• If a platform is missing its goals or users are dissatisfied, then ask the owner for an improvement action first, not a committee review.
• If a project needs a cross-functional team of many departments, such as bringing in new equipment, then treat that as a sign that ownership is fragmented. Consolidate the steps under platform engineering.

• Ownership by title only: the role says owner, but development, sustaining, and transfer remain split across groups. The tell: the owner cannot act on a problem without asking another department.
• Shared objectives persist: everyone in the same position still carries the same job objectives. The tell: after a bad repair, no one can say who was responsible.
• Owner scope limited to maintenance: objectives still cover only upkeep, not the whole platform environment. The tell: nobody owns software, network connections, or support structures.
• Meetings substitute for ownership: cross-functional teams and project meetings that pull in ten or more departments. The tell: employees say meetings consume much of the day and no one owns each step.
• Accountability aimed at the group: performance misses are discussed at the department level. The tell: you cannot tell whether engineers or technicians need to improve.

• ▸Platform name: the equipment platform being assigned.
• ▸Platform scope: list the tangible and intangible elements included, such as network, facilities, software, and network connections.
• ▸Named owner: one individual, and whether engineer or technician.
• ▸Complexity/criticality: why this owner level fits the platform.
• ▸Lifecycle coverage: confirm development, sustaining, and transfer all sit with this owner.
• ▸Platform job objectives: the department's objectives restated for this platform only.
• ▸Performance goals: the measures the machine must meet, such as downtime and output.
• ▸User satisfaction check: how users' view of service on this platform is collected.
• ▸Trigger for owner action: what miss or complaint requires the owner to act, and what they commit to do.

1. 1Test your own posture first: if your capacity model simply adds expected downtime (MTBF/MTTR-based) and buys more machines when output falls short, you are reactive in a proactive costume. The passage calls this still reactive because management accepts that downtime will occur. Set a target to remove causes, not just to forecast them.
2. 2Run RCM on the equipment where failure costs most (safety-critical or costly when it fails). Five steps: (1) identify all functions; (2) examine every way each function can be lost; (3) list the failure modes behind each loss; (4) classify consequences as safety, environmental, operational, or nonoperational; (5) write action plans that detect before-fail conditions, or install fail-safe systems when detection is not possible. Keep only actions that are technically possible and make sense.
3. 3Staff PM with the right people. Use entry-level workers (even operators) only if the task can be written as a detailed step-by-step procedure with little uncertainty or deviation. For complex, sensitive, or costly-to-fail equipment, assign your most skilled maintenance personnel. Pick PM inspectors as diagnosticians with a proactive mindset, planning ability, forecasting and statistical knowledge, and the reliability to work unsupervised.
4. 4Protect PM from firefighting. Repair calls outrank PM, so consider a separate PM crew that repair calls cannot pull away. Because a PM shortcut is invisible (the equipment is running when you start), add some form of verification and choose trustworthy people.
5. 5Write an efficiency-improvement section into every planning cycle. List the measures that raise uptime, reliability, and maintainability and cut maintenance cost: upgrading skills of maintenance and operations staff, new repair and PM procedures, new vendor contracts, a changed spare strategy, and transferring simple tasks to operations under TPM. This shows maintenance is not just waiting for failures.
6. 6Add a risk section to the plan with a mitigation tactic per risk. Scan the listed categories: significant equipment excursions; safety and ergonomic issues; process changes that demand new capacity; vendor support changes (warranty or contract termination, closure, ownership change, field-service cuts); spare and material availability and price inflation; new software environment (patches, security, connectivity); internal support changes (loss of key personnel, a new CMMS).
7. 7Manage customers rather than only serving them. (1) Negotiate mutual expectations, e.g., users flag failures in real time in the CMMS with a detailed description. (2) Track the production schedule and usage model like a weather forecast, and monitor how users operate the equipment if you can. (3) Educate customers to avoid unreasonable requests. (4) Communicate proactively about conditions that may lead to issues, and watch customers' hot buttons so bad news never arrives as a surprise.

The source describes a common pattern. A planning group uses MTBF and MTTR to compute how many machines are needed for a target output at a given confidence level, and builds expected downtime into the model. When a machine goes down, nobody is surprised, because the failure was budgeted. When output still falls short, the model is blamed as inaccurate and more machines are purchased. The passage labels this reactive: management has implicitly accepted downtime. The proactive correction is to leave the capacity model but add RCM on the machines that drive the shortfall. For each function, you list how it can be lost, the failure modes behind each loss, and the consequence category. You then set a detection action for before-fail conditions, or a fail-safe where detection is not feasible. You also assign PM to a separate crew of diagnostician-type inspectors, so repair calls cannot interrupt it. The test of success is that the downtime assumption in the model can be lowered, rather than the machine count raised.

• If a PM task can be fully documented step by step with little deviation, then entry-level staff or operators can do it; if the equipment is complex, sensitive, or costly when it fails, then assign your most skilled people.
• If repair calls keep displacing PM, then separate the PM crew from the repair crew.
• If the failure consequence is safety or environmental, then use RCM to find a before-fail detection action first and a fail-safe system only where detection is not possible.
• If output falls short and the proposed answer is more machines, then first ask what failure causes could be removed; buying capacity to absorb known downtime is reactive.
• If a plan lacks efficiency measures and mitigated risks, then add both before submitting it, since otherwise maintenance appears to be waiting for failures.

• Treating downtime forecasts as proactivity: the tell is a capacity model that raises machine counts when output falls short and never reduces expected downtime.
• Staffing PM with repair-minded people: the tell is PM done with minimal planning and little prediction, and inspectors who fix instead of diagnose.
• Unverified PM: the tell is PM marked complete on running equipment with no way to confirm the work, because shortcuts go unnoticed.
• Letting repairs preempt PM in a pooled team: the tell is PM tasks repeatedly postponed after repair calls.
• Over-serving customers until maintenance becomes a dumping ground for issues: the tell is production citing equipment as the excuse for missed output, with no agreed expectations, no real-time CMMS flagging, and no customer education.

• ▸Equipment / system: name the asset and why it matters (safety, cost of failure, output).
• ▸Functions and loss modes: list each function and every way it can be lost.
• ▸Failure modes and consequence class: for each loss, list failure modes and tag safety / environmental / operational / nonoperational.
• ▸Before-fail detection or fail-safe action: state the action; confirm it is technically possible and makes sense.
• ▸PM staffing and crew: skill level required, entry-level vs. skilled, separate PM crew yes/no, how completion is verified.
• ▸Efficiency improvements this cycle: skills, procedures, vendor contracts, spares strategy, tasks moved to operations.
• ▸Risks and mitigations: risk item (vendor change, spares pricing, software, personnel loss, etc.) paired with a mitigation tactic.
• ▸Customer agreements: mutual expectations set, real-time CMMS flagging, usage monitoring, education planned, proactive warnings.
• ▸Review date and owner: who checks this plan next cycle and when.

1. 1Pick one equipment type and write down how a failure travels today under the functional setup (the Figure 9.1 pattern): who detects it, who is called, who repairs it, who approves the return to production. Count each transfer between departments. That count is your handoff baseline.
2. 2Redraw the same path under the platform setup (the Figure 9.2 pattern). In the source, maintenance functions are either absorbed into operations (the universal tech concept) or merged with equipment development (platform ownership). Mark which handoffs disappear under each option.
3. 3Name one platform owner for the equipment. The source defines the platform as everything associated with the equipment, from tangible elements such as network and facilities to intangible ones such as software and network connections. The owner's responsibility runs from keeping equipment operational to optimizing equipment output.
4. 4Take a baseline with the source's own indicators: MTBF, MTTR, nonproductive downtime, labor productivity, and operational misses and error rates. Split each MTTR record into hands-on repair time and waiting time, since MTTR is an average of repair time and also tracks maintenance efficiency, skills, and training effectiveness. Waiting time is where handoff overhead shows.
5. 5Write the escalation structure (Figure 5.5 is the source's example) as a short list: problem type, who decides, and at what point it moves up. Remove any step where the person escalating could decide.
6. 6Challenge the PM schedule with the source's questions: What determines the current schedule? Can PM be done less often? Can it be eliminated through better reliability or by foreseeing failures? PM counts as scheduled downtime and affects output, so every unneeded PM stop is lost efficiency.
7. 7Re-measure after one full cycle on the same indicators. Count the handoffs, MTTR waiting time, and nonproductive downtime again. Keep the structure change only if handoffs and waiting time fall without a rise in operational misses and error rates.

The source's reliability example is a machine with an MTBF of 500 hours and an MTTR of 5 hours. It fails about every 500 hours and takes 5 hours to repair each time, so repair consumes about 1% of the failure cycle (5 of 505 hours, simple arithmetic). The lever is the 5 hours, because MTBF depends on equipment design and PM. Suppose you log those 5 hours and find (illustrative numbers, not from the source) that 3 are waiting for another department to diagnose, approve, or release the machine, and 2 are hands-on repair. That waiting is the handoff overhead the integrated structure targets. Move to a platform owner or universal tech who can diagnose, decide, and repair. The 3 waiting hours should shrink while the 2 repair hours stay. If MTTR falls without a rise in operational misses and error rates, the streamlining is real. If MTTR stays at 5, the structure changed on paper only.

• If most of MTTR is waiting rather than hands-on repair, then fix the decision path and handoffs first, not technician skill or training.
• If a failure is routinely escalated and the escalated decision is almost always the same, then move that decision to the first responder and drop the escalation step.
• If a PM task takes equipment offline and no one can state what unscheduled failure it prevents, then challenge or eliminate it, since PM is scheduled downtime that reduces output.
• If hands-on repair time is the long part of MTTR, then look at skills and training, because MTTR also reflects personnel skill and training effectiveness.
• If handoffs fall but operational misses and error rates rise, then roll back or add the missing skill coverage, because the speed was not efficiency.

• Renaming the department without changing the process. The tell: the handoff count from the baseline is the same after the reorganization.
• Treating PM as proof of smooth operation. The source calls this view incorrect because PM is itself scheduled downtime. The tell: PM hours are never questioned and the schedule traces back only to the manufacturer's recommendation or habit.
• Tracking only MTBF and MTTR averages. The tell: MTTR improves on paper while waiting time inside it stays hidden, so no one can say where the hours go.
• Giving ownership without authority. The tell: the platform owner still waits for approvals from other departments, so the escalation structure is unchanged.
• Measuring speed but not quality. The tell: downtime drops while error rates and operational misses are not reviewed.

• ▸Equipment/platform: name the one equipment type being studied.
• ▸Current setup: functional or platform, and which department owns each step from detection to return to production.
• ▸Handoff count: number of transfers between departments for one typical failure.
• ▸MTBF (hours): average time between failures from your records.
• ▸MTTR split: hands-on repair hours versus waiting hours, per failure.
• ▸Escalation points: each step where a decision moves up, and who makes it.
• ▸PM challenge: for each PM task, the failure it prevents, its downtime hours, and keep, reduce, or eliminate.
• ▸Quality guardrail: current operational misses and error rates, to compare after the change.
• ▸Re-measure date and result: handoff count, MTTR split, and nonproductive downtime after one full cycle.