In a knitwear factory near Vizela, the industrial director opens the laptop at 8:05 and performs the same ritual as seven years ago: he exports three files from the ERP, pastes them into an Excel workbook with forty tabs, runs a macro nobody remembers who wrote, and by 9:30 he finally has yesterday's production report. Yesterday. The night shift closed at 6 a.m. Machine 4 was down for three hours due to a thread break, and he will only discover this when the Excel opens — when there is nothing left to do about yesterday's shift.

The thesis of this article is simple and uncomfortable: the problem with industrial BI in Portugal is neither a lack of data nor a lack of tools — it is that most dashboards are built to impress management, not for the supervisor to use at 3 a.m. Qlik Sense solves the technical problem. It only solves the real problem when you design it from the shop floor up, not from the CEO's slide down.

Over 35 years implementing vertical software in factories in the North, we have seen the same pattern repeat itself in textiles, footwear, metal and distribution: companies that buy top-tier technology and carry on deciding by intuition. Not for lack of will — for lack of sequence. This article is about the right sequence.

1. The real operational problem

Let us begin with what is not said in the demos. In 2025, 45% of companies in Portugal carried out data analysis — 6.4 points more than in 2023, according to the INE. It looks like progress. It is. But the figure hides a cruel truth: for most of these companies, "data analysis" is a financial analyst building pivot tables in Excel on the 4th of each month about what happened the previous month.

That is not industrial business intelligence. It is retrospective accounting with charts.

The month-end close nobody believes

In a typical garment factory in the Vale do Ave, "month-end" has a sound of its own: the printer spitting out listings, the call to IT at 18:40 because "the efficiency report doesn't match the production one", and the Monday meeting where three people argue about which of the three Excels is right. None of them is. Each was built from a different export, at a different moment, with different rounding rules.

The classic symptom: management has data but does not trust it. And if it does not trust it, it decides by intuition — which is exactly what BI was supposed to have eliminated.

There is a hidden economy in this ritual. If one person spends two days a month reconciling spreadsheets, that is roughly 24 days a year — more than a month of annual work devoted to producing numbers nobody fully trusts. Multiply this by the three or four people who, in many companies, each maintain their own parallel Excel, and the cost of non-BI becomes greater than the cost of BI. It is just that the first is hidden in scattered working hours, and the second appears on an invoice.

Time lag as an invisible tax

The common denominator of all the symptoms is time lag. Too much time passes between the event and the number, and in a low-margin industrial business the time between the problem and its detection is money that has already walked out the door. The operating margin of a garment factory subcontracting for a parent house is rarely comfortable — many work on single-digit margins. In those conditions, three hours of machine downtime in a shift only discovered the next day are not a setback: they are the difference between a profitable order and an order in the red.

The lag has three distinct origins, and it is useful to separate them because each is corrected in a different way:

  • Capture latency — the event happens on the shop floor but is only recorded at the end of the shift, on paper, and entered into the system hours or days later.
  • Reconciliation latency — the data exists in several places and someone has to combine it manually before it makes sense.
  • Trust latency — the number exists and is available, but nobody believes it enough to act, so a second validation is requested that delays everything.

The three gaps by sector

Each vertical has its own particular information gap, and it is important to name them precisely:

  • Textiles and finishing — the real cost per batch is unknown until the close, because the consumption of dye, energy and water per lot is not captured in real time. When the brand asks for proof of compliance with the EU Strategy for Sustainable and Circular Textiles, the factory does not have the batch traceability data structured.
  • Footwear — a sample collection in Felgueiras has 800 to 1,200 SKUs with three axes (colour, size, last). The generic ERP models this poorly, and the result is that nobody can say, mid-season, which models are pulling orders and which are burning samples with no return.
  • Food distribution — the warehouse manager knows by heart where everything is, but when he is on holiday picking performance drops and nobody has a number to prove it or act on it.

A dashboard that arrives on the 4th about the previous month is not management information — it is an autopsy.

The textile gap seen up close

