BI with Qlik Sense: operational dashboards for Portuguese industry

In a knitwear factory near Barcelos, the production manager had a Friday ritual. He would close the office door, open six Excel sheets — production, scrap, overdue orders, absenteeism, yarn consumption, margins — and spend three hours pasting values from one to another until he arrived at a number he trusted enough to take to the Monday meeting. That number was already stale by the time he said it aloud. And it was the only one the board ever saw.

Here is the thesis: most Portuguese industrial SMEs do not have a data problem — they have a latency and data-trust problem. The data exists, scattered across the ERP, the shop-floor terminals and thirty Excel files. What is missing is turning it into a dashboard that the warehouse manager checks before coffee and the CFO checks before the close. That is what a BI project with Qlik Sense solves — or ruins, when done badly.

The Barcelos manager is not a caricature. He is the norm. And the most uncomfortable part is that he is competent: he knows the business by heart, knows where the errors are, guesses the margin to within two euros. The problem is that this knowledge lives in his head and in an Excel screen that only he understands. The day he leaves — retirement, illness, a better offer — the company goes blind. And it goes blind slowly, without noticing, because for months nobody realises the numbers have stopped adding up.

1. The real operational problem

According to the INE, in 2025 only 45% of companies in Portugal carried out data analysis (big data/analytics), a rise of 6.4 points on 2023. In other words: more than half of the Portuguese business fabric still decides without structured analytics. And within the 45% that "do analysis", a substantial share do what the Barcelos manager did — manual Excel, late, fragile.

The problem is not abstract. It has a smell, a noise and deadlines. Let us look at where it hurts, sector by sector.

Textiles and clothing: the number that arrives too late

In the textiles of the Vale do Ave — Famalicão, Guimarães, Vizela — the subcontracting cycle for the parent companies (Inditex, Decathlon, Tom Tailor) lives on two things: meeting the date and defending the margin. The problem is that the real margin of a make-up order is only known after it is closed, when someone adds up the machine times, the fabric scrap, the overtime and the cost of the yarn actually consumed. By then, the next order is already under way with the same budgeting error.

An operational dashboard reverses the order: it shows the projected margin while the order is in production, cross-referencing real yarn consumption with the standard. When the deviation exceeds 4%, the planning manager sees it on Monday, not at the month-end close.

There is an additional layer that has become mandatory rather than intuition. The EU Strategy for Sustainable and Circular Textiles, and the digital product passport framework that accompanies it, are pushing the parent companies to demand lot traceability from Portuguese subcontractors. A German brand selling in Germany wants to know which dye house the lot came from, with what composition, with what water and energy consumption. In clothing, the maker who cannot return that data quickly loses the order to whoever can. And that data — lot number, technical sheet, consumption — is exactly the kind of information a well-fed BI cross-references without drama, provided it is born reliable in the ERP.

Lot traceability has stopped being an auditor's whim. It is the entry pass to keep producing for the European brands.

There is a nuance here by size. The 40-person maker working exclusively for one parent company has a different problem from the 120-person spinner serving twenty clients. The first needs to defend its margin within a relationship of dependency — BI serves to avoid losing money on orders the buyer imposes. The second needs to decide which clients are worth keeping — BI serves to discover that two of the twenty clients consume half the capacity and leave the smallest margin. These are different questions requiring different dashboards, and that is why copying the neighbour's panel almost never works.

Footwear: 800–1,200 SKUs that no spreadsheet can bear

A sample collection in Felgueiras has between 800 and 1,200 SKUs, crossed on three axes — colour, size and fitting. International buyers visit twice a year (men's in August, women's in February) and decide within days. The operational question is brutally simple and brutally hard to answer in an Excel: which of the 900 references in this collection have a positive margin after subtracting the sampling cost, and which are killing us?

Without BI, that question is answered by the owner's intuition. With BI, it is answered by reference, by client and by fitting, with the data from the MULTI ERP feeding the panel.

Portuguese footwear has a characteristic that distinguishes it from textiles: exports are the overwhelming majority of the business, and the target markets — Germany, France, the Netherlands — are demanding on deadline and on quality consistency. This changes what the BI has to show. Margin by reference is not enough. Deadline compliance by client is needed, because a two-week delay on an order for a German retailer costs the entire next order. It is necessary to know, by fitting, how much real production deviates from the standard — because a new, poorly studied fitting silently eats margin throughout the whole collection.

