Industrial BI with Qlik Sense: from raw data to operational decision

In a knitwear factory in Vizela, the previous day's production map comes out on a spreadsheet at 9:30 am — after the night supervisor has written the last hour's figures by hand, because the system "didn't close the shift in time". At 11 am, when management looks at that map, the operators are already producing the next order. The report describes a world that no longer exists. This is not a lack of data. It is an excess of dead data.

The thesis of this article is simple and uncomfortable: most industrial BI projects in Portugal fail not because of the tool, but because companies buy dashboards before solving the latency and reliability of data collection on the shop floor. Qlik Sense — or any BI engine — is only worth as much as the data that feeds it, and the speed at which it arrives. This text is about the whole journey: from sensor to decision, with the Portuguese industrial context that international manuals ignore.

1. The real operational problem

Let us start at the wrong place where almost everyone starts: the pretty screen. An industrial director sees a Qlik Sense demonstration at a conference, is enchanted by the interactive charts, and returns to the factory convinced that their problem is visualisation. It is not. Their problem is that no one knows, at 2 pm on a Tuesday, how many conforming pieces came out of the finishing section that morning without phoning three people and opening two Excel files.

Data is born late, incomplete and scattered

In a typical Portuguese industrial SME, operational data lives in silos that do not talk to each other. The ERP has the orders and the invoicing. A spreadsheet has the production map. The supervisor has the machine stoppages in their head (or in a notebook). The warehouse has its own system — when it has one. And quality records non-conformities on a form that someone keys in at the end of the week, if there is time.

When everything is finally brought together, the data is two, three, seven days old. It serves to account for things. It does not serve to decide. And deciding with yesterday's information, in a factory that changes articles three times a day, is driving while looking in the rear-view mirror.

There is a subtlety that rarely comes up in digitalisation conversations: scattered data is not just slow — it is contradictory. The supervisor's spreadsheet counts pieces produced; the ERP counts pieces invoiced; quality counts conforming pieces. All three refer, in theory, to the same batch. They almost never match. And when they do not match, management's time is spent reconciling figures instead of deciding on them. In a Monday morning meeting, it is common to see forty minutes consumed discussing which of the figures is right before even reaching the decision the meeting existed to take.

Latency has a cost that no one accounts for

No one opens a line in the accounts called "cost of deciding late". But it exists. A line that stood idle for forty minutes for lack of material — because the shortage warning only appeared on the next day's map — costs productive capacity that does not come back. An urgent order accepted without knowing that the critical line was already overloaded generates a late delivery, a contractual penalty, and an irritated parent company. These costs do not appear in a spreadsheet because they are diluted across a thousand small decisions taken with old information.

The empirical rule we apply: the shorter the production cycle of an article, the more toxic the information latency. A dyeing works that turns a batch around in hours cannot take decisions with daily data. A metalworking shop working long-run series parts has more margin. The urgency of BI is not measured by the size of the company — it is measured by the speed at which the operation changes state.

The case of the garment maker subcontracting for Inditex

A garment-making house in the Famalicão–Guimarães axis working for large chains faces a specific pressure: the parent company demands indicators of deadline compliance, defect rate and batch traceability — often on its own portal, with tight deadlines. If the factory cannot extract these figures reliably and quickly, it spends expensive people compiling reports by hand, and even then delivers figures that do not match the reality of the line.

The pressure has intensified with the EU Strategy for Sustainable and Circular Textiles. The large brands push onto subcontractors the demand for traceability of raw material origin, water consumption per batch in the dyeing works, and fibre composition at article level. This is not an annual sustainability report — it is a data point the parent company requests batch by batch, and that the factory can only provide if it captures it at source. A garment maker recording production on paper simply has no way to respond. And the brand does not wait: it chooses the supplier that responds.

Industrial BI does not serve to make prettier reports. It serves to shorten the distance between what happened at the machine and the moment someone with authority acts on it.

Footwear and the curse of the 1000 SKUs

In Felgueiras, a sample collection easily has 800 to 1200 SKUs, crossing model, colour, size and last. International buyers visit twice a year — men's footwear mainly in August, women's in February. When the buyer asks "how much of this model can you produce in brown leather, sizes 39 to 44, for delivery in eight weeks?", the answer depends on capacity data, raw material stock and line loading that no spreadsheet can cross in useful time. The order is lost by deciding slowly.