Walk into a dye house in the Vale do Ave on an August afternoon. The smell of the dye bath stays on your clothes for hours. There is a batch of knit being dyed in a jet, and the master dyer knows, from experience, how much dye and how much water that recipe takes. But "knowing from experience" is not the same as having the consumption recorded per batch, linked to the production order, the customer and the lot. When the client brand — a house that has already signed up to sustainability commitments — asks for the water footprint and chemical traceability of the item it bought, the factory faces two weeks of manual work reconstructing data that should have been captured at the moment.

The EU Strategy for Sustainable and Circular Textiles and the forthcoming Digital Product Passport will make this mandatory, not optional. The factory that captures consumption per batch today is building a commercial asset; the one still doing it from memory is accumulating technical debt that is paid for in lost orders.

The footwear gap and the tyranny of SKUs

Felgueiras and S. João da Madeira live in cycles of two seasons — the men's collection that international buyers come to see in August, the women's in February. A sample collection with a thousand SKUs, crossing colour, size and last, generates a combinatorial explosion that generalist ERPs treat as if each variant were an independent product. It is not. It is the same model with axes. When the system does not model this correctly, mid-season analysis — which models confirm orders after the fair, which get stuck — becomes impossible to do in time to react.

In footwear, the BI that matters is the one that answers, mid-September, a simple question: of the 900 models we showed in August, which are pulling firm orders and should we push into production, and which cost us prototypes and leather with no return? Without the three axes properly structured in the ERP, that question can only be answered at the end of the season — too late.

2. What exactly are Qlik Sense industrial production dashboards

Qlik Sense is a Self-Service BI platform — data analysis combining a proprietary associative engine with interactive visualisation. The technical difference from traditional query tools lies in the engine: instead of following pre-defined join paths (SQL query by query), Qlik loads the data into memory and keeps all associations live at the same time.

What the "associative engine" means on the shop floor

Translated into supervisor's language: when you click on a machine, the dashboard shows you instantly which production orders passed through it, which operators, which shifts, which defects — and also, and this is the point, what is not associated (it goes grey). You see simultaneously what is related and what is excluded. In an analysis of stoppage causes, seeing what did not happen is often more revealing than seeing what did.

Let me give a real example of the reasoning. A production director selects on the dashboard all the orders that closed late in the last quarter. The associative engine, as it filters, keeps the operators, machines and shifts involved lit up — and switches everything else off. Suddenly you see that, of the twelve machines in the section, only three appear lit in the delays, and one specific shift is over-represented. This is not a report someone asked for; it is a discovery that emerged from clicking and seeing what went grey. No Excel pivot table does this without already knowing in advance what you are looking for.

An industrial production dashboard in Qlik Sense typically combines:

  • Shop-floor capture data (terminals, sensors, operator entries) — quantities produced, times, stoppages, defects, ideally measured at the OEE level.
  • ERP data — production orders, routings, standard costs, material consumption, planning.
  • Commercial and logistics data — order book, deadlines, priorities, SCM status.

A brief historical note that matters

Qlik was born in Sweden in the 1990s with QlikView, and the leap to Qlik Sense (from 2014) was precisely the shift from the dashboard built by a programmer to the dashboard that the business user composes alone. That distinction — who builds the analysis — is what separates a data-driven culture from a culture of dependence on IT. It is worth reading how to take the first step towards a data-driven organisation before choosing any tool.

OEE, MES, MRP — sorting out the acronyms

There is recurring confusion between these three things, and it kills projects. OEE (Overall Equipment Effectiveness) is a metric: availability × performance × quality. The MES is the system that captures what happens on the machine. The MRP is the requirements planning engine in the ERP. Qlik Sense is none of these three — it is the reading layer that combines the data from the three and turns it into decisions. If you do not have shop-floor capture feeding Qlik, you are building pretty dashboards on data that still arrives on the 4th.