Managing the collection as a data problem

The real pain of footwear is not producing. It is deciding what to produce. A sample collection is a bet: the factory invests hundreds of hours of pattern-making and sampling with no guarantee the buyer will buy. BI turns that gut bet into an informed probability. By cross-referencing past collections — which fittings, which colours, which price ranges sold to which clients — the panel reveals patterns the owner's memory no longer holds: the French client who always buys the classic fitting in dark leather, the Dutch client who only reacts to novelty, the client who requests many samples and converts few.

Distribution and retail: the warehouse manager who hates reports

Along the Lousada/Paços de Ferreira corridor, the warehouse manager of a food distribution centre does not want reports. He wants the radio in his hand and the picking moving. Anything that pulls him off the Gemba for more than two hours is sabotaged — and he is right. The classic SME error is to build dashboards for the board and forget that the data is born on the floor. If the operator sees no benefit, the data he enters degrades, and the board's pretty panel goes on lying with confidence.

A dashboard that only the board uses is doomed. The BI that survives is the one that gives value back to whoever feeds the data.

In retail, retail trade turnover grew 4.7% in 2024 (INE). But sales growth without visibility of margin by store, by category and by hour of the day is fuel for wrong decisions — opening SKUs that do not turn over, promoting what already sells on its own.

Portuguese food distribution lives on thin margins and high volumes. A distribution centre with 15,000 m² and 4,000 active references manages stock-outs, over-stocking and expiry dates simultaneously — and each of those three problems costs money differently. The stock-out loses a sale. Over-stocking ties up capital and fills the aisles. Expiring shelf life is pure loss. An operational dashboard that cross-references turnover, stock cover and days until expiry gives the warehouse manager the information to act before the problem materialises — not the autopsy at the end of the month.

Warehouse data, when born from radio-frequency terminals connected to the KORA Inventory Suite, reaches the BI clean and timestamped to the real operation. It is the difference between knowing a reference is out of stock now and discovering it three days later in a stock count. For retail with a physical store, the sale data to the second comes from the POS — and a synchronised MAXIRETAIL feeds the margin-by-store and by-category panel with no manual exports.

Retail: the margin by hour of the day that nobody looks at

There is one indicator that almost no regional chain analyses and that changes staffing and promotion management: the margin by hour of the day and by day of the week. A food convenience store does not sell the same at 8am and at 7pm, nor on Monday and Saturday. Staffing is usually flat; the sale is not. A dashboard that reveals the real peaks and troughs allows shifts to be adjusted and promotions to be concentrated where there is traffic, instead of burning margin in dead hours. It is the kind of insight the Qlik associative engine delivers almost by accident — because it lets the user cross hour, category and store without building a new query each time.

Metal/plastic industry: the one-off part against the series

Along the Aveiro–Marinha Grande corridor, the mould and plastic injection industry has a costing problem that embarrasses many generalist ERPs. The one-off part — a mould — is a project with hundreds of hours of milling, erosion and bench work, and the real cost is only known at the end. The series — injection of thousands of parts — lives on machine cadence and scrap. They are two costing worlds coexisting in the same factory. Without MES capturing the real time by operation and by cost centre, mould costing BI is fiction. With real-time capture via KORA Productivity, the dashboard shows the deviation of hours to the mould's budget while the mould is being made — in time to renegotiate or to learn for the next quotation.

2. What exactly Qlik Sense and BI for industry in Portugal are

Qlik Sense is a business intelligence and data visualisation platform that lets you build interactive dashboards over multiple sources — ERP, MES, payroll sheets, Excel files, databases. The technical difference that matters to decision-makers is not the pretty chart. It is the associative engine.

The associative engine — why this is not just another chart

Most SQL-based BI tools force you to define the questions in advance: you build a query, you filter along one path. The Qlik associative engine works the other way — it loads the data into memory and lets the user navigate in any direction, instantly seeing what is related and, just as important, what is not related to the current selection.

