Skip to content
All insights

General

How to Integrate AI with Your Workflow Across a Multi-Site Manufacturing Group

By Shanshan "Sasha" Ma

For manufacturing groups that grow by acquisition: three AI workflows that repeat at every site, how to decide build vs buy, and what to require before you buy.

Your digital team spent eight weeks at one plant building an AI tool that reads incoming RFQs, checks them for missing drawings and tolerances, and flags quotes that have gone quiet. It works. The estimators like it. Then the plant two states away asks for the same thing.

That plant runs a different ERP. Its RFQs come through a shared inbox instead of a portal. Its estimators call a "complete" package something slightly different. So the team starts again.

For a group that has acquired a dozen businesses, that's the real AI problem. Building one useful tool is no longer hard. Building it so it works at the next eleven sites is.

The systems differ. The work doesn't.

Acquired manufacturers keep their own ERPs, MES systems and spreadsheets, often for good reasons. Replacing them all to get a common platform is a multi-year project nobody wants to fund.

But look at what people at each site do all day, and the pattern repeats. A machine shop, a wire harness shop and a composites plant all:

  • receive requests that arrive incomplete
  • wait on customers, suppliers and engineering
  • chase status across email, the ERP and a spreadsheet
  • discover problems late, when a date has already slipped

The records differ from site to site. The coordination around them is almost identical. That is where AI is most reusable: not inside each system, but in the work that runs between them.

A pattern that travels between sites

The approach that works across different systems has four steps:

  1. Capture. Read what arrives (emails, PDFs, drawings, supplier notices, ERP exports) and attach each piece to the quote, order, purchase order or program it belongs to.
  2. Track. Keep each one as a work item with a state, an owner and a clear "waiting on": customer, supplier, engineering, quality or production.
  3. Flag. Notice what's stalled or at risk, and say why in a sentence.
  4. Recommend. Suggest the next action for a person to approve.

Each site's ERP stays the system of record. AI reads and suggests. Nothing changes in a system without a person approving it through the controls that site already has. That is what makes the approach safe to deploy at a business you acquired six months ago.

Here are the three workflows where this pays off most, at almost every site.

1. RFQ to quote

What happens today: RFQs arrive by email with drawings attached, sometimes without the revision, the quantity break or the material spec. Estimators ask questions, wait, and juggle dozens of open requests. A good quote goes out late, or a request sits unanswered until the customer moves on.

Where AI helps:

  • Check each RFQ for completeness against the site's own checklist, and list exactly what's missing.
  • Track every open RFQ: waiting on the customer, on engineering review, on a supplier price, or on the estimator.
  • Flag requests at risk of missing the customer's due date.
  • Draft the clarification email for the estimator to review.

What it doesn't do: price the job. The estimator owns the number.

Why it travels: every site quotes. Only the checklist and the due-date rules change.

2. Supplier expediting and order exceptions

What happens today: a supplier pushes a delivery by two weeks in a reply to a three-week-old thread. A certificate of conformance is missing. Long-lead components for a defense or medical program slip, and production finds out on the day the parts were needed.

Where AI helps:

  • Match supplier emails to purchase orders, even when the reference is buried or written differently.
  • Compare promised dates against the dates production needs, and flag the gap.
  • Track missing documents (certifications, test reports) per order.
  • Draft the expedite request or the heads-up to the customer for a buyer to send.

What it doesn't do: change the schedule or the purchase order in the ERP.

Why it travels: every site buys materials, and the risk shows up in email before it shows up anywhere else.

3. Design-to-production handoffs and engineering changes

What happens today: a customer sends a revised drawing. Engineering updates the model. Purchasing doesn't hear about it until the old parts arrive. In new product introduction, open action items live in meeting notes and spreadsheets, and nobody can say with confidence what's blocking the move to production.

Where AI helps:

  • Turn customer change requests, engineering notes and meeting action items into tracked work with owners.
  • Link each change to the orders, purchase orders and work in progress it affects.
  • Show what's blocking each program milestone, and who it's waiting on.
  • Flag changes that reached engineering but not purchasing or the floor.

What it doesn't do: approve an engineering change. Engineering and quality still sign off.

Why it travels: every site that does engineering has handoffs. For groups that sell "design through production," this is the promise customers are paying for.

