Most Portuguese industrial companies do not fail for lack of data. They fail because they have too much data, scattered across Excel files, the ERP, the invoicing system and the sales director's head — and nobody knows which is the true version. This guide takes a clear position: becoming data-driven is, above all, a problem of political authority, not of technology. And it gives you a concrete method to solve it — audit what you have, decide what matters and create a foundation that can bear the weight of day-to-day decisions.
The thesis nobody wants to hear
Becoming data-driven does not start with technology. It starts with a political decision: who has the authority to declare that a number is wrong?
According to INE, in 2025 only 53.7% of companies in Portugal used an ERP. Without an integrated transactional core, any BI initiative works on scattered data — and the resulting dashboards are, at best, an average of incompatible versions of reality. Real growth in analytics, therefore, but built on sand in many industrial SMEs. The production director still trusts the foreman's notebook more than the Qlik Sense screen — not because he is behind the times, but because the notebook never lied to him with poorly entered data.
The problem is not the software. It is the absence of an agreed source of truth. As long as the CFO calculates margin with one formula and the COO uses another, the organisation is not data-driven — it is data-confused. The industrial KPIs the CFO and COO disagree on are the most visible symptom of this problem, and the most expensive.
A data-driven organisation is not the one that has the most data. It is the one where everyone uses the same data to debate — and where disagreeing with the number requires proof, not opinion.
What you need before you start
Do not move on to tools without checking these prerequisites. Each missing one is a concrete reason for the project to stall halfway through — and in our experience with factories in the North, it is almost always the first or the last that is missing, not the ones in the middle.
You need an executive sponsor with real authority to resolve data conflicts between departments — not someone who "supports the initiative", but someone who can tell the sales director that the ERP number prevails over his Excel. You need at least one centralised transactional data source — ERP, invoicing system, WMS — that covers more than 80% of the business volume. You need to identify the three to five processes where a wrong decision costs the most money: production, purchasing, customer credit, stock, margin per product line. And you need a named data owner with allocated time — not a volunteer. It can be the financial controller or internal IT; it does not have to be a data scientist. What it cannot be is "everyone when they have time".
Before moving on, also define what is confidential: who sees margins per customer, who sees production costs, who sees salaries. And prepare the team to accept that some historical reports will show different numbers from the ones they know. That is information, not error.
Step 1 — Audit your data sources in 90 minutes
Bring together IT, the controller and an operations lead. Open a blank sheet. For each system the company uses, fill in the following table. It does not have to be exhaustive — it has to be honest.
| System | What it records | Update | Who trusts it | Known problem |
|---|---|---|---|---|
| ERP / invoicing | Sales, purchasing, stock, financial | Real time / daily | CFO, sales | Items without updated standard cost |
| Production Excel | Orders, times, scrap | Weekly (manual) | Production director | Different versions per shift |
| HR / time clock system | Attendance, overtime | Monthly | HR, payroll | Not integrated with production |
| Route sheets / paper | Operation times | Per order | Foreman | Not digitised, get lost |
| CRM / email | Pipeline, visits, complaints | Ad hoc | Sales (partially) | Incomplete, not mandatory |
By the end of the session you will have the real map of your data territory — not what should exist, but what does exist. Keep it. It is the working document for everything that follows. A detail the manuals rarely mention: the "Known problem" column is the most important in the table. If nobody writes anything in it, the session was not honest — start again.
Step 2 — Choose a business question, not a data project
The most frequent mistake we see in Portuguese industrial companies: they start with the infrastructure. They buy a data warehouse, install a BI tool, and then ask "what reports do we want?". The result is dashboards that measure everything and answer nothing — and that nobody opens six months later.
Do the opposite. Choose a business question with three characteristics: it has an identified decision-maker, it has a measurable financial impact, and the answer changes a concrete behaviour. "What is the real margin per product reference, after accounting for scrap and rework?" is a good question. "Which customers buy less than €X per quarter but consume more than Y hours of support?" is another. "In which production orders does the deviation of actual vs. planned time exceed 20%?" solves a problem the production director has every week. "What is the average collection period per customer segment — and how much does it cost in working capital?" is the question the CFO should have been asking two years ago.
One question. One decision-maker. A deadline for having the answer. Only then do you define the data needed to answer it. Read more on how to structure this process in Strategic planning with BI: when data replaces intuition.
Before moving on to the next step, confirm: does the question have a decision-maker with a name and role? Does the answer change a concrete operational or financial decision? Do the necessary data exist — even if scattered? Have you set a date for having the first answer?
Step 3 — Define your source of truth by domain
In a clothing factory in the Vale do Ave with 120 employees, it is common to have three different numbers for "fabric stock": the ERP's, the warehouse's Excel, and the one the foreman has in his head. All three are technically "right" — each measures something slightly different, with a different timing. The problem is not technical. It is the absence of an explicit declaration: for decision-making purposes, the official number is this one, updated in this way, by this person.
For each critical data domain, document on a simple page the official source — which system or file prevails in the event of a conflict —, the person responsible for validating and correcting, the update frequency, and the conflict rule: if two systems diverge by more than X%, who is notified and within what timeframe. Call it a "data contract" or whatever you like. This document is more valuable than any dashboard in the first six months. Without it, Self-Service BI becomes a factory of alternative versions of reality — and each department produces its own.
A specific mistake we encounter repeatedly: companies define the official source for stock and invoicing, but forget about margin. The result: sales presents gross margins, the CFO presents net margins with indirect cost allocation, and the management meeting spends half an hour working out why the numbers do not match. Declare the source of margin before building any financial report.
Step 4 — Measure quality before building reports
Before connecting any visualisation tool, spend a week measuring the data quality of your official source. It is not glamorous. It is what separates the projects that work from those that die within six months.
Four simple metrics to start with:
- Completeness: what percentage of records have all the mandatory fields filled in? Items without a standard cost, customers without a segment, orders without a cost centre — each empty field is a decision that will be made based on zero.
- Consistency: is the same concept coded the same way across all records? "Portugal", "PT", "PRT" in the country field seem like a detail until the day the sales-by-market report groups them wrongly and the sales director presents incorrect numbers to the board.
- Timeliness: what is the average delay between the actual event and its recording in the system? A goods receipt recorded two days later invalidates any real-time stock analysis.
- Uniqueness: are there duplicates — customers with two codes, items with duplicate references? In an ERP with ten years of life and three migrations, the answer is almost always yes.
You do not need a data quality tool to start. Basic SQL or a Power Query does the job. What you need is to record the results and share them with the executive sponsor. Data quality problems are not solved in IT — they are solved with operational processes and with the people who execute them. IT measures and reports; the purchasing manager is the one who has to enforce filling in the standard cost before saving the item.
Step 5 — Build the first dashboard for a decision, not for a report
A data-driven dashboard answers a question and suggests an action. A report lists what happened. The difference is not in the tool — it is in the design. And in most companies we have visited, the first dashboard built is a report disguised as a dashboard: 14 charts, three tables, two date filters and no indication of what to do next.
Apply this rule to the first dashboard: if the user cannot say, in less than 30 seconds, what to do next, the dashboard has failed. One main indicator at the top — the number that defines whether the day or the week is good or bad. Two or three context indicators that explain why the main number is where it is. A list of exceptions — the cases that need immediate action: overdue customers, orders with deviation, stock below minimum. No decorative charts. If it does not change a decision, it is not on the screen.
Before presenting to management, test the dashboard with real data and with the main user present. Ask them: "What would you do now?" If the answer is "I don't know" or "I'd have to go and check something else", the design needs to be revised. See how this principle applies in practice in Business KPIs: the operational guide for Portuguese industrial directors and in How a data-driven culture changes decision-making.
Common mistakes and how to avoid them
Starting with the software. Buying the BI tool before having the source of truth defined guarantees a six-month project that ends in dashboards nobody uses. The correct sequence is: business question → data source → data contract → quality → tool. Reversing any step in this order costs time and internal credibility.
Treating data quality as an IT problem. IT can measure and report. But the cause of an empty field in an ERP item is a purchasing process that does not enforce filling it in. The fix is operational, not technical. Involve the process owners from the outset — and formalise the obligation in the procedure, not in a request email.
Wanting to measure everything at once. A company that tries to build 40 KPIs simultaneously builds none of them well. Choose three. Make them work for 90 days. Only then expand. The pressure to "make the most of the project" and add indicators is real — and it is the most common reason BI projects lose focus and credibility before producing value.
Ignoring the access layer. Defining who sees what is not bureaucracy — it is the condition for users to trust the system. A dashboard of margins per customer accessible to the entire sales force creates commercial and GDPR problems at the same time. Define access profiles before publishing the first report, not after someone complains.
The transition to a data-driven organisation is not made in a quarter, nor with a single project. It is made with small, repeated decisions: declaring the official source of a number, resolving a version conflict, building a dashboard that one person uses every Monday. Scale comes later — when trust in the data is already embedded in the company's culture, not before.
Frequently asked questions
What does it mean for an organisation to be "data-driven"?
A data-driven organisation is one where everyone uses the same data to debate and decide. It is not about who has the most data, but about who uses consistent, agreed data. When there is disagreement about a number, one is obliged to prove it with data, not to opine. It is the opposite of "data-confused", where each department has its own version of the truth.
Why do data initiatives fail in Portuguese industrial companies?
They fail because they start with technology, not politics. Most have data scattered across Excel, ERP and isolated systems — nobody knows which is the true version. Without an agreed source of truth and someone with the authority to resolve conflicts, dashboards measure everything and answer nothing. The problem is not lack of data, it is lack of political authority.
What is the first step to becoming data-driven?
Auditing what you have in 90 minutes. Bring together IT, the controller and an operations lead. Map each system (ERP, Excel, CRM, etc.), what it records, how often it updates, who trusts it and what problems it has. This real map — not the ideal one — is the working document for everything that follows.
Do I need a data scientist to start?
No. You need a named data owner with allocated time — it can be the financial controller or internal IT. What it cannot be is "everyone when they have time". You do not need to be a technology specialist, but you have to have the authority to ensure the data is consistent and used correctly.
What is the most common mistake when starting a data project?
Starting with the infrastructure: buying a data warehouse, installing BI, and then asking "what reports do we want?". The result is dashboards that measure everything and answer nothing. Do the opposite: choose a business question with an identified decision-maker, financial impact and that changes a concrete behaviour. Then define the necessary data.
What prerequisites do I need before moving on to tools?
You need: an executive sponsor with real authority to resolve conflicts between departments; at least one centralised transactional source (ERP, invoicing, WMS) that covers more than 80% of the volume; three to five processes where a wrong decision costs money; and a named owner with allocated time. Without these, the project stalls halfway through.
How do I choose the first business question to answer?
Choose a question that has: an identified decision-maker with a name and role; measurable financial impact; and that changes a concrete operational or financial behaviour. Examples: "What is the real margin per product after scrap?" or "What is the collection period per customer and the cost in working capital?". One question, one decision-maker, one deadline.
Sources
- Instituto Nacional de Estatística (INE) — Statistics on ERP adoption in Portuguese companies (2025)
- ISO/IEC 27001:2022 Standard — Information security management and data governance in organisations
- Regulation (EU) 2016/679 (GDPR) — Personal data protection and compliance in information systems
- ENISA (European Union Agency for Cybersecurity) — Guidelines on data governance and information quality in critical infrastructures
- Banco de Portugal — Recommendations on operational risk management and internal control in financial data processes