A concrete footwear example: select a German client and the panel immediately shows the fittings he buys, the months he buys in, the margins of those orders — and, in grey, the references he has never bought despite them being in the collection. That "grey" is commercial gold that a classic SQL report hides.

Why does this matter in an SME and is not just vendor jargon? Because the business question never comes alone. The salesperson asks for margin by client, and the answer generates three new questions — by range, by month, by fitting. In a tool based on rigid queries, each new question is a request to IT and a wait of days. In the associative model, the business person follows the thread without leaving the panel. It is the difference between a two-hour investigation and a two-minute one, and that is what decides whether the dashboard is used or abandoned.

Terms you will hear in the meeting room

• Operational dashboard — a panel of indicators updated frequently (daily or intra-daily), geared to action on the ground, not to quarterly historical analysis.
• KPI — key performance indicator; in an industrial context, things like OEE, scrap %, deadline compliance, stock turnover.
• ETL / data load — the process of extracting, transforming and loading data from the sources into the Qlik model. This is where 70% of a project's effort lives, and where generic consultancies always underestimate.
• Self-service BI — the capacity for the business user to create their own analyses without depending on IT for each new question.
• Semantic layer — the common definition of what each indicator means, so that "margin" means the same in the salesperson's panel and in the CFO's.
• Section access — Qlik's security mechanism that limits, at the data-row level, what each user profile sees.

For the full journey from problem to decision, we go deeper in another article on how Qlik Sense in Portuguese industry: from spreadsheet to decision works, and the continuous-update mechanism in Real-time Business Intelligence with Qlik Sense.

A brief history — from QlikView to Qlik Sense

Qlik was born in Sweden in 1993. The original product, QlikView, popularised the associative engine in the 2000s and gained traction in Portugal above all in industry and distribution. Qlik Sense, launched in 2014, rebuilt the experience for self-service and responsiveness, with centralised governance. Those still running QlikView in production are not wrong — but the development roadmap and the augmented-AI capabilities are today in Sense.

This distinction has a practical consequence for anyone who inherited an old project. Many Portuguese factories have QlikView applications ten or twelve years old, built by a consultant who no longer works there, that nobody knows how to maintain but that nobody dares switch off because the CFO still opens them. Migration to Sense is not urgent — but postponing it indefinitely creates a technical debt that one day bursts, typically when the old server dies and the backup does not restore. The moment to plan the migration is before there is a crisis, not during one.

On-premise, cloud or hybrid — the hosting decision

A question that arises early: where does the BI run? Qlik Sense works well in your own datacentre (on-premise), in the cloud, or in a hybrid model. For the Portuguese industrial SME that has not yet moved the ERP to the cloud — and they are the majority — on-premise on a managed server is the natural option, because it keeps the BI beside the data source and avoids the latency of pulling large volumes over the internet connection. Those with several branches wanting uniform access tend to lean towards models with a cloud component. There is no universal answer; there is the right answer for the data architecture that already exists.

3. The panorama in Portugal today

Three INE numbers (2025) sketch the terrain with uncomfortable honesty:

• Only 53.7% of companies in Portugal used an ERP in 2025. Without an integrated core, BI works over scattered data — and a dashboard over dirty data is a faster lie.
• Only 38.7% purchased cloud services, which constrains modern BI architectures (although Qlik works perfectly on-premise in your own datacentre).
• Those same 45% that do data analysis — a number that is rising, but slowly. Data-based management is still not the norm in Portugal; it is a competitive advantage available to whoever grabs it first.

Read together: the barrier to entry for useful BI in Portugal remains the ERP and data hygiene, not the visualisation tool. Those who already have a well-implemented vertical ERP are halfway there. Those who do not spend the BI budget fixing source data — and then complain that "BI didn't work".

BI does not fail because of the chart. It fails because nobody wanted to tidy the data house first.

The difference between large and small — the digitalisation gap

The statistical averages hide an enormous gap. Large Portuguese companies adopt analytics at rates approaching the European average; micro and small ones lag far behind. This gap is the most relevant fact for the industrial SME, because it means two things at once. First: the majority of direct competitors still decide in the dark, so there is an advantage in seeing first. Second: the large clients — the textile parent companies, the footwear retailers, the distribution buying centrals — are already digitalised and will demand that suppliers keep up. The pressure comes from above in the value chain, not just from lateral competition.

