Logistics Management System
One picture of the movement, and one owner for every record.
Logistics work is planned, executed, constrained, approved and recorded in one governed system covering shipments and cargo, transport requests and routes, planning scenarios, fleet assets, marine movements and the operational exceptions that affect delivery.
A request becomes a plan, an allocation, a route and a berth.
Planners, movers, asset owners and port operators normally look at different copies of the same stale spreadsheet. LGMS puts the whole movement in one record, and every step it passes through leaves something the next step can rely on.
Request. Somebody needs something moved. The transport request records what, from where, to where and by when, and waits on a decision rather than on a reply.
Not checkable is not a pass.
Where a port has not declared the information required for a berth check, LGMS reports that the check cannot be completed. Missing control data is not interpreted as a pass.
The application is deliberately bounded. It does not perform route optimisation, demand forecasting or pricing, and it does not use generative AI to make operational decisions. Guidance is presented alongside the governed record and does not alter approval authority.
- Plan feasibility
- Constraints
- Scenarios
- Planning calendar
A constraint that makes a plan infeasible is surfaced before the plan is committed, not after it is issued.
- Resource allocation
- Fleet assets
- Operators
- Allocations
Double allocation is prevented by the database, so two plans cannot both believe they hold the same crane.
- Route restriction
- Versioned routes
- Corridor restrictions
- Movement check
The movement is checked against the route version in force, and the version is recorded with the check.
- Berth limit
- Port limits
- Berth finder
- Marine checks
Where a port has not declared a required limit, the result is reported as not checkable and the information gap remains visible.
Every governed record has a steward, a score and a separation of duties.
Quality is measured across eight dimensions, with the two that cannot be measured stated as not measured rather than scored optimistically. The person who submits a record cannot approve it, and the control is enforced independently of the interface.
Published is not the same as in force: a record released to consuming systems still waits for its effective date.
- Quality against a minimumEach domain sets a minimum quality, and a record states its score against that minimum rather than in the abstract.
- Not measured is shownIntegrity and conformity are reported as not measured where they are, instead of being counted as satisfied.
- Versioned and datedA record carries its version and the date it comes into force, so consuming systems know which one applied when.
Six areas that are built, and nothing that is not.
The application's own navigation, covering transport, transport management, planning, fleet, marine and master data. Every chip is a page that exists today.
Transport
Records govern shipments, cargo, required approvals and operational exceptions so logistics status is derived from the work actually recorded rather than entered as a standalone declaration.
- Shipments
- Approvals
- Exceptions
Transport management
Transport requests from the people who need something moved, and versioned routes with the corridor restrictions that apply to them, so a movement is checked against the route rather than assumed to fit.
- Transport requests
- Routes
Planning
Logistics plans with their activities, scenarios compared against each other, planning boards and a calendar, and the constraints that make a plan infeasible before it is committed.
- Logistics plans
- Scenarios
- Planning boards
- Planning calendar
- Constraints
Fleet and resources
Fleet assets and operators with their allocations, maintenance and inspections. The database itself prevents the same asset or operator being promised to two movements at once.
- Fleet assets
- Operators
- Allocations
- Maintenance
- Inspections
Marine and ports
Ports with their berths and the limits each one declares, and a berth finder that reports an unstated limit as not checkable rather than quietly passing it.
- Ports
- Find a berth
Master data and knowledge
Governed records with a named steward, a measured quality score and a separation-of-duties control, with guidance shown beside the record it applies to and its sources named.
- Governed records
- Domains
- Guidance
- Sources
Heavy lift, offshore cargo and the berth that has to take it.
Transport coordinators and planners, dispatchers, fleet managers, port administrators and project managers all work the same movement. The failure mode they share is a resource somebody else already promised, and a restriction nobody checked.
- Marine, heavy-lift and fleet role groups with external access
- The database prevents double-promising an asset or an operator
- Ports declare their limits; the berth finder reports the ones they have not
Correct anything rejected, then commit whole or not at all.
Select a dataset, download its template, upload and preview the data, correct rejected rows, then confirm and commit. Every rejected row is returned with the reason it failed validation, and only accepted records are committed.
- Twenty portable datasets across eight business domains
- Export-only sets distinguished from those that round-trip
- Data that LGMS writes itself is held apart from customer data
A record cannot be double-promised
Preventing an asset or an operator from being allocated twice is enforced by the database, not by a validation somebody can work around.
Not checkable is not a pass
Where a port has not stated a limit, the berth finder says the check could not be made. It never treats an absent constraint as a satisfied one.
Master data has an owner
Every governed master-data record identifies its steward, source, submitter and approver. Segregation of duties prevents the submitter from approving the same record.
Guidance decides nothing
Guidance is advisory. It does not approve, sign, close or otherwise change the governed record, and no generative component is used to make the operational decision.
More of what the application covers.
- Shipment lifecycle with every shipment shown by state
- Cargo held against the shipment carrying it
- Scenario comparison before a plan is committed
- Planning boards and a planning calendar
- Fleet maintenance and inspections
- Versioned routes with corridor restrictions
- Quality scored across eight dimensions per governed record
- Hash-chained audit behind every change
Movement, beside the systems that create the demand for it.
- PMSPMS: Procurement Management SystemPMS creates the requirement for movement; LGMS plans and executes the logistics activity.
- OPMSOPMS: Offshore Projects Management SystemOPMS governs offshore project execution; LGMS governs the transport and marine logistics that support it.
- SPIRSPIR: Spare Parts Interchangeability Record Management SystemSPIR governs the spares and materials whose movement and delivery are planned in LGMS.
- CVMSCVMS: Contractor / Vendor Management SystemCVMS governs the assurance position of carriers, freight forwarders and other logistics suppliers.
See LGMS with one of your heavy-lift movements.
Bring one movement with its cargo, its route and its berth. We will show the plan it enters, the allocation the database will not double-promise, and the checks it has to pass.