On the first visit to a production facility, we don't bring a list of features. We bring three questions, refined over time through direct observation of different manufacturing contexts. They are not technical questions.
They don't ask which systems the company uses — that information comes later. First come the operational questions, and every project grows from the answers.
Not from the software. Not from the architecture. Not from a list of machines to connect. From the answers to these three questions we understand what information is missing, where the data that could generate it lives, and what the concrete value of having it would be. From there comes the first use case. From there, the pilot begins.
The Practice has two worlds. AQ holds aqumo's identity: who we are and what we believe in. OI holds the Operational Intelligence method: how we observe, diagnose, design, and deliver. The path is always the same, regardless of the project's size.
Running across all three phases are two levels that belong to none of them in particular: shared knowledge — the shared vocabulary, the interpretive framework, the catalogue of recurring patterns — and governance, the decisions that evolve the Practice over time.
The pilot is not a sales technique. It is a methodological verification: it serves to confirm whether the problem we identified matches the real problem, and whether the approach we propose is the right one to address it.
One of the reasons companies postpone digitalisation is the perception of risk. In manufacturing organisations, resistance to adopting new tools is rarely financial: it is almost always perceptual — memories of projects that did not deliver expected results, fear of implementation complexity.
That is why the barrier to entry is deliberately set to zero. No CAPEX, no multi-year commitment, no disruption to production.
Connection of the chosen data source via aSkimmer, data model configuration, first correlations across domains.
First operational dashboard, first answer to the managerial question defined together, presentation to management.
This is part of the "demonstrate" phase, not a separate service: after the assessment, alongside the diagnosis, we assess whether and how the project can be funded. Incentive schemes have precise requirements on what is eligible and in what form — if the project is designed with those requirements in mind, it remains fundable without being distorted to chase a grant.
The usual sequence is the wrong way round: you buy first, then look for the subsidy, and discover that the expense category is ineligible, that an expert appraisal was needed before the order, or that the investment had to start after the application and not before.
Every cost item has a nature — tangible asset, intangible licence, digitalisation, consulting, training, recurring cost. It is that classification, not the amount, that determines what is recoverable and through which scheme. Correctly separating hardware and licences from the outset, for example, changes the outcome: for funding purposes they count differently.
This is project structuring work, not grant-hunting. And it is done while the project is still being defined — afterwards, you can only take stock of the situation.
When two schemes are alternative regimes covering the same investment, only one can be used. Presenting the sum of everything as "recoverable" is the most widespread shortcut — and the least honest one.
The tax adviser remains the company's own accountant, who knows the full picture and takes responsibility for it. We bring experience in structuring an industrial project so that it remains eligible, and we provide the technical elements needed to assess it: the nature of expenses, timelines, required documentation. We do not replace the accountant and we do not submit applications on their behalf.
At the end of the assessment, alongside the operational diagnosis, we assess whether and how the project can be funded. Not because we are subsidised-finance consultants — we are not, and when that kind of expertise is needed we say so. But because the structure of an industrial project determines its eligibility, and that structure is what we design.
To do this we have built an internal tool that keeps an up-to-date database of grants and incentive schemes — European, national, regional, and sector-specific — and matches the company's profile and the project's real cost items against the requirements of each scheme.
Requirements analysis is handled by language models, which read the actual grant texts in the database and assess compatibility. However, amounts are not estimated by AI: they are calculated by deterministic code, based on the coverage percentages and ceilings declared by the scheme, applying cumulation rules and thresholds. This is the same rule we follow throughout — the model reasons, the code calculates.
The material is designed to be taken to your accountant: it contains the technical elements they need to make a decision, not a ready-made application.
It is delivered when the client knows how to use it, the team knows how to maintain it, and the documentation reflects what was actually built. This is the rule that holds the entire build phase together.
The solution design delivers the architecture: what to build and how, in architectural terms. The detailed design turns it into specifications that a developer can follow without needing to ask for clarification every hour — specific versions, physical schemas, precise endpoints, exact configurations.
The detailed design is the most critical moment. The choices made here — database schema, API contracts, technology stack, platform configuration — are hard to change afterwards. Time is invested here and cut elsewhere.
After the first production deployment, the database schema is never modified without a numbered, versioned migration. Never. Not even "for a quick fix".
A detailed design is complete when it allows a developer who was not at the kickoff to start working the next day.
The method is fully documented: from the principles that guide it to the operational guides for assessment, diagnosis, design, and delivery. This is not marketing material — it is the codification of a way of working built by visiting production facilities, observing the same problems, and trying to describe them with precision.
The observations running through these documents are not invented: they are field notes collected over time, recurring patterns, mistakes made and corrected. The method grows with every project.
It is a recurring pattern in industrial consulting: in the early stages of an engagement you bring a list of features. With experience you learn to bring questions instead. The difference does not lie in the product: it lies in the depth of understanding of the problem before any proposal is made.
It is the same reason our documentation openly states when we are not the right answer. Those who are honest about when their product is not the right fit earn the trust they need where it truly matters.
No product presentation. One hour to understand which decisions you make every week without the right data to make them well.