Qlik Sense in industrial production: from data collection to the operational dashboard

In a knitwear factory in Vizela, the production manager has a 55-inch screen on the office wall. It shows a Qlik Sense dashboard with OEE per machine, refreshed every 15 minutes. Handsome. Except nobody on the shop floor sees it — it faces the management corridor. And the data feeding it comes from an Excel file that Dona Fernanda fills in at 5.30pm, with the numbers the supervisors give her off the top of their heads. The dashboard exists. Data-driven management does not.

This article makes an uncomfortable case: in Portuguese industrial production, Qlik Sense almost never fails because of Qlik Sense. It fails because upstream data capture is fantasy, because nobody has defined what a "unit produced" means, and because the dashboard was designed to impress visitors rather than to change a decision at 10am. The BI software is the easy part. The hard part is everything that happens before the data reaches the associative engine.

Let us put it another way, so there is no doubt. Buying Qlik Sense without sorting out data capture is buying an extremely powerful microscope to observe a blank slide. The resolution is magnificent. There is nothing to see. And this mistake repeats itself in factories of 20 people and in groups of 400 — the scale changes, the nature does not.

1. The real operational problem

Let us begin with what you see in factories when you walk in. Not with theory.

The report that arrives too late to be of use

In a garment maker near Famalicão, the month-end close takes three days. Not because the figures are complex — because the real output of each line lives in notebooks, in supervisors' memories and in a shared Excel that three people edit at the same time and no one knows which is the good version. By the time the consolidated figure reaches the CEO, it is already the 4th of the following month. The decision he could have made — stopping an order that was running at a loss per item — has missed the window.

The problem is not the lack of a report. It is that the report describes a dead past. An operational dashboard that cannot answer "what is happening now" is decoration.

Note the asymmetry. The decision that makes money is almost always a quick-correction decision: stopping a line that is producing scrap, reassigning an operator from a machine idled by a lack of yarn to another that is falling behind on the Inditex order, anticipating that a batch of knit will reach finishing late. These decisions have a window of minutes or hours. A monthly report, however handsome, always arrives after the window has closed. It is announcing the funeral, not preventing the illness.

The case of the order that bled in silence

A pattern we see far too often in a subcontracted garment maker: an order of 4,000 pieces for an international parent company, with a fixed price per item, negotiated against a target production rate. If the real rate falls 18% below the forecast — because the fabric is harder to sew, because the experienced machinist went on sick leave, because the machine setup took twice as long — the margin evaporates. And in a garment maker without real-time capture, this is only discovered at the close. The order has already shipped. The loss has already been booked. Nobody consciously decided to lose money; simply, nobody saw it in time.

In a garment maker working on a subcontracting margin, it is not the lost order that kills — it is the order won and produced at a loss, that nobody saw bleeding until the close.

The three places where data gets lost

In three decades implementing systems in Portuguese industry, we always see the same leak points:

• Manual capture at the workstation — the operator who notes the quantity on a piece of paper and transcribes it at the end of the shift, with the transcription errors that entails and the temptation to "round up" to the number the supervisor wants to hear.
• The ambiguous definition of a metric — does "the day's output" include the reworked piece? Does it count scrap? Does it count setup time as downtime or as production? Each supervisor answers differently, and the dashboard adds apples to oranges.
• The silo between ERP and shop floor — the MULTI ERP knows what was ordered and invoiced; the shop floor knows what was actually made. If the two do not talk, the BI picks one side and lies about the other.

A dashboard fed by manual capture is not business intelligence — it is the same spreadsheet, now with colours.

The economics of the transcription error

Some dismiss the transcription error as a detail. It is not. Consider a factory with 60 workstations, three shifts, each operator recording around eight entries per shift. That is more than 1,400 manual records a day. If just 2% contain an error — an optimistic rate for handwriting transcribed at the end of the shift — that is nearly 30 wrong data points entering the system every day. By month-end, the accumulated error in OEE, in cost per unit and in material consumption is not random noise: it tends to be biased, because the operator always rounds in the same direction, the one that keeps the supervisor happy. The dashboard does not show uncertainty. It shows an exact and false number.

Why the spreadsheet survives so long

According to INE, in 2025 only 45% of companies in Portugal carried out data analysis (big data/analytics), up 6.4 points from 2023. The majority still manage by eye and by instinct. And the spreadsheet survives because it works well enough — until the day Inditex asks for batch-by-batch traceability, or the German customer demands a quality report that Excel simply cannot produce without two nights of work. We say more about this transition in Qlik Sense in Portuguese industry: from spreadsheet to decision.