AcronymWhat it isWhere it livesWhat Qlik does with it
OEEMetric: availability × performance × qualityCalculated from machine and order dataVisualises trend, breaks down the three components, compares lines
MESProduction capture and execution systemShop floor: terminals, sensorsReads the captured events and turns them into analysable series
MRPRequirements planning engineCore of the ERPCrosses the plan with the actual to show deviations
BI (Qlik)Reading and decision layerOn top of all the aboveIt is Qlik itself: combines, associates, reveals

Why OEE breaks down more than it summarises

The value of OEE is not in the final number — it is in the breakdown. An OEE of 65% may have radically different causes: it could be low availability (machine stops a lot), low performance (running below nominal pace) or low quality (produces but rejects). Each requires a distinct management action. A dashboard showing only "OEE: 65%" is almost useless; one showing "65% = 82% availability × 88% performance × 90% quality" tells the supervisor where to attack first. This is the difference between an indicator and a decision tool.

3. The Portuguese landscape today

The 2025 INE figures draw the real picture, and it is less advanced than vendors like to suggest:

Indicator (companies in Portugal, 2025)ValueReading
Carry out data analysis (big data/analytics)45%+6.4 pp vs 2023; still not a robust majority
Use ERP53.7%Almost half have no integrated core for BI to read
Purchase cloud services38.7%The infrastructure for modern BI is still a minority

Cross-referencing these three numbers is the insight most ignore: you cannot do serious industrial BI without an integrated ERP, and almost half of Portuguese companies still do not have one. Selling Qlik Sense to someone whose data is not tidy in the ERP is selling a microscope to someone who has not yet collected the sample.

The distance between the average and the typical factory

There is an important nuance in these national averages: they include large services, banking and telecommunications companies, which pull the numbers up. The garment factory with 60 people or the family metalworks with 40 are, almost always, below average. The industrial fabric of the North, home to much of the textile and footwear production, is made of small and medium-sized, family-owned companies, with a lower digital maturity than the aggregate statistic suggests. When you read "45% carry out data analysis", read "probably far fewer than 45% of garment factories do it in a way that deserves the name".

The industrial weight that justifies the investment

At the same time, the industrial fabric that benefits from this is enormous. The Portuguese metallurgical and metalworking sector alone has more than 23,000 companies and around 250,000 people employed, according to AIMMAP/Metal Portugal data. Add textiles, clothing, footwear and distribution, and we have hundreds of thousands of jobs in an economy that competes on margin and on deadline — the two dimensions a good production dashboard attacks directly.

Reshoring, Asian pressure and the race on deadline

The competitive context changes the calculation. Pressure from Asian competition never disappeared, but reshoring — European brands bringing production closer to shorten supply chains — has given Portuguese textiles and footwear an advantage that plays out on two variables: short lead time and small-batch flexibility. A brand that redirects production to Portugal does so because it wants fast deliveries and the ability to respond to capsule collections. Now, lead time and flexibility are precisely what can only be managed with real-time visibility. The factory that does not know today whether it will meet Friday's shipping date cannot compete for this advantage — it can only pray.

Retail as background context

The turnover of retail trade in Portugal reached €201.8 billion in 2024, with retail growing 4.7% (INE). For those producing for brands or for retail, this means demand, but also growing demands on deadline, traceability and response to peaks — precisely where real-time visibility ceases to be a luxury.

Almost half of Portuguese companies still have no ERP. Before buying dashboards, tidy up the house that feeds them.

The funding exists — but the technical report decides

There is money available for industrial digitalisation through PT2030, the PRR, COMPETE 2030 and Norte 2030. We see companies applying and receiving support for exactly this kind of project — ERP, shop-floor capture, BI. But there is a practical lesson worth saying plainly: what approves or blocks an application is not the idea, it is the technical report. A well-articulated industrial BI project — with baseline metrics, quantified efficiency objectives and a credible implementation sequence — gets through. A project framed as "we want dashboards to modernise" gets stuck in the assessment. The discipline of defining baseline KPIs, which we advocate for operational reasons, is also what unlocks the funding.