The footwear problem is structural and poorly served by generic tools: the three variant axes (colour, size, last) multiply explosively. A generalist ERP treats each combination as an independent article — and management collapses under tens of thousands of lines. A system designed for the sector models the variant as a matrix, and the BI resting on it can answer the buyer's question in minutes, not days. The difference between winning and losing the order is often exactly here: in the ability to give a reliable figure while the buyer is still sitting in the room.

The warehouse and the manager who won't put down the radio

There is a character who decides the fate of half the projects and who rarely appears in the room where the contract is signed: the warehouse manager of a distribution centre in the Lousada–Paços corridor. This man coordinates picking, cross-docking and dispatch by radio, and knows the layout better than any floor plan. Any system that forces him to leave the radio for more than two hours to "receive training" will meet fierce resistance — and rightly so. The operation does not stop because BI has arrived.

The operational lesson: data collection in the warehouse has to happen within the existing workflow, not at its margins. A warehouse management terminal that confirms picking with a scan is accepted; an additional screen where someone has to "record what they did" is sabotaged on the first day. Distribution BI is only reliable if the data is born from the gesture the operator already makes anyway.

2. What exactly is industrial BI Qlik Sense Portugal

Industrial Business Intelligence is the discipline of collecting, integrating, modelling and presenting operational and financial data so as to support decisions — preferably before the problem costs money. Qlik Sense is a BI and data analytics platform that runs this cycle with a technical characteristic that distinguishes it: the in-memory associative engine.

The associative engine — why this matters

Most BI tools work by hierarchical queries: you choose a dimension, drill down, filter. Qlik's associative engine loads the data into memory and keeps all the relationships between all the fields simultaneously. In practice, when a director clicks on a specific machine, all the other charts — shifts, articles, defects, operators — react instantly, showing what is associated and, more importantly, what is not. That "grey" (what is excluded from the selection) is frequently where the answer lives.

A concrete factory example: a certain type of finishing defect is selected. The charts show which machines, which shifts and which operators are associated with that defect. But the real value appears in reverse — the list of operators that stays grey (that is, who never produced that defect) tells you where the good practice is that should be replicated. Hierarchical tools hide this absence; the associative engine makes it visible. In a non-conformity root cause investigation, this ability to see what is not there saves hours of manual cross-referencing.

The terms you will hear and what they really mean

• ETL / data load — the process of extracting, transforming and loading data from the sources into the model. This is where the overwhelming majority of the real work of a BI project happens, and it is the part no one shows in demonstrations.
• Data model — the structure that links fact tables (production, sales, stoppages) to dimensions (time, article, customer, machine). A poorly designed model gives wrong figures with total confidence.
• KPI — an indicator that measures something that matters to a decision. If no one acts on it, it is decoration.
• OEE — Overall Equipment Effectiveness, the indicator that combines availability, performance and quality of a piece of equipment. It is the king figure of production BI — and the most falsified when calculated by hand.
• MES — manufacturing execution system, the layer that captures what happens at the machine in real time. Without this layer, production BI is blind to the present.
• MRP — material requirements planning, the engine that translates orders into purchasing and production needs. It feeds purchasing and planning BI.
• Data Lake — a repository where raw data from multiple sources is stored before modelling it. Useful in complex scenarios; excessive for most SMEs.

It is worth distinguishing BI from real-time operational dashboards. The operational panel that production uses minute by minute and the analytical report that management reads at month end are different things, with different latency requirements. Confusing them is the source of half the frustrations.

A brief history — where this comes from

Qlik was born in Sweden in the 1990s with QlikView, a product that popularised in-memory associative analysis at a time when BI was the territory of heavy static reports. Qlik Sense, launched in 2014, rebuilt that philosophy in a modern architecture, oriented to self-service, responsive and with centralised governance. For industry, the relevant change was allowing a supervisor to explore their own data without waiting for a report from the IT department.

This transition — from a static report requested from the IT department to autonomous exploration by the business user — is the turning point that changes the economics of BI. In the old model, each new question generated a request, a queue of days, a report that no longer answered the original question by the time it arrived. In the associative model, the supervisor clicks, filters, discovers, and acts the same day. For an industrial SME that does not have a team of data analysts, this autonomy is not a luxury — it is the only way for BI to survive the initial enthusiasm.

3. The landscape in Portugal today

