Insights · Bluehaven Maritime Services BV

Notes from the delivery team

Practical notes written by the people who do the work at Bluehaven Maritime Services BV. Each one takes a specific problem in legacy modernisation, system integration, or data work and explains what actually happens on projects in Belgium and the wider port sector.

A cold datacentre aisle of ordered cabinet rows receding into the distance, cool daylight entering from the left, one figure at the far end. — Antwerp · the inside of what a port runs on

Every note below stands on its own. A reader can start with the problem that resembles theirs and skip the rest. Where a project taught us something worth writing down, we wrote it plainly, without the marketing layer that usually goes on top.

Jump to the notes Ask about a topic

Reading order

Eight notes, chosen by the problem they touch

Grouped by the situation, not by the technology. A finance lead usually starts with the ERP question; a plant manager with the integration one.

Why legacy modernisation stalls at the second system

Sequencing · port and industrial

Integration failures you only see at 03:00

Timing · monitoring outcomes

What a data warehouse looks like before it works

Modelling · from questions

Choosing between extending the ERP and building beside it

Financial vs operational

The customs interface problem

Formats · human in the loop

Multilingual requirements in Belgian systems

Dutch, French, English

When AI earns its place in an operations system

Repeated decisions · at volume

Reading a vendor's proposal critically

Assumptions · scoping

Filed from this week · a note shown in full

Integration failures you only see at 03:00

An interface that works in testing and fails in production is almost always a timing problem. A nightly batch that overlaps with a backup window. A carrier portal that returns a different error code under load. A queue that fills quietly when a downstream system is slow.

The lesson we keep relearning is that monitoring has to check outcomes, not just whether the process ran. A job that reports success while the record never arrives is the most expensive kind of green light — it costs a shift before anyone notices, and it puts a customer conversation on your desk that should have been a system message.

Where each note lands in the work

The eight notes map back to the service lines we run at Bluehaven. If one of them describes a live problem at your site, that is usually the right conversation to open.

Custom software development

Plant-floor logic that used to live inside the ERP

Operational requirements that move fast and belong to one team rarely sit well inside the ERP. This is the note about where to draw the line — and what integration looks like once you have.

See our service lines

System integration

Interfaces that fail between 02:00 and 05:00

Timing, retries, and the outcome-level monitoring that finds an interface before a customer does. Written from our own post-mortems, not from a vendor playbook.

See our service lines

Data platforms

A warehouse built from the questions, not the sources

How the first models we build in a logistics or maritime warehouse are usually the reports someone rebuilds by hand, and the two numbers two departments argue about.

See our service lines

Enterprise modernisation

Customs and port-authority interfaces, isolated

Formats that change without notice, environments that behave differently from production, and the layer we put behind a maritime interface so a rejected declaration becomes a message someone can act on.

See our service lines

The notes, in full

Written by the delivery team over the last few years of port and industrial work in Belgium. Each one is short on purpose — the length is the point that the problem is clear once it is named.

Sequencing · port and industrial

Why legacy modernisation stalls at the second system

The first system usually gets replaced. It is the second one that stalls, because by then the budget has been spent, the sponsor has moved on, and the two systems now disagree about a shared field. We have watched this pattern repeat across port and industrial clients.

The fix is sequencing, not technology: plan the migration order around data dependencies rather than around which system is most annoying, and keep a reconciliation report running across the boundary for as long as both are live. A migration plan that survives the second system is usually the one where the second system was never left to fend for itself while the first was celebrated.

Modelling · from questions

What a data warehouse looks like before it works

Most first attempts at a maritime or logistics data warehouse produce a technically correct warehouse that nobody uses. The usual cause is that it was built from source systems rather than from questions.

We now start by listing the reports someone rebuilds by hand every month, and the numbers two departments argue about. Those become the first models. The rest of the source data can wait until there is a reason to bring it in — which is usually three weeks later, when someone asks a question the first models can already half answer.

Financial vs operational

Choosing between extending the ERP and building beside it

