A global automotive safety system manufacturer's textile components division ran line configuration through Excel, email and manual PLM entries, with no shared source of truth, no validation and no traceability. This is the design and build of the tool that replaces it with a guided, rule-enforced workflow.
A textile Product Area building production lines for cushion and seam-based components across multiple manufacturing sites.
Nothing enforced which machine, tool or poka-yoke combination was valid, so invalid configurations surfaced in review, procurement or on the shop floor.
A five-step quotation wizard where each tab feeds the next and nothing generates until every mandatory field is filled and valid.
The MVP is designed and built. Performance testing and go-live outcomes are targets, not results, and this page says so wherever a number appears.
Central Engineering and Purchasing owned the master data. They had no system to publish it, so engineers worked from whatever copy they had.
The client's textile Product Area builds production lines for cushion and seam-based components across multiple manufacturing sites. Every new line or variant starts with a Process Engineer working out which machines, tooling and poka-yoke devices are allowed for a given part.
Historically that was done by cross-referencing spreadsheets, emailed specs and direct entries into the PLM system.
Because nothing enforced which machine, tool or poka-yoke combination was valid for a given seam or product family, invalid configurations were not caught until much later.
Master data existed, but nothing stopped an engineer from selecting a machine or tool that was not actually approved for that site or seam type.
Configuration attempts left no audit trail. There was no record of who changed what, when, or why a version was superseded.
When master data was missing or inconsistent, engineers had no structured way to flag the gap back to Central Engineering and Purchasing, so they worked around it instead.
Reduce rework, standardise across plants, and give leadership real-time visibility into price, floor space and headcount from quotation through serial production.
Every workaround an engineer invents to get past a missing rule is a rule the next engineer will not know to follow.
Let a Process Engineer build a valid line configuration, with its seam table, operations, machines and tooling, using nothing but approved master data.
Block invalid combinations at the point of selection, not after the fact. If a machine or tool is superseded, or does not match the site or seam, the engineer should not be able to pick it.
Give engineers a way to distribute cycle time across operations and see, before committing, whether the line balances against the target tact time.
Keep a full version history and audit trail, covering every quotation, every master-data change and every action, so a configuration can be defended after the fact.
Each tab feeds the next, and nothing generates until every mandatory field across all five is filled and valid.
Site, part, product family and demand volumes are captured. Site and product family are pulled straight from master data, never free-typed.
The engineer enters seam-level parameters from the drawing: stitch type, needle count, thread cut. This becomes the filter for the next step.
Each operation picks a machine, tooling and poka-yoke device, but only from options pre-filtered by site, seam data and status. Nothing superseded is selectable.
Cycle time, operator count, tact time and utilisation are calculated live. Engineers can borrow time between operations to balance the line before committing.
Every prior tab's data is shown on one page for a final check, then either saved as an editable draft or generated. Once generated it is locked, read-only, and visible to every Process Engineer.
Site, then product family, then product name, then part number, then the quotation itself, with draft and archived states, cloning, PDF export, and a set as serial flag to mark the active configuration.
The filter is applied to the options list itself, so an invalid machine, tool or device is never offered. An engineer cannot build an invalid configuration and discover it on submit.
Isolated services behind an API gateway, with every zone able to reach only the one below it. Nothing talks to the data layer directly except the services that own it.
An engineer's request enters through the frontend, is authenticated against Azure AD, passes through the API gateway into the Builder API service, which persists to PostgreSQL and Blob Storage and emits an event on RabbitMQ. The notification and audit log services consume that event independently, so the engineer's action and its downstream side-effects are decoupled.
The obvious next step is pulling seam parameters straight from the drawing. That was deliberately descoped for the MVP.
Manual entry is slower, but it ships now, and it keeps the validation logic decoupled from a drawing-parsing integration that would have doubled the surface area to test.
Operations default to 10, 20, 30. When an engineer needs to insert a step between two existing ones, they type a number in between, say 14, rather than triggering a renumber of everything downstream.
No auto-renumbering means no silent reshuffling of a sequence someone else is relying on.
Rather than an algorithm that redistributes cycle time automatically, an engineer manually chooses which operation lends time to another, and by how much.
It is slower than automation, but every rebalancing decision is visible and attributable, which matters more for a first release the team has to trust.
A draft is visible only to its author and stays fully editable. The moment it is generated it becomes read-only and visible to every Process Engineer.
That trades flexibility for the guarantee that a generated number never silently changes underneath a decision already made on it.
Cloning a quotation carries forward every field except file attachments.
A cloned quote is a new starting point, not a certified copy of the original evidence, so it cannot be mistaken for one.
Because this replaces a process people already distrust, the plan is to prove stability and correctness under load before go-live, not after.
concurrent users
core-operation response
availability SLA
log retention
These targets are defined in the Non-Functional Requirements and the Performance Test Plan. Results will be published here once testing completes.
These are the numbers the Solution Vision commits to. None of them is measured, because the tool has not gone live. They are published here so this page can be honestly updated against them.
rework reduction
shorter lead time
first time right
shared master-data source
Rework reduced by 30% or moreTo be measured post go-live
Lead time cut by 20 to 25%To be measured post go-live
Over 90% first time rightTo be measured post go-live
Non-functional performance targetsTest plan defined, execution pending
A case study that reports a target as a result is worth less than one that reports nothing, because the next reader has no way to tell which of its numbers were earned.
The MVP drew a hard line around what it would and would not attempt. What sits outside that line, in order of likely priority.
If the approved list lives in a spreadsheet and the enforcement lives in somebody's memory, the gap shows up in procurement or on the floor. We can walk one of your configuration paths end to end in a single session and show you where the rule stops being enforced.