It is worth anchoring the conversation in real figures, not in tech-fair enthusiasm. According to INE, in 2025 only 45% of companies in Portugal carried out data analysis (big data/analytics) — 6.4 points more than in 2023. Adoption is growing, but data-driven management is far from universal. Most still decide by intuition and experience, which in a factory with tight margins is an increasingly expensive luxury.

More revealing still: only 53.7% of companies in Portugal used an ERP in 2025 (INE). This has a direct consequence for BI — almost half of companies do not have an integrated core from which to extract coherent data. Doing BI over data scattered across spreadsheets and isolated systems is possible, but it is like cooking with ingredients of unknown quality: the result is unpredictable.

Without an ERP functioning as a single source of truth, BI does not eliminate the confusion — it amplifies it, giving it the appearance of rigour.

The cloud is still a minority

In 2025, only 38.7% of companies in Portugal purchased cloud services (INE). This matters for BI because modern analytics architectures — Qlik Cloud included — increasingly assume a cloud model. Many Portuguese industrial SMEs still prefer to keep data in-house, for reasons of control, predictable cost and legitimate distrust. It is an architecture decision that conditions the whole project.

This distrust has concrete roots, it is not irrational. A factory that has spent thirty years controlling its own servers is wary — with some reason — of a model in which production data, costs and margins live on third-party infrastructure. The answer is not to convince it by force that the cloud is always better. It is to design the architecture that makes sense for its risk profile: on-premises for the most sensitive data, cloud for what gains from scale and remote access, or a hybrid model. The decision of where the data lives should precede the decision of which BI tool to buy — and not the other way round.

The digital skills gap

There is an obstacle that adoption figures do not capture: the scarcity of people capable of keeping a data analytics system running. In the typical Portuguese industrial SME, the "IT manager" is frequently a self-taught professional with fifteen years of deep business knowledge and no formal training in data science. It is a hugely valuable figure — they know every process exception, every difficult customer, every machine that needs pampering. But asking them to design a multidimensional data model from scratch is asking too much.

This profile conditions the choice of architecture decisively. A BI platform that requires a dedicated team of analysts will fail in a company where that team does not exist and will not exist. The right tool for this reality is one whose data model arrives pre-designed by the supplier who knows the sector, leaving the internal figure with what they do well: validating that the figures make sense against the reality only they know.

Where there is money and where there is movement

The Portuguese metallurgical and metalworking sector has over 23,000 companies and about 250,000 people employed (AIMMAP / Metal Portugal). It is a huge universe, with very uneven digital maturity: from the Marinha Grande foundries with advanced Industry 4.0 to family metalworking shops that still close the month in a notebook. In commerce, turnover reached €201.8 bn in 2024, with retail growing 4.7% (INE) — pressure that pushes chains to analyse margin, stock rotation and performance per store better.

In textiles and footwear, the movement is different and comes from outside: reshoring. As European brands have reweighed their dependence on Asian production — pulled by the volatility of transport costs, by shorter delivery times and by regulatory sustainability pressure — Portugal is recovering orders. But those orders come with demands for traceability and rapid response that the factory only meets with reliable data. Reshoring does not reward those who produce cheaply; it rewards those who produce with information. This is where industrial BI ceases to be a discretionary investment and becomes a condition of market access.

Retail and the pressure of certification

In retail, especially regional food and specialised retail, digitalisation is not optional — it is imposed by compliance. The POS software has to be certified by the AT, e-Fatura has to communicate, the ATCUD has to be on every document. A regional chain with twenty-two stores that still lives off Excel sales maps per store is leaving money on the table in stock rotation, in avoidable shortages and in performance compared across stores. Retail BI answers questions the store manager cannot answer alone: which articles rotate better in this store and worse in that one, and why.

4. The industrial BI implementation models

There is no one right way to implement BI. There is the right way for your company, given the size, the maturity of the data and the urgency. These are the four approaches we see in practice, with their real costs — not the promised ones.

Model 1 — the honest starting point

Starting with ERP extractions is not defeat, it is prudence. A factory that never had BI gains enormously simply by having, on a single screen, the invoicing, the margin per customer and the stock rotation — even if the data is from yesterday. It is fast, cheap and teaches the organisation to trust data. The mistake is staying here forever.

This model has an underrated pedagogical virtue: it creates the habit of looking at data. In an organisation that has always decided by intuition, the cultural change is the greater obstacle — not the technique. A margin-per-customer panel, updated daily, that the sales management starts opening every morning, changes the company's conversation. You move from "I think this customer is one of the good ones" to "this customer has an 8% margin and takes up 20% of capacity — why?". When that habit takes hold, the organisation itself begins to ask for fresher data. And that is where the evolution to the following models ceases to be a sale and becomes an internal demand.