Two more once the first is proven

  • Quality evidence. Corrective actions, supplier certificates and first-article packages for aerospace and medical customers follow the same pattern: gather the evidence, flag what's missing or expired, and route it to the owner.
  • Group-level work health. Once a few sites run on the same work model, leadership can see what's stalled across the portfolio without forcing every business onto one ERP.

Build or buy: how a group with its own AI team should decide

If you've hired a digital team with AI engineers, the default answer is "we'll build it." Often that's right. The team knows your sites, has access to your data, and can move without a procurement cycle. Here's how to tell when it is and isn't.

Build it yourself when:

  • The workflow is unique to one business. A custom inspection step or a process tied to one customer's program won't repeat elsewhere, so there's nothing to reuse.
  • It's a competitive advantage. If how you quote or schedule is part of why customers choose you, owning it outright is worth the cost.
  • Your team has room to maintain it. Building is a few weeks. Keeping it right across sites, ERP upgrades and model changes is permanent work.

Look at buying when:

  • The same pattern repeats at every site. Matching supplier emails to purchase orders, tracking who's waiting on whom, and spotting a stalled quote work almost the same way at a machine shop and a harness shop.
  • The first version was easy but the next 80% isn't. A prototype that reads emails comes together quickly. Getting it reliable on real inboxes, where references are misspelled and threads mix three orders, takes months of tuning and testing.
  • Your engineers are spending site visits on plumbing. If forward-deployed time goes to rebuilding the same tracking logic for each site, it isn't going to the problems only that site has.
  • Acquisitions keep coming. Every new business is another round of the same deployment. A layer that's already proven shortens it.

Costs to count honestly on both sides:

  • Building: engineering time to build, then the ongoing time to test, tune and support it at every site. That second number is the one most estimates leave out.
  • Buying: subscription cost, a security and data review, dependence on a vendor's roadmap, and integration work your team still has to do.

Questions to settle before deciding:

  1. Will this workflow look the same at your next three sites?
  2. Who maintains it after go-live, and is that the best use of their time?
  3. Does the tool need to write to your ERP, or only read and suggest? Read-and-suggest is lower risk to buy.
  4. Can you exit cleanly, with your data and your rules, if it doesn't work out?

The common answer is both. Your team owns site discovery, system connections, permissions, the interfaces people use and the site-specific rules. A shared layer handles the work model, evidence matching, exception flags and recommended actions that repeat everywhere. Your engineers spend their time on what's unique to each business, and arrive at the next acquisition with the repeatable part already working.

What to require before you buy

If you do bring in an outside layer, hold it to the standard your own team would meet. Four things are worth insisting on:

  1. It fits your stack and your governance. It should use your access controls, read from your ERPs without writing to them unless you approve it, and pass your AI governance review. Where it runs should be your call.
  2. It measures waste, not activity. Waiting is one of the classic lean wastes. The useful measures are the days an RFQ sits incomplete, or the days between a supplier changing a date and production finding out. Agree on the measure before you start, not after.
  3. It helps with the next acquisition. A new business arrives with its own systems. You should be able to see what's stuck there in its first month, without waiting for an ERP migration.
  4. It proves itself on your data. Start with one workflow at one site, side by side with how the site works today. If your team already has a prototype for the same workflow, compare the two directly. A good vendor will welcome that.

Two conversations, not one

The people who feel the problem and the people who decide are usually different. Estimators, buyers and plant managers know where work waits, so start discovery with them. Your digital team owns the decision and the deployment, so make them the owner from day one. The sites get results in weeks, and the digital team gets a repeatable asset for every site that follows.

How to start

  1. Pick one site where people still chase status by email. Ask: how many quotes, orders or changes are waiting on someone right now, and how long did it take to find out?
  2. Pick one workflow from the three above. RFQ to quote is usually the easiest to measure.
  3. Start with one workflow for a few weeks alongside the systems that site already uses. Measure how long items sit waiting and how often someone has to ask for status.
  4. Write down what changed per site (checklists, thresholds, owners). That list is your deployment playbook for site two.

Try this week

  • Ask your estimators how many open RFQs are waiting on missing information right now.
  • Ask a buyer which supplier date changes this week arrived only by email.
  • Ask a program manager what's blocking their next milestone, and how they know.

If the answers live in inboxes, you can see which changes put orders at risk with Operations Workbench Starter, free for 30 days. If you'd like to scope a first workflow at one of your sites, talk to LevelOneAI.