Funding — PT2030, RRP and the reality of technical reports

A BI and data digitalisation project is eligible for several instruments — PT2030, COMPETE 2030, Norte 2030, and digitalisation components of the RRP. In practice, what we have seen approved are projects with a clear scope, measurable deliverables and a demonstrable link to productivity. What gets bogged down are the vague applications — "digital transformation" with no metric — that die at the technical-report stage because nobody can prove what changed. The lesson for the SME is the same one that serves the project itself: narrow scope, concrete indicator, demonstrable value. A dashboard that reduces the month-end close from five days to one is a defensible application story. "We're going to be data-driven" is not.

The standard Portuguese error: buying the tool before having the question

In 36 years accompanying Portuguese factories, the pattern repeats itself: the company buys BI licences, thrilled by a demo, builds twenty dashboards in the first quarter, and in the second nobody opens them. The reason is always the same — panels were built from what the data allowed to be shown, not from the decisions management needed to make. A dashboard with no decision attached is expensive decoration. We explored this launch in how to build a data-driven organisation: the first step.

The decision trio and the IT hero without a diploma

In Portuguese family businesses, BI is decided by a trio — CEO, CFO and the IT person. And the IT person is, often, a self-taught individual with fifteen years of business knowledge and no formal degree. He is the one who knows where the data is, what each macro does, why that ERP field can never be trusted. Ignoring him in a BI project is guaranteeing failure; listening to him is gaining the map of the territory without digging. What he needs is a tool that frees him from being the human bottleneck of every report — not one that replaces and humiliates him. Self-service BI, well introduced, turns him from an Excel factory into a curator of the data model. It is a promotion, and it is worth selling it that way.

4. The industrial BI implementation models

There are five practical approaches to getting BI working in a Portuguese industrial SME. They are not equally good — each has a cost, a risk and a type of company it serves.

The trade-off nobody tells you about

Jumping straight to governed corporate BI in an SME without data maturity is the most expensive error. The self-service departmental model, started in an area with acute pain (typically production or treasury), generates trust and funds the rest. The rule of thumb: prove value in one area within 8–10 weeks before promising the universal dashboard. On turning this into a financial result, see turn data into profit with Qlik Sense.

Excel is not the enemy — it is the symptom

It is worth being fair to Excel. It is not a bad tool; it is a badly used tool when it becomes the management database of an eighty-person company. Excel is great for an ad-hoc analysis, for a one-off calculation, for sketching an idea. The problem starts when José's Friday file becomes the company's official source of truth. The sign that the line has been crossed is simple: when two departments open the "same" report and argue about which is right, Excel has stopped being a tool and become an operational risk. Migrating to BI is not abolishing Excel — it is relieving it of the weight it should not carry.

Excel does not kill the company. What kills it is Excel promoted to source of truth without anyone having decided to promote it.

The dashboard silo — the silent failure of self-service

The departmental model has a risk that only appears after two years: each area builds its own panels, with its own definitions, and when the board cross-references production with sales it discovers that "unit produced" means different things in each dashboard. That is the dashboard silo. The prevention is not technical — it is governance. One person responsible for keeping the definitions of the core indicators coherent is enough, even while each department builds the rest its own way. Light governance, not bureaucracy. The error is the opposite extreme: blocking all self-service behind a committee that approves every chart, killing the agility that was the whole point of departmental BI.

5. How to assess whether your company needs it

Not every company needs BI right now. Those who suffer from at least three of these symptoms do:

• The month-end close depends on one person who "knows where the numbers are" — and that person goes on holiday.
• The management meeting argues about which number is correct, instead of discussing the decision.
• The real margin of an order/store/product is only known weeks after it is closed.
• There is data in the ERP, on the shop-floor terminals and in Excel, and nobody cross-references it without manual work.
• Purchasing, production or pricing decisions are made on intuition because the data arrives late.

Step-by-step diagnosis

