โ†
AI for Manufacturing
Strategic ยท M6 ยท lesson 6 of 21 ยท queued
Preview โ€” browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll โ†’
Building the Business Case
๐Ÿ“–
now learning

Building the Business Case

15 min

The plant manager liked the vision-QA pilot. The quality engineer who built it liked it more. So when the two of them walked into the quarterly budget meeting to ask for the money to deploy it across three lines, they had a slide that said "AI improves quality" and a screenshot of the green light catching a defect. The CFO listened for ninety seconds, then asked one question: "What is this worth, and how do you know?" The room went quiet. The quality engineer started talking about precision and recall. The CFO, who has approved capital for thirty years and has never once funded a sentence with the word "recall" in it, stopped him. "I am not asking how good the camera is. I am asking how many dollars this puts back on the table, when, and what happens to that number if you are wrong by half." The pilot was real. The save was real. But the business case did not exist, so the money did not move. This lesson is about building the number that would have moved it, the downtime, yield, and labor-leverage math that turns an AI idea into something a plant manager and a CFO will both fund.

Why the Case Decides the Deployment, Not the Demo

A demo proves the technology works on a good day. A business case proves the technology is worth more than what it costs over a year of bad days. These are different claims, and the gap between them is where most floor-AI projects die. The pilot impressed everyone, the rollout never got funded, and a year later the camera that caught a real defect is gathering dust because nobody could answer the CFO's question.

The reason this matters more in manufacturing than in almost any other field is the brownfield reality. Most readers do not run a greenfield plant where the digital infrastructure is already paid for. They run a plant with a 1990s PLC (Programmable Logic Controller, the industrial computer that runs the machine), a historian (the database that logs every sensor tag over time) nobody has queried in years, and a CMMS (Computerized Maintenance Management System, the software that tracks work orders and maintenance history) that techs update when they remember to. Greenfield plants deploy AI 40 to 60% faster than brownfield, which means your case has to carry the cost of the retrofit, the integration, and the slower ramp, not just the license fee. If your business case assumes a clean plant, it will be wrong by the exact amount of money it takes to make your plant clean enough.

The business case is also the artifact that protects you when the project is half done and somebody asks why it is not finished yet. A case with a documented baseline, a defined target, and a payback window is a contract with leadership. Without it, every delay reads as failure. With it, a delay reads as "we are at month four of a nine-month payback and tracking to plan." The number is not just how you get funded. It is how you stay funded.

A demo earns a meeting. A defensible number earns the budget. Build the number before you build the slide.

The Downtime Math: From the Pareto to a Dollar Figure

Unplanned downtime is usually the tallest bar on the loss chart, and it is the easiest place to build a clean, defensible number because the data already exists. Your CMMS knows when the line stopped, and your production system knows what a running hour is worth. The work is connecting the two.

Start with the cost of a downtime hour on the specific line you are targeting. This is not the maintenance labor cost; that is a rounding error. The real cost is lost contribution margin: the units you would have made in that hour, times the margin per unit, plus any scrap created during the unstable startup and shutdown around the event, plus expedite or overtime costs if the missed volume has to be made up. Suppose the target line runs 60 units an hour at $40 of contribution margin per unit. That is $2,400 an hour in lost margin before you count scrap or overtime. A single four-hour breakdown on a hot afternoon is $9,600 gone, and that is the conservative version.

Now pull the baseline. Say this line logged 180 hours of unplanned downtime last year, and the maintenance and reliability team agrees that a predictive maintenance (PdM, using sensor and historian data to flag a failing component before it stops the line) workflow could realistically address the failure modes behind 40% of those hours: the bearings, motors, and pumps that trend before they fail, as opposed to the random electrical faults that do not. Forty percent of 180 hours is 72 hours. Apply a conservative capture rate, because no model catches every save and some alerts will fire too late to act on. Assume you act successfully on 60% of the addressable hours in year one. That is roughly 43 recovered hours, times $2,400, or about $103,000 in avoided downtime in the first year on one line.

The discipline that makes this number survive the CFO is showing your work on every multiplier. Do not claim you will eliminate downtime. Claim you will address a named slice of it, at a stated capture rate, with the rest left on the table on purpose. A case that recovers 43 of 180 hours is more credible than a case that promises to recover 150, because the CFO has seen the 150 promise before and watched it deliver 30. Underclaim the recovery and overclaim your honesty. That is what gets funded twice.

Logging the save so the number is real later

The downtime number in the business case is a forecast. The number that keeps you funded is the logged save. When the PdM workflow flags a bearing and a tech replaces it on a planned weekend instead of during a Tuesday production run, that avoided breakdown has to be written into the CMMS work order in plain terms: the alert, the finding, the part replaced, and the production hours that would have been lost. One logged save with a dollar figure attached is worth more to your next budget ask than ten slides about model accuracy, because it converts the forecast into evidence.

