Most software projects that go wrong do not die during implementation. They die in the first meeting, when someone designs the architecture on top of what the salesperson showed in the demo, rather than on top of what the factory does at 5.30pm on the Friday of month-end closing. An architecture designed from the demo is an architecture designed from fiction. At the end of this guide you have a six-step method for designing the architecture before signing any contract — and a decision matrix you can take to your next board meeting.
The thesis is simple and uncomfortable: the product is almost never the problem. The problem is choosing the product before understanding what the operation actually does when nobody from management is watching. That is why factories with the same ERP get opposite results — one modelled the real business, the other twisted the business to fit the screen it liked in the demo.
What you need before you start
Serious consultancy starts with fieldwork, not slides. Before any architecture design session, gather the real org chart of who decides — in a family-owned SME it is almost always the trio of CEO, CFO and the head of IT, the latter often self-taught with fifteen years of business knowledge and no diploma on the wall. It is this last person that nobody invites to the first meeting and who, six months later, is the one keeping the system standing. Invite them now.
Alongside this, you need the honest list of current systems and how they talk to each other — or don't: ERP, spreadsheets, shop-floor terminals, POS, shared files. You need the three processes that hurt the most, the ones that generate phone calls at 6pm. You need the real volume — SKUs, orders per day, employees, warehouses, branches — and the outstanding regulatory obligations: monthly SAF-T, certified invoicing, NIS2 if your sector is covered.
The most forgotten one is missing: the business calendar. In a footwear factory in Felgueiras you do not kick off a rollout in July, with international men's footwear buyers arriving in August. And, if there is a PT2030, PRR or Norte 2030 application on the table, you need the deadline for the technical report — which is where things get stuck, not in the approval of the call for applications.
Step 1 — Technical and functional assessment
An INFOS Consultancy assessment is not a 40-minute interview with the operations director. It is going to the warehouse, connecting to the terminals, opening the ERP and timing the stock listing that nobody can bear to wait for. The operational diagnosis documents what exists, not what management thinks exists.
We see this regularly: management describes a linear, clean process; on the shop floor there are three parallel Excel sheets that nobody in management knew existed and that, in practice, are the real production management system. One of them is usually on the personal laptop of someone who is retiring the following year. The architecture has to start from there — from the real shadow system, not the official org chart.
If you have not observed the process on site, you do not know it — you know the version they told you in the meeting room.
Step 2 — Design the target architecture before choosing a product
Classic mistake: choosing the tool and then twisting the business to fit it. Reverse it. First design the capability map — what the system has to do — and only then assess which product fits.
A clothing factory that subcontracts for parent companies such as Inditex or Decathlon has batch traceability and compliance requirements that a construction-materials distributor does not. A vertical MULTI ERP models the three axes of colour-size-shape of a footwear collection with 800 to 1,200 SKUs; a general-purpose ERP forces you to invent concatenated codes that seem to work in the demo and blow up in the sales-by-axis reports six months later. It is the target architecture that reveals this difference. The demo hides it, because the demo uses ten pretty items and no shape shared between two models.
Step 3 — Map integrations and the data layer
This is where projects die silently. Does the ERP talk to the shop floor? To the stores' POS? To the distributors' order portal? To the BI? Each of these connections is a point where a well-designed project falls apart in production.
Design each flow with source, destination, frequency and owner. If you have branches, define how they synchronise — Multi Connect solves the integration between MULTI ERP units. If the goal is operational decision-making from the data, plan the Data Lake and the Qlik Sense layer from the outset — not as a vague phase 2, but with the concrete KPIs already defined. It is worth first reading what to measure and what to ignore in industrial KPIs in Qlik Sense.
The detail that integration manuals do not mention: for each master data item — customer, item, stock — define which system is in charge. If two systems both think they are the source of truth for stock, you do not have an integration, you have a cold war that breaks out at the first inventory. Write on a board who owns what before touching any connector.
Step 4 — Architecture decision matrix
Take this matrix to the board meeting. Score each option from 1 to 5 and multiply by the weight. It is not exact science — it forces the conversation out of "I liked this screen better".
| Criterion | Weight | What to assess |
|---|---|---|
| Vertical fit | 5 | Does it model your business without workarounds (SKUs, batches, subcontracting)? |
| Integrations | 4 | Does it connect to what you already have without fragile middleware? |
| Legal compliance | 5 | Certified invoicing, SAF-T, NIS2 if applicable? |
| User adoption | 4 | Can the warehouse manager use it without leaving the radio for two hours? |
| Scalability | 3 | Can it handle twice the volume in 3 years' time? |
| Support and proximity | 3 | Who answers when it goes down at 6pm on month-end? |
| Eligibility for funding | 2 | Does it fit the criteria of the PT2030/PRR call? |
The best architecture is not the one with the most features. It is the one the warehouse manager does not sabotage in the second week.
Step 5 — Roadmap by waves, not big-bang
Do not start everything at the same time. Sequence in waves that deliver value early and reduce risk. A regional grocery retail chain with 22 stores does not migrate POS, back office and e-commerce on the same weekend — it starts with a two-store pilot using MAXIRETAIL, stabilises, and only then replicates. The two-store pilot is there to uncover the problems with 2 angry managers, not with 22.
In industry, first capture production in real time with KORA Productivity. Kaizen needs real OEE data before improving anything at all — and the number that comes out of the first measurement is usually uncomfortable. We have seen lines that management swore were running at 85% efficiency show 58% once the terminal started counting the micro-stoppages that nobody recorded. Wave by wave, with metrics before and after each one.
Step 6 — Governance and end-to-end monitoring
The architecture is designed in weeks; the project is lived in months. Define the committee cadence, who owns decisions and the acceptance criterion per wave. End-to-end monitoring means having someone who closes the triangle between what was designed, what was built and what the factory actually uses — because these three things diverge, always, and without anyone watching they diverge fast.
- Project committee with CEO, CFO and IT present, not delegates who come back to the room saying "I have to check upstairs".
- Each wave has a written and signed "done" criterion before it starts, not negotiated on delivery day.
- Data management and security plan from the architecture stage — not as a final patch, when there is no budget left to do it well.
Common mistakes and how to avoid them
Buying based on the prettiest demo. Demand a proof of concept with your real data — your footwear collection with shared shapes, your item file with the codes you already use — not the vendor's sample dataset, carefully chosen so that it never breaks.
Ignoring security until the end. In 2024 CERT.PT recorded 2,758 cybersecurity incidents in Portugal, 36% more than in 2023, and around 78% occurred in private entities (CNCS, 2024). In SMEs, ransomware was present in 88% of the breaches analysed, against 39% in large organisations (Verizon DBIR, 2025) — the industrial SME is the disproportionate target, not the exception. Security goes into the architecture, not afterwards. Start with the silent risks.
Underestimating adoption. Involve the warehouse manager and the operator in the design, not in a training session the week before go-live. Whoever sabotages the rollout is usually the one who was not heard — and the warehouse manager of a distribution centre in the Lousada/Paços corridor will fight against any system that keeps them off the radio for more than two hours. Give them reasons not to fight.
Treating NIS2 as a problem for the big players. Directive (EU) 2022/2555, transposed in Portugal by Decree-Law No. 65/2025, extends cybersecurity obligations to medium-sized and large companies in 18 critical sectors, including industry. See the technical controls for factories in 90 days.
Locking the architecture to the application calendar. Design the right solution first; if the PT2030 call fits, adjust the phasing — never the other way round. An architecture twisted to fit a call delivers the technical report and fails the factory.
The next step
Take this matrix and the six-step method and put them through the toughest test there is: the process that hurts at 6pm on month-end closing, in a garment workshop near Famalicão, with the ERP dragging its feet and the parent company's order closing tomorrow. If the architecture does not solve it on paper, it will not solve it in production — however pretty the demo screen may be.
Sources
- CNCS — CERT.PT Report on cybersecurity incidents in Portugal, 2024.
- Verizon — Data Breach Investigations Report (DBIR), 2025.
- IBM — Cost of a Data Breach Report, 2024.
- Directive (EU) 2022/2555 (NIS2) — Official Journal of the European Union; transposition in Portugal by Decree-Law No. 65/2025 (Diário da República).
Frequently asked questions
Why do software projects fail in Portuguese companies?
Most fail in the first meeting, when the architecture is designed based on the salesperson's demo, not on the real operation. The problem is not the product — it is choosing the product before understanding what the factory actually does. Companies with the same ERP get opposite results because one modelled the real business and the other twisted the business to fit the screen it liked.
Who should be present at the architecture assessment?
The trio of CEO, CFO and head of IT — the latter often forgotten in the first meetings, despite being the one who keeps the system standing six months later. In family-owned SMEs, it is this technician with fifteen years of business knowledge who has the real view of the processes. Invite them from the start.
What is a "shadow system" and why does it matter?
These are the parallel processes that nobody in management knew existed — Excel sheets on someone's personal laptop, non-integrated shop-floor terminals, shared files. The architecture has to start from there, from the real system, not the official org chart. If you have not observed the process on site, you only know the version they told you in the meeting room.
Which comes first: choosing the product or designing the architecture?
First design the capability map — what the system has to do — and only then assess which product fits. The classic mistake is choosing the tool and then twisting the business to fit it. A clothing factory with traceability requirements needs a different vertical ERP from a construction-materials distributor.
What is the "data cold war" and how do you avoid it?
It occurs when two systems both think they are the source of truth for the same data — for example, stock. You do not have an integration, you have a conflict that breaks out at the first inventory. Solution: write on a board, before touching any connector, who owns each master data item — customer, item, stock.
How do you use the architecture decision matrix in the board meeting?
Score each option from 1 to 5 and multiply by the weight of each criterion — vertical fit (weight 5), integrations (4), legal compliance (5), user adoption (4). It forces the conversation out of "I liked this screen better" into a factual assessment. The best architecture is the one the warehouse manager does not sabotage in the second week.
Why is it important to consider the business calendar in planning?
In a footwear factory you do not kick off a rollout in July, with international buyers arriving in August. If there is a PT2030 or PRR application on the table, the technical report deadline is critical — it is where things get stuck, not in the approval of the call. Align the roadmap with periods of lower operational pressure.