Process bassed

Safety Risk
Managment
Safety.lec .
13-14
 Topics.

• The “standard” model of safety risk management/safety assurance.

• Process-based SRM/SA.

• Process-based SA.

• The risk management plan.

• The ERP as a component of the RMP.

• SRM/SA in the Real World.

• AC 120-92 relates SRM and Safety Assurance (SA) in the following way
(FAA, 2006, p. 10):
• Integration of Safety Risk Management and Safety Assurance.
• The safety risk management process provides for initial identification of
hazards and assessment of risk. Organizational risk controls are developed
and, once they are determined to be capable of bringing the risk to an
acceptable level, they are employed operationally.
• The safety assurance function takes over at this point to ensure that the risk
controls are being practiced and they continue to achieve their intended
objectives.
• Page 182 Figure 8.1 Safety risk management and safety assurance processes.

• Organizational risk controls are developed and, once they are determined to
be capable of bringing the risk to an acceptable level, they are employed
operationally.
• The description in the advisory circular begs questions that must be
understood before SRM/SA can be done. For example, what exactly is the
“system” that must be described, before one can accomplish SRM? What is
it, exactly, that we should be continuously monitoring in SA? Against what
standard should audits be accomplished in SMS? What should an SMS-
oriented investigation finding focus upon? How does one go about judging
that a control is ineffective?

• serious look at the very first question, concerning the system that must be
described, will lead us to the answers.

• What is a system? A system is a network of interdependent components

that work together to try to accomplish the aim of the system. A system must
have an aim. Without an aim, there is no system. The aim of the system
must be clear to everyone in the system. The aim must include plans for the
future. The aim is a value judgment. Deming, 1993, p. 50).
 In the discussion of quality in Chapter 3, frequent mention was made of
Deming, and it is not surprising that this giant of the quality discipline can
provide guidance to assist us in understanding how to do SMS.

Deming was a very strong proponent of the assertion that activities must be
clearly described as processes.

It is only through the exercise of process description that the true extent,
detail, dependencies, contingencies and outputs of an activity can be
understood.

In Deming’s definition of system above, processes comprise the “network of

interdependent components that work together to try to accomplish the aim of
the system”. SRM/SA in a mature SMS is based upon well-designed process
descriptions.
 Process-based SRM/SA.

• The required elements of a complete process description.

• In order to be a component of a mature SMS, a process description should
contain all of the following:

• Purpose,
• Scope,
• Interfaces,
• Stakeholders,
• Responsibility,
• Authority,
• Procedure description/flowchart.
• Materials/equipment/supplies,
• Hazards,
• Controls (production and protection),
• Process measures (production and protection),
• Targets (production and protection),
• Assessment (production and protection),
• Change management,
• Qualifications required for participants in process,
• Documentation/record-keeping.
• This is not to suggest that every organization must adopt this specific
outline and enumerate process characteristics in exactly this order. As
mentioned many times, SMS implementation is quite flexible, and operators
can choose their own format for most components. But to be effective, any
process description should contain within it the elements above.
• 1. Purpose.
• The purpose of the process should be described as clearly and concisely as
possible .This explanation can help guide the rest of the description.
• A well formed purpose statement can also guide the creation of training
materials used to educate stakeholders involved in the process.

• 2. Scope.
• The statement of scope for a process is an extremely important component.
A well-defined scope statement is helpful in a number of ways .
• Scope identifies limits, boundaries, and restrictions for the process at hand.

• 3. Interfaces.
• Readers familiar with ATOS will recognize the interfaces component as one
of the five “safety attributes” that a process must have, as defined in the
FAA’s Air Transport Oversight System documentation.
• Unless the inputs to a process are well controlled and possess the needed
characteristics, the process is unlikely to work well. Equally, it is important to
view the process from the customer perspective—from the point of view of
the output—in order to understand what the process must accomplish.
• By exhaustively listing all the interfaces to a process, one can determine
what the inputs to the process are, who the customers are, and what those
customers need delivered by the process, information essential to
establishing targets. This is why interface considerations should be third on
the list when designing the process.