4. The implementation models

There are four practical approaches to implementing production dashboards with Qlik Sense, and the difference between them is not technical — it is organisational. Choosing the wrong one for the company's maturity is the main cause of projects that die in the pilot.

ModelHow it worksGood forMain risk
Finance-first dashboardStarts with management KPIs (margin, cash, sales)CFO who wants quick proof of valueThe shop floor never uses it
OEE-first (shop floor)Production capture feeds real-time operational dashboardsFactories with unexplained stoppagesRequires reliable capture before BI
Phased hybridOperational OEE + management layer on top, in phasesMost industrial SMEsRequires roadmap discipline
Broad self-serviceBusiness users build their own analysesCompanies with a mature data cultureChaos of "truths" if there is no governance

The most expensive sequencing error

We see this repeatedly: companies that buy Qlik Sense and start with financial dashboards because that is what impresses management. Six months later, management has some nice charts and the shop floor is still on Excel. BI gained political visibility and lost operational usefulness. This is the model that produces the famous "we have Qlik but nobody uses it".

The underlying reason is psychological. The financial dashboard gives immediate satisfaction to whoever decides the budget, but it does not change any decision taken during the day. The CFO already knew, more or less, how the margin was doing; now he sees it prettier. Nobody on the shop floor changes what they do because of it. And since the operational value never appears, the project is left orphaned by anyone to defend it when the time comes to renew or expand.

Why the phased hybrid almost always wins

For the typical Portuguese industrial SME — 50 to 250 employees, a vertical ERP, a pragmatic industrial director — the phased hybrid model is the winner. You start with the layer where value is immediate and measurable (stopping the loss of three hours of a shift without knowing why), and the management layer comes later, fed by the same reliable data. This is the pattern we describe in detail in operational dashboards for Portuguese industry.

The financial dashboard impresses whoever signs the cheque. The operational dashboard changes what is done during the shift. Only one of the two survives two years.

When broad self-service is a trap

Broad self-service — giving everyone the ability to build their own analyses — sounds like democratisation and maturity. In companies with a solid data culture, it is. But in an organisation still arguing about which of the three Excels is right, giving each department the freedom to create their own metrics is multiplying the chaos, not solving it. You go from the three-Excel problem to the thirty-Qlik-apps problem, each with its own definition of OEE. Analysis freedom without a governed data layer and single definitions produces more discord, more elegant. Governance first, freedom later.

Real time is not the same as fast

A distinction that saves disappointment: real-time BI requires an upstream data chain that many factories do not have. If operators note production on paper and someone enters it into the ERP at the end of the shift, your "real time" is, at best, end-of-shift time. Industrial sensors and terminals, often with protocols such as MQTT carrying machine readings, are what makes real time literal. Without them, be honest about the latency.

5. How to assess whether your company needs it

Before any project, a readiness diagnosis is carried out. It is not about wanting dashboards — everyone wants them. It is about having the conditions for them to be used.

Signs that you really do need it

  • The production close takes more than two days and nobody fully trusts the final number.
  • There are three or more "official" Excels saying different things about the same reality.
  • When a machine stops, nobody can say the next day for how long and why.
  • Production-order priority decisions are made by whoever shouts loudest, not by order-book and capacity data.
  • A client brand has already asked you for traceability or sustainability data that took weeks to compile.

Signs that it is not yet the moment

There are also honest signs that BI is premature, and a good vendor says so instead of selling anyway:

  • There is no integrated ERP — sales, purchasing and production data live in separate systems or spreadsheets that do not talk to each other.
  • Nobody in the organisation can own the data of a domain; all information depends on the memory of one or two people.
  • The company has never agreed a single definition of even one KPI — everyone calculates efficiency their own way.
  • There is no willingness to change the shop-floor routine; the expectation is that BI will solve it without anyone refining the capture.

