The first two AI transformation workflows in engineering

The evolut workflow selection method does not name a machine. It names five tests.

This note applies those tests inside a Maschinen- und Anlagenbau firm — engineer-to-order and configure-to-order houses that live on tenders, variant design, long-lead parts, commissioning, and an installed base that pays the margin.

The 70% question still comes first. If two people plus an agent stack could reconstruct a high-margin line in 60 to 90 days, that line is the map. The first two workflows are the terrain you actually walk.

In this industry, the map is usually one of two places: the offer factory that turns inquiries into priced commitments, or the aftermarket factory that turns a serial number and a complaint into parts and a work order. Everything else is identity, theatre, or a science project.

A workflow here is not “engineering,” “service,” or “digitalization.” It is a repeatable sequence with a named input, a committed output, a decision gate, and a system of record. If you cannot write those four on one line, you do not have a workflow. You have a department.

How the four traps show up on the shop floor

The political attractors do not change. Their costumes do.

Visible demo. A chatbot on the intranet that answers “where is the drawing for the 2019 filler?” A Copilot in Outlook that drafts a polite delay to the customer. A 3D configurator shown at Hannover Messe that is not wired to cost, capacity, or the ERP. Impressive. No twin. No deprecation decision. No effect on cycle time or margin.

Orphan process—the archive of old commissioning protocols. The translation of spare-parts lists into a fourth language. Useful, ownerless, and unable to force a comparison the CEO can read.

Sacred cow. The chief designer’s variant logic. The works-council-facing shop-floor sequence. The “every machine is unique” pricing ritual owned by a Kalkulationsleiter who has been right often enough to be unchallengeable. Debate the existence of the process, and you never reach a parallel run.

Science project. “We will first cleanse 30 years of Teamcenter, stand up a knowledge graph of every installed plant, and fine-tune a foundation model on our drawings.” That is a platform program. It is not the first two workflows. The twin has to run on the files you already receive.

If a candidate fits one of these four, discard it even if the strategy deck calls it strategic.

Score the real candidates, not the slogans.

Typical slogans in this sector fail the definition before they fail the tests:

  • “Use AI in engineering” — no input, no output, no gate, no baseline.
  • “An assistant for the Konstrukteur” — a tool inside a role. The firm’s architecture does not move.
  • “Redesign how we do special machinery” — low frequency, high identity, high judgment. A craft, not a workflow.
  • “Predictive maintenance for the installed base” — often a science project until the sensor estate, the failure taxonomy, and the service process already exist.

Score only sequences you can name as from X to Y.

Apply the five tests as written. Two yeses in tests 1–3 and a pass on 4 and 5 is enough. Perfection is how steering committees are born.

1. Throughput, not prestige.
A four-week parallel run must produce enough instances to argue with. In a mid-size machine builder, that usually means inquiries, order-engineering packs, spare-parts identifications, or service cases — not the three lighthouse plants of the year and not the one-off turnkey project that will be discussed for eighteen months.

Aim for a workflow that already happens tens of times a month. If you cannot count 50 instances in a quarter, you are choosing a park, not a road.

2. Coordination-heavy, judgment-light at the core.
The compressible core in this industry is search, assembly, checking, routing, drafting, and notifying: pull the similar job, extract requirements from the RFQ PDF, compare against the product rules, draft the offer structure, list the long-lead items, match a photo to a part, assemble the service brief. Human judgment stays on the narrow gate — price, technical deviation, safety-critical interpretation, commercial exception.

If 80% of the elapsed time is waiting for a person to find, copy, and align, you have a workflow. If 80% is a senior engineer inventing a new kinematics package, you have a craft. Do not start there.

3. Same inputs, same customers, measurable output.
Live RFQs, live orders, live spare-parts requests. Outputs that already exist: a submitted offer, a released order BOM, a confirmed parts list, a first-action service pack. Metrics that already have a shadow, even if they live in Excel: days-to-offer, quote error rate, cost per quote, hit rate, days from order to manufacturing-ready pack, first-pass completeness of the order folder, parts-identification cycle time, first-time-right on spare-parts shipments, time-to-first-action on a service case. No baseline, no selection.

4. Contained blast radius.
A late or imperfect offer can be held in a review queue. A wrong spare-part recommendation can be confirmed before the truck leaves. A wrong released manufacturing BOM that goes to the laser cutter cannot be fixed. Prefer workflows whose failure mode is “queued for a human,” not “steel is already cut.” Rollback is a design requirement, not a hope.