There is also a cultural reason that is rarely admitted aloud. The spreadsheet is someone's property. Dona Fernanda, who fills it in, holds, in practice, a monopoly over the truth of production. Digitising capture takes that power away from her — and it is natural that she resists, consciously or unconsciously. Anyone who has seen an implementation run aground on "Excel does everything, why complicate things" knows it is rarely a technical objection. It is territorial. Ignoring this human dimension is the quickest way for a good BI project to die in its first week.

The effect of supply chain pressure

What ultimately pushes is the customer. The EU Strategy for Sustainable and Circular Textiles and the forthcoming Digital Product Passport will require traceability that a notebook does not provide. When a brand asks for the composition, the origin of the yarn, water and energy consumption per batch and the subcontracting chain, the factory managing in Excel discovers, overnight, that its truth is not auditable. And there is no last-minute report that solves the absence of structured capture throughout the whole year. Regulatory and brand pressure is turning BI from a luxury into a condition of market access.

2. What exactly is Qlik Sense in industrial production

A rigorous definition

Qlik Sense is a business intelligence and data visualisation platform based on an in-memory associative engine. Translating from the brochure to the factory: it loads data from several sources (ERP, shop-floor capture, files, databases), keeps it in memory and lets you explore the relationships between them without having to build every query in advance. Click on "machine 4" and the whole dashboard reacts — output, downtime, scrap, operator — showing what is associated and, critically, what is not.

That "what is not" is the part that distinguishes the associative model from traditional reports. In a classic report, you filter by machine 4 and see machine 4's data. In the associative model, when you select machine 4, the rest of the dashboard also shows you, greyed out, the operators who never worked on that machine, the shifts in which it was stopped, the downtime reasons that did not occur. Absence is information. In a quality analysis, knowing that a particular defect never appeared on a certain shift can be as revealing as knowing where it did appear.

In industrial production, this materialises in three families of indicators: efficiency (TPM, OEE, availability, rate), quality (scrap rate, reworks, non-conformities per batch) and cost (real cost per unit, deviation from standard, material consumption per manufacturing order).

OEE — the number everyone quotes and few calculate correctly

OEE (Overall Equipment Effectiveness) multiplies three factors: availability × performance × quality. An OEE of 60% is not "60% good" — it is the product of, for example, 85% availability, 80% performance and 88% quality. The classic error is a factory reporting an OEE of 90% because it is only measuring availability and calling it OEE. Qlik Sense does not solve this — the correct definition has to be at source, in the capture.

It is worth breaking down each factor, because that is where the honest discussion begins:

• Availability — the time the machine was effectively producing, over the planned time. Here lies the great trap: what counts as "planned time"? Does it include the lunch hour? Setup? The cleaning break? Two factories with the same machine and the same output report different availabilities purely because of this definition.
• Performance — real rate over the machine's theoretical rate. If the machine was designed for 100 pieces/hour and made 78, performance is 78%. The common error is to use an optimistic theoretical rate from the catalogue, which the machine never reached in real life.
• Quality — good pieces over total pieces produced. Simple to define, hard to measure honestly, because it requires recording scrap — and nobody likes recording their own mistake.

A world-class OEE is around 85%. Most of the series-production factories we visit, when they measure honestly for the first time, find themselves in the region of 45% to 60%. And this discovery is often traumatic: management was convinced it was "running at 80". The distance between perception and the real number is, very often, the biggest discovery of the first month of a BI project.

A factory's first honest OEE is almost always a shock. Not because the factory is bad — because everyone lived with an inflated number that no one had the courage to audit.

Where the ERP ends and BI begins

Much of the confusion is born here. The ERP records transactions: orders, manufacturing orders, stock movements, invoicing. The shop-floor capture system — an MES such as KORA Productivity — captures production events in real time: order start, piece count, downtime and its reason. The BI, Qlik Sense, reads both and cross-references them to produce the indicator. Three layers, three functions. Anyone who tries to use the ERP as a BI tool ends up with rigid reports that take a week to change every time the business changes.

The ERP says what should have happened. Capture says what happened. BI shows the difference between the two — and it is in that difference that the money lives.

MRP, planning and the role of BI in the cycle