Model 2 — the direct connection to the ERP

When the habit is installed, daily latency begins to grate. The sales management wants to know the order book now, not as it was last night. The direct connection to the ERP database — instead of periodic exports — solves this for the sales, purchasing and stock areas. It is a moderate leap in complexity: it requires care not to overload the ERP's production database with heavy queries, but it is well-known territory. For a commercial or distribution SME, this is frequently the model that delivers the best value-per-effort ratio.

Model 3 — where industrial BI becomes industrial

The difference between generic BI and industrial BI is here: connecting BI to real-time production capture. A MES layer is needed — in our case, KORA Productivity captures production, stoppages and efficiency directly at the shop-floor terminals. Only with this flow does OEE stop being a figure calculated by hand at month end and become a live signal. It is also the most demanding model, because it involves the shop floor, the operators and the natural resistance to change.

OEE calculated by hand at month end is, almost always, a comforting fiction. Short stoppages — five minutes here, ten minutes there to change article or clear a jam — are not recorded because no one has time to note them. The result is an inflated OEE that hides precisely the problem it ought to reveal. It is common for a factory to discover, on capturing stoppages in real time for the first time, that the real OEE of a line was substantially lower than it always reported — not because the line got worse, but because the truth is finally being measured. This moment is uncomfortable and essential: without it, all capacity investment decisions rest on a false figure.

The production manager who hides the KORA tablet under a box with sticky tape is not sabotaging the project — they are telling you that the collection process spoils their working rhythm. Listen to them before buying more tablets.

Shop-floor resistance deserves respect, not disdain. An operator who has been producing for twenty years knows that every second spent interacting with a screen is a second not producing — and, if paid by the piece, is a second that costs them money. Production capture only works when the recording is almost invisible: a physical button at the workstation, a code scan, a one-touch confirmation. The more the system asks of the operator, the more the operator works around the system. The success of Model 3 is measured less by the sophistication of the software and more by the brutal simplicity of the interaction at the workstation.

Model 4 — the Data Lake, and when you do NOT need it

Groups with three, four factories, each with its own system, and management that wants to consolidate everything, have a legitimate argument for a Data Lake. An 80-person SME with one ERP and a spreadsheet does not. Selling a Data Lake to that company is selling it a lorry to go shopping. The rule of thumb: if the number of relevant data sources is fewer than five, you do not need a Data Lake — you need a good data model.

The Data Lake is frequently sold as a solution to the wrong problem. The difficulty of consolidating data from several factories is rarely one of storage — it is one of semantics. Factory A calls one thing "OEE"; factory B calls a slightly different thing "OEE"; factory C does not even calculate it. Dumping all that data into a central repository does not solve this — it merely concentrates the confusion in a bigger place. The real work, before any Data Lake, is agreeing common definitions of indicators between entities. With that governance work done, the physical repository becomes a technical detail. Skip that work, and the most expensive Data Lake in the world produces figures no one trusts.

5. How to assess whether your company needs it

Before looking at tools, look inward. Most companies discover, on doing this honest diagnosis, that the problem is not the lack of BI — it is the lack of reliable data to feed the BI. Treat the source first.

Signs that you are ready (or that you are not)

• Someone in your company spends more than half a day a week compiling manual reports in Excel — a strong sign that there is immediate return.
• Two people present the same indicator with different values in the same meeting — a sign that a single source of truth is missing before BI.
• Important decisions always wait for month end — a sign of excessive latency in the information.
• Your ERP is stable and most processes pass through it — a green prerequisite to proceed.
• Production data is still noted by hand on paper — treat this collection first, or factory BI will have nothing to show.

The trio that decides — and how to talk to each one

In Portuguese family companies, the decision to invest in BI almost always passes through three people: the CEO (frequently the owner or a second-generation offspring), the CFO and the IT manager. Each has a different language and a different fear, and a project that ignores any one of them derails.

The conversation that works is the one that gives each their own victory: to the CEO, a decision that has become faster; to the CFO, a figure that reconciles with the trial balance; to the IT manager, the assurance that the data model arrives maintained and does not become exclusively dependent on them. Selling only to the CEO — who is the one who gets enthusiastic at the fair — and ignoring the other two is the recipe for an approved project that never gets going.