5. A named owner who does not need a coalition.
A named owner who does not need a coalition.

Head of Quotations / Bid Management. Head of Order Processing / Order Engineering. Head of Spare Parts or Service Operations. Someone who can change the path without assembling Sales, Design/Engineering, Purchasing, IT, and the works council into a standing committee. If the owner’s first move is to schedule a regular standing meeting, you picked a sacred cow.

The pair we would rebuild first

Which pair you pick depends on which line the 70% question exposed. In most machine and plant builders, two pairs survive the tests. They share data. That is the point of choosing two rather than one.

Pair A — when the exposed line is new equipment

Workflow 1. Complete RFQ pack → released offer.
Input: a complete inquiry (specifications, drawings, commercial conditions, site or interface constraints) sitting in the mailbox, portal, or CRM.
Output: a priced, technically qualified offer in the system of record, with an exception log of every deviation from the standard product or from similar jobs.
Gate: the offer owner approves price and technical exceptions. Everything else is assembly.

Why it passes: high frequency relative to projects; the work is search–compare–assemble–check; the customer and the file are the same as today’s; cycle time, completeness, and cost-per-quote are measurable; a bad draft stays in a queue; ownership sits with Quotation / Bid Management, not with a coalition.

Workflow 2. Accepted offer → released order-engineering kickoff pack.
Input: the signed order, the frozen offer baseline, and the clarification notes that always arrive in the first ten days.
Output: a released order folder — specification, manufacturing-relevant BOM or module list, long-lead purchase requisitions, and the project record in PDM/ERP.
Gate: the order-engineering or project lead releases the pack.

Why it adjoins: it consumes the structured offer the first workflow just produced. The similar-job library, cost model, rule table, and supplier lead-time table are the same objects. Learning compounds in a week instead of a quarter.

This is quote-to-order-release. It is not “AI in Sales,” and it is not “redesign engineering.”

Pair B — when the exposed line is the installed base

Aftermarket is often the higher-margin, higher-throughput line, and the political surface is smaller than the design office.

Workflow 1. Identified machine + parts request → confirmed parts list with price and availability.
Input: serial number or type plate plus a photo, a marked drawing, a part number fragment, or a plain-language description.
Output: a confirmed list in the spare-parts system — part numbers, supersessions, stock or lead time, price.
Gate: a parts specialist confirms only the ambiguous matches.

Why it passes: it happens every day; the core is retrieval and checking; the customer is the same service customer you already have; error rate and cycle time are already complained about; the blast radius is a confirmation queue; ownership is Ersatzteilwesen.

Workflow 2. Fault report on a known machine → first-action service pack.
Input: machine identity plus symptom, operating context, and any error codes or photos.
Output: a brief the technician can act on — likely causes ranked against history, required documents, recommended parts, safety notes, and a proposed work order.
Gate: a service engineer releases the pack when the case is non-standard.

Why it adjoins: it uses the same machine identity, parts catalog, document store, and installed-base record as workflow 1. The event stream is shared. The stack is reusable on Monday morning.

Do not mix one workflow from Pair A with one from Pair B to satisfy two vice presidents. Two workflows show how one stack generalizes to adjoining work. A compromise pair is how you get two orphans.

What the intelligence stack does on these workflows

The five layers are not a slide. They are the jobs the twin must perform on live files.

Sense. Ingest the RFQ PDF, the email thread, the customer portal dump, the type-plate photo, the fault description. Watch incoming mailboxes and tickets continuously, not when someone remembers to forward them.

Interpret. Structure the inquiry against your product and project taxonomy. Retrieve similar jobs, similar plants, similar failures. Extract constraints that later become exceptions: interface dimensions, ATEX, food-grade, local norms, liquidated damages, requested documentation language. For parts: match image and text against the catalog and the supersession chain.

Decide. Propose a configuration, a parts list, or a first-action pack under the existing rules. Flag the 20% that break a rule. Do not invent a new machine. Do not silently accept a deviation that once required a human signature.

Orchestrate. Assemble the offer document, order folder, purchase requisitions, and service brief. Write into the systems of record you already have — CRM, ERP, PDM, service ticket — rather than creating a sixth place where truth lives. Route only the exceptions to the named gate.

