要素のレベルの作り方の例 (v6.x)

※ 本項目は、欧州における Q&A を翻訳したものです。

質問：

私は７レベルのツリーを使って作業しています。概念的な理由で、いくつかのレベルは機能や故障の定義をせずに、配置しています。構造内のこのようなレベルを維持し、機能ネットまたは故障ネットの生成によって、このようなレベルをスキップすることはできますか？

回答：

FMEA に対して、故障、影響、原因に対して場所（＝要素をアンカーする場所）が必要です。大多数のユーザーにとって、この情報を３レベルを持つ１つの構造に統合することが適しているように思われます。しかし、機能ネットと故障ネット、フォームにわたる構造を持つ、１つ以上の構造が可能です。

影響に対する場所としてルート要素（レベル１）を使い、故障に対してその次のレベル（レベル２）を、原因に対して更にもう１つのレベル（レベル３：ツリーの葉のレベル／ソースレベル）を使うことが一般的です。

機能ネットや故障ネットに関連性を持つ、追加の情報を持つ追加のレベル、持たない追加のレベルを統合することは自由です。追加のレベルの統合にはいくつかの異なる理由があります：

• 顧客のシステムが更に上位のトップレベルを持っていた
• 組織上の理由で追加で中間レベルを持っていた
• 再利用時の最適化のために追加で中間レベルを持っていた
• ルートの原因分析を掘り下げるために葉のレベルを追加していた（“五なぜ／なぜなぜ5回” 等）
• 機能と特性／制限を分離することができるように1つの葉のレベル（2つの原因レベル）を追加した

特定しやすくするために追加レベルを保持しておくことを推奨します。要素／要素レベルの役割を指定し、不必要な議論が避けられるように標準のアプローチを確立しておくことは良いアイデアです。これらを行うには、いくつかの可能性があるでしょう。例えば、ユーザー定義の属性、名前の付け方のルール付け、色付け、FMEA フォームシートアイコンの使用など。