Step by step of the readiness diagnosis

  1. Inventory the data sources. List where the production, cost and sales numbers live today — ERP, terminals, Excel sheets, the supervisor's notebooks. If more than half is outside the ERP, the problem is capture, not BI.
  2. Measure the real latency. Time how long passes between an event on the shop floor (a stoppage, a produced quantity) and the moment that data becomes available in a system. This number sets the ceiling of what BI can do.
  3. Identify the three KPIs that change decisions. Not the twenty that look good on screen — the three that, if seen in time, would change an action. For many factories these are OEE, deadline compliance and real cost per order.
  4. Name the real users. Who will look at each dashboard, when, and on what device? If the answer for the operational dashboard is not "the supervisor, several times per shift, on a terminal on the floor", that dashboard will die.
  5. Validate the source of truth. Confirm that there is a system — ideally the MULTI ERP or equivalent — that is the single reference. BI on top of multiple truths multiplies the confusion, it does not resolve it.

The best test of a dashboard is not whether management likes it. It is whether the supervisor opens it without anyone asking.

Two quick wins before the big project

Two things a company implements in one to two weeks, even before any formal project: first, consolidating the three conflicting Excel sheets into a single one with agreed rules — the very exercise of agreeing the rules already reveals half the problems. Second, manually timing the stoppages of a critical machine for a week, with the operator noting the cause. The shock of seeing the real number is usually the argument that unlocks the budget.

The Portuguese decision trio and how each reads the diagnosis

In the family companies we serve, the decision almost always crystallises around a trio: the CEO, the CFO and the IT person — often a self-taught hero with fifteen years of business knowledge and no formal qualification, who knows the system better than whoever sold it. Each reads the readiness diagnosis through a different lens, and the project only takes off when all three see value:

Decision-makerWhat worries themHow the diagnosis convinces them
CEOCompetitiveness, deadline, relationship with client brandsThe sign that a brand asked for data that took weeks to compile
CFOReturn, hidden cost, real margin per orderThe calculation of hours lost in Excel reconciliation
IT / self-taught heroNot inheriting yet another system nobody usesThe proof that capture and the source of truth are sorted before BI

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

The recommendation changes according to size and maturity. There is no single answer, and be wary of anyone who gives you one.

ProfilePriorityRecommended approach
<50 employees, no integrated ERPSort out the data source firstVertical ERP before BI; simple financial dashboards as a start
50–150, integrated ERP, manual productionShop-floor captureCapture terminals + OEE, then Qlik Sense on top of that data
150–250, ERP + existing capturePhased hybrid modelOperational + management Qlik Sense, with data governance
>250 or multi-siteComplexity and integrationHigher-complexity ERP + corporate BI + integration between sites

For the small company without an integrated ERP

It is the greatest temptation and the greatest error: wanting to jump straight to the dashboards because they seem the most visible step. In a company with fewer than 50 people and no integrated ERP, BI has nothing to read from. The priority is to build the core — a vertical ERP that models the sector — and only then think about visualisation. At this stage, a handful of simple financial dashboards, connected to the newly installed ERP, are enough to create the habit of looking at reliable numbers. Rushing to Qlik before this is building the roof before the foundations.

For the company without shop-floor capture

This is the most common case and the worst served. The temptation is to buy the BI and "sort out the capture later". Wrong. Without reliable machine data, Qlik Sense will show, with graphic precision, the wrong data from manual entries. The correct order is: first real-time capture with KORA Productivity, then visualisation with Qlik Sense. OEE calculated from manual entries is fiction with decimal places.

There is a frequently underestimated collateral gain here. When production capture is installed, the first benefit is not the dashboard — it is the honest number. A factory that thought it had a machine availability of 85% discovers, with real data, that it is closer to 65%, because the micro-stoppages nobody counted add up to hours. This shock, painful at first, is what finally makes the whole improvement discussion concrete. You cannot improve what you do not measure honestly.

For the multi-site company

When there is more than one unit — something common in footwear and textiles, with distributed production and subcontracting — the challenge is consolidation. The data has to converge with identical definitions before reaching the dashboard. The integration between units, with tools such as Multi Connect, has to be resolved upstream, or you will spend your life explaining why factory A's OEE and factory B's are not comparable.

