An aviation safety management system (SMS) provides service providers with risk management processes that are:
These structured, repeatable processes are custom-designed to satisfy each company's "operational risk profile (ORP). An ORP is a list of hazards, risks, and mitigation measures unique to a certain operator based on their aviation industry segment, size, and operating theater (where they operate).
While the high-level structure of every aviation SMS remains consistent with each SMS implementation, the "one-size-fits-all" description will never apply to any aviation SMS implementation. Let's face it: companies are unique.
Numerous factors help account for these SMS implementation variations, including:
Due to these logical variations, the "operational risk profile" will remain understandably different for each organization and may be unique across different divisions within the organization. For example, a common scenario is an airline that performs maintenance in-house. Maintenance operations encounter different hazards than flight operations. We do not mean to imply that there will not be common, shared hazards, such as those related to human factors, including:
So let's summarize quickly before moving into a deeper topic. An aviation SMS' Safety Risk Management (SRM) component includes your
The Safety Assurance (SA) component centers around "system monitoring."
Question: What are you monitoring?
Answer: Your system design documented in the SRM process.
As your organization fulfills its mission, system monitoring activities are carried out by employees, contractors, regulatory agencies, and other stakeholders. Whenever anomalies are detected, they are expected to be reported via implemented SA features, of which the most common include the safety/hazard reporting system and safety assurance audits.
The operational risk profile (ORP) can be considered "system design" or SRM documentation. After all, these risk management activities fall under the "design phase" of your SMS, which we fondly refer to as the "safety risk management" component of an aviation SMS implementation.
Now, let us consider:
As the environment changes, the aviation SMS must;
Initially, new SMS implementation may need to "consciously and purposely" focus on these "organizational changes;" however, as time passes, these processes and inter-related activities become engrained within the organization's culture. As time passes, these safety processes are intended to eventually become "the way we do business."
Each operator with a regulatory-compliant SMS must have a repeatable, documentable process to manage change.
Whenever an organizational change is considered, such as modifying an ineffective risk control, safety management teams must consider "interfaces." Per ICAO Document 9859, 4th edition:
Interfaces can be internal (e.g. between operations and maintenance, finance, human resources, or legal departments), or they can be external (e.g. other States, service providers, or contracted services). States and service providers have greater control over any related safety risks when interfaces are identified and managed. Interfaces are defined as part of the system description.
ICAO Doc 9859, section 1.3.3 Interfaces
In a simple Management of Change (MOC) process, managers will always be asking themselves: "Who are the affected parties regarding this change?" In the majority of cases, these "affected parties" are your interfaces, i.e., internal departments within your company as well as external organizations, such as
Affected parties in your MOC provide a quick, yet incomplete analysis of affected interfaces within a MOC project. The "System Analysis and Description" of affected elements provide another opportunity to ensure interfaces are not overlooked during the MOC process.
The "System Analysis & Description" can be viewed as your second dive into identifying potential, "affected parties" resulting from the proposed change. This process is easier said than done. ICAO has identified the common aviation-industry challenge of how to best manage interfaces among "dissimilar interacting systems." See ICAO Document 9859, 4th ed. Section 1.2.1.2
Risk management teams are expected to conduct a system analysis in every accepted Management of Change (MOC) project. If a systems analysis is not your organization's MOC modus operandi, your SMS processes require a review.
A universally-recognized, systems analysis template accepted by regulators becomes most useful to satisfy MOC regulatory requirements. Industry-accepted templates remove much of the guesswork associated with documenting your MOC projects.
For new safety managers, an MOC template reduces anxiety and provides assurance to the safety team that they don't have to recreate the wheel. Templates also benefit the process by providing an industry-accepted checklist to document your change management activities. In the case of the SMS Pro database, the embedded template provides ample opportunities to consider the role of interfaces in the proposed change.
The system analysis and description created in Phase 1 of your SMS implementation facilitate brainstorming. Your initial system description review most likely begins at the beginning of your Operational Risk Profile created during the proactive hazard analysis review. As the MOC project team reviews the system description, they are encouraged to envision proposed changes to:
These above elements should be considered for every major organizational change. As you describe these affected elements and their role in the proposed change, you will often uncover additional interfaces previously overlooked in the initial "Affected Parties" section of your MOC template.
Will deeper analysis always bear fruit? Probably not, but there is a higher likelihood of discovering more interfaces than had we ignored this advice.
Remember: MOC projects are part of the SRM (Safety Risk Management) design process. SRM is the design aspect of the aviation SMS, while Safety Assurance (SA) monitors the design for effectiveness.
Hazard analysis and review should remain a primary objective as the change management team considers how their proposed change may affect the operating environment, personnel, equipment, and facilities. This MOC hazard analysis process reviews known, documented hazards and evaluates whether existing risk controls are adequate.
New hazards may be discovered during the hazard analysis process. This provides an excellent opportunity to shore up your risk management system's (RMS) design documentation. Similarly, safety management teams will learn that their hazard register may require updating as they evaluate existing assumptions regarding hazards':
Some changes may require subject matter expertise, such as changing aircraft weight and balance configuration or flying heavy aircraft on short runways near mountainous terrain. Other changes may require regulatory approval or input from an equipment manufacturer. These are the interfaces that you will be documenting in your MOC project as they provide inputs or stimulate review throughout your MOC projects.
This hazard review process must have some structure in order to provide consistent, reliable results. Unfortunately, most operators don't possess a thorough, sustainable process to easily review and document their hazard analysis activities. This challenge can only be overcome with an integrated aviation SMS database designed specifically for this task or using another quality management tracking system.
I don't believe that exhaustively defining the benefits of your interfaces will add much additional value to this discussion. Let's get to the point--where the rubber hits the road.
Up to now, we've discussed what are interfaces and why they should be reviewed in your system description during both reactive and proactive risk management processes. I'm guessing that 20-25% of operators are competently performing this task, and I'm being generous with my estimate. The reason that interfaces are glossed over in a perfunctory manner is that operators lack:
Having interfaces integrated deeply into your aviation SMS data management strategy pays huge dividends. I'll not be able to cover each instance, but two quick examples will highlight the importance of comprehensively defining and reviewing interfaces in your aviation SMS.
Example 1: During each Management of Change (MOC) project, system analysis and system description are used to define existing and potentially unidentified hazards. For example, in the SMS Pro database, there is a section in the MOC labeled "Associated Hazards Related to Change." This section boasts a drag-n-drop interface where managers drag related hazards into the project.
Great utility comes from having these highly integrated hazards linked in the MOC project. First, managers can review each interface and determine the role they may need to play in managing the MOC project. Do they provide regulatory guidance or are they, subject-matter experts? By having a list of interfaces, along with relevant contact information, managers can easily communicate with these interfaces as they entertain proposed organizational or procedural changes.
Example 2: This second example requires us to journey to the Safety Assurance (SA) monitoring activities. Suppose a pilot submits a safety issue concerning weight and balance limits. We are in "reactive risk management mode." To evaluate whether the pilot's concerns are valid, the safety team must seek information from qualified subject matter experts that were defined in the SRM process.
Using SMS Pro as an example, safety managers may classify issues from hazards populating the hazard register. Directly in the Issue Manager, safety teams can easily see the affected interfaces and contact them when the situation is required. In a few cases, reported safety issues may prompt new "Management of Change" projects. Having all your interfaces documented in your risk management system adds obvious value, especially when you need to contact them and document your interactions with these interfaces during the change management process.
Interfaces affect every aviation service provider. Unfortunately, there don't seem to be many sophisticated techniques to capitalize on this information in extant aviation risk management documentation. Once again, SMS Pro is leading the pack in refining modern aviation SMS data management strategies.
If your processes are not simple, they will never become sustainable.
Documenting interfaces does not have to be difficult; however, you need more than just a name, which is what the majority of operators provide when discussing interfaces. Having an integrated data management system such as SMS Pro facilitates the overwhelming data management nightmare faced by thousands of aviation safety professionals across the globe.
Hopefully, this article will shed some light on how to use interfaces more effectively in your SMS. If you are a current SMS Pro user and you don't see "interfaces" in your proactive hazard analysis tool (PHAT), contact tech support and we'll turn it on for you. This is a very sweet functionality. I know you will be impressed, as this SMS Pro integration is especially impressive!
To see SMS Pro in action, check out these short demo videos:
Last updated in August 2024.