{"id":344563,"date":"2026-08-04T10:00:07","date_gmt":"2026-08-04T10:00:07","guid":{"rendered":"https:\/\/scanda.com.mx\/?p=344563"},"modified":"2026-08-05T15:24:49","modified_gmt":"2026-08-05T15:24:49","slug":"como-presentar-una-tesis-de-inversion-en-datos-e-ia-que-un-consejo-de-administracion-no-pueda-rechazar","status":"publish","type":"post","link":"https:\/\/scanda.com.mx\/en\/how-to-present-an-investment-thesis-in-data-and-that-a-board-of-directors-cannot-reject-it\/","title":{"rendered":"How to present an investment thesis in Data and AI that an board of directors cannot reject?"},"content":{"rendered":"

The real problem: advisors no longer want to hear about \u00abROI\u00bb<\/strong><\/h2>\n\n\n\n

I have spent enough years sitting on the technical side and on the board to recognize that the pattern only begins to emerge during the presentation.<\/p>\n\n\n\n

The IT team or the CIO starts with architecture. They talk about models, platforms, capabilities. At some point, someone at the table asks: \u00abAnd what does this do to the business?\u00bb And that\u2019s where most data and AI projects start to die.<\/p>\n\n\n\n

They don't die because of a lack of technical ability. They die because of a lack of commercial rigor.<\/p>\n\n\n\n

An investment board is not evaluating whether the technology works. It assumes that it does \u2014 that\u2019s why you were hired or promoted. What it is evaluating is whether you, as the person responsible for that investment, understand the risk you are asking them to take with the shareholders\u2019 capital.<\/p>\n\n\n\n

\u00abThe \u00bbROI\u201d no longer convinces anyone in a board room. They have heard it hundreds of times, almost always without any operational backing. A return number without a specific business decision behind it is a promise, not a thesis.<\/p>\n\n\n\n

The difference between a project that gets approved and one that gets shelved is almost never in the technology. It\u2019s whether the presenter speaks the language of the board \u2014 capital, risk, margin \u2014 or the language of IT \u2014 features, platforms, roadmap.<\/p>\n\n\n\n

This article is about how to cross that bridge. Not with storytelling. With structure.<\/p>\n\n\n\n

The case: how the decision that was ultimately approved looks<\/strong><\/h2>\n\n\n\n

It is worth starting with a pattern that we have seen repeated in manufacturing, because that is where it is most clearly noticeable.<\/p>\n\n\n\n

The first version of this type of project almost always presents itself as a catalog of capabilities: sensors, OT\/IT integration, predictive models, a dashboard with plant visualization. Technically solid. Commercially orphaned. One consultant cannot approve a catalog \u2014 he doesn\u2019t know what he\u2019s buying in terms of business.<\/p>\n\n\n\n

The version that does convince starts differently. It doesn't open with the platform. It opens with a concrete operational decision: reducing the cost of production lost due to unplanned maintenance and variation in OEE (Overall Equipment Efficiency).<\/p>\n\n\n\n

That reformulation changes everything that follows. The request for budget is no longer for \u00aba data and AI project in the plant.\u00bb It is for a specific decision: how much capital are we willing to risk to recover the margin that is currently lost due to unplanned downtime and quality variability?<\/p>\n\n\n\n

This is the approach behind what Grupo Scanda calls plant operational intelligence \u2014 a best practice concept, not the diary of a particular client: connecting OEE, quality, maintenance, and the supply chain into a single data model, with the practice of Factory 360 as the way we execute it. The business case presented to the board does not talk about sensors or data architecture as the central argument. It talks about impact on OEE, reduction of unplanned downtime, and savings that in implementations of this type have exceeded $2 million dollars annually when the project is operating at full capacity.<\/p>\n\n\n\n

Technical depth \u2014 integration OT\/IT<\/a>, With predictive maintenance models, the digital twin of the asset \u2014 it\u2019s still there. But that\u2019s not the argument. It\u2019s the evidence that the thesis is executable, not the thesis itself.<\/p>\n\n\n\n

That is the change in attitude that a board needs to see: someone who is not selling technology but managing an investment with the same discipline with which they would manage any other capital of the company.<\/p>\n\n\n\n

The 4-layer framework for building the thesis<\/strong><\/h2>\n\n\n\n

What follows is the structure I use \u2014 and that I teach the teams I prepare to present to the board \u2014 to turn a data and AI project into a defensible investment thesis. Four layers. If one is missing, the thesis falters.<\/p>\n\n\n\n

Layer 1 \u2014 Identification of the operational decision (the business lever)<\/strong><\/h3>\n\n\n\n

Before mentioning a single data point, a single platform, or a single model, we have to answer a question: what business decision will change if this works?<\/p>\n\n\n\n

No \u00abwe will have better plant visibility\u00bb. That is not a decision; it is a desired state. The business lever is specific and actionable: \u00abwe will decide when to intervene on a team before it fails, rather than after\u00bb. Or: \u00abwe will decide which SKU to produce first based on real margin, not on arrival order\u00bb.<\/p>\n\n\n\n

If in your organization no one can name the operational decision that changes, you don't have a data and AI project. You have an experiment with a project budget\u2014and the advice, rightly, is getting increasingly harsh on that difference.<\/p>\n\n\n\n

This layer is the responsibility of the business area, not of IT. If IT comes alone to build this layer, you have already lost before you even started.<\/p>\n\n\n\n

Layer 2 \u2014 Documentation of the baseline (reality, without embellishments)<\/strong><\/h3>\n\n\n\n

This is where most projects weaken, because documenting the baseline forces us to expose uncomfortable numbers: how much is being lost today, with how much variability, and with how much certainty that number is known.<\/p>\n\n\n\n

A consultant will not believe a savings projection if you can't first show them, with precision, what the current cost of the problem you say you're going to solve is. Without a baseline, any improvement figure is a disguised result.<\/p>\n\n\n\n

Documenting the baseline means: actual cost measured (not estimated by eye), source of that data, quality of that source, and the range of uncertainty that exists today around that figure. If the baseline has gaps, those gaps are also documented. A more respectful advice is to document honest baselines with declared gaps than a perfect figure without substantiation.<\/p>\n\n\n\n

This layer takes more time than the teams want to invest. It is, without exception, the layer that most determines whether the thesis survives the questions of the board.<\/p>\n\n\n\n

Layer 3 \u2014 The data lever (which specific data changes the decision)<\/strong><\/h3>\n\n\n\n

Here\u2014and only here\u2014does the technical discussion enter. But it does so with a restriction: every data source, every model, every capability you propose must be explicitly connected to the decision of Layer 1.<\/p>\n\n\n\n

The question that needs to be answered for each technical component is: what operational decision becomes possible, or better, with this specific data? If you cannot draw that direct line, that component does not enter the first phase of the thesis\u2014it becomes a future phase, not the core of what you are asking to be approved today.<\/p>\n\n\n\n

In this type of plant operational intelligence project, the data lever is not \u00abhaving all the data from the plant.\u00bb It specifically refers to the combination of maintenance, quality, and equipment availability data that enables you to anticipate a failure before it stops production. Everything else\u2014the rest of the data model, advanced analytics, the full catalog of use cases\u2014lives in later phases, not in the initial thesis.<\/p>\n\n\n\n

This discipline avoids the most common mistake: presenting a data and AI project as a comprehensive transformation when what the board needs to approve is a limited, measurable bet with a clear path to the next phase.<\/p>\n\n\n\n

Layer 4 \u2014 Cancellation criterion (when to stop the project if there is no traction)<\/strong><\/h3>\n\n\n\n

This is the layer that makes the difference most between those who manage capital and those who sell technology. And it is almost always the layer that no one brings to the presentation.<\/p>\n\n\n\n

A board of directors not only wants to know what success looks like. They want to know, with the same clarity, what the sign that this is not working looks like\u2014and what to do when that sign appears.<\/p>\n\n\n\n

The cancellation criteria are defined before the project starts, not after six months of inertia and no one wants to be the one to stop it. It is defined in concrete terms: if in X weeks no movement is observed in the Capa 2 metric, the project is stopped, the hypothesis is revised, or the capital is reassigned.<\/p>\n\n\n\n

Bringing an explicit cancellation policy to the presentation does not weaken the thesis; it strengthens it. It tells the board that the person asking for the capital understands that they are also responsible for recognizing when the bet is not working\u2014and that they will not need the board to stop the project for them.<\/p>\n\n\n\n

The questions the council will ask \u2014 and for which layer you are preparing yourself<\/strong><\/h2>\n\n\n\n

If you built the four layers well, you already have the answer to the questions that an experienced board will ask. If you didn't build them, those same questions will show the gap in real time, in front of everyone.<\/p>\n\n\n\n