The Federal Aviation Administration’s (FAA) safety risk management (SRM) compliance requirement for System Description has one clear goal: establish the components of your operating environment’s
Despite the fact that the goal is clear, system description is too often skimmed over by safety teams during the initial implementation phase of their aviation safety management systems (SMS). This is a mistake.
Why is this element of SRM often skimmed over?
Just consider the following questions:
These are not easy questions. Part of the problem is that this element needs to be left intentionally vague in order for different service providers operating in different aviation industry segments, such as
Considering the breadth of the aviation industry as well as the size and complexity of these various operators, the operators required to implement formal SMS need to have flexibility in establishing their System Description. We will walk through and establish what you need to know in order to complete your System Description element as part of the FAA's system safety operation guidelines.
The FAA’s SRM System Description element is basically asking you to create an outline of your safety management system in terms of what is important:
The frustrating truth about the above points is the before mentioned vagueness. Understanding how to analyze and describe these points involves narrowing the language to terms that provide more guidance. Here is the important language that the FAA uses in their Advisory Circular, per the latest January 2015 release:
The above language synonyms are important to keep in mind as you describe your system. They can help you keep from “getting stuck,” by keeping important elements of System Description less vague.
System Description is the first step in the SRM process. It leads directly into the FAA's SRM Hazard Identification element, where hazards will be identified in each of the identified systems (SRR. Section 5.53(a)). The FAA defines the objective of System Description as, “To gain an understanding of the components and elements of operational systems, processes, procedures, and the operational environment.”
Does that clarify things? It’s extremely vague, and seems to almost say “describe everything.” It certainly doesn’t help me understand specifically what the FAA wants. Let’s break it down into terms that provide a much more specific understanding.
Using the language of the FAA, the primary goal of System description is to describe what resources and activities are needed to successfully mitigate hazards (i.e. “function”) in your operational environment. This goal may be accomplished by the following tasks:
System Description from this perspective is very straightforward.
Though the FAA’s Advisory Circle doesn’t seem to indicate it, the steps and requirements for fulfilling the System Description are simple and straightforward, though very time-consuming. The outcome is the creation of an operational risk profile that can easily feed your hazard register. This becomes a very important point when safety teams begin to list and document hazards that affect operations.
The system description becomes an incredibly important first step in the proactive hazard identification process. Why? As you start your system description, hazards will naturally surface from the exercise of documenting the systems. While safety teams are considering the systems that they must describe, this process of describing the system will serve as an inspiration for getting started with your hazard list, which will subsequently populate the hazard register.
In short: The process of System Description facilitates preliminary proactive hazard identification activities. The act of writing will cause managers to become inspired and hopefully, the activity will jog the memory and cause the "ah-ha" moment and say, yes, that is a hazard we need to document.
Part of the frustration with the FAA’s SRM description is the interchangeable use of “System” and “Systems”. Your “System” in the singular simply means your safety management system:
Your System is simply the conglomeration of everything that makes up your operational "safety program," including the risk management processes.
“Systems” in the plural is a vague word, but it basically amounts to your specific area of operations, such as:
If you were building a classification schema to classify hazards, these would be your "level 1 hazard categories.” The assumption is that different risk mitigation strategies may be used in different Systems. To maintain a logical format, hazard categories:
Your Model is the framework that you will use to analyze and describe each of your Systems. The two most common Models are:
Both models are thorough, however, the SHELL model may be superior for the purposes of System Description, though this is debatable.
Fulfilling the FAA’s SRM System Description components has four straightforward, though time-consuming, steps:
The outcome is that each of your systems has 4 (if SHELL) or 5 (if 5M) components, and each component lists the activities and resources that will be used to mitigate hazards in that hazard category.
In the previous section, I mentioned that you should document the system description and related identified hazards in aviation SMS software or another tool. If you are still documenting hazards in a spreadsheet, this is not a best practice.
Hazards listed in a spreadsheet are very difficult to track and associate with safety reports treated in your risk management processes. A better approach is to have an integrated hazard register that allows managers to easily associate identified hazards with:
Why is this important? If you wish to benefit from proactive and predictive risk management activities, you will want your safety data organized. System descriptions with the relevant hazards sitting in a spreadsheet will offer very little value to mature SMS implementations. You may get away with this in the early SMS implementation phases, but when it comes time to demonstrate continuous improvement or engage in predictive risk management activities, you will realize that your SMS data management strategy is severely lacking.
A better approach is to either develop an SMS database that has your hazards integrated into the system or to adopt a low-cost, commercially available SMS database. For smaller companies, this is a "no-brainer." Larger operators may already have quality management systems in place that can be extended to include their hazard register. If you need any assistance in this area, I can think of an SMS database that provides a complete, soup-to-nuts solution. It is called SMS Pro.
If you've come this far, chances are this information was helpful. The good news is we have much more guidance to offer in this free ebook that offers FULL coverage of what you need to know to comply with each element of the FAA's Safety Risk Management process.
Last updated January 2024.