There is a fourth piece that rarely enters the conversation and should: MRP and production planning. MRP calculates what to buy and when to produce based on orders and stock. But MRP works with theoretical capacities — it assumes the line produces at the nominal rate. If BI reveals that the real rate is 20% below the theoretical, planning is systematically promising lead times the factory does not meet. Here BI stops being merely a mirror of the past and starts feeding back into planning: the MRP rate parameters should be calibrated with the real data that Qlik Sense exposes. This feedback cycle — measure, calibrate the plan, measure again — is what separates a factory that learns from one that merely reports.

3. The picture in Portugal today

The numbers that define the starting point

The conversation about BI in Portugal has to start by acknowledging where the installed base is. Three data points from INE, referring to 2025, sketch the picture:

• Only 53.7% of companies used an ERP. Almost half do not even have an integrated transactional core — and without a core, BI works over data scattered across islands.
• Only 38.7% purchased cloud services. The infrastructure for modern data analysis is still not the majority.
• 45% carried out data analysis — rising, but far from universal. And "doing analysis" includes anyone who opens a dashboard once a month.

Read together, this says one thing: the majority of Portuguese industrial SMEs are skipping steps. They buy a Qlik Sense before having the ERP and capture in order, and then find it odd that the dashboard does not match the reality of the warehouse.

The fracture between large and small companies

The national average hides a deep fracture. Large Portuguese companies adopt ERP, cloud and analytics at rates approaching those of their European peers. It is in the micro and small companies — which make up the overwhelming majority of the industrial fabric of the North — that the lag is concentrated. A family garment maker of 18 people in Barcelos and a textile group of 400 in Guimarães live in different digital worlds, even 30 kilometres apart. Any BI strategy that ignores this asymmetry sells the same prescription to patients with opposite conditions.

According to data published by the European Commission as part of the digitisation index, Portugal sits close to the EU average on connectivity and digital public services, but below on the integration of digital technology in companies — precisely the dimension where industrial BI lives. In other words: we have a good network, we have mandatory e-Fatura, but the internal analytical maturity of industrial companies lags behind the available infrastructure. The tool arrived before the culture of using it.

The industrial weight that justifies the investment

It is not for lack of industry. The Portuguese metallurgical and metalworking sector has, according to AIMMAP, more than 23,000 companies and around 250,000 people employed. Textiles and clothing from the Vale do Ave cluster and footwear from Felgueiras and Guimarães export to the world's biggest brands. These are operations with tight margins, where a percentage point of OEE or half a point of scrap defines whether the order made a profit. It is precisely here that operational BI pays back the investment — and precisely here that capture, very often, is still in a notebook.

The calendar as a data source: the footwear case

In footwear, the data structure has a dimension that generalist ERPs ignore: the rhythm of collections. International buyers visit twice a year — men's footwear typically in August, women's in February. A sample collection brings 800 to 1,200 SKUs, with three simultaneous axes of colour, size and last. This means the data model has to support a combinatorial explosion: a single model in eight colours, ten sizes and three lasts generates 240 SKUs. A BI that does not understand this structure will produce sales dashboards by "product" that aggregate what should not be aggregated — mixing the boot that sells with the one that stayed in stock, because it treats them as the same article. Verticality is not a commercial argument; it is a condition for the number to make sense.

Distribution and retail: the same problem, a different floor plan

The pattern is not exclusive to production. In a distribution centre in the Lousada/Paços corridor, the warehouse manager runs picking and cross-docking with a radio in hand. The truth of the stock lives in the physical movement, not in the ERP — and any rollout that takes it away from the radio for more than two hours meets fierce and legitimate resistance. In regional food retail, BI cross-references sales per store, margin per category and shelf stock-outs, but depends on a certified POS feeding it clean data. In both cases, the lesson repeats itself: the dashboard is only as good as the capture at the point where reality happens — the dock, the shelf, the sewing station.

Funding: the PT2030 and PRR window

A good part of these projects goes through applications to PT2030, PRR, COMPETE 2030 or Norte 2030. What gets approved easily is investment in digitisation with measurable productivity indicators. What gets stuck in technical reports is the vague project, with no baseline or targets. An operational tip: before submitting, have the current OEE measured for at least one month. Without a baseline, the evaluating technician has no way to validate the promised gain — and the application drags on.

