R&D & Consultancy

Where it pays off

What these projects have in common is that nobody yet knows what the work actually is. Automating a line is a defined job; “could we do this inspection with a camera” is first a question and only then a job. Closing that gap is what consultancy is for.

The situations we run into most often:

• Before an investment decision. A budget is going up for approval but technical viability is unclear, and the numbers come from supplier presentations.
• Bids that cannot be compared. Three quotes for the same job describe three different jobs, and where the price gap comes from is impossible to see.
• An existing system that misses expectations. The system runs, but the target cycle time or quality rate is never reached, and whether the cause sits in the control layer, the mechanics or the process is unknown.
• There is an idea, but no first step. A new product, a special machine or a test rig is being considered and nobody knows where to begin.
• Several suppliers, no single owner. Mechanics, electrics and software sit with different firms, and the work left at the interfaces is in nobody’s scope.

What a proof of concept is for

The purpose of a PoC is not to show that something works, but to learn cheaply if it will not. In practice that distinction changes everything. When the goal is to demonstrate, the experiment gets built under conditions known to succeed: clean samples, fixed lighting, hand-picked parts. When the goal is to learn, the experiment targets the hardest condition.

So before any work starts, two things are written down: the single question being tested and the success criterion. The criterion has to be numerical — “it gave good results” is not a result. Written up front, it produces a clear decision even when the answer is negative; written afterwards, whatever came out gets counted as success.

We say at the outset that a negative result is a valid deliverable. An investment stopped by a few weeks of experiment costs far less than learning the same thing during commissioning.

Specifications and tender evaluation

The most visible consequence of a badly written specification is that bids become incomparable. A sentence like “high-precision measurement shall be performed” means something different to every supplier: one reads ±0.1 mm, another ±0.01 mm, and a threefold price difference looks inexplicable. The same vagueness returns at acceptance — the system is delivered, and with no criterion the argument begins.

The rules we follow when writing one:

• Every requirement is written to be measurable: value, tolerance, measurement method and conditions together.
• Acceptance criteria are part of the specification; FAT and SAT protocols are agreed with the contract, not improvised at handover.
• Scope boundaries are explicit: field wiring, mechanical adaptation, training and documentation — whose job each is.
• Brands are not dictated, but interface standards are — communication protocol, data format, delivery of source code.

When we evaluate bids we build a comparison matrix: technical fit, work excluded from scope, spare part and support availability, and the skill set of the maintenance team. What the cheap bid left out of scope is usually where the difference comes from.

What we watch for

A maturity assessment starts from the current state. Proposing a prediction model to a plant that collects no data is skipping a step; measurement infrastructure comes first.

We state in writing that a prototype is not production code. PoC code is written fast and carries known limits; putting it on the floor because “it works anyway” produces stoppages whose cause can no longer be traced.

The roadmap is tied to decisions. Every stage ends with a continue / stop / change direction point. An uninterrupted twelve-month plan is worthless the moment the first measurement arrives.

How this connects to the other solution areas

Consultancy output usually turns into implementation work: a quality inspection idea that passes feasibility gets built under machine vision and camera systems, while the line-side implementation belongs to industrial automation. The measurement and reporting needs of a prototype are covered by software and application development.