The Yield Math: First-Pass Yield, Scrap, and the Escape

The second tall bar is scrap and rework, and the metric that drives it is first-pass yield (FPY, the percentage of units that pass every step the first time, with no rework). A vision-QA system earns its money in two distinct ways, and a strong business case separates them because they are funded by different fears.

The first is reducing the defect escape that becomes a customer containment. This is the catastrophic, low-frequency, high-cost event: the night the line was one inspector short, a subtle cosmetic defect slipped through, and 4,000 parts shipped to a customer. The containment that follows, sorting, return freight, the customer's line-down charge, the corrective action, the lost trust, can cost more than a month of the entire program. You cannot put a clean expected-value number on a rare event without overclaiming, so the honest move is to size it as risk reduction. State the cost of the last escape your plant actually had, state how often escapes like it occur, and present the vision system as buying down the probability of the next one. The CFO funds catastrophe avoidance differently than steady savings, and naming it honestly as insurance, with a real historical loss behind it, is more persuasive than burying it in an averaged annual figure.

The second is the steady scrap-and-rework reduction from catching defects earlier and more consistently than a tired crew on a thin shift can. This one you can model cleanly. Suppose the target line produces 400,000 units a year, FPY sits at 96%, and the cost of a scrapped or reworked unit averages $18. That is 16,000 bad units a year, or about $288,000 in scrap and rework cost. If a consistent vision system lifts FPY by 1.5 points, from 96% to 97.5%, by catching drift earlier and flagging the upstream cause before a bad run gets long, that is 6,000 fewer bad units, or roughly $108,000 a year on one line.

The false-reject line the CFO will find if you do not

Here is the number that separates an honest manufacturing business case from a vendor pitch: the false-reject cost. A vision system's false-reject rate (how often it flags a good part as bad) is real money flowing the wrong way. Every good unit the camera throws out is scrap you created, plus the operator time to review the false alarm, plus the erosion of trust that ends with an operator disabling the green light because it cried wolf one too many times. If your case shows $108,000 in scrap reduction but ignores a 2% false-reject rate that quietly scraps 8,000 good units at $18 each, you have hidden $144,000 of cost, and your real net is negative. Put the false-reject cost in the case yourself, before the CFO finds it, and show the net. A case that says "gross benefit $216,000, false-reject cost $40,000, net $176,000" is bulletproof. A case that only shows the gross is a case waiting to be shot down.

The Labor-Leverage Math: The Thinning Crew Is the Real Driver

The downtime and yield numbers are the ones the CFO scores. The labor-leverage number is the one that explains why this is urgent now and not next year. It is the talent cliff translated into the plant's own math.

The forcing function is demographic, not technological. Roughly 2 million manufacturing workers need reskilling by 2026 against about 500,000 unfilled roles, and 85% of manufacturers say staffing shortages are already hurting product quality. Your plant is living this: you are short three maintenance techs, the best quality inspector retires in November, and the new hires have never seen this machine throw this fault before. The business case for floor AI is not "replace people." It is "let a thinner, greener crew run a safe, high-quality line," which is the only honest framing and also the one that gets operator buy-in instead of operator sabotage.

Translate it into a number two ways. First, the productivity-per-head figure. If a knowledge-capture and AI-troubleshooting workflow lets a green tech resolve a fault in 40 minutes instead of the 2 hours it takes without the captured expertise, and that fault occurs 200 times a year, that is roughly 270 technician-hours returned to the floor annually. At a loaded labor rate of $55 an hour, that is about $15,000 a year, but the larger value is the downtime avoided while the green tech was stuck, which folds back into the downtime math. The labor number is real, and the throughput it unlocks is larger.

Second, the retention of expertise. When Dave the inspector retires, the plant does not just lose a salary; it loses the only person who could hear a bearing going bad and the only eyes that could spot a subtle cosmetic defect at line speed. Capturing his knowledge before November, into a knowledge base the AI and the next shift can both use, is the highest-ROI move a thinning plant can make, and it is nearly impossible to put a single clean number on because its payoff is everything that does not go wrong after he leaves. The honest way to carry it in the case is as the enabling investment: the captured knowledge is what makes the green crew productive on the troubleshooting workflow, so it underwrites the labor-leverage number rather than competing with it. Structured training programs see 3 to 4x higher adoption than self-directed learning, so the training line in your budget is not overhead; it is the multiplier that decides whether the rest of the case lands at all.

Assembling the Case: Investment, Payback, and the Honest Risk Line

Now you stack the pieces into one number leadership can act on. The benefit side, for the single line in the examples above, is roughly $103,000 in avoided downtime, plus about $176,000 net in yield improvement after the false-reject cost, plus around $15,000 in direct labor leverage, for a benefit near $294,000 in year one, with the escape-avoidance insurance value and the captured-knowledge value named separately as upside you are not putting in the headline figure.