• 4. Stakeholders.
• Establishing the list of stakeholders in a process is an important step.
Typically the stakeholder list is composed of those people or parties who
actually accomplish the work, but also contains an enumeration of the
interfaces to the process—the suppliers and customers.
5. Responsibility.
• Next it is essential to assign responsibility for the conduct of the process.
This responsibility needs to be clearly and overtly spelled out in the process
documentation.
• Typically a process has a number of parts, each of which must be assigned
to someone, or some party, to accomplish. Each of those areas of
responsibility must be again clearly described.

• 6. Authority.
• Responsibility and authority attributes are frequently confused. Someone
who has authority over a process has the ability to manage the process
itself—stop it, start it, or (within specified procedures described below)
change it. Responsibility and authority might or might not be shared by the
same person or group. it, or (within specified procedures described below)
change it. Responsibility and authority might or might not be shared by the
same person or group.
• The party responsible for a process is the one that is accountable for the
accomplishment of that process as it is outlined in the process description,
and is accountable for the output of the process and the meeting of the
target outcomes of the process during the time he or she participates in the
process.

• 7. Procedure description/flowchart.
• The procedure description and the process flowchart are the components
usually associated with the idea of a process description. It should be clear
by now that the description/flowchart component is only a part of a complete
process description. But it is an essential one, the one that describes how
things are actually going to get done.
• By being flexible and moving back and forth from working on the flowchart
to hazard identification to control description, to process measurement
creation, as needed, the final product is most likely to incorporate all
requirements.
• 8. Materials/equipment/supplies.

• When planning a new process, it is natural and intuitive that the planning
team would give close consideration to the materials, equipment and
supplies.

• In fact, once the organization has well-documented processes for all of its
activities (no small task), the specifications document for the ramp arrival
process (for example) feeds into the output requirements for other
interfacing processes.

• Consideration of equipment requirements is equally important for a

successful and safe process design.
• 9. Hazards.
Another quality tool is the method of choice for working on the hazard
identification component of a process description. It is the process decision
program chart (PDPC),described in Chapter 3, and used liberally in both ICAO
and FAA documentation.
The team should pay particular attention to the inputs—poorly controlled
input quality is always a hazard, and should always be listed as such on the
PDPC used to list hazards. The process flowchart is a primary resource for
hazard identification, in that the team can walk through the process step by
step and consider what hazards exist along the way.

10. Controls (production and protection).

It’s important to emphasize that the SMS practitioner should be the resident
expert concerning controls for the team creating or evaluating process
descriptions, and should be prepared to explain the differences and relative
advantages and disadvantages of open and closed loop controls.
• . These are the signals that the control needs in order to determine the
desired path. Just as a process depends upon high quality inputs, a control
depends upon high quality signals, so the team should closely examine how
the quality of those signals is going to be assured.
• The astute reader no doubt noticed that the parenthetical phrase production
and protection was appended to the topic of controls, as it is for the
following three topics.
• Processes exist in order to accomplish an outcome that adds value to the
organization. The “gate departure process” is accomplished in order to get
paying passengers on the airplane, load up the plane with revenue-
producing cargo,and leave the gate on time.
• Thus, on the production side of the production-protectionaxis, it is critical
that process descriptions have effective production controls built in,just as it
is important that safety controls are built in so that protection needs are met.
• Both sets of controls need to be understood in order to accomplish SRM.
• 11. Process measures (production and
protection).
A process cannot be managed from either the production or the protection
aspect without having process measures built into it. The simplest of process
measures can be done (and always should be done) at the output of the
process.
In order to create efficient and meaningful measures, a process design team
needs to identify key performance indicators, or KPIs, along the workflow path.

Safety assurance (SA) cannot exist unless those processes under scrutiny
have KPIs defined. It is through the monitoring of KPIs that risk is managed. It’s
therefore critical that the correct KPIs are chosen.
• Since the purpose of SA is to measure the effectiveness of controls, a
logical place to put KPI measurement is downstream of controls in the
workflow diagram. But don’t forget to consider measuring hazards.
• Once again the SMS practitioner should keep in mind the nature of the
controls used in the process. It’s a good idea to try to create a KPI
downstream of an open loop control, because otherwise no one will know
whether the control works or does not.

• 12. Targets (production and protection)

• In SMS SA, a control is judged to be effective or ineffective based upon a
comparison to a pre-defined target.12. Targets (production and protection).