The most insidious problem here is not technical — it is semantic. Factory A counts as a "stoppage" anything over five minutes; factory B only counts above fifteen. Factory A measures quantity produced at the machine output; factory B measures it after quality control. Combine the two in the same dashboard and you get a meaningless comparison, which generates distrust rather than decisions. Multi-site consolidation begins with a boring meeting where the exact meaning of each word is agreed. Without that meeting, no tool saves the project.

For the highly complex company

In organisations above 250 employees, with multiple units, highly specific processes or heavy integration requirements, the ERP itself may need to be of another class. This is the context for a high-complexity, low-code ERP such as QAD Adaptive ERP, capable of accommodating processes that deviate from the standard without each change requiring code to be rewritten. Corporate BI on top of these systems gains a governance dimension — who sees what, with which profile, in which unit — that in an SME is incidental but here is central.

The terminal the supervisor hides

An operational truth that 35 years in factories teach: the tablet or capture terminal left on the shop floor will be mistreated. It will collect thread dust, it will be taped to a column, it will mysteriously disappear before an audit. If the operational dashboard depends on a fragile device or a complicated login, it dies. The capture screen has to be so simple that an operator uses it with gloves on and without thinking. This apparently minor detail decides more projects than any advanced BI feature.

The capture screen has to work with gloves on, with thread dust and without a manual. If it requires a course, it has already lost.

The warehouse manager's resistance and how not to ignore it

On the Lousada–Paços de Ferreira corridor, in a distribution centre, the warehouse manager is king. He knows by heart where each pallet is and runs the operation from a radio in his hand. Any rollout that takes him off the radio for more than two hours will have a determined enemy — and he will win, because the operation cannot stop and management knows it. The lesson for those implementing warehouse management and the BI that reads it: involve him from day one, make him owner of a metric that values him (the picking productivity he intuits but never proved), and never, ever design the process in a room far from the warehouse. The best logistics dashboard is the one that proves the warehouse manager right with numbers — not the one that tries to replace him.

7. Regulatory framework and applicable compliance

Production dashboards seem neutral from a regulatory point of view. They are not. As soon as you connect ERP, HR and invoicing data on a network-accessible platform, you enter a set of obligations worth knowing before, not after, the audit.

Data feeding the BI and AT certification

The invoicing data that enters the commercial dashboards comes from a system that must be certified by the Tax Authority, under DL 28/2019, with ATCUD and monthly SAF-T communication (Ordinance 195/2020). BI reads this data, it does not replace it — but if the source is not compliant, the dashboard's commercial numbers inherit the problem.

GDPR when the dashboard touches people

A productivity dashboard showing performance per operator processes personal data. The GDPR and Law 58/2019 apply: minimisation, purpose, and special care with individual metrics that can drift towards abusive monitoring. The practical rule is to aggregate by team or line whenever the management decision does not require the individual. A poorly designed Employee Engagement dashboard is a compliance risk and a workplace-climate risk at the same time.

There is a real tension here that technology does not resolve. The industrial director wants to know who produces more and who less; the law and workplace-climate common sense call for restraint in the use of individual metrics. The balanced way out is to distinguish the purpose: to manage the process (where are the bottlenecks, which line needs support), aggregate by team; to manage the person (training, recognition, correction), use the individual data within the legal framework of people management, with transparency towards the worker. A platform such as pplPortal handles this data in the proper context of people management, separating it from the operational shop window everyone sees on the shop floor.

Cybersecurity: NIS2 and access to BI

The NIS2 Directive (EU 2022/2555), transposed in Portugal by DL 65/2025, extends cybersecurity obligations to more sectors, including relevant manufacturing industry. A BI server with operational and financial data from the entire company is a target. Access with MFA, profile management and a serious security posture are no longer optional. Those handling critical data should know the silent risks of cybersecurity in the company and the role of a perimeter protection with SOC. Certifications such as ISO 27001 structure this discipline.