Learn. Compare the twin’s draft with what the human released. Compare cycle time, error rate, unit cost, and risk events of the two paths on the same inputs. Feed the miss back into retrieval and rules. This layer is why you run two workflows, not one: you need to see whether the loop generalizes.

Humans stay above the loop. They approve or refuse at the gate. They do not search, copy, and align. That is the distinction between a twin and a copilot.

The parallel run, in this company

Same RFQs. Same spare-parts requests. Same fault reports. Two paths.

The legacy path continues to produce the official offer, the official order pack, the official parts list. The twin produces its version from the same input, into a review queue, with a full trace: which similar job it used, which rule fired, which field it could not fill.

Once a week, the owner and the CEO read four numbers for each workflow: cycle time, quality (first-pass completeness or error rate), cost per instance, risk events (wrong part, missed constraint, undocumented deviation). Not a demo. Not a sentiment survey. Not “hours saved,” which is how headcount politics re-enters.

When the twin is better on those four, you deprecate the old path for the standard 80% and keep the human gate on the 20%. Then you take the next adjoining workflow—supplier RFQ for the long-leads the order pack just named, or the commissioning-to-as-built documentation pack that closes the project. The edge grows by evidence, not by a transformation office.

Four weeks is enough to know whether you chose a road. If the queue is empty because the workflow happens twice a month, you chose prestige. Start over.

The one-page test, filled in

If you can’t complete this page without a workshop, the candidate isn’t ready.

Workflow 1 — RFQ pack to released offer

  • Input: complete customer inquiry file (PDF/email/portal), classified as in-scope product family.
  • Output: priced offer in CRM/ERP, with an attached exception log.
  • Gate/owner: Head of Angebotsmanagement. Approves price and technical deviations. Reports to the CEO for the twin, not to a digitalization board.
  • Metrics: hours or days to release an offer; completeness against a checklist; cost per offer; hit rate on offers the twin touched.
  • Why coordination-heavy: most elapsed time is finding the last similar job, reconciling drawing notes with the configurator, collecting Einkauf numbers, and formatting the document.
  • Rollback: twin output stays in a review queue; nothing is sent to the customer without the gate.
  • Reporting: weekly four-number sheet on the same inquiries the legacy path processed.

Workflow 2 — accepted offer to released order-engineering pack

  • Input: signed order + frozen offer + clarification notes.
  • Output: released specification, manufacturing-relevant BOM/module list, long-lead requisitions, project record in PDM/ERP.
  • Gate/owner: Head of Order Engineering / Auftragsabwicklung.
  • Metrics: days from order to released pack; first-pass completeness; change orders in the first 30 days attributable to an incomplete kickoff; long-lead coverage at release.
  • Why it adjoins: it consumes the structured objects workflow 1 created; same product rules, same similar-job library, same cost and lead-time tables.
  • Rollback: the pack is not released to production or purchasing without the gate.
  • Reporting: same weekly sheet, same owner line to the CEO.

If you are on Pair B, rewrite the page with machine identity + parts request, and fault report + first-action pack. Do not leave the page generic.

What not to choose in this industry

Do not start with generative design. It is judgment-heavy, low-throughput at the beginning, and it clashes with construktion’s identity.

Do not start with a full PLM migration. That is a science project wearing a workflow badge.

Do not start with shop-floor execution. The blast radius includes scrap, safety, and the works council. The twin has not earned that radius.

Do not start with “an employee assistant for everyone.” That is a tool. It will never produce a deprecation decision.

Do not start with the broken process you have been meaning to fix for years. The twin will inherit the fog, and the comparison will be unreadable.

Do not start where a vendor already has a demo that looks like your machine. Vendor gravity is not a test.

The practical recommendation

Sit with the CEO and the two named owners. Do not invite the standing committee.

Write the 70% line in one sentence — new equipment or installed base. Name two adjoining workflows on one page using the template above. Score them against the five tests. If either workflow is a demo, an orphan, a sacred cow, or a science project, discard it and name another.

Stand up the twin inside the firewall, on the files you already receive, with humans on the gates. Run both paths on the same inputs for four weeks. Read the four numbers. Deprecate what loses. Then take the next workflow on the same chain.

The line maps the exposure. In machinery and plant engineering, the high-traffic roads are the offer that commits you and the aftermarket request that pays you. Choose those. Leave the parks for later.

Send the notes!

Short pieces on AI-native work: workflows, guardrails, humans above the loop.