Port operations platform: what to unify at a support base

Monday, seven in the morning. A client of the base calls to ask how many of their contractor's people are inside the site. The gatehouse opens the day's spreadsheet, the HSE team looks for open permits to work in a paper folder and the quality department tries to remember which email brought last week's non-conformity. Each department holds a piece of the answer, stored its own way, and nobody can put it together before the phone rings again.

This article shows what a port operations platform needs to bring together at a support base, what stays in the WMS and the ERP, and in what order to roll out the modules. In the middle you will find a checklist per process to map your base as it works today. If the most urgent pain is a paper permit to work, start with the article on the digital permit to work, which covers that module in detail.

What is a port operations platform?

A port operations platform is a single system where the support base runs its field processes, such as permits to work, gatehouse control, training, non-conformities, maintenance and overtime, on one shared registry of people, companies and locations. Platform here means the software, not the oil platform the base serves.

Brazil's Law 12.815/2013, known as the Ports Law, defines a port facility as a facility, inside or outside the organized port area, used to move passengers or to move or store goods carried by water. An offshore support base fits that definition: it receives vessels, stores cargo and has people from several companies coming and going every day, each company with its own rules and documents.

What sets a platform apart from a collection of systems is the registry. When the gatehouse, the permit to work and training control all look at the same person record, an expired course shows up everywhere at once. On the operations platform for a port support base that we have kept evolving since 2019, every new module reuses that registry, and the database now has more than 160 tables.

Why do separate systems per department leave the base without answers?

Separate systems leave the base without answers because each department keeps its own part of the information, while everyday questions cut across several departments. Who is inside the base right now? Which permits are open? Is this contractor's training up to date? Those were the questions the base in our case could not answer quickly. The permit to work was a paper form that travelled around collecting signatures, the gatehouse logged contractors in a spreadsheet and the quality department received non-conformities by email.

Brazil's port safety rules assume this information flows. The NRs are the regulatory standards on occupational safety and health issued by the Ministry of Labor and Employment. NR-29, the standard for port work, applies on board and ashore, at ports and at public or private port facilities, inside or outside the organized port. Item 29.4.1 requires the port operator, the service taker and the employer to draw up and implement a Risk Management Program (PGR, in Portuguese) under NR-01, and to exchange information on risks that affect port operations with the port administration and the port labor management body (OGMO). Item 29.4.6 asks for procedures available to workers on safe access to vessels, cargo handling, confined spaces and dangerous cargo, among others.

NR-01, which covers occupational risk management, completes the picture. Under item 1.5.7.1, the program must include at least a risk inventory and an action plan. Item 1.5.5.2.2 calls for a schedule, ways of monitoring and ways of measuring results for each prevention measure. A non-conformity handled by email, with no owner or due date on record, is hard to follow up and even harder to show in an audit.

Neither standard requires software. What they ask for is information that is organized, current and available to the people doing the work. With one spreadsheet per department and a paper folder, that depends on the memory of whoever looks after each file.

What belongs on the platform and what stays in the WMS and the ERP?

The platform takes what happens in the field and has no home in the corporate systems: releasing work, letting contractors in, handling deviations, maintaining the base's assets and internal approvals. Inventory, warehouse, finance and billing stay in the WMS (warehouse management system) and the ERP, and the platform reads that data when it needs it instead of copying it.

The most important row in the table is the last one. An operations platform does not need to replace the WMS or the ERP, and trying to do so stretches the project without fixing what hurts in the field. In our case, the dashboards read data straight from the WMS database and show the warehouse operation without anyone typing anything again.

Berth planning and billing the base's clients also tend to stay out of the first scope, since they usually have their own systems and processes. They can be integrated later, once the registry and the field modules are stable.

What does the platform need to control in each process?

In each process, the platform needs to record who asked, who approved, based on what data and when, always using the same registry. The list below follows the process groups of a support base.

To use the list, take one process at a time and answer each item with what exists today: a system, a spreadsheet, paper or nobody. The shared registry group comes first on purpose. If it stays scattered, each new module will create its own list of people, and the platform turns into several systems behind the same login screen.

Two items are often missing from requests and are missed later. The first is contractor access. At the base in our case, each contractor company has access limited to its own workers, documents and requests, and the gatehouse checks on screen whether the company is cleared. The second is enforcing permissions on the server. In a full security review of that system, we mapped route by route what each profile can do and fixed actions the screen hid but the server accepted. The more profiles and modules a platform has, the more it pays to repeat that review from time to time.

In what order should you roll out the modules?

The order that works best starts with the most critical safety process, builds the shared registry alongside it and adds one module at a time. That is how the platform in our case grew: the permit to work was the first flow to leave paper behind, and the other modules came as the operation asked for them.

1. List the base's processes and where each one lives today. The checklist above works as a script for that conversation with each department.
2. Pick the first module by risk and by pain. At support bases, it is usually the permit to work or the gatehouse.
3. Build the registry of people, companies and locations together with the first module, including training and expiry dates. Every other module will use it.
4. Define the profiles per department with the people who run them: HSE, gatehouse, maintenance, quality, supervisors and contractors.
5. Put the first module to use in one area or one shift, fix what got stuck and then extend it to the whole base.
6. Connect data that already lives in other systems, such as the WMS, through read-only integration before you think about migrating anything.
7. Add the next modules one at a time, such as non-conformities, work orders, overtime and management of change, always on the same registry.
8. Review each profile's permissions whenever a new module goes live.

The system has to work on a phone, because the gatehouse, the yard and the quay are far from the office. The platform in our case is accessed through the browser and installed on the phone as an app. We build this kind of project as custom web systems. For the gatehouse in detail, with a checklist for releasing a contractor from registration to exit, see the article on third-party access control.

What if the base has many contractors or an old system?

With many contractors, the way forward is to give each company its own access instead of putting everything on the gatehouse. The company registers its workers, uploads documents and follows its requests, seeing only what belongs to it, while the base approves and checks. There are fewer emails going back and forth, and it is clear who is responsible for keeping each document current. For an industrial gatehouse with scheduling and QR badges, see also the industrial access control case.

When the base already has an old system covering part of the processes, the question is whether it becomes a data source or gets replaced. If the system works and its database is reachable, the platform can read from it, as it does with the WMS in our case. If it holds the operation back and nobody can change it, compare the options carefully. The article on legacy system modernization has a decision matrix for that choice.

Areas without signal on the quay or in the yard call for another design decision: what has to work offline and how records sync when the signal returns. The answer depends on the base's locations and goes into the design of each module.

Then there is the team that already has its own way of working. Starting with the process where the system takes work off the user's plate tends to go well, like the gatehouse that stops hunting for names in a spreadsheet or the supervisor who stops chasing signatures on paper.

When is a single platform not enough?

The platform organizes and records the processes, but the base's safety rules come from outside it. The risk management program, the procedures NR-29 requires and the risk assessment for each activity remain the responsibility of the company, its safety department and the HSE team. If a procedure is out of date, the system will only make it faster to follow. The review comes first.

Nor does it take the place of the corporate systems. Inventory, finance, payroll and billing have their own tools, and the platform's job is to read what it needs from them. When the request starts to include everything, go back to the table in this article and separate field processes from what already has an owner.

The platform connects to other routines we have covered on the blog. Coordinating incidents, from the first call to close-out, is the subject of the article on the emergency response system. Ongoing care of a system that has been running for years, including security reviews like the one in our case, is part of support and modernization.

If your base still answers the day's questions with one spreadsheet per department, boosting.tech is a custom software company that builds this kind of platform from the processes your team already has, one module at a time. We can look at your case in a free diagnostic conversation. The details are in custom web systems.