Most textile factories in the Vale do Ave do not have an ERP problem. They have a boundary problem. The financial software knows everything up to the shop-floor door — and beyond that it goes blind. On the far side of that boundary is where real production happens: the dyeing bath, the cutting sheet, the machine that stopped at 14:37. On this side, the CFO closes the month with numbers that described yesterday's factory.
The thesis is simple and uncomfortable: the integration that matters is not the pretty dashboard at month-end. It is the one of the batch. If the raw-material batch number does not survive intact from the reception of the yarn to the label that leaves with the box, everything else — OEE, margin per order, traceability for the brand — is fiction built after the fact in Excel. We know where projects fail: they fail here, at the seam between two systems that learned to call different things a "batch".
Why the boundary matters more than the dashboard
Around two thirds of national textile and clothing production is destined for export (ATP). And exports of the Portuguese textile and clothing industry reached 5,499 million euros in 2025, led by Spain (€1,318M), France (€834M) and Germany (€461M) (INE, provisional data Feb/2026, via ATP). Translated to the shop floor: most production leaves the country and passes through the purchasing filter of Inditex, Decathlon, Tom Tailor.
When the buyer from those parent companies asks for proof of compliance with the EU Strategy for Sustainable and Circular Textiles, what they want is the genealogy of the product: which yarn, which dyeing, which bath, which machine, which shift. This cannot be reconstructed on the eve of the audit. Either it was captured at the moment it happened, or it does not exist.
The MULTI ERP models batch-by-batch traceability from the raw material, in the core — not as a layer stuck on top. KORA Productivity captures production at the terminal, at the instant it happens. The link between the two is what turns loose declarations into an auditable chain. Three tests distinguish a real integration from a cosmetic one: each production declaration carries the consumed batch coming from the ERP; the OEE per machine cross-references with the concrete manufacturing order, not a generic period; and a rework generates a record instead of quietly disappearing from the efficiency calculation.
What needs to be on the table before you start
Before touching any configuration, there are baseline conditions without which the project starts off lame. They are not optional and cannot be bought halfway through.
- An ERP core that already models textile by batch — not a financial one bodged to fit.
- Shop-floor terminals with industrial tolerance (not consumer tablets) that withstand dust, humidity and three shifts.
- Reliable network in weaving and finishing — real-time capture dies exactly where the Wi-Fi dies.
- Documented value stream map: spinning → knitting → dyeing → finishing → making-up → dispatch.
- Article structure with the three real axes: colour, size and, in clothing, type/fitting.
- A production manager who accepts stopping the machine for 90 minutes to validate data — and no more than that.
- A written agreement on what a "batch" is in each section. It is not obvious, and it is the origin of half the arguments that come next.
The map of the four layers
Design the project by layers, not by modules. Each layer has an operational owner and an acceptance test that either passes or does not — with no grey area.
| Layer | System | Owner | Acceptance test |
|---|---|---|---|
| Management core | MULTI ERP | CFO / IT | Month-end close without manual reconciliation in Excel |
| Shop floor | KORA Productivity | Production director | OEE per machine and shift in real time |
| Warehouse and dispatch | KORA Inventory Suite | Warehouse manager | Packing list generated at picking, without double keying |
| Customer / distributor | KORA B2B | Sales | Order enters the ERP without going through email |
The warehouse manager in the Lousada/Paços corridor is the acid test of this table. If the rollout takes him off the radar for more than two hours, he sabotages it — and rightly so, because the lorry does not wait for training. The warehouse layer has to work before you convince him, not during. We have seen entire rollouts derail because the man who holds up dispatch was asked to learn new screens on a month-end close morning.
A four-step start-up method
Step 1 — Freeze the article structure. Before any configuration, decide how the three axes (colour, size, fitting) are coded. A jumper collection may have 40 SKUs; in footwear, a sample from Felgueiras can reach 800-1200 SKUs with three axes — colour, size and last. The wrong structure here contaminates everything downstream and no report can save it afterwards.
Step 2 — Define the batch by section. In dyeing, the batch is the bath. In making-up, it is the cutting sheet. In spinning, it is the yarn lot. Force a written definition, signed off by the manager of each section, before configuring anything at all. Without this, traceability breaks at the first transfer between stations — and nobody notices until the brand asks for the genealogy of a specific reference.
Step 3 — Link capture to consumption. Each declaration at the terminal deducts real stock and charges cost to the manufacturing order. This is where margin per order stops being a back-office estimate. And this is where the deviations nobody wanted to see appear — the line running at 62% OEE when the proposal assumed 80%, the yarn consumption 7% above the technical sheet. Uncomfortable, but true.
Step 4 — Only then open the BI. Connecting Qlik Sense to dirty data produces convincing and wrong reports — the worst of both worlds. Stabilise the capture over at least two month-end closes before giving dashboards to management. Trust in the number is lost once and does not come back.
Don't integrate in order to have reports. Integrate so that the yarn batch arrives intact at the label on the box. The reports are a consequence — never the objective.
The mistakes that repeat from factory to factory
The pattern of failure is remarkably consistent across the Vale do Ave. It is not the technology that breaks. It is the data discipline that nobody was willing to impose at the start.
Automating the chaos. If the article structure lives in a mess in a shared Excel file, the ERP merely tidies it up faster — and propagates the error faster too. Clean up first, computerise afterwards. The cleaning step seems bureaucratic and it is what separates a 14-week start-up from an eight-month quagmire.
Consumer terminals in dyeing. A home-grade tablet in the humid and aggressive atmosphere of finishing lasts weeks, not years. Specify equipment with a protection rating suited to dust and humidity, or real-time capture evaporates with the first terminal that dies on the night shift.
Connecting the BI too early. It has been said and it bears repeating because it is the most expensive mistake: unstable capture data generates permanent distrust. As soon as management decides "the number is always wrong", they stop looking at the screen and go back to the same old Excel. The project dies in silence.
Ignoring the fitting axis in clothing. Modelling only colour and size collapses the day the parent company asks for cut variants — regular, slim, oversize. Rebuilding the article structure halfway through the project costs weeks and reopens Step 1 when you were already at Step 3.
Leaving tax authority compliance until the end. Monthly SAF-T reporting (Portaria 195/2020) and ATCUD (DL 28/2019) are not an optional module you switch on in the last week. Validate them in the design phase, because the certification of the software conditions how the document series are structured.
Where the boundary really breaks
In INFOS projects, the breaking point is rarely technological. It is the definition of the batch — that seemingly trivial conversation from Step 2 that everyone is in a hurry to get out of the way. Two sections that call different things a "batch" produce a traceability that looks complete on screen and crumbles at the brand's first audit. The dyeing director thinks in terms of the bath, the cutting supervisor thinks in terms of the sheet, and nobody wrote down which of the two governs when one bath feeds three distinct cutting sheets.
This is the detail that implementation manuals do not mention: integration does not fail at the interface between software and software. It fails at the interface between two people who never needed to agree on a word — until the day Inditex's compliance depends on it.
How to validate before generalising
Choose one production line and one article family. Run the complete cycle — raw-material batch to packing list — in a controlled environment, before extending it to the whole factory. If that line survives two month-end closes without any reconciliation Excel, you have a real value chain and you can generalise with confidence. If it does not survive, you have found out exactly where the boundary is still blind — and that is worth more than a hurried rollout that hides the problem beneath pretty dashboards.
To go deeper, see the textile production management guide and how to assess the vertical fit before signing a contract. Further reading: MULTI ERP as the base for scaling an industrial SME, the importance of a centralising ERP and the challenges of the textile industry 4.0. For sector context, see the textile vertical.
Sources
- ATP — Associação Têxtil e Vestuário de Portugal: ITV sector indicators (share of manufacturing industry GVA and employment; export orientation; 2025 exports, INE provisional data Feb/2026).
- INE — Instituto Nacional de Estatística: international trade in goods statistics (ITV exports and destination markets, 2025, provisional data).
- European Commission — EU Strategy for Sustainable and Circular Textiles (COM/2022/141).
- Decree-Law No. 28/2019 (invoicing, ATCUD) and Portaria No. 195/2020 (SAF-T reporting) — Portuguese legislation.
Frequently asked questions
What is the "boundary" between the financial ERP and the shop floor?
It is the separation between the system that records financial data (up to the factory door) and the real production that happens inside. The ERP knows costs and margins, but goes blind as to what really happens: dyeing baths, stopped machines, consumed batches. This boundary causes outdated numbers and fictional traceability.
Why is the batch more important than the dashboard?
Because without batch-by-batch traceability from raw material to the final label, every calculation of margin, OEE and compliance is built in Excel after the fact. International buyers (Inditex, Decathlon) demand the genealogy of the product. The pretty dashboard does not replace data captured at the real moment.
What is the difference between real and cosmetic integration?
Real integration has three characteristics: each production declaration carries the consumed batch from the ERP; the OEE cross-references with the concrete manufacturing order, not a generic period; reworks generate a record instead of disappearing from the calculation. Cosmetic integration is software stuck on top without changing the real data flow.
What baseline conditions are mandatory before starting?
An ERP that models textile by batch (not an adapted financial one); industrial terminals on the shop floor; a reliable network in weaving and finishing; a documented flow map; an article structure with colour, size and fitting; a manager who accepts stopping machines for 90 minutes to validate data; a written agreement on what a "batch" is in each section.
How is the batch defined in different sections of the factory?
In dyeing, the batch is the bath. In making-up, it is the cutting sheet. In spinning, it is the yarn lot. Each section has a different definition. It is essential to force a written definition signed off by the manager before configuring the system, otherwise traceability breaks at the first transfer between stations.
When should the dashboards and BI reports be connected?
Only after stabilising the data capture over at least two month-end closes. Connecting Qlik Sense to dirty data produces convincing and wrong reports — the worst of both worlds. Trust in the number is lost once and does not come back. The dashboards are a consequence, never the objective.
What is the risk of failing in the integration between the ERP and the shop floor?
The failure happens when two systems call different things a "batch". This breaks traceability and makes it impossible to meet EU compliance requirements. When the brand asks for the genealogy of a product, there is no time to reconstruct data. Either it was captured at the moment, or it does not exist.