There is a second recurring error in applications: promising productivity gains without indicating how they will be measured afterwards. The IAPMEI or CCDR-N evaluator wants to see the measurement mechanism. If you say "we will increase productivity by 15%", you have to say how you measure productivity today and how you will measure it at the end — and this is where having Qlik Sense over the MES already producing reliable OEE turns the application into an easy case to approve, because the project itself provides the instrumentation for its own evaluation. Digitising capture and BI are not just the object of the investment; they are the proof of its return.

A PT2030 application without a measured baseline is a promise without a witness. The evaluator does not refuse the ambition — it refuses the impossibility of verifying it.

4. The implementation models

There are four typical approaches to getting Qlik Sense working in industrial production. Choosing badly costs months.

Comparison of the four approaches

Trade-offs no one explains in the sales pitch

The temptation is to start with the first row — "let's just connect Qlik to Excel to get going". Do it, but with a death sentence: an Excel pilot that lasts more than two months fossilises and becomes the definitive system, with all the defects of manual capture. The third row, MES + ERP via KORA Productivity, is the sweet spot for the overwhelming majority of Portuguese garment, footwear and series-metalworking factories. The fourth, with IoT and sensorisation, only pays off in processes where the machine data is dense and continuous — plastic injection in the Marinha Grande, for example — and where it makes sense to move towards a Digital Twin of the process.

When IoT pays off and when it is technological vanity

The fourth approach seduces because it sounds like Industry 4.0. But sensorising everything without a clear use case is the most expensive way to collect data that no one reads. IoT pays off when the process is continuous and the physical variable is the key to the problem: temperature and pressure in a plastic injection machine, vibration in a critical bearing, electrical consumption per cycle. In these cases, the data density justifies the sensorisation and opens the door to predictive maintenance. It does not pay off on a sewing line, where the relevant event — piece made, downtime, scrap — is discrete and better captured by a workstation terminal than by a sensor. The right question is not "can we sensorise?" but "what business decision changes with this data every second instead of every shift?". If there is no answer, the sensor is expensive decoration.

Integration as the Achilles' heel

The quality of BI is the quality of the integration. Connecting MES, ERP and any sensors requires a serious integration layer — what today is called iPaaS or, in the MULTI ecosystem, MULTI Connect. Underestimating this layer is the error that most delays projects. The rule of thumb: for every week you planned to build dashboards, plan two to ensure that the data feeding them is consistent, deduplicated and with single definitions.

There is a specific trap in integration that is rarely anticipated: temporal reconciliation. The ERP closes a manufacturing order at one moment; the MES counted the pieces over the course of the shift; the quality system recorded the scrap hours later, when the inspection was done. If BI cross-references these three without aligning the clocks and the time windows, it produces numbers that do not add up — the sum of good pieces plus scrap does not match total production, and the manager loses confidence at first glance. Integrating is not just connecting tables; it is reconciling the time at which each system records its truth.

No one trusts a dashboard twice. If in the first week the numbers do not match the reality of the shop floor, you have lost the production manager forever.

5. How to assess whether your company needs it

Not every factory is ready for operational BI. Some first need to put their upstream house in order. This diagnosis separates the two cases.

Signs that you are ready

• You have an integrated ERP recording manufacturing orders and movements — not isolated invoicing in one program and production in a notebook.
• You can identify, today, who is responsible for defining what counts as a "unit produced", "scrap" and "downtime".
• Management is already asking for indicators that the current system cannot deliver in less than a day.
• There is at least one internal person — often the self-made IT person with 15 years in the house — who masters the business and will be the functional owner of the project.

Signs that you need to tidy up first

• Real production lives in papers and memories. There is no digital capture at the workstation.
• Each supervisor calculates their indicators their own way.
• No one can say, without hesitation, what the factory's average OEE was last month.

The functional owner: the self-made IT person as the central piece

In Portuguese family companies, the decision almost always goes through the trio of CEO, CFO and the IT person. And that IT person is often a self-taught hero with 15 years of business knowledge and no formal degree — the one who knows where all the ERP's custom fields are buried and why order 2019/0043 has to be handled separately. Ignoring this figure is the most expensive error of a BI project. He is not an obstacle; he is the asset. He knows the exceptions that no documentation records and that make any dashboard gain or lose credibility. The role of functional owner falls to him naturally, provided management gives him protected time — and does not pile the project on top of the current work already running at 110%.

Step-by-step diagnosis

