"Standardize? No two of our machines are ever the same." Bring up standardization in special machine building and you are guaranteed to get this answer. And it is true: in engineer-to-order work every order is just that little bit different, which is exactly what the customer pays for. But the conclusion glued to it does not follow. The product being custom does not mean the process has to be.
Take a good look at one of those "unique" orders: the machine is new, but the route it travels is the same every time. A project structure is set up, parts get names and numbers, there are drawings, a check, a release and a set of export files for the shop floor and purchasing. Especially in an engineer-to-order process, that fixed route is what you hold on to. In this article we look at which parts of the process can be standardized just fine, which ones you should leave alone, and how a toolbox like Thundercad helps make the fixed parts genuinely fixed.
The custom work sits in the design, not in the route around it
Put two random orders side by side and the difference sits almost entirely in the design itself: different dimensions, different power, different customer demands. The steps around it are surprisingly similar. Both orders got a folder layout, a main assembly, naming, iProperties, drawings, a review moment, a release and a stack of files heading for the shop floor and purchasing. One part is thinking work and belongs to craftsmanship; the other part is routine that you reinvent with every order for as long as you leave it undefined.
If you do not believe it, measure it. Take the post-calculation of a finished order and mark which hours went into the design and which into the paperwork around it: creating folders, retyping data, staging files, chasing missing information. At many special machine builders it turns out that a good share of the engineering hours is not spent on engineering at all, and precisely that share is nearly identical from order to order. That is where standardizing pays off first.
That distinction is the core. Standardizing in engineer-to-order is not about building catalog machines, but about making the routine around the work predictable, so all the attention can go to the thinking.
What can be standardized
Five parts of the process return in every order and can be pinned down just fine:
- Project structure: the same folder layout and the same build-up of the main assembly for every order, so everyone finds their way blindfolded.
- Naming and numbering: one logic for file names and article numbers, however different the parts themselves may be.
- Metadata: the same mandatory iProperties per document type, from material to finish.
- Check and release: a fixed review moment with a fixed checklist, no matter who engineered the order.
- Issuing: the same export routine and the same package build-up for the shop floor, purchasing and the customer.
Notice what is not on the list? The design itself. More on that further down. Each of these five is small enough to pin down within a month, and together they decide how smoothly an order moves through the department.
Metadata: the quiet foundation under every order
Precisely because almost every part is new in engineer-to-order, metadata carries more weight here than anywhere else. A series manufacturer fills its article master data once; a special machine builder creates dozens of new parts every week, and each of them has to get the right data straight away. If that does not happen, it strikes back further down the process: empty fields in the title block, gaps in the bill of materials, search work at purchasing.
This is exactly the job for a fixed data card. With the iProperty Panel from Thundercad you define per document type which fields it shows: a part asks for material and finish, an assembly for project data, a drawing for check and release fields. The engineer sees the same card every time and fills it in seconds; a jungle of personal conventions never gets a chance.
A fixed data card and a fixed issuing routine only work once they are also the easiest path. Experience with your own orders how that feels.
Try 30 days freeThe issuing routine: the same finish for every order
At the end of every order the same ritual waits: update the bill of materials, export the drawings, put the files in the right place. With custom work the content changes every time, but the routine does not have to. Whoever pins it down as a fixed series of steps can also run it in bulk: with Batch Publish you export all drawings of an order in one run to PDF, DWG, DXF or STEP, with the same preferences every time, and it works together with Vault if you use it. Fix the order of steps as well: first update the bill of materials, then export, so no package ever leaves with an outdated list.
The effect on lead time is bigger than you would expect: not because exporting is slow, but because a fixed routine eliminates waiting moments and forgotten files. How those last meters from quote to production drawing leak time is something we described earlier in From quote to production drawing: how to cut your lead time in half.
What you should not want to standardize
Standardization has a limit, and whoever crosses it pays in workarounds. The design itself is the engineer's domain: the solution to the customer's question, the concept choice, the calculation. Squeeze that into templates and pick lists and you give up exactly what sets you apart as a special machine builder. A useful test: if an agreement touches what the machine is, stay away; if it only touches how the paperwork around it is done, pin it down.
Be careful too with rules for exceptions that rarely occur: a procedure nobody remembers is worse than no procedure. And modularizing, building fixed product platforms, is a strategy in its own right; do not confuse it with process standardization. A standard process can be up and running quickly, a product platform is a project of months. So start with the process: it pays off on every order, including the most exotic one.
How to start: one order as a trial
Rolling out something big next to running orders rarely works. Starting small does:
- Take one completed order and write down the route it traveled, from purchase order to issuing.
- Mark which steps were pure routine and where the thinking sat.
- Define a standard for three routine steps: for example the project structure, the data card and the issuing routine.
- Run the next order by those agreements and note where it chafes.
- Adjust, and only then expand.
With a small team this does not have to turn into a shelf of manuals; how to keep agreements light and workable is covered in Standardizing in Inventor with a small team.
Frequently asked questions
Is standardizing not mainly something for series production?
No, rather the other way round. A series manufacturer gets its repetition from the product; a special machine builder can only get it from the process. Precisely because every order is different, the fixed route is the only repetition you have, and therefore the only place where practice accumulates.
What if a customer demands something that cuts straight across our standard?
Then the customer wins, and that is fine: the standard process is a starting point, not a straitjacket. The difference is that you now deviate consciously and know what the deviation costs, instead of every order quietly bringing along its own way of working.
How much time does it take to get started?
Less than it seems: writing out the route of one order is an afternoon's work, and a first data card or export routine stands in a few hours. If you want to try the fixed parts on your own orders straight away, the free Thundercad trial month lets you do exactly that.