Aviation Safety Management System Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the hazard chain keep getting built as separate tools?

Because each piece is bought or built at a different time by a different person solving a different immediate problem. Reporting arrives first because somebody needed a form. Investigation lives in documents because that is what investigators already used. The risk register is a spreadsheet the safety manager built and now maintains. Corrective actions go into whichever tracker the quality team already had. Nothing is wrong at any single step, and the whole is unauditable.

The specific breakage is identifiers. The report has a number, the investigation has a filename, the risk has a row, and the corrective action has a ticket. Nobody can move from one to the next without a person who remembers. When that person is on leave during an audit, the chain does not exist.

The fix is not a bigger tool, it is one identity carried across the whole lifecycle. Occurrence, investigation, hazard, risk assessment, mitigation, corrective action and effectiveness verification are distinct objects with real relationships, not statuses on a ticket. Ask a developer to draw the model before you talk about screens. A team that has done this separates those seven and asks early whether a hazard can carry multiple assessments over time. A team that draws incidents with a status field has built a helpdesk, and you will discover it in front of an auditor.

The safety work at most operators is genuinely good. What breaks is the record, and an auditor cannot see safety culture. They can only see whether the record holds together.

What goes wrong when the existing risk register gets migrated?

This is the largest hidden cost in the category and it is not engineering. A register with a decade of history has been scored inconsistently, because the matrix was revised twice, the definitions of severity shifted, and different safety managers applied them differently. Some rows are hazards, some are occurrences, and some are corrective actions that were entered as risks because there was nowhere else to put them.

Import that unchanged and every trend line you produce afterwards is meaningless, because a score from 2018 and a score from 2024 do not mean the same thing. Worse, the new system lends them an authority the spreadsheet never claimed.

Two decisions make this manageable. Migrate open items plus the last two years fully structured, and keep the older archive searchable rather than scored. And pin every imported assessment to the matrix version that produced it, including an explicit entry for legacy where the version is unknown. That honest label is worth more in an audit than a clean looking number nobody can defend.

Budget somebody's time for the classification pass. It is a safety manager decision, not a data task, and it cannot be delegated to the development team. Operators who skip it spend the following year explaining why their risk profile appears to have changed shape on the day the software went live.

Why do flight data, occurrence reporting and audit feeds break after launch?

Because they are periodic imports from systems owned by other departments, and periodic imports fail politely. Flight data monitoring events arrive on a cycle from a specialist tool. Maintenance events come from the engineering system. Occurrence data may go outbound to a regulator in a prescribed format. Customer audit findings arrive as documents.

The recurring failures are identifier drift and format drift. Aircraft registrations get reformatted, employee identifiers change after a payroll system migration, and event category codes are renamed upstream without anyone telling the safety office. The import continues to run and simply stops matching, so a feed that was contributing a third of your data quietly contributes nothing. Nobody notices, because a reduction in reports looks like a good month.

Regulator submission formats break differently: they are prescriptive and they change, and a rejected submission that returns an error to an unmonitored mailbox is a compliance gap rather than an inconvenience.

Put every feed behind a visible last success date and an expected volume range, and alert when the count falls outside it rather than only when the job errors. Hold unmatched records in a queue with an owner instead of discarding them. And treat regulator submissions as acknowledged or not acknowledged, never as sent.

What happens when effectiveness verification and control mapping are not covered?

These are the two omissions that separate a safety management system from an action tracker, and both are usually cut for schedule.

Effectiveness verification is the one an auditor is really probing. A corrective action gets marked complete when somebody issues a notice or updates a procedure. Whether the risk actually reduced is a separate question that almost nobody asks, because asking it means returning to the indicator months later. Make it a required, scheduled step with its own owner and date, tied to a measurable indicator where one exists. If the mitigation for a ramp damage trend was a new marshalling procedure, the check reruns the damage rate for the following quarter using the same query. Where no metric exists, it is a documented verification with evidence attached.

Control mapping is the second. A ground handler is audited by an industry ground operations programme, by every airline customer with its own protocol, by the airport and internally. One control in your organisation satisfies questions in four protocols, and without a many to many mapping your quality team re-evidences the same controls in four formats every year. That is the single largest avoidable workload in an audited aviation organisation, and it is invisible in a feature list because every product does audits.

Should you build custom or configure what you already own?

If you hold a single certificate with modest report volume and one or two audit programmes, configure Ideagen Coruson, Ideagen AQD or Vistair SafetyNet properly and put the difference into a safety manager. Those products encode a great deal of accumulated aviation practice and will get you to a compliant system faster than any build. Baldwin Aviation is worth considering where you want service alongside software rather than a platform to run yourself. We tell operators this regularly and it costs us work.

The case for building is about organisational shape rather than features. A group holding several approvals across airline, maintenance and ground operations, where each needs its own risk instrument and taxonomy but leadership needs one consolidated picture, is a structure packaged products handle awkwardly. A ground handler carrying twenty customer audit protocols is another, because the control mapping is the actual workload and no product will map your controls for you.

The clearest signal is a serious parallel spreadsheet running alongside a purchased system. That spreadsheet is not a workaround, it is a requirements specification, and it is describing exactly what the product could not hold.

How do hidden costs get into the quote?

Audit protocol count is first. Each mapping is real analysis performed with your quality team, not a configuration import, so a quote priced around two protocols does not stretch to twenty. Ask for a price per protocol and ask who does the analysis.

Multiple certificates under one group is second, because it means separated data with shared controls, and that separation touches permissions, reporting and every consolidated view.

Offline audit and inspection execution is third. Working on a ramp or in a hangar with no usable connection is genuine mobile engineering, not a responsive web page, and it includes conflict resolution when two inspectors sync the same checklist.

Regulator submission formats are fourth, prescriptive and subject to change, so budget them as recurring maintenance.

Risk register migration is fifth and largest, covered above, and it is the item most often priced as a data import when it is actually a series of safety manager judgements.

What separates a safety management build that works from one that fails?

The ones that work make reporting take under ninety seconds with free text first, and apply classification afterwards in the safety office. Report volume is the single biggest determinant of whether the system works at all, and a form with twenty two mandatory fields opened on a phone at the end of a night shift produces silence. An assistive model proposing a category and contributing factor tags from the narrative, for a human to accept or reject, is the one place automation genuinely earns its place here. Automated risk scoring is not, because the assessment is a judgement the accountable manager owns and must defend.

They version the assessment instrument. Matrices, scales, tolerability bands and escalation rules are configuration, and every assessment records which version produced its score, so revising your methodology does not silently rewrite three years of trend data.

They implement confidentiality as structure rather than policy. Identity known to one named role, access to it logged, and the reporting population told the log exists. Safety systems fail on trust before they fail on features.

And they settle ownership before kickoff. You should own the repository, the infrastructure accounts and the right to move to another firm. At Digital Heroes the client owns the code from the first commit. This system holds regulatory evidence spanning years, and losing access during a certificate renewal is not a risk worth carrying to save a negotiation.