The committee almost never votes against “digitalize.” It votes against a sentence it does not know how to approve. “Reduce incident investigation time” sounds fine in engineering. It does not say what is being authorized, with what money, under which owner, or what would count as failure. Without those pieces, the meeting postpones, asks for another slide, or turns the request into an open-ended platform.
This guide shows how to move from a technical benefit to a business sentence built only from records the plant already keeps, then put that sentence into a one-page case: owner, window, limit, and stop criterion. The worked example turns “reduce incident investigation time” into “recover weekly engineering hours now lost gathering data.” Every number in that example is labeled arithmetic on inputs the plant supplies (recorded hours, incident counts, window). Not an industry benchmark.
Not a savings percentage invented for the slide.
This is not investment advice. The only number valid for approval or rejection is the plant’s own, reviewed by whoever holds financial and operating authority. NIST documents heterogeneous metrics and limited national-scale understanding, not a local yardstick ready to sign (NIST publication page). This page does not choose the asset to buy; that belongs in plant investment decisions.
It also skips the five failure modes after the pilot (why industrial digitalization projects fail), the cost of searching for information (plant information search cost), and why a single engineer absorbs alarms and deviations (process engineer as plant bottleneck). The object here is narrower: a sentence the committee can sign.
The decision a committee can approve: scope, owner, horizon, and what stays out
A platform is not a decision. Phrases such as “deploy analytics” or “connect the historian” describe a catalog. They do not describe an act someone can authorize with a date and a limit (ISO 55000:2024). The committee needs a package that separates what will be tested, who owns the result, how long the evidence window runs, and what sits explicitly outside scope. Without that, the meeting debates technology while nobody has defined the work being authorized.
ISO 55000 places asset management in lifecycle value and organizational objectives, above the mere purchase of a system (ISO 55000:2024). Translated for a committee: the useful question is which operating value you mean to realize, with which asset or process, and under which plant objective. Tool novelty is secondary. NIST work on operations-driven performance measurement insists on characterizing the system and analyzing operational data before evaluating improvements (NIST performance measurement).
Asking for budget to “start measuring” without naming the problem goes the other way.
Scope is written in decision language. It includes the population (which lines, shifts, or product families), the task expected to change, and the measure that will be reviewed. The owner is not the vendor and not the committee as a bloc: it is a person with authority to free plant time, request records, and accept or reject the next step. The horizon is an evidence window, not a transformation slogan.
If the benefit depends on infrequent incidents, the window must be long enough to see several comparable events; if it depends on a specific shift, the window must cover that shift.
What stays out is written too. Out of scope may include expansion to other plants, replacing a control system, a headcount-cut promise, or any cash savings finance has not recognized. Declaring what is out does not weaken the case: it stops the committee from hearing a narrow sentence and accidentally approving an open transformation.
AACE 18R-97 classifies estimates by the maturity of project definition and reminds readers that the purpose of that classification is to improve communication among those who prepare, evaluate, and use cost estimates (AACE 18R-97). A digitalization case that reaches the committee with Class 5 (concept) definition should not be sold as if it already had the maturity of a detailed budget authorization.
The approvable decision, then, has four visible boxes: scope, owner, horizon, and exclusions. If one is missing, the technical sentence remains an engineering opinion. If all four are present, the committee can say yes, no, or “yes with this limit,” which is exactly the kind of vote a capital or expense meeting knows how to cast (AACE 18R-97). That vote is about an authorized act with a date and a boundary, not about liking a platform demo.
Keep the four boxes on the same page as the benefit line so nobody has to reconstruct the decision from a vendor appendix. When the boxes are filled in plant language, the non-technical members of the room can challenge the case without translating jargon first. If they still cannot, the request is not ready for a committee calendar slot.
The records the plant already keeps
The case does not start by asking for new sensors. It starts by inventorying what is already recorded: incident reports, downtime codes, timesheets, quality holds, and overtime. Each record proves something concrete and leaves other things unproven. Mixing those proofs is the fastest way to inflate a benefit the committee will not be able to defend three months later.
Douglas S. Thomas, in the NIST report on costs and benefits of advanced maintenance, details the line items needed to estimate costs and losses: direct maintenance and repair costs (labor and materials), downtime costs, lost sales from delays or quality, and rework or defects (NIST AMS 100-18). The same work notes that those line items should be separated by maintenance type with help from maintenance staff.
For a digitalization case before the committee, the lesson is not to copy a percentage from the literature: it is to use the same line-item discipline with local records.
An incident report can show that the event happened, when it opened and closed, and sometimes who intervened. It does not by itself show how many engineering hours went into gathering data versus diagnosing. A downtime code can show interruption of scheduled time if the plant uses that definition; it does not show opportunity cost or delivery impact.
A timesheet can show time charged to a work order or an investigation; it does not show that time will free up cash if nobody changes staffing or work scope. A quality hold can show that a lot was held; it does not by itself show cause or investigation time. Overtime can show extra load; it does not show that the cause is gathering incident data.
The NIST performance measurement project notes that performance improvements today come mostly from concrete applications, and that measurement science is needed to evaluate performance in the design and analysis of smart manufacturing systems (NIST performance measurement). In committee practice, that means choosing in advance which record feeds the case measure. If the measure is weekly engineering hours spent gathering data, the master record is the timesheet or the time log tied to incidents, not a new dashboard.
Michael Brundage describes a manufacturer that bought sensors before deciding what it would do with the new data, even though it already had maintenance work orders that were hard to analyze (NIST, How Do We Get Smart?). The example works here as a boundary: asking for new instrumentation to justify digitalization is often a sign that the case has not yet looked at existing records.
ISO 22400-1 requires, among other criteria, that an indicator be quantifiable, actionable, and understandable, and it characterizes each KPI by content (a quantifiable element with a unit) and context (a verifiable list of conditions) (ISO 22400-1). A plant record enters the case only if it can feed that content and that context without silent reinterpretation.
Every claim in the case points to an existing record. Every record declares what it does not prove. If a datum the plant does not capture is needed, the case names it as a gap. Inventing it as a benefit is what later collapses the review. Keep the inventory short enough to fit the one-page case.
Five record types are enough to start, and each one should carry a one-line “proves / does not prove” note next to the measure it supports. Without that note, a later meeting will treat a downtime code as a cash line, or a timesheet total as if finance had already converted hours into cost. An honest inventory of gaps still allows a bounded next step. A benefit that depends on a record nobody owns does not.
Translating a technical sentence into a committee sentence
The translation needs a mechanism, a unit, an owner, and a window. The mechanism says what changes in the work. The unit says how it is measured (hours, downtime events, held lots, or a cost finance recognizes). The owner is who lives with the result. The window fixes the observation period. Without those, “improve incident investigation” remains an intention.
Worked example. Starting technical sentence: reduce incident investigation time. Committee sentence: recover weekly engineering hours now lost gathering data. The mechanism is stopping the spend of engineering time assembling scattered records for each incident, not “more analytics.” The unit is engineering hours per week. The owner is whoever leads the investigation or frees that time. The window is the period in which incidents and hours will be counted.
The arithmetic is labeled as arithmetic on plant inputs, not as an industrial benchmark. Suppose the plant supplies, for a five-week window, its own inputs: 15 closed incidents in the agreed perimeter and a recorded average of 4.0 engineering hours per incident spent gathering data (not diagnosing or executing the repair). Then:
15 incidents × 4.0 h/incident = 60 h in the window
60 h ÷ 5 weeks = 12 h/week
Those 12 h/week come from the formula with those inputs (ISO 22400-1). If the plant supplies other numbers, the result changes. It is not a sector saving. It is not a vendor percentage. It is also not photographic evidence: the article image only illustrates the contrast between an incident note and a card in weekly hours. The 42 hours and EQ-4729 that appear in that photo are for illustration, not inputs for the case.
ISO 22400-1 indicates that operations KPIs are calculated from control-domain data and support decisions in the enterprise and MOM domains, and that a comparable indicator needs means to reference supporting measures over time and a normalizing factor with suitable units (ISO 22400-1). Converting the window total into hours per week is that kind of normalization.
It makes the load readable for a committee that thinks in weekly capacity, not in the sum of an atypical month.
The NIST report on maintenance costs reminds readers that published estimates use very different metrics and wide ranges, and that at national scale there is limited understanding of costs and losses associated with maintenance (NIST publication page). That is why this guide forbids importing a savings percentage from the literature into the local case. What can be imported is the line-item structure: separate labor, downtime, quality, and rework before adding (NIST AMS 100-18).
If the committee asks “and in money?”, the honest answer depends on finance. Recovered hours are not cash until there is a staffing decision, a scope decision, or an avoided cost finance recognizes. The case can show the hours line and, on another line, the condition under which finance would accept translating them into cost. Putting both into a single figure without that condition usually costs credibility at the next review.
Keep the conversion condition visible next to the hours so a later slide cannot quietly promote 12 h/week into a cash saving the plant never approved. The sentence the committee signs should still be the hours sentence; money is a second sentence with its own owner.
The one-page case
One page is enough if it concentrates what the committee can sign and leaves out the vendor catalog. The minimum format carries the cost of the next step, the benefit line, what is not claimed, a review date, and a stop criterion. Plant language. Records already cited.
The cost names the spend or effort of the next step (trial license, bounded integration, internal hours), not the price of a full platform. AACE 18R-97 aligns estimate class with definition maturity and with the intended use of the estimate (conceptual screening, study, budget authorization, control, or bidding) (AACE 18R-97). If the case only has early definition, the cost is presented as a low-maturity estimate, not as a closed capital line.
The benefit line repeats the committee sentence and the measure: for example, weekly engineering hours spent gathering incident data, with the formula and the plant’s inputs. ISO 55000 frames that benefit inside the value the organization expects to realize with its assets and objectives (ISO 55000:2024). There is no need to narrate digital transformation; there is a need for a line finance and operations can check against a record.
What is not claimed is written on the same page. No sector savings percentage is claimed. No claim that hours convert into cash by themselves. No claim that the pilot will scale to other lines. The World Economic Forum documented that more than 70% of industrial companies were still in “pilot purgatory,” and that among those piloting, many stumbled aligning value and return (WEF Beacons report).
Declaring what is not claimed is how the case avoids entering that purgatory with an open promise.
The review date is a calendar appointment, not “when the vendor finishes.” The stop criterion is fixed before spending: if on that date the measure has not moved within what was agreed, if the owner is missing, or if the records do not support the assumptions, the sponsor decides to stop, repair, or reduce. NIST stresses the need to characterize the system and use operational data to evaluate improvements (NIST performance measurement).
A stop criterion without a measure is follow-up theater.
The page fits a meeting if it avoids annexes that reintroduce the catalog. Extra technical detail belongs in an engineering appendix, not as homework the committee must finish before it can vote. Print the page or paste it into the agenda packet as a single block: cost of the next step, benefit line with formula, exclusions, review date, stop criterion, and named owner.
If someone asks for the vendor brochure during the meeting, answer with the same page rather than opening a second deck. The committee is voting on that block. When the block is complete, postponement for “more slides” needs a named empty box, not a vague request for polish.
Objections a non-technical committee raises
The usual objections do not ask for more jargon. They ask for proof that does not depend on new instrumentation or on the vendor slide.
Pilot theater. The committee has already seen demos that work for a day and do not change the shift. The World Economic Forum described pilot purgatory and the difficulty of aligning value and ROI when scaling (WEF Beacons report). Without new sensors, the antidote is dull and effective: the same case measure, a review date, a stop criterion, and records that already exist.
If the pilot is not fed by those records, it is not yet time to ask for it.
Vendor ROI. An attractive percentage enters the presentation and gets multiplied by local production. NIST documents that published maintenance estimates use different metrics and very wide ranges, and that the effect of advanced techniques is not well documented at national scale (NIST publication page; NIST AMS 100-18). Treat that ROI as an external hypothesis. Replace it with the local arithmetic from the previous section. The vendor can help design the test.
The number the committee approves is set by the plant.
Hours without an owner. The committee accepts that there is load, but does not see who will recover those hours or what will stop being done. ISO 22400-1 includes the criterion that a KPI be actionable: the responsible team must have the knowledge, capability, and authority to improve the indicator’s value within its process (ISO 22400-1).
Name the operating owner in the same sentence as the hours, and say which work is reduced or redistributed if the measure falls. Without an owner, the hours are a symptom.
One quieter objection remains: “what if we buy the platform first and write the case later?” Brundage describes buying sensors without knowing what to do with the data, while maintenance orders already held information that was hard to exploit (NIST, How Do We Get Smart?). The correct order is the reverse: first the business sentence with existing records; then the minimum tool able to move that measure.
AACE reminds readers that definition maturity conditions the estimate class and its use (AACE 18R-97). Buying the platform before the case is funding a definition that does not yet exist.
These answers do not ask for a new data-acquisition system. They ask for discipline over what the plant already writes: paper, the CMMS, the timesheet, the quality log. When an objection returns in the next meeting, answer it with the same four boxes and the same record inventory rather than a longer vendor deck. If the real worry is cash, bring finance into the conversion condition before the next vote instead of inventing a currency figure from hours alone.
If the worry is trust after past pilots, put the stop criterion and the review date at the top of the page so the committee can see the exit before it sees the spend. A non-technical room can stay in control of the decision without learning the stack.
Frequently asked questions
What can a committee approve when it does not speak the technical language?
It can approve a bounded scope, an owner, an evidence horizon, and a stop criterion expressed in hours, downtime, or cost with the plant’s own records. ISO 55000 places that decision in organizational value and objectives, not in system novelty (ISO 55000:2024). NIST asks teams to characterize the system and use operational data before evaluating improvements (NIST performance measurement). A platform without those four pieces is not an approvable decision.
The committee is authorizing a bounded act with a named owner and a review date, not endorsing a technology category. If any of the four pieces is missing, ask for the case to be rewritten before the vote rather than translating the jargon live in the room.
Is the vendor ROI enough to justify digitalization?
No. The vendor narrative is a hypothesis; the plant case needs a local baseline, a mechanism, a full load, and a stop condition with the plant’s own numbers. NIST shows wide ranges and heterogeneous metrics in the maintenance-cost literature, not an ROI that transfers to any site (NIST AMS 100-18). The WEF notes the difficulty of aligning value and return when leaving the pilot (WEF Beacons report). Plant finance decides which assumptions are acceptable.
A vendor percentage can inform the design of a test; it cannot replace the plant’s labeled arithmetic or the stop criterion written before spending.
How does “reduce incident investigation time” become a committee sentence?
It is expressed as recovering weekly engineering hours now lost gathering data, with labeled arithmetic on recorded hours, incident counts, and a window. ISO 22400-1 describes content, context, and normalization so the indicator is understandable and comparable (ISO 22400-1). The numbers come from the plant; they are not imported from a sector yardstick. Hours are not cash until finance recognizes the conversion condition.
Keep the mechanism (less time assembling scattered records), the unit (engineering hours per week), the owner, and the window on the same line so the sentence survives a non-technical reading.
Which existing records show the benefit without new instrumentation?
Existing incident reports, downtime codes, timesheets, quality holds, and overtime; each proves one part, and none alone proves cash return. Thomas details labor, downtime, quality, and rework line items that should be separated with help from maintenance staff (NIST AMS 100-18). Brundage warns against buying sensors before using knowledge already present in hard-to-analyze orders (NIST, How Do We Get Smart?). If the datum does not exist, the case declares the gap.
Choose the master record that feeds the chosen measure before asking for new capture, and write what each record does not prove next to what it does.
When should the digitalization case be stopped?
When, on the agreed review date, the evidence does not move the chosen measure, an owner is missing, or the case assumptions lack support in the plant’s records. The criterion is written before spending, aligned with the real maturity of the estimate definition (AACE 18R-97). Continuing to fund a pilot without a measure is the path into the purgatory the WEF documented (WEF Beacons report).
Stopping on time is a committee decision with evidence, not an engineering failure. Put the stop rule on the same page as the cost of the next step so the exit is visible before the spend is authorized.
Sources
- NIST: The Costs and Benefits of Advanced Maintenance in Manufacturing
- NIST AMS 100-18 (PDF)
- NIST: Operations-driven Performance Measurement for Smart Manufacturing Systems
- ISO 55000:2024
- AACE International: 18R-97 Cost Estimate Classification System
- ISO 22400-1:2014, public preview
- World Economic Forum: Fourth Industrial Revolution Beacons of Technology and Innovation in Manufacturing
- NIST: When a Manufacturer Asks “How Do We Get Smart?”
Talk to us
If you want to review a technical sentence from your plant and turn it into a one-page case (measure, records, owner, and stop criterion), talk to us. Bring a concrete problem and the records that already exist. WizeeMind helps organize the evidence; approval stays with the committee and the plant’s authorized functions.