Why "Free Proofs of Concept" is a way to destroy best specialised companies on market

A large industrial company recently asked us to look at a group of ageing control systems in packaged equipment such as compressors.

The situation itself was familiar. Different generations of PLCs, old engineering stations, obsolete Windows installations, package HMIs, vendor-specific software, incomplete engineering projects and equipment that has accumulated modifications over many years.

Nothing unusual there. This is normal life in a plant that has been operating for decades.

What caught my attention was something else.

The company already has a major OEM responsible for a large part of its automation environment. Yet the projects now being discussed with smaller specialist companies are exactly the projects carrying the ugly part of legacy automation: poor documentation, obsolete hardware, uncertain software status, incomplete backups and unclear boundaries of responsibility. Then comes the request.

Can you make a Proof of Concept? Of course for free.

That is the point where I lose interest.

BM Global AS has worked with industrial control systems for 26 years. We have worked with obsolete systems, unsupported systems, old PLCs, old Windows platforms, historians, control networks and plant data long enough to know what such a project contains.

So what exactly should we prove?

If somebody has invented a new physical principle, a POC makes sense. If nobody knows whether a technology can perform the required task, testing it makes sense.

That is not what is happening in many legacy automation projects. The requested POC often contains the most valuable engineering work in the entire job.

Someone has to study the installed system, understand its history, locate usable backups, identify unsupported hardware, inspect interfaces, find communication paths, understand what can remain and what has to change, define the migration concept and work out how the old system can survive until the final replacement.

Once that work is finished, the client has learned something valuable.

• They know what the real problem is.
• They know what has to be changed.
• They know which parts can remain.
• They know where the technical risks sit.
• They know roughly what the project should cost.
• They can then take that knowledge back to the OEM, another contractor or a tender.
• The specialist who discovered all of this gets nothing.
• Calling that a POC does not change what it is.

It is engineering. And engineering has a price – they are real engineers behind it, real engineers who need to pay school for kids, pay the rent, care for their families – is there any reason why they should work for free?

There is another question worth asking

Why did the large OEM not take the project in the first place?

Major OEMs are not stupid. They know their installed base. They know where the clean migration projects are, and they know where twenty years of undocumented modifications are waiting behind the cabinet door.

A standard migration can be attractive. An old package system is different.

Perhaps the PLC still works, but the engineering software runs on an old operating system. Perhaps the HMI needs replacement, but the controller cannot communicate with the new platform. Perhaps the backup exists, but it is only an upload from the controller and not the original engineering project.

Then there are field problems.

• A sensor has been unstable for years.
• A relay works intermittently.
• One analog signal chatters.
• Scaling is wrong.
• A calculation uses an undocumented correction.
• The display shows two decimal points here and three somewhere else.
• An alarm has not worked for five years.
• A wire was moved during an outage in 2014 and nobody changed the drawing.
• A parameter was modified by somebody who left the company ten years ago.
• None of these problems was created by the company arriving today.

But once that company touches the system, the history starts becoming its responsibility. That is the real danger of package projects.

“It worked before you touched it”

Anyone who has spent enough time in old industrial plants knows this sentence.

• You modify one part of a twenty-year-old package.
• Three weeks later somebody finds another fault.
• Suddenly the question becomes whether your modification caused it.
• The compressor trips.
• Your problem.
• The old pressure transmitter drifts.
• Your problem.
• An alarm is missing.
• Your problem.
• A calculation is wrong.

Your problem .... The original drawings are incomplete. Still your problem.

Proving that a fault existed before your intervention will consume more engineering hours than the modification itself.

That risk becomes much larger on package equipment. These systems often sit outside the main DCS engineering discipline. They came with compressors, water systems, filtration skids, pumps or other vendor packages. Each package can have its own PLC generation, HMI, software version, communication method and documentation quality.

A commercial request can describe all of this with one innocent sentence:

“Upgrade the package control system.” The sentence is short.The liability behind it is not.

The most dangerous package is the one somebody else does not want. There is a commercial pattern here that smaller engineering companies should recognise.

The large OEM keeps the work it understands well.

• Standard migrations.
• New equipment.
• Defined scope.
• Known hardware.
• Known software.
• Good documentation.
• Predictable engineering hours.
• Then the difficult work appears elsewhere.
• Legacy packages.
• Missing drawings.
• Old Windows machines.
• Unsupported controllers.
• Uploaded backups instead of original projects.
• Unknown modifications.
• Locked logic.
• Field problems mixed with control problems.

Now somebody tries to place all of that into a package contract and hand responsibility to a smaller specialist.

The OEM keeps the cream.

The specialist gets the risk.

That is not a clever way for a specialist company to grow.

It is a very good way to spend months solving twenty years of somebody else's problems under a fixed commercial commitment.

The free POC makes this worse

A free POC changes the commercial balance before the project has even started.

• The large industrial company owns the asset.
• It owns the problem.
• It has the production revenue.
• It has the purchasing organisation.
• It has existing contracts with major vendors.

Yet the specialist company is asked to finance the investigation.

That makes no sense to me. Our engineers' time has value before the purchase order for the main project exists. The first week of investigation can contain more intellectual value than weeks of installation work later.

• Finding the real technical boundary has value.
• Recovering an incomplete project has value.
• Understanding an obsolete control system has value.
• Designing a practical life-extension concept has value.
• Finding a safe migration path has value.
• None of this becomes free just through changing its name to “Proof of Concept.”
• There is another commercial danger.

A free POC become a very cheap way to collect specialist knowledge.

The client receives a technical concept. Procurement now has a much better specification. The incumbent OEM gets another chance to quote. Other bidders receive a clearer scope.

The specialist has financed the education of everyone involved. We have seen enough of that over 26 years.

Cybersecurity responsibility works the same way

The same principle applies to cybersecurity. A company cannot ask a specialist to take responsibility for OT cybersecurity and then remove control over the architecture.

• Remote access matters.
• Third-party access matters.
• Account ownership matters.
• Network boundaries matter.
• The method used to move data between security zones matters.
• A vendor cannot own the cyber risk yet have no authority over these items.
• I often hear cybersecurity discussed as another product purchase.
• Install this firewall.
• Install this remote-access platform.
• Install this monitoring package.
• Connect everything to the central system.

Then call the plant secure.

Cybersecurity is an outcome of properly implemented Business Continuity.

The organisation must know what is installed. It must know who has access. It must know which connections exist. It must know how systems are recovered. It must know what happens after a server fails, a network disappears or a third party loses access.

Technology sits inside that operating model. It cannot replace it.

So what project will BM Global accept?

We will take difficult projects.

In fact, difficult legacy systems are part of our business.

We will investigate obsolete equipment. We will reconstruct engineering information. We will support systems that no longer receive practical OEM support. We will design life-extension concepts. We will work out how an old system can remain operational for another three years until a replacement budget arrives.

There is real value in this work.

There is often a long gap between the moment a plant identifies obsolete equipment and the moment money becomes available for final replacement. During that period, somebody still has to keep the plant running.

That is a proper engineering assignment.

• But we will not pretend that such engineering is a free demonstration.
• A technical assessment is work.
• A system investigation is work.
• A migration study is work.
• Reverse engineering is work.
• A POC containing these activities is work.

And work gets paid.

BM Global has no problem proving that a proposed technical concept works.

We have a problem with paying for the privilege of solving somebody else's problem, then handing over the answer for free.

After 26 years in this business, we know the difference.