IBM MAS for terminal and airside operations at a UK regional airport
Two asset systems, one regulated estate, and an audit cycle already in the diary. Nine months to go-live on IBM MAS 9, and the design was set less by what the airport wanted to build than by what its safety case and its closure windows would allow to happen.
The main character
Not the platform. A safety case in force, a closure window measured in minutes, and a regulator with a date already in the diary.
The constraint, in three parts
Three lines this programme was not allowed to cross
The airport ran two parallel asset systems: a legacy Maximo 7.x instance for airside ground assets, and a separate facilities management tool for terminal building services. Engineers carried two devices, work and parts data did not reconcile, and the CIO had ruled out a third tool to fix a problem caused by having two. Three constraints then decided the design.
- A safety case in force
- Airside assets sit inside a safety case that stayed in force while the work happened, so nothing could change in a way that weakened the evidence trail behind it.
- Often read as a document that can be tidied up after consolidation. That is the comfortable sequence, and it was not available here.
- A working window measured in minutes
- Work on airside assets happens inside a permit and a closure slot. Neither is advisory and neither extends, so the window sets how much of it may be spent on a system rather than on the asset.
- Often read as a performance target for the mobile app. It is the design constraint on the mobile flow.
- An audit cycle already in the diary
- The regulatory audit cycle was scheduled before the programme started, so the evidence model had to be right on the first day the platform was live rather than improved into shape over the following year.
- Often read as something a reporting layer added afterwards can rescue.
The boundary, row by row
What is allowed to cross, which way, and who signs
This ledger is the design. Every argument on the programme, from the length of a mobile flow to how a deferral is recorded, was settled by deciding which side of a line something sat on.
| What moves | From | Direction | To | Signed by |
|---|---|---|---|---|
| A work order for an airside asset | MAS Manage | ← | A closure slot, with a valid permit attached | Airside supervisor, at dispatch |
| A permit | The permit system, which stays the system of record | → | A reference on the Maximo work order | The permit authority, in the permit system |
| A building management event | BMS and SCADA, agreed event classes only | → | A prioritised work order with an SLA clock | Terminal engineering, who agreed the class list and the priorities |
| Evidence from the field | Maximo Mobile at the asset, offline where coverage is poor | → | The asset record | The engineer who did the work |
| A deferral | The planner or supervisor, at the moment of deferral | → | The deferred work register, carrying reason and approver | The named approver for that criticality band |
| Cost | MAS Manage | ← | Finance, as purchase order, invoice and cost centre | Finance, on their own approval route |
What never crosses, by decision
- Permits are never issued, amended or approved inside Maximo.
- Dispatch never proceeds on an expired permit or an unconfirmed closure slot.
- Unclassified building management events never raise work, because a queue nobody triages is worse than a phone call.
- A deferral is never reconstructed for an audit after the event, and no status change is written on behalf of another engineer.
- Maximo never becomes a second set of financial books.
Two jobs, traced
Who decided, and what got written where
A terminal fault and an airside inspection cross different lines and are signed by different people. Both end with a record written by the person who did the work, at the asset, rather than typed up afterwards.
A terminal building services fault
Event to evidence
- Signal
- A building management system event on terminal plant, inside an agreed event class.
- Decision
- The duty engineer accepts the work order at the priority that class carries.
- Written to Maximo
- Work order with an SLA clock, attributed to the concession area it affects.
- Decision
- Work done, evidence attached, record closed by the engineer at the asset.
- Written to Maximo
- Completion, photo evidence and time on tools, against one asset record.
A planned airside inspection
Due date to compliance pack
- Signal
- A planned inspection falls due on an asset inside the critical-asset register.
- Checked by Maximo
- Permit reference and closure slot validated before the job can be dispatched.
- Decision
- The airside supervisor confirms the permit and the slot, and releases the job.
- Decision
- The engineer works inside the slot, records at the asset, and leaves before it closes.
- Written to Maximo
- Inspection record against the register, ready for the compliance pack without rework.
What the boundaries required
The platform, and what it talks to
One MAS Manage instance on Red Hat OpenShift replaced the legacy airside system and the terminal facilities tool, with corporate single sign-on giving an engineer one account across MAS applications. It was built in the order the lines demanded: register, then obligation, then platform, then the interlocks that hold the lines.
What each side of the diagram carries
- One register, one owner per asset
- Boarding bridges, baggage handling, runway and taxiway lighting, terminal plant and ground service equipment in a single hierarchy. Where the two legacy systems disagreed, the owning engineering team decided. Criticality and regulatory tagging were set with safety and compliance, not inferred from the hierarchy.
- Inbound, filtered
- Permit and closure slot references from the permit system, and building management events for agreed classes only, with SLA clocks tied to commitments the airport holds.
- Field execution
- Maximo Mobile for airside engineers, offline capable, with photo evidence and barcode lookup. Anything that did not have to happen at the asset was moved out of the flow.
- Outbound
- Purchase order, invoice and cost centre to finance. Inspection and certification records, planned against done on the critical-asset register, and the deferred work register, produced as routine output.
What we did not build
Three things left out, on purpose
On a regulated estate what you leave out is a safety judgement as much as a scope judgement, so each of these was agreed and written into the plan.
Permits rebuilt inside Maximo
Not attempted. Reimplementing a live safety control inside a platform that is itself being replaced concentrates risk in the wrong place. The boundary in the ledger holds instead.
Further MAS applications
Health and Scheduler were left to the managed service roadmap rather than pulled into a programme that already carried a regulatory date.
Condition-based maintenance analytics
Deferred. The condition feed was scoped to raise work reliably first. Using that history to change maintenance strategy needs several cycles of clean data before the conclusions are honest.
What consolidation changed, and by what mechanism
- The audit cycle passed with no findings on the asset management estate. The mechanism was the critical-asset list agreed with safety and compliance, and deferrals carrying a reason and an approver recorded at the moment of deferral.
- Planned maintenance compliance became a number rather than an estimate. Planned and done are now recorded against the same register, so the two can be divided.
- SLA performance is visible per concession area. Building management events arrive already attributed to the area they affect, which is what makes an aggregate figure decomposable.
- The duplicate facilities tool and its licences were withdrawn. Engineers carry one device and managers read one schedule, so the consolidation removed cost rather than adding a platform.
MaxIron continues as the managed service partner: monthly service reviews, a roadmap covering further MAS application uptake, and upgrade planning aligned to the IBM release cadence. The architects who designed the platform are still on the account.
What we would do differently
Three judgements we would make differently
We ran the asset register and the regulatory tagging as two consecutive pieces of work, register first. That held here because the audit date was far enough out to absorb it, but it makes the obligation feel like an overlay on the design rather than part of it. We would now bring safety and compliance into the first hierarchy workshop, so criticality is a property of the register from the beginning.
On a shorter runway to an audit date, consecutive would not have worked at all.
The permit interlock was designed in workshops and tuned during rollout. An enforcement rule that reads sensibly across a table behaves differently in the hands of a supervisor holding a slot that closes in twenty minutes. We would now pilot the order of checks with a small group of airside supervisors before it applies across the estate.
The rule did not change. The order the checks are presented in did.
Withdrawal of the duplicate facilities management tool was scheduled as "once cutover is stable", which is a condition rather than a commitment. Parallel tooling survives on that ambiguity, and every week it survives is a week the organisation maintains two versions of the truth. We would name the owner and the retirement date at the start of the programme.
The tool did go, and the licences with it. It went later than it needed to.
The engagement, in facts
- Sector
- Transport & airports
- Region
- United Kingdom
- Duration
- 9 months to go-live, ongoing managed service
- Scope
- MAS Manage, Mobile, BMS integration, regulatory reporting
- Versions
- IBM MAS 9 on Red Hat OpenShift
If you are running two systems on a regulated estate
Services and products in this engagement
Questions this consolidation usually raises
- Did the permit-to-work system get rebuilt inside Maximo?
- No, deliberately. The permit system remains the system of record for permits. Maximo holds the reference and enforces the dependency, so work cannot be dispatched without a valid permit and a confirmed closure slot. Reimplementing a live safety control inside a platform that is itself being replaced concentrates risk in the wrong place.
- Does the building management system feed create work automatically?
- It raises prioritised work orders for agreed event classes only. Which classes qualify, and at what priority, was decided with terminal engineering rather than taken as a default, because an unfiltered feed produces a queue nobody triages. Maximo integrations covers how we scope a feed of this kind.
- How much of the audit result was the platform?
- Less than you would hope. The audit cycle passed without findings on the asset management estate because the critical-asset list was agreed with safety and compliance, and because deferrals carried a reason and an approver recorded at the time rather than reconstructed afterwards. The reporting was straightforward because the data underneath it was already defensible.
- Would this pattern work for a port or a rail depot?
- It travels wherever a regulated estate is split across two tools and one of them is a facilities system. What changes is the regulator, the permit regime and the length of the working window. See Maximo for transport and airports, or the ferry operator upgrade for the same pressure inside a maritime operating calendar.
- Why is the airport not named?
- The operator asked us not to name them, and the detail that makes this account useful, the safety case, the permit interlock and the regulatory evidence model, is exactly the detail an operator does not want published against their name. A reference conversation is arranged under an NDA once a discussion is serious.
If you are running two asset systems on a regulated estate, the second one is costing more than its licence.
A fixed-price scoping engagement that produces a consolidation sequence, an approach to criticality tagging, and an honest view of which working windows the plan needs. If the answer is that your two systems should stay separate, we will say so.
Bring this and the first session can be concrete
- Both asset hierarchies, however inconsistent, and who owns each one.
- Your critical-asset list as the safety and compliance functions currently hold it.
- The permit regime, and the typical length of a working window on your restricted areas.
- Your next audit or inspection date, because that usually sets the sequence.
- The licence and support cost of the tool you would like to withdraw.