
Filled in from personal experience
A new product cannot be sold until two documents are complete, one describing what the product is technically and one describing how it is sold. Nobody in the company held a map of who filled which field, in which system, in what order. When the map was drawn, two of the fields turned out to be filled in from personal experience, and one had no owner at all.
Nobody owned the process, only their part of it
The reporting chain from engineering to sales was globally established and locally invisible. Two documents move through it across the product introduction milestones. One carries the technical configuration, the other carries the commercial structure that feeds the pricing systems, the order configurator and the enterprise resource planning system.
Everyone knew their own fields. No one held the whole. So the question put to the sprint was not how to improve the process, it was what the process actually is, and whether anything in it that runs one after another could run at the same time.
One product was chosen as the vehicle for the mapping, and thirteen people across seven functions were interviewed to establish who fills what, in which tool, and when.
What the map showed
The documents are not started until manufacturing forces them. Neither exists in draft until the manufacturing release has to be done, which means the commercial structure is built at the end of development rather than alongside it. The design input meeting that should set the structure was described as unstructured, producing repeated iterations settled by further meetings, mail and calls.
Data is then copied by hand from the technical document into the commercial one. Where the technical document is incomplete, that transfer is done twice.
And two fields had no reliable source at all. Country of origin was being filled from personal experience rather than from the customs function that holds the answer. Sourcing rules were also filled from personal experience, although they follow a strategy decision that one named function attends, which made the ownership obvious once anyone asked. Separately, nobody owned requesting the harmonisation code, so it was being requested by a service colleague as an informal favour.
Six fields nobody downstream was reading
The team that consumes the commercial document was asked what it actually extracts. Six fields came back as unnecessary. One price field had been superseded by seven regional price columns and was in any case identical to one of them. Four more flow through the engineering system directly and do not need to be in the commercial document at all.
The analysis was careful about its own conclusion. Of the fields the consuming team does not use, only two can actually be deleted, because the others are read by two other teams further down. That distinction is the difference between a real simplification and one that breaks something quietly three months later.
Version control had already broken. Everyone was working from a personal copy on their own desktop, so many versions of the commercial document were in circulation at once. What happens to it after launch, when a product changes, was undefined.
Six fields recommended for removal
Traced field by field to whoever reads them downstream. Only two can be deleted outright, because the rest are consumed by other teams.
| Field | Why it is in the document | Why it does not need to be |
|---|---|---|
| Global base price | Historic | Superseded by seven regional price columns, and identical to one of them |
| Engineering description | Historic | Flows through the engineering system directly |
| Maintenance flag | Historic | Flows through the engineering system directly |
| Serial number control | Historic | Flows through the engineering system directly |
| Lot control | Historic | Flows through the engineering system directly |
| Inventory cost value | Needed downstream | Supplied directly by the team that owns it, not via this document |
Three designs, one rejected on the spot
Three ways to run the two documents were built and compared. Filling them simultaneously was rejected, because the sourcing rules in the commercial document cannot be completed until the engineering part number exists. That dependency is real and it kills the most obvious answer.
Filling them sequentially, with the commercial document built from an export of the technical one rather than retyped, was recommended as the short term move. Building the technical document with the commercial structure already inside it, so the commercial structure is finalised in the first draft, was recommended as the long term one.
The modelled effect of overlapping the five sequential steps was drawn as roughly halving the elapsed time. Both the before and after figures are marked in the deck as illustrative examples, not measurements, and they are repeated here on that basis. There is no measured before and after in this work.
What the client was left holding
A field level map of both documents, each of twenty nine data points traced to an owner, a destination system and a mandatory or optional status. A list of six fields to remove and a note on which two of them are actually safe to remove. Named owners for the two fields that had been filled from experience. And a short term and a long term process design, with four preconditions attached to the long term one, including the uncomfortable one, that it needs a change of habit rather than a change of tool.
One number in the source material claims this work reduced product development time by a fifth. There is no baseline, no calculation and no measurement date anywhere behind it, so it is not repeated on this page.
Download the full case study
Have a similar requirement?
Contact us today to learn more about on-demand workforce and accelerate development on your most pivotal projects!
Accelerating Success for Enterprises in 20+ Geographies

Launch Your Sprint with
Download the full report
Enter your email to access this exclusive case study.


