An AI project is first a data project. The statement is simple; its consequences are less so. When a model does not reach production, or reaches it without being used, the cause is rarely the algorithm. It lies in what surrounds it: the data that feeds it, the question it is asked, the place where its answer is delivered and the way it is followed once in service.
Four causes of failure
1. Scattered data and definitions that vary
Projects stumble on data spread across several systems, definitions that change from one department to the next and reference data nobody is accountable for. A model trained on data whose definition is not stable learns inconsistencies, not behaviours.
2. Populations that were not separated
Not all the lines of a fact table are equal. Credit notes, returns, partial payments, unallocated entries, inconsistent dates, extreme cases: if these populations are not identified and excluded by justified, traced rules, they blur the learning. This preparation step is the one that weighs most on the result, and the one most projects underestimate.
3. A deliverable that remains a notebook
A model that lives in a data science environment, next to the information system, is not used. For a prediction to serve a decision, it has to become a fact table integrated into the data model, displayed in the dashboard the teams already open, next to the actual indicator.
4. A model nobody measures or monitors
A model that is neither measured nor monitored degrades silently: the data changes, so do behaviours, and the prediction drifts away from reality without anyone noticing. Training traceability, continuous evaluation, hardened and monitored infrastructure are part of the project, not of a later phase.
How we avoid them
Our method for a predictive project comes in four steps, each with a verifiable deliverable: data preparation (documented training and test sets), modelling (quantified comparison, selected model and its limitations), predictions (prediction table integrated into the data warehouse) and delivery (operational dashboard and documented gaps). It sits within the DataReady approach that frames the engagement as a whole.
The commitment is decided step by step: a two- to three-week use case scoping, which ends with a scoping note and a reasoned decision to launch — or not — a proof of concept; a six- to ten-week fixed-price proof of concept, which delivers a measured model and an operational dashboard; then industrialisation and run. Nobody has to commit to a full programme to get started.
Two illustrations
At an international industrial equipment manufacturer, the on-time delivery rate was only measured after the fact. Seven years of orders accumulated in the Operations datamart made it possible to train a predictive model, provided justified, traced exclusion rules were defined with the business and explanatory variables were built from the order history. The prediction was integrated into the existing star schema and delivered in the dashboard already in use, next to the actual indicator. Read the case study
In the finance department of an industrial group, the cash forecast rested on theoretical due dates that customers do not keep. The fact table was split into settled and open invoices, partial payments, credit notes and unallocated entries were excluded, and the model learned for each account the usual gap between due date and payment. The forecast arrived as a “predicted payment” column in the existing customer accounts report. The model’s limitations were delivered together with its results. Read the case study
Start without waiting for an overhaul
You do not need a modern platform to get started. Our models are built on the data and the tools you have today. The method assumes nothing about the compute engine or the storage layer: if your architecture changes tomorrow, the models remain valid — only the way they are run and fed changes. An AI project therefore does not have to become the pretext for a technical overhaul, nor wait for one to finish before producing value.
To go further: the Artificial Intelligence & Automation page describes the method, the areas of intervention and the formats; the Data & AI Assessment gives an objective view of your data maturity before a first project.
Quantified results correspond to achievements measured on the scopes and datasets described; they do not constitute a performance commitment on any other scope. Offers flagged as "to be scoped" describe a proposed approach, not an existing achievement.