Tackling Data Overwhelm in Vessel Performance Management: Shifting from Full Visibility to Real Clarity

Many of the arguments for digitalisation, both inside the shipping industry and beyond, have rested on the same promise: see more, and you will manage better.

Whilst the first half has largely been delivered, the second has not followed seamlessly. This is because seeing more and knowing more are not the same thing. Unfortunately, all too often, the gap between them is being absorbed by the operations and technical teams who sit between the data and the decision. And the more each new system contributes, the wider that gap becomes, because every additional feed arrives as something further to read, to reconcile and rule out.

More to watch, no help deciding where to look

That gap is not a failure of the people doing the work. It is the predictable result of more instrumentation, more reporting obligations and the same number of hours in the day. The right people are simply dealing with more information than any system has helped them prioritise.

Alerting is where most fleets look first. But a fixed threshold has no view of the conditions the vessel is in. Take consumption: the same figure can be entirely expected on a laden passage in heavy weather, and a sign of real underperformance in ballast.

Teams do what anyone would: the alert that keeps being wrong gets checked last, then not checked at all, and attention shifts to the vessels someone has flagged by hand. At that point the system has stopped working, even if it still looks as though it works. It has become one more thing for teams to manage, instead of something that helps them manage the load.

The problem is not the alert. It is what the alert is measured against. A fixed figure knows nothing about the vessel it is watching.

A deviation is only as good as its baseline

If a fixed number is the wrong reference point, the right one is what this particular vessel should be doing in the conditions it is actually in. That is a modelling problem, and solving it is what turns performance data into something an operations team can act on rather than something a technical team interprets after the fact.

Our virtualVESSEL digital twins combine physics-informed models with machine learning to predict power, fuel consumption and RPM across varying speeds, drafts and sea states. Degradation models built on the same framework track hull and propeller performance against that baseline over time.

A deviation measured against a per-vessel, condition-aware baseline is a different object from a threshold breach. It comes with the expected figure beside it, and the conditions that produced it, so the size of the gap and its likely cause are visible at the same time as the flag.

Fuel typically accounts for a majority of voyage operating costs, so degradation caught in weeks rather than at the next drydocking is not a technical improvement. It is a commercial one.

The same report, two different answers

Any system that cannot separate a bad data point from a genuine change will raise both, and raising both teaches people that alerts are unreliable.

That is why we treat data quality as something measured rather than assumed, with filtering applied according to what each calculation is for. A report covering a period of variable speed may be unusable for a speed and consumption comparison while remaining perfectly valid for cylinder oil consumption in the same view. The same data, judged differently depending on the question being asked.

Context does not stop at the vessel

Where a vessel is changes what a deviation means. A consumption figure that would warrant investigation at sea may be entirely explicable for a vessel manoeuvring in a port approach, and a flag raised after it has berthed has arrived too late to be worth anything.

OpenOcean STUDIO’s differentiating capability comes through its event-driven onRADAR module, which enables management by exception through intelligent alerting and task management, with built-in chat messaging. It is available onshore, onboard and on mobile.

The platform also draws vessel position and geographic data from Lloyd's List Intelligence, including Geo Zone coverage of ports, terminals and other operational areas. onRADAR uses it to raise alerts earlier and more precisely as vessels approach those areas.

onRADAR also applies configurable rules so what surfaces reflects the role receiving it. Operations, compliance and technical performance are looking for different things in the same underlying data. There is no reason they should be served the same view.

Conclusion

Alerts that go unread, deviations noticed too late, and teams working from their own judgement rather than the system's look like separate problems. They share one root cause: systems that surface everything have made no decision at all, and have moved the filtering problem onto the people least able to absorb it.

Full visibility was the right ambition. Clarity is the harder one, and it is the one that gives teams their attention back. Clarity is not a lighter version of visibility. It is built from the same data, with three things added:

• a baseline that knows what each vessel should be doing

• confidence that what is being flagged is real

• delivery to the people whose job it is to act, while acting still matters

That is the work onRADAR does, and it is the difference between a platform that adds to the load and one that takes it off.

The question to ask of any performance programme is not how many metrics it can display. It is what the system chose not to tell you, and whether it can explain that choice when asked.

At 90POE, our mission is to make global shipping simpler, smarter and more sustainable. OpenOcean STUDIO is how we deliver on that, helping owners optimise their assets by giving them data they can rely on and delivering it at the time and to the people who need it most.

To book a demo of OpenOcean STUDIO, connect with the team here.