Step by step

1. Inventory the data sources. List where the data that matters lives: ERP, spreadsheets, warehouse systems, quality records, shop-floor notes. For each, note who maintains it and how often it is updated.
2. Identify the 3 to 5 decisions that cost most money to delay. Do not try to measure everything. Choose the concrete decisions — accepting an order, stopping a line, buying raw material — where delayed information hurts most.
3. Assess the reliability of collection at source. For each decision, check whether the necessary data exists, is reliable and arrives in time. Where it fails, the problem is one of collection, not of BI — solve it first.
4. Define the minimum viable indicators. For each decision, define the exact indicator, the formula, the granularity (per line? per shift? per customer?) and the acceptable latency.
5. Do a proof of concept with a real case. Choose one decision, connect the real data and build a functional panel in two to four weeks. Measure whether the decision came to be taken faster and better. Only then generalise.

This exercise, done honestly, saves most of the budget that is wasted on dashboards no one opens. It is also worth reading about which KPIs make sense from the shop floor to management before fixing the indicators.

6. What to choose and why (decision by company size)

The question "what is the best BI approach" has no universal answer. It has an answer by profile. The matrix below condenses what we recommend according to size and maturity.

The SME under 50 people — start small, start now

The temptation of the small company is to defer: "we are few, we do not need this yet". It is a mistake. Precisely because it is small, each wrong decision weighs more on the result, and each hour a key person spends compiling Excel is an hour not spent selling or producing. The starting point for this profile is modest and effective: BI over the ERP, three indicators, one month of start-up. What this profile should not do is let itself be convinced to buy group architecture — it is the most expensive mistake a small company can make with data.

The company of 150 to 300 people — the OEE maturity point

It is at this tier that OEE per line and shift starts to make a real difference to the result. With multiple lines competing for capacity, knowing which yields most and why ceases to be curiosity and becomes asset management. This profile can withstand — and benefits from — the full Model 3: BI connected to MES, with a solid data model underneath. The typical mistake of this tier is the inverse of the small company's: wanting predictive analytics (predicting breakdowns, predicting demand) before having the basics of reliable capture working. Predict the future after managing to measure the present.

The "let's measure everything" trap

The most expensive mistake we see is not choosing the wrong tool. It is the wrong ambition. A company decides that, since it is going to do BI, it will measure fifty indicators. Six months later it has fifty charts and zero different decisions. Start with three indicators that change behaviour. When the three are being used seriously, add three more.

There is a psychological reason for this trap being so common: a panel with fifty indicators seems more valuable than one with three. It impresses in the demonstration, it justifies the budget before the board. But the value of BI is not in what it shows — it is in the behaviour it changes. A single indicator that makes the production director stop a line one hour earlier is worth more than forty charts everyone admires and no one acts on. Measure the success of your BI in decisions changed, never in number of views.

Self-service does not mean without governance

Qlik Sense shines in self-service — letting each area explore its own data. But self-service without a governed data model is the fastest path to the chaos of "several figures for the same thing". The rule: centralised and certified data and indicator definitions; freedom of exploration on top of that. Whoever confuses the two layers returns to the problem BI was supposed to solve.

Self-service without governance is giving the key to the archive to everyone and then being surprised that each person has a different version of the figures.

7. Regulatory framework and applicable compliance

BI deals with data. In Portugal and the EU, dealing with data has rules — and ignoring them is accumulating silent risk that only appears when there is an inspection or an incident.

GDPR and people's data

If your panels cross operator data — productivity per person, absenteeism, performance — you are processing personal data under the GDPR and Law 58/2019. This requires a legal basis, minimisation and special care with individual indicators. Measuring efficiency per line is one thing; exposing a named ranking of operators on a public factory screen is another, with real legal and labour implications. The people management tool should treat this data with the due rigour.

The practical boundary is useful to fix: measuring the process is legitimate; surveilling the person is a minefield. A panel showing the efficiency of line 3 on the night shift helps to manage the operation. A panel exposing, by name, who produced least on that shift creates a data protection problem and a labour problem — the workers' representatives have a legitimate interest here, and Law 58/2019 backs them. Wherever possible, aggregate at line, shift or team level. Only descend to the individual level with a clear legal basis, documented purpose and prior information to the data subjects.

Information security — NIS2 and ISO 27001

