You are between the last strategy document and the next commitment, and the last one reads like a cloud-AI artifact — transformation language, hyperscaler diagrams, and very little about the OEE impact, the IEC 61508 SIL classification your safety team will require, or the 36-month procurement cycle that governs how your plant buys physical systems. This is the Discover stage of the Hyperion Lifecycle at full enterprise scope: four weeks, embedded with your leadership and engineering teams, producing a single reconciled document that covers strategy, business case, ROI, and 12-month execution — anchored to the real constraints of physical-AI deployment. I've shipped 10 AI ventures including work on autonomous physical systems, written 11 articles on AI strategy for Forbes Technology Council, and serve as French Government AI Ambassador for Finance and Business Digital Transformation. The strategy I write survives a board conversation because it has already survived the engineering conversation.
The strategy was written for cloud AI and cannot address physical-system constraints. The previous document assumes elastic inference, network connectivity, and software-update cycles measured in days. Your actual deployment environment — factory automation, vehicle ECUs, substation SCADA, autonomous guided vehicles — has hardware provisioned for seven to twelve years, safety-critical update procedures, and OT networks with no path to the cloud inference stack in the strategy slides. The strategy needs to be rewritten from the physical system outward, not from the cloud platform downward.
OEE and yield impact are absent from the ROI model. The CFO and the plant manager need to see the impact in the language of operations: Overall Equipment Effectiveness, yield rate, Mean Time Between Failure, planned-versus-unplanned downtime ratio. A strategy that quantifies AI value in API cost savings and developer productivity is not a strategy the operations board can approve. The ROI model needs to be built in the units that operations accounting uses, with sensitivities on the variables that actually move outcomes — sensor-data quality, model retraining cycle, hardware refresh rate.
Safety-regime scope is unaddressed. If your AI system is embedded in or adjacent to a safety-critical function — a manufacturing robot, an ADAS stack, an autonomous guided vehicle, a grid protection relay — then the IEC 61508 SIL classification, the ISO 26262 ASIL decomposition, or the IEC 62443 zone and conduit model is part of the delivery scope, not an afterthought. A strategy that does not acknowledge the safety-regime timeline is a strategy that will be blocked by your safety and certification engineers six months before the planned go-live.
Physical-system procurement timelines are not reflected in the execution plan. Ordering a compute node for a substation, qualifying a new sensor vendor for an automotive line, or running a Factory Acceptance Test for an edge AI appliance takes months under procurement rules your IT team has never navigated. The execution plan needs to be built around these timelines — not the software sprint cycles the previous strategy assumed.
The engagement runs in four one-week phases, each ending with a draft you can react to. I work on site for the first and last weeks and embedded remotely in between. The output is a single document with four views — board view, CFO view, operations view, engineering view — all reconciled to the same underlying model and grounded in the operational, safety, and procurement constraints of your physical environment.
Structured interviews with the CEO, CFO, COO or VP Operations, head of engineering, the safety or certification lead, and two plant or operations managers whose P&L will carry the AI commitment. I review AI-related board decks from the past 18 months, all relevant vendor contracts, the current execution plan, the OT/IT architecture, and any existing safety assessments. By end of week one I produce a written diagnostic: where you are, what the previous strategy missed about physical-system constraints, and the three or four strategic questions the next document actually has to answer.
I draft the strategy spine — the commitments that hold regardless of which model ships next quarter. This includes the operational domains where AI is a competitive lever (OEE, predictive maintenance, quality inspection, autonomy) versus those where it is back-office efficiency, the safety-regime scope and its impact on timeline, the build-versus-buy-versus-partner boundary for physical-AI components, the sovereign and edge infrastructure requirements, and the explicit list of things this strategy says no to. End of week two: a 15-page strategy draft your leadership and engineering teams review and redline.
A quantified business case for each strategic commitment, denominated in operations units where appropriate: OEE percentage points, yield-rate improvement, MTBF extension, planned-versus-unplanned downtime shift. Sensitivities on the variables that actually move outcomes: sensor-data quality at training time, model-retraining cycle, hardware refresh rate, safety-certification lead time. Kill criteria: the conditions under which each initiative gets stopped rather than extended. Every number has a source — no unsourced industry statistics, no fabricated benchmark figures.
A 12-month execution plan that reconciles line-by-line to the strategy and the business case, with physical-system procurement timelines built in: hardware qualification windows, Factory Acceptance Test slots, safety-certification review periods, OT-network change-freeze windows. Specific initiatives, owners, quarterly milestones, success metrics, and dependencies. Week four ends with a 3-hour board-level readout where I walk the document with your leadership.
CEOs, COOs, and CAIOs at manufacturers, automotive OEMs, energy utilities, and infrastructure operators preparing a Q+2 AI commitment that involves physical deployment — on factory floors, in vehicles, at substations, in logistics facilities — and will be debated at the board. CFOs who need a defensible ROI model denominated in operations units, not just API costs. Safety and certification engineers who need the strategy to acknowledge their timeline before it is committed to the board. SMEs can commission the 2-week light version — same methodology, smaller surface area, same deliverable quality. This is not for pure SaaS companies with no physical operations — those organizations need the standard Strategy Sprint track.
Usually you wouldn't — but the fact that you're asking suggests the last one didn't hold under operational scrutiny. Big-four AI strategies are typically produced by analysts who have not shipped AI into physical systems and have not navigated a Factory Acceptance Test or an IEC 61508 gap assessment. If your existing strategy is surviving engineering review and reconciling to your actual procurement timeline, you don't need this engagement. If it is being rewritten every quarter because the physical-system constraints keep surfacing as surprises, that is what I'm built to fix.
Same methodology, smaller surface area. For an SME deploying AI into one or two production lines or vehicle programs, there are typically 2–3 strategic questions that matter rather than 8–10. The business case has fewer initiatives. The physical-procurement timeline section is shorter. The deliverable format is identical — strategy, business case, ROI model, execution plan — but compressed because the scope is smaller. The one thing I do not compress is the safety-regime section; if it applies, it takes the time it takes to be defensible.
Then we start from it rather than from a blank page, and the engagement becomes a rigorous pressure-test of the physical-system assumptions — OT/IT boundary, safety-certification timeline, procurement cycle — and a rewrite of the sections that have not survived that pressure-test. Bring the draft to the first interview. I will tell you on day two whether it is a starting point worth keeping or whether we are better off starting fresh from the physical-system constraints outward.
Yes, and I often do. Your automation partner owns the PLC programming environment, the OT network, and the systems-integration layer. I own the AI strategy, the business case, and the execution plan. We meet weekly during the engagement so the work products reconcile, particularly on the procurement timeline and safety-regime sections where the automation partner's knowledge of lead times and certification procedures is essential input.
Explore other services that complement this offering
30 minutes. I diagnose your situation, tell you honestly whether this service fits — and if it doesn't, what does.