Why we built VECHR MES

It started as an implementation problem

VECHR did not begin as a product idea. It began as a pattern we saw over and over while doing implementation work directly on plant floors.

Every plant has its own way of working and its own requirements. Nothing exotic or unusually specific, just the consequence of how the production process actually runs.

A routing that needs to branch on an operator’s judgement. A tank whose occupancy time depends on pump rate rather than a fixed duration. A quality check that, when it fails, has to hold the affected unit immediately rather than waiting until the end of the shift.

Things like this look simple when you look at the process. Taken into an MES that is too rigid, all of them can become complicated.

The more often we ran into the same pattern, the clearer it became. The problem is not the process in the plant. The problem is when the software forces the plant to work the way the software works.

What “too rigid” costs

The problem is rarely that the system says outright, “that is not possible.”

Far more often the answer is, “it is possible, but…”

The customization may be doable, but only by changing core system behaviour. After that, the change has to be maintained through every platform upgrade.

The change may also be buildable, but it takes months. And by the time it is finally done, the need on the shop floor may have moved on again.

The most dangerous case is when the solution does technically satisfy the requirement, but feels unnatural to operators. They then start looking for other ways to get their work done.

And that is where the real cost appears.

Once operators start avoiding the system, the MES is no longer a trustworthy record of what actually happened on the shop floor.

Which is one of the main reasons an MES is built in the first place.

The alternative we wanted

The conclusion was not simply to build a more flexible MES and sacrifice enterprise standards.

Quite the opposite. Standards like ISA-95, ISA-88, 21 CFR Part 11, access control, and audit trails are exactly what makes a platform trustworthy. Standards are not what makes an MES rigid.

Rigidity comes from a platform assuming there is only one way to run or model a process, then treating every different requirement as custom development work.

So we took a different approach.

The parts that genuinely differ between plants should be designable and configurable from the start, not treated as exceptions.

• Routings are drawn directly on a canvas, including sequential, parallel, and conditional rework paths, without changing code.
• Automation between equipment and MES transactions is built by connecting nodes, not by writing integrations from scratch.
• Resources can have different characteristics. Machines, tanks, and pumps cannot always be treated under the same scheduling rules, because the way they consume capacity genuinely differs.
• Transactions can be adapted to what a process needs, without forcing every plant into one fixed model.

With that approach, VECHR keeps its enterprise foundation and discipline while leaving each plant room to work in the way its process actually calls for.

If you are evaluating an MES

Two questions we think are worth asking any MES vendor, ours included:

1. When our process does not match the model you have, what happens? Can it be configured, or does it mean waiting on a change request and a change to the core system?

2. Which parts are configuration, and which parts need code? The line between those two decides how fast, how expensive, and how easily the platform can grow with your business.

We built VECHR MES because we watched that line fall in the wrong place far too often.

Software should adapt to the business process. Not force the business process to adapt to the software.