The NIS2 Directive (EU 2022/2555), transposed into national law through DL 65/2025, significantly widens the universe of entities obliged to take cybersecurity measures — many medium-sized industrial companies come to be covered, especially those operating in critical supply chains or supplying essential sectors. A BI platform concentrates sensitive data from the whole operation: if it is compromised, it exposes everything at once. Certifications such as ISO 27001 and controls such as EDR and perimeter protection cease to be optional. We recommend reading about the silent cybersecurity risks in the company — BI is precisely one of them when poorly protected.

A BI panel accessible on the network is a concentrated target: it gathers, in a single point, the complete portrait of your operation. Protect it as you protect the ERP server.

There is a dimension of NIS2 that catches industrial companies by surprise: responsibility over the supply chain. A company may not, in itself, be an essential entity — but if it supplies one that is, it comes to inherit security requirements by contractual contagion. The parent company that demands batch traceability also begins to demand information security guarantees from its suppliers. BI, being the point where data concentrates, is the first place a security audit will want to see protected.

SAF-T, DL 28/2019 and the coherence of financial data

The financial indicators of your BI should match what you communicate to the Tax Authority under DL 28/2019 and the monthly SAF-T communication (Ordinance 195/2020). Having a BI that shows one invoicing figure and a SAF-T that shows another is creating two versions of the truth before the tax authorities — a problem no one wants to explain in an inspection. The source should be the same: the certified ERP, with its ATCUD and its electronic invoicing in compliance.

This coherence is an argument in favour of doing BI over the ERP and not at its margins. When the financial panel reads directly from the same database that generates the SAF-T, reconciliation is automatic by construction. When BI lives in a parallel system, fed by manual exports, the door opens to divergences — and the divergence between what the company reports to the tax authorities and what management sees on its panels is exactly the kind of thing that turns a routine inspection into a prolonged headache.

AI Act — when BI starts to predict

As soon as BI goes beyond the descriptive and enters the predictive — predicting demand, anticipating breakdowns, estimating staff turnover risk — one enters the scope of Regulation EU 2024/1689, the AI Act. Most of these industrial applications fall into low or limited risk, but there are relevant exceptions: systems that assess the performance or risk of workers may classify into higher risk categories, with increased obligations of transparency and human oversight. Before activating a predictive module on people, check where it falls in the risk classification. The people management tool that incorporates predictive AI for turnover and absenteeism has to be designed with this classification in mind.

Funding — PT2030 and PRR

Digitalisation and data analytics projects frequently fit into instruments such as PT2030, COMPETE 2030 and Norte 2030. Experience tells us that what stalls applications is rarely the idea — it is the poorly substantiated technical report and the inability to demonstrate result metrics. A well-defined BI project, with starting and finishing indicators, is precisely the kind of investment these programmes like to approve.

The secret, in our experience with these applications, is in quantifying the before and the after. A project that says "we are going to improve efficiency" is rejected or gets stuck in requests for clarification. A project that says "the average OEE of the three lines is today X%, and the investment aims to take it to Y% in eighteen months, measured by the capture system" has a story the assessor can defend. BI is, ironically, the tool that produces the metrics that justify the very funding of the BI — provided you start by measuring the starting point before investing.

8. How INFOS approaches this

We have worked with Portuguese industry for over three decades, and the main lesson is this: BI does not start with BI. It starts with having reliable operational data. That is why we connect Qlik Sense to sources that already capture the operation in a structured way — the ERP MULTI for the management core, KORA Productivity for the shop floor, the KORA Inventory Suite for the warehouse. The data is born structured at source, it is not patched at the end.

That is the advantage of a supplier who knows the sector: we know that a footwear collection has three variant axes, that a Vale do Ave dyeing works needs batch traceability for compliance, that the warehouse manager will not put down the radio for more than two hours. We model BI on that reality, not on a generic imported model.

This sector knowledge translates into something concrete: the data model arrives largely pre-designed. A generalist ERP handed to a generic consultancy forces the company to explain, from scratch, how a footwear variant matrix works or how the yield of a yarn batch is calculated. We already know. That shortens the project and, more importantly, reduces dependence on the self-taught IT manager who, otherwise, would remain the sole guardian of a model no one else understands.

We do not sell pretty screens over bad data. When the data at source is not enough, we say so — and we deal with the collection first.

It is less glamorous than a dashboard demonstration, but it is what makes the project survive the second month. For cases of data analysis with applied AI, exploring how to turn data into automated decisions is the natural next step — after the basics of collection are solid, never before.