The cost side is where brownfield honesty earns its keep. Count all of it: the software license or subscription, the cameras and sensors and the edge hardware, the integration labor to connect the system to your MES (Manufacturing Execution System, the layer that tracks production and routing), historian, and CMMS, the OT/IT (Operational Technology, the plant-floor control networks, versus Information Technology, the business networks) security work to put the model on the network safely, the operator and tech training, and the ongoing cost of managing drift, because a vision model degrades as lighting, camera angle, and material change between shifts and somebody has to maintain it. A case that shows a $60,000 license and hides the $90,000 of integration, security, and training is the case that blows its budget in month three and poisons the next ask.

Suppose the all-in year-one cost lands at $180,000 and the recurring annual cost at $50,000. Against a $294,000 year-one benefit, the simple payback is under eight months and the year-two return is strong because the heavy integration cost is spent. That is a number a CFO funds. Present it with three things attached and it becomes nearly unkillable:

  • The baseline, documented and dated. The 180 downtime hours, the 96% FPY, the $18 scrap cost, each pulled from the CMMS, the quality system, or finance, not estimated. A case built on real baselines can be audited after the fact, which is exactly what makes it credible before the fact.
  • A sensitivity line. Show what the payback looks like if you capture half the downtime hours you projected, or if the FPY lift is one point instead of 1.5. If the case still pays back inside eighteen months at half the benefit, you have answered the CFO's real question, which was never "what is the number" but "what happens if you are wrong by half."
  • A staged commitment. Ask for the money in tranches tied to evidence: fund the one-line deployment, prove the logged saves and the measured false-reject rate, then fund the rollout to the next lines from a position of demonstrated return. This lowers the leadership's risk and raises your credibility for the multi-line ask that comes next.

Avoiding the Vanity Trap and the Customer-Audit Cost

Two things quietly destroy otherwise good business cases, and both are about counting the wrong thing.

The first is vanity metrics. "Models deployed," "alerts generated," and "dashboards built" are not results; they are activity, and a CFO who has been around knows the difference. A business case headlined by "we deployed AI on four lines" with no dollar tied to any of them is a case that funded itself once and will never fund itself again. Every benefit line in the case must terminate in a number finance recognizes: avoided downtime hours converted to margin, scrap units converted to cost, technician-hours converted to throughput. If you cannot connect a metric to a dollar the plant controller would book, leave it out of the headline and put it in the supporting notes where it belongs.

The second is the cost the vendor never mentions and the catastrophic one to forget: the customer audit and the governance it requires. In manufacturing, the customer audits you, not the vendor. "The model flagged it" is never a sufficient answer to an IATF 16949 or AS9100 auditor or to a customer whose containment you caused. Any AI touching a quality decision has to log that decision in an audit-grade trail, keep the human accountable for the disposition, and stay advisory rather than in direct control, especially given that 78% of OT networks lack centralized monitoring and you cannot govern what you cannot see. This governance is not free. The documentation, the verification step, and the OT security work belong in the cost side of the case. A business case that wins the funding and then fails the customer audit has not saved the plant money; it has created a liability with a positive ROI slide stapled to it. Build the audit cost in, and the case is one that survives contact with the customer, which is the only kind worth funding.

Key Takeaways

  • A demo proves the technology works on a good day; a business case proves it is worth more than it costs over a year of bad days. The CFO funds the second, not the first, so build the defensible number before you build the slide.
  • Build the downtime number from the cost of a downtime hour (lost contribution margin, not maintenance labor) times a named, conservative slice of baseline hours at a stated capture rate. Recovering 43 of 180 hours credibly beats promising to recover 150.
  • Split the yield benefit into escape avoidance (sized honestly as insurance against a real historical containment cost) and steady scrap-and-rework reduction (modeled cleanly from FPY, volume, and per-unit cost).
  • Put the false-reject cost in the case yourself before the CFO finds it. A 2% false-reject rate can quietly turn a positive case negative, and showing the net (gross benefit minus false-reject cost) is what makes the case bulletproof.
  • The labor-leverage number explains the urgency: 2 million workers need reskilling, 500,000 roles are unfilled, and 85% say shortages hurt quality. Frame AI as leverage for a thinner, greener crew, never as replacement, and carry captured knowledge as the enabling investment.
  • Count the full brownfield cost: license, hardware, integration to MES/historian/CMMS, OT/IT security, training, and ongoing drift management. Greenfield deploys 40 to 60% faster, so a brownfield case that hides integration cost will blow its budget by month three.
  • Attach a documented baseline, a sensitivity line (does it still pay back at half the benefit?), and a staged, evidence-gated funding ask. These answer the CFO's real question, which is never the number but what happens if you are wrong by half.
  • Reject vanity metrics and budget for governance. Every benefit must terminate in a dollar finance recognizes, and the customer-audit, verification, and OT-security costs belong in the case, because the customer audits you, not the vendor, and a winning ROI slide stapled to a failed audit is a liability.