1. Measure the decision latency. Ask: how much time passes between a problem happening on the shop floor and someone with decision-making power knowing about it? If the answer is "at the month-end close", you have a capture problem, not a BI problem.
2. Audit the definition of the three base metrics. Gather the supervisors in a room and ask each of them to define "unit produced", "scrap" and "downtime". If the answers diverge, resolve this before buying any software.
3. Map out the data sources. List all the places where production information lives: ERP, sheets, notebooks, heads. Each manual source is a future failure point for your dashboard.
4. Identify the three decisions you want to support. Not "I want to see everything". You want to decide what? Stopping a loss-making order? Reassigning operators? Anticipating a safety stock break? Three concrete decisions define the three dashboards worth having.
5. Name the functional owner. Without an internal person responsible for the indicators, the project dies at the first report that does not match up.

The coffee test: a quick heuristic

Before any formal project, there is a two-minute test worth more than many meetings. Ask the production manager, at coffee time, three things: what yesterday's OEE was, which order is losing the most margin this week, and which machine stopped most this month and why. If he answers with numbers without going to look anything up, the factory already has a data culture and BI will merely accelerate it. If he hesitates, looks sideways, or answers "I have to check with the supervisor", the diagnosis is made: the problem is not a lack of dashboard, it is a lack of live data. No software solves a culture that still manages by instinct — it only makes it visible.

This exercise of tidying the house before digitising is at the heart of how to build a data-driven organisation: the first step.

6. What to choose and why, by company size

The decision matrix

Why this logic and not another

Size determines the order, not the ambition. A factory of 25 people that spends its budget on Qlik Sense before digitising capture is buying an expensive mirror of its own chaos. Capture first, analysis later. Above 30 employees, with several lines and shifts, the cost of not having reliable OEE outweighs the cost of the project — and there the ERP + MES + BI combination is fully justified. In groups with several units, the challenge changes in nature: it becomes data governance, ensuring that a "unit produced" means the same in Barcelos and in Felgueiras. Here QAD Adaptive ERP and a governed Qlik Sense make sense.

The small company: resisting the seduction of the dashboard

For the factory with fewer than 30 people, the most valuable advice is often "not yet". Not because it does not deserve data — but because the money yields more in digitising capture and integrating the ERP than in buying visualisation of data that does not exist in a usable state. A simple terminal at the workstation, a single definition of the three metrics and the ERP recording manufacturing orders are worth more, at this scale, than any dashboard. BI comes the following year, when there is data worth seeing. Ordering the investment the wrong way round is the most common waste we see in this segment.

The medium-sized company: the clearest point of return

In the 30 to 250 employee band, with several lines and shifts, lies the clearest return of all. The scale already generates enough complexity that the supervisor's instinct no longer suffices, and it is still small enough that an implementation of KORA Productivity with Qlik Sense on top covers the whole factory in a single, manageable project. It is here that the half point of scrap avoided or the point of OEE recovered translate, by year-end, into a value that pays for the project several times over. And it is here that most funding applications with good returns are concentrated.

The groups: governance before tool

Above 250, with several production units, the technical problem is the smallest one. The hard part is organisational: making "piece produced", "scrap" and "hour of downtime" mean exactly the same in every factory, so that the group's consolidated dashboard does not add apples from Barcelos to oranges from Felgueiras. This requires a central metrics dictionary, a data owner per domain and a governed Qlik Sense, with control over who sees what and a single authoritative definition of each indicator. The tool is the same; the governance discipline is what changes — and it is what tends to be missing.

The error of buying dashboards instead of decisions

The worst brief we receive is "we want to see everything on one screen". Seeing everything is seeing nothing. A good operational dashboard fits on a shop-floor TV and answers one question in a two-second glance: are we or are we not meeting this shift's plan? Deep-exploration dashboards, with associative filters, are for the office — not for the line wall. Confusing the two produces handsome screens that no one uses. We detail this distinction in dashboards that industrial production actually uses.

7. Applicable regulatory and compliance framework

What BI touches in matters of compliance

An industrial BI project seems neutral from a regulatory point of view. It is not. As soon as it cross-references production data with operator data — who produced what, at what rate — it enters the scope of the GDPR and Law 58/2019. Individual performance indicators have to respect the declared purpose and data minimisation. You cannot surreptitiously turn a dashboard of OEE per machine into a system of individual productivity surveillance without a legal basis and information to workers.

The fine line between managing and surveilling

