When every department has its own spreadsheet, the problem isn't the spreadsheet.
It's that no standard system describes how you actually work. Pwas starts from your description — job, bill of materials, operation, inspection — and builds the system from it. Including the exceptions that make your company different from everyone else's.
Your ERP covers 80%. The remaining 20% is what sets you apart.
Almost every manufacturer has an ERP that handles master data, orders and accounting well. Then there's the rest: the product configurator a colleague built ten years ago, the progress sheet production updates by hand, the inspection register that lives on paper, the last-minute variants a customer asks for that the ERP can't represent. That 20% isn't a detail: it's precisely the know-how that wins you contracts. And it's usually the part software supports worst, because customising the ERP costs too much and takes too long.
illustrative scenario
A day at Valsesia Engineering, a company that doesn't exist but resembles many.
At 9am a customer calls and asks where job 2847 stands. Answering takes four steps: sales opens the ERP and sees the order is confirmed, but not its progress; they call the shop floor supervisor, who checks the progress sheet updated last night; the supervisor calls the paint shop to find out whether the parts have come out; meanwhile the customer waits. Thirty-five minutes later an answer arrives that is, at best, a day old.
This isn't a problem of people working badly. It's that the information exists but is spread across five places that don't talk to each other: the ERP knows the order, CAD knows the bill of materials, the shop floor knows the progress, paint knows its queue, inspection knows the results. None of these systems knows the concept that is central for Valsesia Engineering: the job, with its operations, its variants and its constraints.
What changes with Pwas
The first step isn't technical. It's a session in which the shop floor supervisor, the quality manager and sales explain how the work really flows. Out of it comes a structured description: a job has a customer, a promised date and one or more lines; each line has a bill of materials; each bill has operations; each operation has a department, a status and a planned time; some operations require inspection; a failed inspection raises a non-conformance that the quality manager must sign off before the part moves on.
That description isn't a document someone then translates into code. It is the system. From it come the screens for entering and searching jobs, the permissions (paint sees only its own operations, sales sees everything but cannot change inspection results), the APIs that read the order from the existing ERP, and the shop-floor tablet on which an operator declares progress with two taps.
The same phone call, three months later
The customer calls and asks about job 2847. Sales opens the record: three of four lines complete, the fourth in paint since this morning, inspection due Thursday, promised date on track. Response time: twenty seconds. And if the company decides to give them access, the customer can look at that record themselves through a portal running on exactly the same data, filtered to show only their own jobs.
And when something changes
Six months later the company starts working for a rail sector customer who requires a material traceability certificate for every part. In a traditional project this is a change request: analysis, quote, development, testing, release — weeks, at best. Here it's adding a "heat number" field to the material object, declaring that field mandatory for jobs of that customer type, and a rule that blocks final inspection when it's missing. The entry screen updates itself, the control fires by itself, the traceability document generates itself. It's a change you make and verify on the same day.
the comparison
What happens today, what happens afterwards.
Not generic promises: the concrete situations that repeat every week in a manufacturing business.
Today
The information is there, but you have to go and find it
The status of a job is reconstructed by phoning three people.
Production progress is updated at end of shift, by hand, in a shared file.
A customer-requested variant is noted in an email and hopefully reaches the shop floor.
Non-conformances live in a paper register and become statistics only at year end.
Adding a control a new customer requires means raising a request with IT and waiting.
There's no customer portal, because nobody knows where it would get its data.
With Pwas
There is one source, updated by whoever generates it
Job status is a screen, updated by whoever performs the operation as they perform it.
The operator declares progress from the shop-floor tablet, not at end of shift.
A variant is structured data that propagates to the bill, the operations and the documents.
Every non-conformance is tracked, assigned and measurable in real time.
A new control is a configuration change, verifiable the same day.
The customer portal reads the same data, automatically filtered to what concerns them.
how you get there
The path, concretely.
No phase requires stopping production or giving up the ERP you use.
01
Half a day on the shop floor
We come to you and watch the work. We ask for the paper forms, the real spreadsheets with real data, the emails where exceptions get handled. This phase determines the final result: everything else follows from it.
02
We write down your vocabulary
Job, line, bill of materials, operation, department, inspection, non-conformance: each concept with its fields, its states, who can see it and who can change it. We have you read and correct it. People who know the trade understand this document without being technical.
03
Connection to the existing ERP
Orders keep being created where they're created today. Pwas reads them through the ERP's interfaces and returns what accounting needs. No migration, no double entry.
04
First real job in parallel
You pick a line or a department and run one real job both ways, new system and old method together. This is where the exceptions nobody mentioned come out — and they get fixed as you go, without risk.
05
Rollout and self-sufficiency
You extend to other departments and plants. In parallel we train whoever will maintain the configuration in-house: adding a field or a rule becomes an internal operation, not a call to the supplier.
an example flow
From order to delivery note, with the job always visible.
The order becomes a job, progress is declared on the shop floor, the quality check is part of the flow and a delay raises an alert before the customer calls.
what changes structurally
Properties of the system, not promised outcomes.
These aren't averages of customer results: they're characteristics of how Pwas is built, and they're verifiable in a demo.
0
lines of code for a new entity
Adding an object to the domain — a type of inspection, a non-conformance category — automatically generates search, entry, editing, permissions and APIs.
1
source of data for every department
Shop floor, quality, sales and the customer portal read and write against the same model: no nightly syncs, no competing versions of the truth.
same day
the time to change a rule
A new mandatory field or a new process block is a configuration change written, verified and published on the same day.
100%
of automated actions traced
Every step the system performs leaves a reconstructable trace: useful for quality, essential when a customer asks about a batch.
The figures above describe how the platform works, not results measured at specific customers. Real timings and benefits depend on your scope, and we estimate them together before starting.
in depth
The four questions owners in this industry ask us.
Not IT's questions: the questions of whoever signs off the investment and has to answer for the result.
"I've already paid to customise our ERP and it didn't end well. Why would this time be different?"
Because the breaking point is almost always the same, and it's structural: in a traditional system, customisation is additional code written on top of a product designed for someone else. Every product upgrade risks breaking it, every subsequent change costs as much as the first, and after two years nobody remembers why that function does what it does.
In Pwas customisation isn't code on top of the product: it is the product. The description of your domain is the system's normal operating mechanism, not a tolerated exception. There's no "standard version upgrade" that can break your rules, because there's no standard version you're diverging from.
This doesn't make the project free or risk-free. It changes the shape of the risk: cost concentrates at the start, in the phase where we understand how you work, and doesn't come back multiplied with every subsequent change.
"Who actually uses it on the shop floor? My people aren't software people."
It's the most well-founded objection of all, and the reason most digitalisation projects in production fail: not because the software doesn't work, but because nobody fills it in.
The rule we follow is simple: whoever generates the information must be able to record it in under ten seconds, without leaving their work. In practice that means a fixed tablet at the machine with three large buttons, not a screen with forty fields. It means the operator declares "operation started" and "operation finished", and everything else — who, when, on which job, how long it took — the system infers. It means a badge or a QR code on the drawing replaces typing.
The complexity lives in the engineering and quality screens, where it belongs. Not on the shop floor, where it would kill the project.
"And if I change software supplier tomorrow? Am I held hostage?"
The right question to ask anyone proposing a business system. In our case the concrete answer comes in three verifiable points.
The data is yours and it's readable. It runs on a standard relational database, queryable with common tools. No proprietary format, no encryption that stops you reaching what you produced.
The configuration is yours and it's readable. It's a set of structured text files, versionable like any company document. They describe your domain in a way any competent professional can follow, not just us.
The system runs where you want. European cloud, your own server room, or a mix. If you decide to move it, it moves.
Staying with a supplier should be an economic choice, not a technical obligation.
"Everyone's talking about AI. Is it actually useful in my workshop?"
In many cases the honest answer is: not as much as you're told. A language model won't optimise your production scheduling better than a good shop floor manager with the right data in front of them.
Where it does produce measurable value in manufacturing is in three very concrete places. First, on inbound documents: a customer order arriving as a PDF or free-form email is read and turned into a structured job, with fields pre-filled and submitted for human confirmation — instead of twenty minutes of retyping per order. Second, on natural-language questions: "which jobs for customer Rossi are behind their promised date?" becomes an immediate answer, with nobody having to build a report. Third, on document generation: certificates, inspection sheets and non-conformance reports are compiled from data the system already holds.
In all three cases one principle is non-negotiable: AI proposes and drafts, but it doesn't decide and doesn't write without control. Every action that changes data goes through a plan verified against the real permissions of whoever requested it, can require explicit human confirmation, and leaves a complete trace. If an operation isn't declared as possible for that user, the agent cannot perform it — however it's asked.
quick check
Do you recognise your company in this list?
If three or more points on the left apply, it's worth a conversation.
Probably yes
You work to order or in batches, with configurations that vary from customer to customer.
You only know production progress by asking someone.
You have an ERP that suits accounting but doesn't describe your production process.
Your most important customers ask for certifications, traceability or order visibility.
Every new customer requirement costs you weeks of manual work or an IT request.
You hold valuable data (inspections, scrap, real times) that never turns into decisions.
Probably not
You make a few standard catalogue items with a process unchanged for years.
Your ERP already covers the full cycle well and nobody uses spreadsheets to work.
Nobody can spend a few hours explaining the real processes.
You're looking exclusively for a MES certified by a specific machine supplier.
frequently asked
Manufacturing: the specific questions.
Does Pwas replace the MES or ERP we already have?
In most projects no: it sits alongside them. The ERP keeps handling orders, purchasing and accounting; Pwas covers the part of the process the ERP doesn't describe — configured jobs, real progress, quality, after-sales — and exchanges data with the ERP through its interfaces. Companies with a rigid MES sometimes replace it over time, but that's a decision taken later with evidence in hand, not a project prerequisite.
Does it connect to machines and PLCs on the shop floor?
Yes, where the machine exposes its data. Pwas can receive signals from PLCs, supervisory systems or IoT gateways over the common industrial protocols and turn them into progress events, piece counts or alarms inside your job model. Where a machine doesn't communicate, the alternative is simplified manual declaration from a tablet or barcode scanner. We check case by case: every workshop's machine park is different.
Does it work without a network, if shop floor Wi-Fi drops?
Shop floor stations can run in degraded mode: declarations made during an outage queue locally and sync automatically when connectivity returns. It's a configuration to design together, because it depends on how critical continuity is in your department and which data cannot wait.
How realistic is a first production release?
For a narrow, well-defined scope — one line, one department, one job type — the order of magnitude is a few weeks from the initial session to first real parallel use. For a multi-plant business with complex integrations timings stretch, but the method stays the same: start from a small, verifiable scope, not a single release covering everything.
Who maintains it afterwards? Do we need a programmer in-house?
For ordinary changes — adding a field, changing who sees what, introducing a new mandatory control — you don't need a programmer: you need someone who knows the processes and has been trained on the configuration structure, typically a production or quality manager comfortable with IT. For deeper extensions, such as a new integration with an external system, you need a technical profile, ours or yours.
Does production data stay inside the company?
If you require it, yes: on-premise installation in your own server room is a supported deployment mode, not a reduced version. Many manufacturers choose a mixed setup, with the production core on site and the customer portal on cloud. The choice is made during the project and stays reversible.
We use technical cookies and, with your consent, analytics cookies (Google Analytics) to understand how the site is used. Read our Privacy & Cookie Policy.