Aviation SMS Provides Structure to Safety Initiatives

An aviation safety management system (SMS) provides service providers with risk management processes that are:

• Globally accepted by the aviation industry;
• Structured and documented to ensure repeatability;
• Implemented organization-wide; and
• Monitored internally and often externally to assure compliance.

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).

Related Aviation SMS Articles

• How to Identify Hazards and Assess Risks in Aviation SMS
• Difference Between Hazards, Risks & Control Measures in Aviation SMS
• What's the Difference Between Hazards and Risks in Aviation SMS

SMS Implementations Are Unique

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:

• Size of operator;
• Complexity of operations;
• Aviation industry segment (fixed wing vs rotor wing; scheduled vs charter; maintenance, etc.)  and
• Geographical/political environment.

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:

• Distractions;
• Fatigue;
• Lack of communication; and
• Stress.

So let's summarize quickly before moving into a deeper topic. An aviation SMS' Safety Risk Management (SRM) component includes your

• system description;
• expected operational hazards;
• reasonable and credible risks to your operations should a hazard manifest itself; and
• risk control strategies to either detect, prevent, or correct the expected risk.

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:

• What happens when the organization changes?
• What happens when the environment changes?
• How does the organization ensure continued safe operations after these changes?

Related Articles on Management of Change in Aviation SMS

• What Is Management of Change in Aviation SMS
• 4 Essential Tips for Management of Change in Aviation SMS
• What Are Best Practices for Change Management in Aviation SMS

Aviation SMS Changes Organizational Attitudes and SRM Activity Levels

As the environment changes, the aviation SMS must;

• recognize the change;
• evaluate how change affects safe, efficient operations;
• analyze operational risk for acceptability; and
• determine whether additional mitigation measures are warranted.

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."

Interfaces in Management of Change

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

• contractors,
• security and emergency support teams;
• subject matter experts and
• regulatory agencies.

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

Related Articles on Management of Change in Aviation SMS

• Understanding Management of Change in Aviation SMS
• Most Important Elements of Change Management in Aviation SMS
• Relationship Between Management of Change, SA Process, and SRM Process

Interfaces Uncovered During MOC System Analysis

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.

Systems Analysis Is First Stab at Interface Identification

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:

• Operating Environment;
• Personnel;
• Equipment; and
• Facilities.

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.

Related Safety Risk Management (SRM) Articles

• 4 Elements of Safety Risk Management (SRM)
• What Are Important Activities in Safety Risk Management (SRM)?
• Best Safety Risk Management Practices for Aviation Maintenance

Interfaces in MOC Hazard Analysis and Review

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':

• Risks associated with hazard related consequences;
• Risk controls and their perceived effectiveness;
• Risk acceptance and review dates; and
• How the new change will affect the system under review.

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.

Why Document Interfaces Extensively in SRM Design?

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:

• Education as to the importance of interfaces in aviation risk management; 
• Tools to efficiently document, track, and review interfaces as operations are affected by related hazards;
• Effective regulatory oversight to stress the importance of interfaces in aviation risk management.

Why Interfaces Need More Attention in Aviation Risk Management Practice

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.

Related Aviation Risk Management Articles

• What Is Reactive Risk Management (Why It’s Essential for Aviation SMS)
• How to Practice Reactive, Proactive, and Predictive Risk Management in Aviation SMS
• Going From Reactive to Predictive Risk Management in Aviation SMS

Final Thoughts on Interfaces in Management of Change

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.