The BI server concentrates the company's most valuable data in one place. That makes it the crown jewel — and the preferred target.

Predictive AI and the AI Act

When the dashboard evolves from describing the past to predicting the future — anticipating a material shortage, flagging the risk of an order delay from historical patterns — you enter the territory of Regulation (EU) 2024/1689, the AI Act, which classifies AI systems by risk level. Most predictive production applications are low-risk, but there is a sensitive zone: any use of AI that touches the assessment or management of people falls into more demanding risk categories. Before letting predictive intelligence come near worker data, classify the risk and document it. It is boring work that avoids serious problems.

A compliance map so nothing is forgotten

BI layerApplicable regulationPractical care
Invoicing and sales dataDL 28/2019, Ordinance 195/2020Source must be AT-certified software (ATCUD, SAF-T)
People / productivity dataGDPR, Law 58/2019Aggregate by team; individual only with purpose and transparency
Access and BI server infrastructureNIS2 (DL 65/2025), ISO 27001MFA, profiles, monitoring; treat as a critical asset
Predictive / AI modulesAI Act (EU 2024/1689)Classify risk; extra caution with worker data

8. How INFOS approaches this

Our position, built over 35 years implementing vertical software for Portuguese industry, is that BI is not a standalone product — it is the reading layer of a system that must already be well fed. That is why we rarely propose Qlik Sense in a vacuum. We propose it on top of a MULTI ERP that already correctly models the sector's complexity — the three SKU axes of footwear, the batch traceability of textiles, the real cost per production order — and of a shop-floor capture with KORA Productivity that ensures the OEE on the dashboard is measured, not estimated.

We work the phased hybrid model because it is the one that survives the supervisor's 3 a.m. test. We start with the operational layer, where value is immediate and visible, and we build the management layer on top, over the same data. This avoids the most frequent and most frustrating scenario: the company that "has Qlik" but where only the finance department opens it.

Why verticalisation is not a slogan

The difference between generic BI and BI that serves a footwear factory lies in the data model underneath. If the ERP treats each colour-size-last variant as a loose product, the dashboard inherits that fragmentation and will never be able to group by model in a useful way. If the ERP models the three axes as what they are — dimensions of the same item — the BI gains, for free, the ability to analyse by any combination. Verticalisation pays off here: not in features listed in a brochure, but in the invisible structure that makes certain questions answerable. A generalist ERP may get there with heavy customisation; an ERP born for the sector gets there by default.

Where capture, integration and analysis come in

In practice, a complete project usually articulates several of our layers according to need: operational capture with KORA Productivity, warehouse management with KORA Inventory Suite when logistics weighs, integration between units and partners with Multi Connect, and the final reading with Qlik Sense. None of these pieces is sold as an end in itself — each exists so that the right number reaches the right person in time to change a decision.

AI comes in last, and with method

When the project involves predictive AI — anticipating a material shortage, predicting order delays from historical patterns — we fit that layer in a controlled way, with attention to the AI Act's risk classification. The path of turning data into automated decisions is described in detail in AI applied to industry, but the principle is always the same: reliable data first, then intelligence. A predictive model fed by delayed manual entries predicts nothing — it repeats the data's error with a statistical confidence it does not deserve.

9. 30/60/90-day roadmap

A realistic plan for an industrial SME starting from an integrated ERP but without operational BI. Verifiable milestones, not intentions.

Days 1–30: foundation and single truth

  • Complete the five-step readiness diagnosis and document the real latency of each data source.
  • Define the three KPIs that change decisions and agree, in writing, the formula for each — especially OEE, where 90% of disagreements arise from different definitions of availability.
  • Consolidate the conflicting Excel sheets into a single source of truth, connected to the ERP.
  • Name the data owner of each domain (production, commercial, financial). Without an owner, there is no governance.

