Somebody has to type it. It shouldn’t be your chief engineer.
A new system arrives empty, and the data it needs often doesn’t exist anywhere digital: it lives in OEM manuals, drawings, paper records, and the heads of the people who run the operation. A new-build vessel or terminal has no history to migrate at all. Operational Data Building turns those sources into structured, standardised data the system can enforce — built by people who know what a job interval and a criticality grade mean. We build data the way we build software: to a standard, with sign-off, meant to last.
When you need this
No digital source? That’s the starting condition.
Data building is for the situations migration can’t touch — when there is nothing structured to move.
- Source data exists only in manuals, drawings, or OEM documents
- A new vessel, terminal, or asset is being commissioned with no digital history
- Equipment registers and asset hierarchies have never been built
- Records live on paper or in scattered, unstructured files
What we build
The data your system runs on.
Equipment & maintenance
Equipment hierarchies to component level, maintenance job libraries with intervals and scopes, and criticality grades.
Spares & stores
Spares catalogues linked to equipment by bill of materials, and standardised store masters.
Tanks & terminal data
Tank masters, strapping tables, product specifications, and asset registers.
Documents & registers
Document registers with numbering schemes, metadata, and revision baselines.
The method
Five steps from paper to production.
Source & gather
Collect the truth, wherever it lives.
We gather the sources — OEM manuals, drawings, maker documentation, old records — and sit with the people who know the equipment, so the knowledge in their heads is captured instead of lost.
- OEM manuals, drawings, and maker documents collected
- Existing records and old files mined
- Your team’s knowledge captured, not lost
Structure
One hierarchy, one convention — designed first.
Before a single record is entered, we design the equipment tree, the numbering scheme, and the naming and coding conventions, and agree them with you — so everything built afterwards follows one standard.
- Hierarchy and numbering designed before entry
- Naming, coding, and unit conventions agreed
- Criticality and grouping rules set
Build
Entered once, entered right.
The dataset is built systematically by people who know what the fields mean — a job interval, a bill of materials, a strapping increment — with quality checks running during the build, not after it.
- Built by people who know the domain
- Quality checks during the build
- Progress visible throughout
Validate
Checked by the people who’ll live with it.
Your engineers and superintendents review the built data in structured passes, corrections are applied at source, and the dataset is formally signed off before it goes anywhere near production.
- Review passes with your technical team
- Corrections applied at source
- Formal sign-off before load
Load & handover
Into the system, ready to run.
The signed-off dataset is loaded and verified in the system, and the conventions are documented and handed over — so the data added next year follows the same standard as the data built today.
- Loaded and verified in the live system
- Conventions documented for the future
- Day one, ready to run
When the data already exists
Building is for data that was never structured. When your records already live in a legacy system or in spreadsheets, the job is moving them safely — that is Data Migration, and the two often run together in one implementation.
Explore Data MigrationQuestions, answered
What evaluators ask first
Where does the data come from?
OEM manuals, drawings, maker documentation, old records — and structured interviews with the people who know the equipment, so nothing lives only in someone’s head.
Can you build a PMS database from scratch?
Yes. The equipment hierarchy, maintenance jobs with intervals and scopes, criticality grades, and the spares links — built to one convention and signed off by your technical team.
We’re commissioning a new vessel or terminal — can you prepare the data?
Yes. New builds are the classic case: there is no history to migrate, so the operational dataset is built from the maker documentation and commissioning records.
How do you keep it consistent across a fleet or site?
Conventions are designed first and applied throughout, and they’re documented at handover — so future data follows the same standard.
How does this relate to data migration?
Migration moves data that exists; building creates data that never did. Most implementations need some of both, and we run them together.