This boundary deserves care, because it is easy to cross unintentionally. A dashboard that measures a machine's OEE is equipment management. The same dashboard, filtered by operator and used to compare people in a ranking displayed on the wall, is the processing of individual performance data — and that has legal and, above all, human consequences. In a factory with an ageing workforce, as is common in northern garment making, exposing an individual productivity ranking destroys morale faster than any efficiency gain it brings. The rule we follow: measure the process, not the person. And, when individual data is necessary, treat it with a declared purpose, minimisation and full transparency with workers and their representatives.

Security and infrastructure

• ISO 27001 — if production data resides on managed infrastructure, require from the supplier a certified information security management system.
• NIS2 (EU Directive 2022/2555, transposed by DL 65/2025) — extends cybersecurity obligations to more entities. Factories in the supply chains of essential sectors may be covered indirectly, at their customers' demand.
• DL 28/2019 and SAF-T — when BI cross-references commercial and invoicing data, the source data has to come from software certified by the AT. The dashboard inherits the reliability of the source.

NIS2: the compliance that arrives through the supply chain

Many Portuguese industrial factories believe that NIS2 does not concern them, because they are not critical infrastructure. It is a risky reading. The directive extends security obligations to the supply chains of essential and important entities — and a factory supplying components or technical textiles to a covered customer may find itself contractually obliged to demonstrate a cybersecurity maturity it does not have. ENISA has been stressing precisely the risk of the supply chain as a dominant attack vector. When production data comes to reside in the cloud and to feed remotely accessible dashboards, the attack surface grows — and the customer who demands the OEE report may come to demand also the security certificate of whoever produces it.

A per-operator productivity dashboard without a GDPR legal basis is not a technical risk — it is a lawsuit waiting to happen.

AI over production data

Anyone moving to predictive models over production data — predicting scrap, anticipating downtime — enters the scope of the AI Act (Regulation EU 2024/1689), with the corresponding risk classification. AI systems applied to workers have heightened requirements. The cybersecurity of these flows, with a SOC and adequate perimeter protection, ceases to be optional from the moment factory data leaves for the cloud.

There is a practical distinction that the AI Act obliges us to make and that changes the regulatory exposure. A model that predicts a bearing failure from vibration data is limited-risk AI — it acts on the machine. A model that classifies or scores workers based on their performance may fall into the high-risk category, with much heavier obligations of documentation, human oversight and transparency. The boundary is again the same as in the GDPR section: modelling the process is safe; modelling the person raises the level of requirement to another plane. Before letting yourself get excited about predictive AI over the shop floor, classify the use case — because the wrong classification is an expensive non-conformity.

8. How INFOS approaches this

Our conviction, after more than three decades in Portuguese factories, is simple: BI is the top floor, not the first. That is why we do not sell Qlik Sense in isolation like someone who sells a licence and walks away. We look first at capture — KORA Productivity capturing real production at the workstation, with terminals the operator can use without taking off their gloves — and at the transactional core, the MULTI ERP vertical for your sector. Only then does Qlik Sense cross-reference everything and produce the indicator the manager trusts.

That verticality matters. A generalist ERP does not model a footwear collection with 800 to 1,200 SKUs and three colour-size-last axes. If the data model at source is wrong, no dashboard corrects it. We work from the knowledge of textiles, clothing and footwear because that is where INFOS has 36 years on the road.

The terminal the operator uses without taking off their gloves

A detail that seems minor and decides projects: the ergonomics of capture at the workstation. In a dyeing plant in the Vale do Ave, the operator has wet hands and sometimes gloves on; on a sewing line, the fingers are busy with the piece; in a distribution warehouse, the gesture has to be made standing up, with the radio in the other hand. If capture requires typing on a small keyboard or navigating complex menus, the operator does not record — or records badly, at the end of the shift, off the top of their head, and we are back to Dona Fernanda's Excel. An industrial terminal designed for the real gesture, with barcode reading, big buttons and the minimum of steps, is the difference between data that exists and data that is invented. The best BI in the world does not survive a capture that the shop floor hates to use.

Honesty about what goes wrong

And we are honest about what goes wrong: the BI projects that fail at INFOS almost always fail because of upstream capture and the absence of an internal functional owner. That is why we insist on the diagnosis in section 5 before writing the first line of data load. We learned this the hard way, in projects where the customer wanted to start with the dashboard and we gave in — and after two months we had beautiful screens that no one believed, because real production went on living in a notebook the system did not see. Today we refuse to start at the end. Not out of stubbornness; out of accumulated experience of knowing where the project derails.