• In some references, ICAO and the FAA refer to this concept as a target level
of safety, or TLS. Whatever one calls it, the association of targets to process
measures is an important part of what makes a process definition useful in
SMS.
• It is again worthy of note that targets should be set for both production and
protection KPIs. A well-run operation will be closely monitoring performance
and measuring that performance against targets, such as on-time departure
rate, or turn time (time between gate arrival and gate departure for a
particular aircraft).

• 13. Assessment (production and

protection).

• From the safety perspective, assessment means risk assessment.

• As described in the ICAO and FAA documentation, new-process risk
assessment can be thought of as a one-time task (though it should be
returned to any time new hazards arise. But established process risk
assessment is much better thought of as a muscle in need of regular
exercise.
• 14. Change management.
• After this much hard work, the team will be highly motivated to assure that
the system they so diligently constructed does not decay because of
uncoordinated action by individual stakeholder members.
• Central to this change process is the need to coordinate changes with all
stakeholders before the change takes effect, and in most circumstances it is
best to give stakeholders input into the design of the change itself.

• 15. Qualifications and training.

• Another oft-neglected but essential detail of any process description is the
enumeration of what documents are needed to perform the process, and
what record keeping is necessary since KPIs are defined in any well-
designed process, it is necessary to describe how those measurements will
be recorded. Check sheets, as described in Chapter 3, are the obvious
choice for this task.
 Where to start?.
• It is also clear that the FAA understands the challenge of assuring that good
process descriptions exist—process documentation as an element in SMS
implementation first appears in phase 2 of its suggested deployment
schedule, and continues through phases 3 and 4. While the eventual goal of
a mature SMS is to transform all of its processes to incorporate the
elements necessary to allow SRM and SA to be efficiently employed, this is
a large assignment, and it is universally acknowledged that this
transformation will take long term commitment.
• Where should an organization start when re-engineering its processes for
SMS? That is, again, left up to the organization to decide. And the
organization is free to define its processes any way it wants, so different
organizations will choose different sets of activities.
• FAA’s Air Transport Oversight System (ATOS). In ATOS, an airline operation
is divided into seven “systems” and within those seven systems are 107
subsystems, another way to say processes. The excerpts below will
illustrate this means of classification.
• 1.1.3 Special Flight Permits (AW)
• 1.2.1 Airworthiness Release/Logbook Entry (AW)
• 1.3.5 MEL/CDL/Deferred Maintenance (AW)
• 1.3.6 AD Management (AW)
• 1.3.16 Fueling (AW)
• 1.3.17 Weight and Balance Program (AW)
• 1.3.18 De-Icing Program (AW
• 1.3.19 Lower Landing Minimums (LLM) (AW)
• 3.1.7 De-Icing Program (OP)
• 3.1.9 Aircraft Performance Operating Limitations (OP)
• 3.1.10 Lower Landing Minimums (LLM) (OP)
• 3.2.2 Flight/Load Manifest/Weight and Balance Control (OP)
• 3.2.3 MEL/CDL Procedures (OP)
• (AW = airworthiness, OP = operations.
• From the list above, let’s choose two subsystems, 1.3.18—the maintenance
• component of the airline’s de-icing program, and 3.1.7—the operational side
of the de-icing program. We’ll use these to walk through how to do SRM/SA
• Process-based SRM.
• Our airline has chosen these two ATOS items to build their first SMS-
compliant SRM/SA because their existing safety program has concluded
that de-icing holds the potential for high-risk outcomes, and their historical
data from audits and ASAP indicate that problems exist within the process.
• The cross-functional development team follows the outline for the creation
of process descriptions above, and first develops a purpose statement for
the de-icing process that encompasses all of the stakeholders at the table.
• Next the team develops the scope statement, and in doing so they realize
that the scope of this process extends beyond their corporate borders,
allowing their maintenance department to provide de-icing services to other
carriers.
• Next the team identifies the hazards associated with de-icing. As the team
works through the constellation of hazards associated with de-icing, one
member realizes that one possible flight crew error involves forgetting to
turn off the air conditioning pack valves before de-icing commences.

• An FMEA analysis of this error reveals that the cabin crew has been so far
neglected as recognized stakeholders—they would immediately become
players as soon as an aerosol of deicing fluid begins circulating in the
passenger cabin. The oversight is corrected, and a representative from the
flight attendant department joins in the effort.

• It’s now time for the team to step back from its draft flowchart and determine
the best means of measuring the system. They settle on the following list of
measures to support KPIs:
• De-icing fluid quality records, from maintenance.
Continuing qualification training records relevant to de-icing, from
maintenance.
Date/time that de-icing procedures were declared in effect, and date/time
they were cancelled, from dispatch.
Flight numbers of flights that departed the station while de-icing procedures
were in effect from dispatch.
Flight number/time of beginning of de-ice application procedure, from
maintenance.
Actual time of start of takeoff roll for affected flights, from dispatch.
Computed time interval between start of de-ice application and beginning
of takeoff roll, from previous two KPIs, and comparison of that measure to
maximum hold-over time for type of de-ice fluid and temperature.
ASAP reports from the pilot, maintenance, dispatcher and flight attendant
programs.
• A representative from the safety department notes that flight ops has one
control in place that is open loop—the yearly de-icing bulletin issued to flight
crews at the beginning of the winter season. An additional KPI is added in
which line check airmen administer a short non-jeopardy quiz on de-icing
procedures to a representative sample of crews undergoing a routine line
check. The purpose of the KPI is to monitor the effectiveness of this open
loop control.
• The team next sets the targets for each KPI:
• All de-ice fluid quality records current and in limits within 6 hours prior to
• start of de-icing.
• Overall error rate for de-ice fluid quality records decreased 10 per cent over
• previous year.
• All designated de-icers trained before start of season (which is itself a
specific date).
• No flights departing beyond established holdover time limits.
• 80 per cent of flights departing within one half maximum holdover time limit.
• Aggregate analysis of ASAP reports concerning de-icing does not indicate
• increasing error trend.
• 90 per cent average score for flight crews quizzed about de-icing
procedures by line check airmen.
• For the SMS practitioner, it’s important to realize that the parts of this work
directly dealing with hazards, controls, and risk assessment—the parts often
assumed to be the entirety of SRM—are essential components of the work
just described, but there is much more to the complete task. Every step is
needed, and should exist, in a mature SMS.

• Process-based SA.
• With the foundation built by this top-notch team, safety assurance
associated with this process is now well-defined. The continuous monitoring
component of SA information acquisition is now directly guided by the
process description.
• The risk management plan.
• The individual performance of the various processes monitored by the SMS
provides the basic data the SC needs in order to determine the overall
priorities for the organization, and in order to determine the overall risk the
organization is exposed to.
• The SC is also the only part of the organization positioned to coordinate the
various safety targets adopted by the designers of individual processes.
• With the SC’s wider view of the organization, and with the detailed
performance data that process-based SRM/SA provides, the RMP plan can
serve as the roadmap that leads the organization into safer operations.

• The ERP as a component of the RMP.

• From a documentation point of view the way to recognize whether an SMS
has incorporated emergency response planning is to examine the
organization’s emergency response plan, or ERP. The first chapter in this
book enumerated the components of a well-designed ERP, and indicated
some of the reasons why an SMS needs to have such a document.
• The SC should have the responsibility for, and authority over, the ERP. Just
as the SC is best situated to manage the RMP, there is no other part of the
organization better connected with the safety component of each of the
processes within the organization. It makes sense—the SC should be the
owners of two documents: the Risk Management Plan, and the Emergency
Response Plan.

• SRM/SA in the Real World.

• There is unfortunately a great danger that an average line manager in an
average operation might perceive a complexity to SMS that immediately
discourages participation or adoption. This is not just a potential problem—it
already exists today, and the only way to overcome this understandable
resistance is for disciples of SMS to patiently explain that one does not
impose SMS. Rather, it is best grown in place, step by step, with small steps
at first. Expecting any organization to transition to a mature SMS within a
short period of time is both unrealistic and self-defeating.
• We will grow a successful and mature SMS by identifying one or two risk
areas at a time, and working on those processes to incorporate the
essential components that allow SRM and SA to develop to their potential. It
is, and should be, a slow, methodical effort, but it is one worth the wait, and
worth the work.

• We will grow a successful and mature SMS by identifying one or two risk
areas at a time, and working on those processes to incorporate the
essential components that allow SRM and SA to develop to their potential. It
is, and should be, a slow, methodical effort, but it is one worth the wait, and
worth the work.
THANK YOU.