In Search of the Elusive System Safety Metric

摘要

For years System Safety Practitioners have been struggling with developing a meaningful metric that both satisfies the management of objectives of measuring programmatic progress and risk. Most metrics that have been satisfactory to program management have concerned the safety engineer. Often quotas suggest or portray identification of risk, particularly those that are catastrophic, as action items to close and forget. They also traditionally attempt to track how long a hazard is in open, monitor status without regard for the true reasons for why the item is not closed - the controls haven't yet been verified. This paper will suggest alternative concepts for development of meaningful metrics that both the Management Team and the System Safety Team can view as positive contributions to the overall program. In order to examine new concepts, the first step is to discard some of the old cliches many of us have heard in the past. Statements such as "we shouldn't have any more hazards than Program X" simply states that our System Safety Program should not be as thorough so we don't identify the same amount or other hazards that Program X may have over-looked. Demanding that no catastrophic or high-risk hazards can be included in the product discourages accurate hazard reporting to comply with the dictate and has no effect on the true residual risk of the item. These approaches may make a program look good on paper but do not support a program's need or the system safety principle to reduce risk to as low as reasonably possible. This paper presents alternative views that do not count how many hazards we identify, or even where they fall on the risk matrix. This paper instead suggests that we should focus on how we serve our customers along the program path. Rethinking how to measure system safety performance does not necessarily require much change within the system safety program execution, but may require changes in how the organization is viewed within the program and the overall development process. To accomplish this we need to think outside the measurements of other engineering disciplines that may appropriately measure drawing defect rates and release on time metrics and focus on measuring the impacts of those who can use the System Safety data product. These users represent our customers and hence, total customer satisfaction should be the measurement objective. The challenge is examining each program phase to determine who the customers are and what they need during each particular phase of the program. Meeting this challenge requires understanding that customers change throughout the program as well as their needs.