Days 31–60: first operational dashboard

  • Build the first production dashboard in Qlik Sense, focused on one critical line or section, not the whole factory.
  • Validate with the supervisor of that line in a real environment — not in a meeting room, but at the terminal where he will use it.
  • If shop-floor capture is still manual, start the implementation of terminals on the pilot line.
  • Measure adoption: how many times per shift the dashboard is opened by those who should use it. This is the only project KPI that matters at this stage.

Days 61–90: scale and management layer

  • Extend the operational dashboard to the remaining lines, with identical definitions to allow comparison.
  • Build the management layer (margin, deadline compliance, cost per order) on top of the same already-validated data.
  • Review the access rights and apply MFA and profiles, aligning with the NIS2 and GDPR obligations before broadening the user base.
  • Hold the first management meeting entirely on the dashboard, with no Excel in the room. If someone still brings a parallel Excel, the project is not yet finished.

What to do after 90 days

The first 90 days create the foundation; what follows determines whether the BI becomes culture or remains a passing fad. From here, the work is about maintaining trust: reviewing definitions when the business changes, removing dashboards nobody opens — yes, removing, because a portal full of dead analyses dilutes attention from the living ones — and resisting the temptation to multiply metrics. The rule we give clients is counter-intuitive: if in six months the number of active dashboards has doubled but the average opens per dashboard has dropped, the project is getting worse, not better. Fewer analyses, more used, are worth more than many ignored.

It is also the moment to consider the predictive layer, if and only if the descriptive data is already reliable and used. Predicting the shortage of a specific material or the delay risk of an order only makes sense when the

Frequently asked questions

Is Qlik Sense mandatory to implement industrial BI, or are there alternatives?

Qlik Sense is a powerful tool, but it is not mandatory. There are alternatives such as Power BI, Tableau or Looker. The choice depends on the complexity of the data, the budget and the internal technical capacity. What matters is that the tool is used operationally on the shop floor, not just for monthly reports.

How long does it take to implement an industrial dashboard in Qlik Sense?

It varies between 4 and 12 weeks, depending on the quality of the existing data and the complexity of the processes. If the data is scattered across multiple systems or in Excel, the time increases. Most of the time is spent on cleaning and integrating data, not on building the dashboard.

What is the real cost of implementing BI in a small factory?

The direct cost (software + implementation) varies between €15,000 and €50,000. But the return appears quickly: reduced time in reconciliations, faster detection of operational problems and decisions based on real data. Many factories recover the investment in 6 to 9 months.

How to prevent the dashboard from being just for management?

Design the dashboard from the shop floor up, not from the CEO down. Involving supervisors, production masters and operators in the design ensures the dashboard answers real questions. A dashboard useful to the supervisor at 3 a.m. is useful to the whole company.

What to do if the factory's data is scattered across several systems?

It is common and it is not a blocker. Qlik Sense can integrate data from multiple sources (ERP, machines, Excel, databases). The greater difficulty is ensuring the definitions are consistent across systems. This requires prior work of data mapping and cleaning.

How to ensure the BI data is reliable?

Trust is built in three steps: first, validating that the captured data corresponds to the operational reality; second, reconciling data from multiple sources with clear rules; third, involving the end users in validation before using it in critical decisions. Without trust, BI does not work.

What is the real impact of an operational dashboard on a factory's margin?

Direct: reduced undetected downtime, less waste from lack of information, and faster decisions. Indirect: less time in manual reconciliations and more time in corrective actions. In a factory with tight margins, the difference between detecting a problem in real time or the next day can be the difference between profit and loss.

Sources

  • Statistics Portugal (INE) — Survey on the Use of Information and Communication Technologies in Enterprises (ITICE), data on data analysis in Portuguese companies, 2023-2025
  • EU Strategy for Sustainable and Circular Textiles — European Commission Communication on the circular economy in the textile sector and traceability requirements
  • Regulation (EU) 2024/1781 — Digital Product Passport and traceability obligations for textile products
  • Textile and Clothing Association of Portugal (ATP) — Sectoral data on environmental compliance and traceability in Portuguese textile companies