There is no universal answer, but there is a useful test. If the requirement is financial, regulatory, or shared across departments, extend the ERP and accept the upgrade cost. If it is operational, fast-moving, and only matters to one team, build beside it and integrate.

The expensive mistakes come from getting that backwards: custom plant-floor logic buried in an ERP that will be upgraded next year, or a finance report living in a side application that nobody governs. The second one looks cheap at build time and costs the most at close.

Formats · human in the loop

The customs interface problem

Customs and port-authority interfaces are the part of a maritime project that planning meetings underestimate most. Formats change, and they change without much notice. Test environments behave differently from production. A declaration that is rejected at 17:00 on a Friday is a customer incident, not a system message.

The design response is to isolate the interface behind a layer you control, validate before submission, and make the failure state visible to a human who can act on it. That last part is where most projects stop short.

Dutch, French, English

Multilingual requirements in Belgian systems

A system used in Antwerp, Ghent, and Brussels will be used in Dutch and French, and often in English for international counterparties. This is not only a translation task. Terminology differs by region, some field labels have no clean equivalent, and the workflow that makes sense in one language may be named differently in another.

Getting this right means involving users from each region during design, not running the interface through a translation tool at the end. The translated system reads fine to a linguist and wrong to a dispatcher in Ghent — and it is the dispatcher who has to use it every shift.

Repeated decisions · at volume

When AI earns its place in an operations system

Most operational AI projects we see are better described as reporting. The genuine cases we have worked on share a shape: a decision that is made repeatedly, at volume, with enough historical outcome data to learn from, and where being approximately right is useful.

Anomaly detection on equipment signals fits that shape. A chatbot answering questions the data cannot support does not. If you cannot point to the historical records that would train the model, the project is not ready — and the honest answer at that point is usually a simpler report, not a pilot.

Assumptions · scoping

Reading a vendor's proposal critically

A proposal tells you more about the vendor's assumptions than their capability. Look at what they assume about your data quality. Look at whether integration is scoped or waved at. Look at the timeline for the first demonstrable output, because a first delivery in month four means you spend a quarter with nothing to judge.

And look at what happens if the estimate is wrong, because that clause reveals who carries the risk. None of this is specific to Belgium, but the market here has enough vendors that a critical read is worth the hour.

Timing · monitoring outcomes

A quiet queue, and the four hours it bought

A single interface between two systems ran cleanly for eleven months, then began to slow. The queue that carried its messages filled silently while a downstream service answered late, and nothing in the dashboard reacted — the process had completed, the job had reported success, and every alert stayed green.

What eventually surfaced the problem was a reconciliation report that counted records in and records out every fifteen minutes. It found the divergence before a customer did, four hours after it started. The strongest thing we added to that stack was not a monitor — it was a rule that every interface has to know what its own success means.

Before you write us

Questions these notes tend to bring up

Do you publish these as articles somewhere we can subscribe to?: No. This page is the library, and it grows when a project teaches us something worth writing down. If you want to be told when a new note is added, the simplest thing is to send us a line and ask.
Can we talk to the team that actually worked on these problems?: Yes — the delivery team takes the call, not a sales desk. Reach us during working hours, Monday to Friday, and we will bring someone who has shipped this kind of work to the conversation.
Do you apply these notes to businesses outside the maritime sector?: The maritime and logistics world is where these notes were earned, but the patterns — sequencing a migration, monitoring outcomes, keeping an interface you control — read the same for many Belgian industrial clients. We usually say so plainly when the fit is only partial.
How do we know which note applies to the problem we have?: Describe the symptom, not the solution — the number that looks wrong, the report someone rebuilds by hand, the interface that only fails on Fridays. From that we can usually point at the one note that overlaps, and what the first four weeks would look like.

Bring us the problem, not the specification

Send us a description of what is going wrong or what you want to run better, and the delivery team will answer. If a note here is close to your situation, mention it — that usually makes the first conversation shorter.

Send us your requirement See our service lines