1. List the company's five most expensive recurring decisions. Not indicators — decisions. "Accept or refuse this order", "restock or not this SKU", "keep or close this sales route". BI serves decisions, not charts.
2. For each decision, note what data underpins it today and how long it takes to obtain. If the answer is "José exports from the ERP and cross-references in Excel in two hours", you have found your first use case.
3. Assess the source of origin. Is that data born reliable in the ERP, or filled in by hand in loose sheets? If the source is dirty, BI does not clean it — it just shows it faster. Fix the source first.
4. Identify the decision owner and confirm he wants the panel. A dashboard imposed on a warehouse manager who did not ask for it dies in three weeks. One he helped design lives.
5. Estimate the value of deciding 24–48 hours earlier and with the right number. If it saves one poorly budgeted order per quarter in textiles, the project pays for itself. Calculate the TCO against that value, not against the licence price.

If you cannot name the decision the dashboard is going to improve, you are not ready to build it — you are ready to waste it.

The data-hygiene test before any licence

Before buying anything, run a cheap and revealing test: ask three different people for last month's sales volume. If the three numbers do not tally, the problem is not BI — it is the source. Repeat with margin by client, with the stock of any reference, with the production hours of an order. Each discrepancy is a sign of where the data is born dirty. An honest BI project begins with this inventory of dirt, and sometimes the conclusion is to postpone the BI and tidy the ERP first. It is an unpleasant conclusion to sell, but it is the one that saves the money.

Who does not need BI yet

Contrary to vendor talk, there are companies that should not proceed. The twelve-person micro-company that does not yet have an integrated ERP should get the ERP working first; building BI over manual exports is building on sand. The company whose entire business fits in the owner's head and will not grow does not need a panel to discover what it already knows. And the company in an acute treasury crisis has more urgent priorities than dashboards — although, ironically, a good treasury panel is exactly what would avoid the next crisis. The criterion is honest: if there is no expensive, poorly informed recurring decision, there is no BI case.

6. What to choose and why — decision by company size

Company size and data maturity determine the choice. This matrix is the one we use on the ground.

Why vertical BI beats generic BI

A generic BI tool gives you a blank canvas. It is powerful and it is a trap: the company spends months reinventing what "make-up line OEE" or "footwear collection margin by fitting" means. The value of a BI anchored in a vertical industrial ERP is that the concepts already exist modelled — the production order, the standard consumption, the colour-size-fitting structure. Qlik Sense connected to the MULTI ERP or to QAD Adaptive ERP inherits that modelling instead of rebuilding it from scratch.

On the shop floor, the efficiency data that feeds the dashboard comes from real-time capture — that is the role of KORA Productivity. Without that layer, the dashboard's OEE is an estimate filled in by hand at the end of the shift, and it is worth what an estimate is worth. For those who want to use the data in planning, see strategic planning with BI: when data replaces intuition.

The data chain that makes the dashboard honest

It is worth tracing the full chain, because that is where you see where a vertical BI saves time. OEE is born from the production capture on the MES terminal. Margin is born from the production order in the ERP cross-referenced with the real cost. Stock is born from the WMS. Sales are born from the POS or the mobile sales force. When all these sources are already connected by a vertical ERP that speaks the same language, the BI merely presents them. When they are not — when OEE is one sheet, cost another, stock a third — the BI project turns, in practice, into a disguised integration project, at triple the cost and timescale. This is the real reason why the same dashboard costs much more in one company and much less in another.

When the data is about people — the HR panel

A dimension that industrial SMEs discover late: people data is worth gold in an industry with an ageing, hard-to-replace workforce. Knowing turnover by section, absenteeism by shift, the age curve of those who can operate a critical machine — this changes recruitment and training decisions. When attendance and payroll are born from pplPortal, HR BI reveals patterns the payroll sheet hides. And it is here that compliance tightens most, as we shall see.

7. Applicable regulatory framework and compliance

A BI project touches sensitive data — sales, margins, payroll, employee data. Compliance is not optional.

GDPR and people data in dashboards

As soon as an HR dashboard shows absenteeism, turnover or performance by employee, it falls within the scope of the GDPR and Law 58/2019. The operational rules: minimisation (only the data necessary for the decision), access control by profile (the line supervisor does not see salaries), and a record of who accesses what. Qlik Sense allows section access — security at the data-row level — which does exactly this when well configured.