On the path of AI applied to decisions, the principle holds: without clean data at the base, AI amplifies the rubbish faster. A predictive model trained on a biased manual capture does not predict the future — it projects the bias of the past with a statistical confidence that deceives. The correct order never changes: reliable capture first, then the honest indicator, only then the prediction.

9. 30/60/90-day roadmap

Days 1–30: foundation and baseline

• Complete the diagnosis in section 5 and name the internal functional owner.
• Close the single definition of "unit produced", "scrap" and "downtime" — documented and signed off by the supervisors.
• Establish the baseline: measure the current OEE for at least four weeks, even if capture is still imperfect. It is the number against which everything will be compared — and what the PT2030 application will require.

Days 31–60: capture and integration

• Get digital capture working on one or two pilot lines — not the whole factory. A poka-yoke on the terminal prevents the operator from recording the impossible.
• Build the integration layer between MES and ERP and validate, line by line, that the numbers match the physical count.
• Run the first operational dashboard in parallel with the old method. It only earns confidence when the two agree for two consecutive weeks.

Days 61–90: dashboard and adoption

• Publish the three dashboards that answer the three defined decisions — one for the line wall, two for the office.
• Turn the line screen to face the operators, not the visitors. Team engagement is born from seeing their own performance in real time, not from being surveilled from above.
• Extend capture to the remaining lines only after the pilot is reliable. Scaling chaos is faster than scaling order, but costs much more.

After the 90 days: what sustains the gain

The final error, more common than admitted, is to declare victory at 90 days and withdraw attention. An operational BI project does not end with the publication of the dashboard; it starts there. Metric definitions drift over time — a new machine comes in, a shift changes, a process is altered — and without maintenance the dashboard slowly drifts away from reality until it no longer matches up again. That is why the functional owner has to continue to exist after the launch, with a quarterly review of the metrics dictionary and a regular check that the Qlik Sense numbers still agree with the physical count. Trust is won in 90 days; it is lost in a week of negligence.

At the end of these 90 days, the test is single and brutal: when the production manager

Frequently asked questions

Does Qlik Sense alone solve data problems in production?

No. Qlik Sense is only the final visualisation tool. If the data feeding the dashboard comes from manual capture or disorganised Excel files, the software cannot create intelligence out of rubbish. The quality of the result depends 80% on upstream capture and only 20% on the BI tool.

What is the difference between a handsome dashboard and an operational dashboard?

A handsome dashboard impresses in presentations, but arrives late. An operational dashboard answers "what is happening now" and enables corrective decisions in minutes or hours. In production, the decision window is short — a monthly report can never prevent losses that occur daily.

Why is manual data capture so problematic?

Manual capture introduces three types of error: transcription (the operator writes it down wrong), rounding (adjusts numbers to please the supervisor) and delay (data arrives too late to act). In a factory with 1,400 daily records, 2% error means 30 false data points a day — enough to completely distort OEE and costs.

How does an order "bleed" without anyone noticing?

When real production falls below the forecast rate — due to difficult fabric, an absent operator or a long setup — the margin evaporates gradually. Without real-time capture, this is only discovered at the month-end close. The order has already shipped and the loss is booked. The decision to stop or reassign resources was never made.

What is the impact of ambiguous metric definitions?

If "the day's production" means different things to each supervisor — some count scrap, others do not; some include setup, others do not — the dashboard adds up incomparable data. This creates the illusion of precision while the system is systematically lying about real performance.

Why do the ERP and the shop floor not talk to each other?

The ERP records orders and invoices; the shop floor records what was actually produced. If they are not integrated, BI picks one side and ignores the other. The result is two contradictory "true data" — one for management, one for production.

Why do companies keep using Excel instead of automatic systems?

Excel works well enough until the customer demands traceability or complex reports that Excel cannot produce. There is also a cultural reason: whoever fills in the Excel holds power over the "truth" of the data. Digitising capture takes away that monopoly, generating natural resistance.

Sources

• National Statistics Institute (INE) — Survey on the Use of Information and Communication Technologies in Enterprises (IUTICE), 2023-2025 data on data analysis and big data in Portuguese companies
• ISO/IEC 27001:2022 standard — Information security management systems, applicable to the capture and processing of operational data in an industrial environment
• ISO 22400:2018 standard — Automation systems and integration — Key performance indicators (KPIs) for manufacturing operations management, a reference for defining metrics such as OEE
• Banco de Portugal — Reports on digital transformation and technology adoption in Portuguese industrial SMEs