MES for High-Mix, Low-Volume Manufacturing: Why Composability Is the New Standard

Most manufacturing execution system vendors will tell you they handle high-mix, low-volume production just fine. But do they?

It's a question worth asking, because high-mix, low-volume (HMLV) work quietly breaks a critical assumption that traditional MES is built on.

A conventional MES expects you to define a process once and run it for a long time, so the effort of setting it up gets spread across thousands of identical units. But that model breaks in a HMLV environment. When a "batch" is only a handful of units before you switch to a new configuration, changeover can eat as much time as the build itself. The setup goes from being the overhead to becoming most of the work.

As a result, one of the most important considerations for an HMLV plant when it comes to evaluating an MES becomes architecture: which system can keep up with constant change without turning every new variant into a major IT project?

In this post, we'll look at why HMLV is oftentimes underserved by traditional MES and why we'd argue composability has become the sensible standard for high-mix work, especially in regulated industries like aerospace, defense, and medical device.

Traditional MES solutions have long been the default answer to a specific problem many manufacturers used to face: lock in an optimized, validated process and run it consistently and at scale. For stable, high-volume production, that rigid architecture made a lot of sense. It enforces standardization of work that's supposed to stay consistent.

But HMLV doesn't stay consistent. Their advantage is taking on the product variety that high-volume factories avoid, which means the execution system must be able to absorb constant change.

Dynamic variance management is where traditional solutions begin to falter. In a build-to-order facility, engineers are in a constant race to create and revise work instructions across an ever-growing catalog of product variants.

Manage that in paper or PDFs, and version-control failure is practically inevitable. The operator at the station has no reliable way to know if the sheet in front of them is accurate or up-to-date, and that uncertainty has the potential to get expensive.

Scrap and rework alone run between 0.6% and 2.2% of revenue for the average manufacturer, according to APQC benchmarking. In an HMLV plant, a dominant driver of those costs can often be traced back to something as simple as an operator following an assembly instruction that’s fallen out of date.

The instinct at this point is to go shopping for a more configurable MES. That instinct runs into the same wall. Configurability inside a rigid core still routes meaningful system change through the vendor or another third party. When your build instructions change weekly, a system that requires third party support to keep up becomes a massive bottleneck.

A composable MES is built from modular building blocks, apps, agents, automations, connectors, and tables, that sit on one governed data model and get assembled and adapted by the people who run the work.

This matters for a high-mix plant because those building blocks let you do what a monolith can't. Here's how it plays out across the four things HMLV operations struggle with most.

Versioned playbooks and dynamic work instructions, built without IT overhead

Instead of maintaining thousands of static documents, engineers maintain the master process logic once, and the system renders the exact instructions for a given work order or serial number. The operator at the station sees the right build for the assembly in front of them, not a binder they have to find the right page in.

Those instructions are authored, version-controlled, and rolled out under governance, so the floor is always running the latest iteration and there's a record of exactly what changed and when. No-code and natural language authoring is what removes the bottleneck we described earlier. Process and manufacturing engineers compose and revise the apps themselves, with governance intact, so a new variant doesn't wait in a vendor queue.

Catching problems while the build is still happening

A lot of systems will tell you what went wrong after the build is done. On a long production run, that may be recoverable. On a short, high-value run, an after-the-fact report often means the part is already scrap.

A composable platform embeds inline quality inspections to capture signals at the source. Purpose-built edge connectivity to machines, sensors, and devices feeds real-time data into the same apps operators are using during the build.

The system can require that quality data, a torque value, a dimension, a sign-off, gets captured before the operator moves to the next step, so an error surfaces in the moment instead of at final inspection. Real-time signals matter more in low-volume work, simply because there's less margin to absorb a scrapped part.

VEKA is a good example. After replacing a homegrown MES with Tulip, they cut mislabeling errors by about 88% and customer returns by about 60%, by catching the problems while the work was still in motion rather than after the product shipped.

Going live in weeks by starting where the pain is

A 90-day proof of concept has become the market's shorthand for "agile". For a composable platform like Tulip, the timeline is closer to weeks to a first working solution, because you don't have to deploy the whole system before anyone sees value. You put one app against the single most painful problem on one line, prove it, and build out from there. That start-small path is also the answer to the implementation history we mentioned above, where the all-or-nothing rollout is the thing that goes sideways.

Keeping agility and traceability in the same system

For high-mix work in industries like medtech or aerospace and defense, speed is worthless if you can't validate it. These teams feel the tension between agility and traceability, and they've usually been forced to prioritize one over the other. Paper instructions change easily but complicate traceability. A rigid, validated MES traces well while fighting every change.

A composable MES supports both. Every execution gets recorded against the correct revision automatically, so changing an instruction per variant and keeping a clean, defensible record become the same motion. Governance comes from the architecture, which means permissions, approvals, and version control apply to every app and every change by default.

We've watched regulated teams move at speeds that surprise their own quality groups.

Avon Technologies launched two regulated production lines in under six months and moved a site in six months instead of the usual eighteen.

Next Pharma overhauled their legacy ERP and MES in nine months, with an MES composed of around 90 apps connected to SAP.

In both cases the agility and the audit trail came from the same architecture, which is what lets a regulated HMLV operation avoid choosing between them.

For high-mix, low-volume plants, the flexibility question comes down to what's underneath the system, and composable architecture is what lets the software change as fast as the product mix does without giving up control of it. That's the bar that leading HMLV manufacturers should be holding their vendors to.

The plants that pull ahead in high-mix work tend to be the ones whose software adapts at the speed of their floor, where a new variant is a morning's work for an engineer rather than a quarter's work for a vendor. The next time a system is pitched to you as flexible, the more useful question is whether your own team could change it tomorrow without calling anyone.

If you want to see what that looks like for a high-mix, low-volume operation, take a closer look at Tulip's Composable MES or talk through your specific mix with a member of our team.