Multi Connect and consolidation between subsidiaries

For the groups facing the Model 4 challenge — several entities, several systems — the integration between subsidiaries and partners of the ERP MULTI solves the problem at the root before it reaches BI. When the entities share a common base of definitions, consolidation ceases to be a painful reconciliation exercise and becomes a natural aggregation. It is the semantics work we spoke of: done at the integration layer, the BI that rests on top inherits already coherent data.

9. 30/60/90 day roadmap

An industrial BI project that does not show value in the first 90 days loses management support and dies. Structure it to deliver early and grow later.

Days 1-30 — foundations and a real case

• Inventory the data sources and validate the reliability of collection at source — this is the invisible work that determines everything else.
• Choose a single high-value business decision (e.g. margin per customer, or OEE of a critical line) and define the indicator precisely.
• Build a proof of concept with real data for that decision. Verifiable milestone: a functional panel that a member of management uses in a real meeting.

Days 31-60 — data model and first area for real

• Consolidate a governed data model, with certified indicator definitions and a single source of truth.
• Put a whole area into production — typically sales/margin or production of one line. Milestone: the manual reports of that area stop being done in Excel.
• If the case involves the shop floor, start production capture as a pilot on one line, with the operators involved from the first day.

Days 61-90 — controlled scale and governance

• Extend to two or three more decisions, always validating real use before adding indicators.
• Formalise governance: who can create panels, who certifies indicators, how access is protected (aligned with GDPR and security policy).
• Define the next horizon — extended real-time capture, multi-factory consolidation or predictive analytics — based on what the first 90 days taught. Milestone: a plan for

Frequently asked questions

What is the difference between having a lot of data and having data useful for decisions?

Useful data arrives in time, is reliable and answers real operational questions. A lot of data arrives late, scattered across different systems and contradictory. A spreadsheet with yesterday's figures is no good for deciding today in a factory that changes articles three times a day. The value is in speed and coherence, not in volume.

Why doesn't Qlik Sense on its own solve the problems of industrial BI?

Because no visualisation tool can correct data that is born late, incomplete or scattered. Qlik Sense is excellent for showing patterns, but it only works well if the data feeding it is reliable and arrives in real time. Buying a pretty dashboard without solving data collection on the shop floor is spending money on cosmetics.

How does information latency affect the profitability of a factory?

Latency costs in lost capacity, wrong decisions and contractual penalties. A line stopped because the shortage warning only appeared on the next day's map, or an order accepted without knowing the critical line was overloaded, generate costs that do not appear in an accounting line but dilute into a thousand small daily inefficiencies.

What is the difference between a dyeing works and a metalworking shop in terms of BI urgency?

The urgency of BI does not depend on the size of the company, but on the speed at which the operation changes state. A dyeing works that turns a batch around in hours cannot take decisions with daily data — latency is toxic. A metalworking shop working long-run series parts has more margin to wait. The shorter the cycle, the more critical real-time information is.

How are the large brands forcing Portuguese factories to improve BI?

International brands demand batch traceability, deadline compliance indicators and sustainability data in real time. A garment maker recording production on paper cannot respond. The pressure comes from the brands' own portals with tight deadlines, and those who cannot provide reliable data lose orders to competitors better equipped digitally.

Why do the figures from the ERP, the spreadsheet and quality never match?

Because each system measures different things with different definitions. The ERP counts pieces invoiced, the supervisor counts pieces produced, quality counts conforming pieces. They refer to the same batch but rarely coincide. When they do not match, management spends time reconciling figures instead of deciding on them, delaying meetings and operational decisions.

How does Felgueiras footwear manage to respond quickly to order requests with 1000 SKUs?

It needs BI that models the variant as a matrix (colour, size, last) instead of treating each combination as an independent article. A generalist ERP collapses under tens of thousands of lines. A system designed for the sector, fed by real-time data on capacity and stock, allows a feasibility question to be answered in minutes that today takes hours or days.

Sources

• EU Strategy for Sustainable and Circular Textiles — European Commission, Directorate-General for the Environment (2022)
• Standard ISO/IEC 27001:2022 — Information Security Management Systems (applicable to operational data in an industrial environment)
• Regulation (EU) 2016/679 (GDPR) — Protection of personal data in production traceability systems
• IAPMEI — Programme for the Modernisation and Digital Transformation of Portuguese Industry (guidelines for BI and automation in SMEs)