The most common error is the HR dashboard that shows everything to everyone with access. A production manager who can see the individual salaries of his team through a poorly configured panel is a breach waiting to happen — and Law 58/2019 does not distinguish between malice and carelessness. The rule is to design access before designing the chart: who can see which row, aggregated at what level, with what granularity. Absenteeism by section is legitimate for the manager; the named absenteeism of a specific employee requires a legal basis and access restriction.

Invoicing, SAF-T and the origin of the numbers

The invoicing data that feeds the commercial dashboards is born from AT-certified software, within the scope of DL 28/2019 (ATCUD, certified programs) and the monthly SAF-T communication (Ordinance 195/2020). BI consumes that data — it does not replace or alter it. The coherence between what the dashboard shows and what was communicated to the AT is a mandatory check at launch.

There is a subtle trap here. The commercial dashboard and the tax return must tell the same invoicing story, but they measure periods and criteria that may diverge — sale by order date in the panel, by document date in the return. If nobody reconciles the two at launch, later someone notices the difference and loses trust in the entire BI. The initial reconciliation against the official source is not bureaucracy — it is what guarantees the panel is not challenged at the first difficult meeting.

Cybersecurity: NIS2 and ISO 27001

A BI server concentrates the company's most sensitive data in one place — which makes it a target. The NIS2 Directive (EU 2022/2555), transposed in Portugal by DL 65/2025, extends cybersecurity obligations to more sectors, including industry and distribution of relevant size. A serious BI project deals with hosting in a datacentre with access controls, encryption and backups, and with perimeter cybersecurity. We go deeper into the risks in the silent cybersecurity risks in the company and into the protection in INFOS security: perimeter protection and SOC.

The point that escapes many an SME: BI amplifies the risk surface precisely because it aggregates. An attacker who compromises the ERP sees one module; one who compromises the BI server sees the whole company in one panel — margins, clients, salaries, all cross-referenced and presented legibly. That is why the BI server deserves the same security treatment as the ERP core, not less. The ISO 27001, 27017 and 27018 certifications give the framework of controls; the operational essentials are minimum access by profile, encryption at rest and in transit, and tested backups — not presumed.

Compromising the ERP shows one module. Compromising the BI server shows the whole company, already cross-referenced and legible. Treat it accordingly.

Augmented AI and the AI Act

If you move to BI with AI — turnover forecasting, automatic anomaly detection — Regulation EU 2024/1689 (AI Act) classifies AI systems by risk. Predictive analytics of people's performance requires heightened attention; anomaly detection in production, much less. Knowing which category each use case falls into is part of the design, not an afterthought. See AI applied at INFOS: turning data into automated decisions.

The practical distinction is this: using AI to detect that a machine is deviating from the normal cadence is low risk and high value — nobody contests a maintenance alert. Using AI to predict which employees will leave, or to score people's performance, falls into a sensitive zone that requires transparency, a legal basis and caution. pplPortal has predictive turnover and absenteeism components precisely because the value is real — but the design has to assume from the outset that these use cases live under regulatory scrutiny, and not treat them as just another chart.

8. How INFOS approaches this

We have worked exclusively with Portuguese industry and distribution for more than three decades. That means we do not arrive at a footwear factory asking what a "fitting" is, or at a maker asking how fabric consumption is calculated. The vertical concepts are already in the MULTI ERP, and Qlik Sense inherits them — which cuts months of modelling from scratch.

Our preference is to start small and prove value: one use case with acute pain, data already born reliable in the ERP and in KORA Productivity, and a decision owner who wants the panel. Then it expands. The onboarding of the business users is handled with the same care as the technical part — because a dashboard nobody knows how to use does not exist.

About INFOS we invent neither cases nor percentages. What we state is generic and true of the category: a vertical BI well anchored in an industrial ERP shortens the time to the first useful dashboard and reduces the maintenance effort, because you do not rebuild the business semantics with each project.

The proof of concept before the commitment

The most honest way to start is not a twenty-page proposal — it is a proof of concept over the company's real data. You take a use case, connect the true sources, and build the first panel with data the CFO recognises. If the numbers tally with what he knows, trust has been won. If they do not tally, you have discovered where the data is born dirty — and that, in itself, already justifies the exercise. A PoC over real data kills the vague promises and replaces them with evidence the board sees with its own eyes.

Maintenance — the cost the demo hides

The demo always shows opening day. What separates a living project from a cemetery of dashboards is maintenance: when the ERP changes a field, when a new line comes in, when the business starts measuring something it did not measure before, someone has to update the model. In a generic BI built by a passing consultant, that maintenance is orphaned. In a BI anchored in a vertical ERP maintained by the same vendor, the change in the ERP and the change in the BI happen together. It is an advantage that does not appear in the demo but that decides whether the project is alive three years from now.

9. 30/60/90-day roadmap

A departmental BI launch in a Portuguese industrial SME fits in 90 days — if there is scope discipline. The error is wanting everything in the first quarter.

Days 1–30: scope and data

• Choose one use case with an owner and acute pain — not three.
• Map that case's data sources and verify reliability at origin.
• Define the 5–8 KPIs that serve the target decision — and refuse the "would be nice to have" ones.
• Confirm hosting, access and GDPR compliance for the data involved.

Days 31–60: build and validate

• Set up the data load from the ERP and the sources into the Qlik model.
• Build the first operational dashboard with the decision owner validating week by week.
• Test row-level security (section access) for the right profiles.
• Verify the coherence of the dashboard numbers against the official source (ERP, SAF-T).

Days 61–90: adopt and measure

• Train the business users in reading and in basic self-service.
• Measure real adoption — who opens the panel and how often. If nobody opens it, the problem is the design, not the training.
• Document the value generated in the target decision (time saved, error avoided).
• Only then plan the second area — with the credit of trust already earned.

Ninety days is enough for a dashboard that changes one decision. It is not enough for the universal dashboard — and just as well, because nobody uses that one.

What to measure to know whether it worked

Adoption is the only honest judge. Three things are counted at the end of the 90 days: how many people open the panel in a normal week, how many times each one, and whether the target decision

Frequently asked questions

Is Qlik Sense suitable for Portuguese industrial SMEs?

Yes. Qlik Sense was designed for companies that have data scattered across ERPs and Excel files but lack operational visibility. It adapts well to factories with 40 to 500 employees that need real-time dashboards without a massive investment in IT infrastructure.

How long does it take to implement an operational dashboard?

Between 6 and 12 weeks, depending on the complexity. A textile SME with a consolidated ERP can have a margin-by-order panel in 8 weeks. The critical time is cleaning the data in the ERP and aligning on which metrics really matter.

Is it necessary to have an internal IT department?

Not necessarily. An external implementer (BI consultant) builds the panel and trains two internal users for basic maintenance. Most industrial SMEs manage Qlik dashboards with a half-time IT technician after implementation.

How does BI help with the lot traceability required by the EU?

Qlik cross-references lot data from the ERP — dye house, composition, water/energy consumption — and presents it in a panel that responds in minutes. Without BI, that information stays scattered across documents. With BI, the German buyer receives the product's digital passport in real time.

What is the typical cost of a Qlik Sense project in a 100-person factory?

Between 15,000 and 35,000 euros (implementation + first-year licences). It varies with the number of dashboards, the complexity of the ERP and the need for data cleaning. The ROI appears when it eliminates 3–4 weekly hours of manual work in Excel.

Can Qlik show the real margin of an order while it is in production?

Yes. If the ERP feeds the panel with real yarn consumption, machine times and scrap in real time, Qlik cross-references that data with the original budget and shows margin deviations daily. This is critical in textiles, where the margin was only known at the close.

What is the difference between a dashboard for textiles and one for footwear?

The textile panel focuses on margin by order and lot traceability. The footwear panel focuses on margin by SKU, deadline compliance by client and time deviation by fitting. They are different business questions requiring distinct data structures in Qlik.

Sources

• Instituto Nacional de Estatística (INE) — Survey on the Use of Information and Communication Technologies in Enterprises (IUTIC), data 2023–2025
• European Commission — EU Strategy for Sustainable and Circular Textiles and Regulation (EU) 2024/1781 (Digital Product Passport)
• Associação Têxtil e Vestuário de Portugal (ATP) — Sectoral Competitiveness Reports