FRACAS：概要

FRACAS は、組織が障害を報告、分類、分析し、それらの障害に対応する修正対応を計画する方法を提供するプロセスです。

FRACASとは何ですか？

障害報告、分析、および修正アクションシステム（FRACAS）は、組織が障害を報告、分類、分析し、それらの障害に対応する修正対応を計画する方法を提供するプロセスです。ソフトウェアは、複数の障害レポートを管理し、対応する修正アクションで障害の履歴を生成するのに役立つFRACASシステムを実装するためによく使用されるため、過去の障害から記録された情報を分析できます。

1985年に米国国防総省グループによって最初に開発および使用されたFRACASは、次の手順を含む閉ループプロセスです。

1. 障害報告（FR）： システム、機器、またはプロセスに関連するすべての障害および障害は、障害レポートまたは欠陥レポートと呼ばれる標準形式を使用して正式に報告されます。障害レポートでは、障害のある資産、障害の兆候、テスト条件、動作条件、および障害時間を明確に特定する必要があります。
2. 分析（A）： 根本原因分析を実行して、障害の原因を特定します。根本原因分析を実行して、障害の原因を特定します。
3. 是正措置（CA）： 障害の原因が特定されたら、障害の将来の発生を防ぐための修正（または予防）アクションを実装および検証します。標準化を確実にするために、変更はすべて正式に文書化する必要があります。

FRACASは、安全/リスク低減、プロセス制御、インシデント報告システムなどの複数のアプリケーションで使用できます。閉ループプロセスは、設計、開発、製造の各段階で問題を検出して解決する、統制のとれた集中的なアプローチです。これは、障害に関するデータや情報の記録とキャプチャを含む、複数の基本的なタスクを通じて行われます。障害の特定と優先順位付け。障害の再発を防ぐための是正措置を決定、実施、検証します。

FRACASは、信頼性データレポートの障害分析と修正措置からの重要な情報も提供します。インシデント数などのレポートの要約には、貴重な信頼性と品質のデータが含まれています。

FRACASは現在広くデジタル化されており、障害の報告、分析、修正に加えて、DMAIC、MTBF、MTTRなどの複数のプロセスやツールと連携して機能します。

FRACASの実装方法

FRACASの実装は、組織のニーズに基づいて高度にカスタマイズできます。実際、全面的に適用される単一のFRACAS標準はなく、多くの標準は業界固有です。以下は、効果的なFRACASのガイドラインと完全な概要、および必要な情報を収集するために必要なものです。前述のように、この情報を収集するための3つの基本的な手順があります。

ステップ1-障害レポートの作成

FRACASは、障害レポートから始まります。つまり、資産の障害、問題、または製品やプロセスに関する懸念の原因を記録します。障害レポートの情報は、業界、プロセス、およびコンプライアンス要件によって大きく異なります。レポートの作成には、組織内の複数の部門と話し合って、技術サポート、ラボからのテスト結果、製造上の欠陥、現場での問題、エンジニアリングまたは設計などについて話し合うことが含まれる場合があります。

FRACAS内で追跡している情報の種類に関係なく、レポートに含める情報を絞り込む必要があることを覚えておくことが重要です。これは、問題の特定と解決に役立つと思われる情報と、将来の追跡のための情報を意味します。

FRACASの障害報告段階では、インシデントレポートに記録する情報の種類を明確に定義する必要があります。時間の経過とともに、障害が閉ループFRACASプロセスを通過するにつれて、より多くの情報が収集されます。ただし、最初は、障害とその検出方法についてできるだけ多くのデータを収集する必要があります。障害レポートでは、次のような情報を収集する必要があります。

• インシデントの日時
• 問題または失敗を見つけたのは誰か
• インシデントレポートを実施しているのは誰か
• インシデントに至った手順を含む、インシデントに関するすべての詳細
• 問題を修正するために行われた修正措置
• 再発を防ぐために実装できる変更の提案

前述のように、この情報は、追跡しているデータの種類、情報を記録しているユーザー、問題を解決するために必要な詳細、コンプライアンス要件などによって異なる場合があります。通常、FRACAS障害レポートは、各組織の要件に合わせてカスタマイズされます。

障害報告の最も重要な側面は、問題がリアルタイムで発生したときにFRACASにログに記録されるようにすることです。これを行うには、すべてのチームメンバーがFRACASにアクセスでき、システムを適切にナビゲートできる必要があります。

ステップ2–分析

障害レポートをログに記録したら、目前の問題の分析を行います。このフェーズは、組織のニーズに合わせてカスタマイズし、問題の分析を進める方法を決定するのに役立ちます。分析フェーズは通常、障害の原因を完全に評価して解決策を特定するチームリーダーまたはエンジニアによって行われます。

ステップ3–是正措置

FRACASの最後のステップは、問題を解決して解決することです。この時点で、障害の根本原因を特定し、それを修正するための解決策を考え出しました。是正措置を実施したら、チームは措置の成功を確認し、システム内のインシデントをクローズする必要があります。閉ループシステムが無傷のままであることを保証するには、各障害をクローズすることが重要です。

FRACASワークフロー

FRACASワークフローは、閉ループプロセスを構成する複数のステップで構成されています。このプロセスは、インシデントの解決を通じて最初のインシデントレポートを取得します。各組織のFRACASワークフローは、問題が内部でどのように処理されるかによって異なります。ワークフローも、ニーズの変化や教訓の学習に応じて進化します。以下は、メーカーに表示される可能性のあるFRACASワークフローの例です。

• ステップ1-エントリ： 障害が検出され、FRACASに入力されます。この場合、ベアリングが押収されています。
• ステップ2–割り当て： チームリーダーは、問題を保守チームのメンバーに割り当てて調査します。メンテナンス部門は、ミスアライメントが原因でベアリングが疲労していると判断しました。
• ステップ3–修正： メンテナンスチームは、機械の作業履歴を調べて、不適切な組み立ての以前の事例を発見します。これにより、足が柔らかくなり、位置がずれ、接続が緩みます。根本原因分析を通じて、メンテナンスチームは、現在のベアリングの欠陥が、不適切なトレーニングによるメンテナンスチームのスキルの不足によって引き起こされたシャフトのミスアライメントの結果であると判断します。

  この問題を解決するために、メンテナンスチームは、適切にトレーニングされたチームメンバーを割り当ててマシンの調整を処理し、問題のマシンを調整する方法についてすべてのチームメンバーに必須のトレーニングセッションを実装します。さらに、アライメントプロセスの各ステップを含むシングルポイントレッスンがマシンの近くに掲載されています。

• ステップ4–確認： メンテナンススーパーバイザーは、振動分析を通じてアライメントの問題をチェックするためにマシンを再起動します。
• ステップ5–見切り： マシンが正常に動作している場合、障害はFRACASでクローズされます。

これは、製造現場でFRACASプロセスがどのように機能するかを示す基本的な例です。一部のメーカーは、FRACASを実装するために他の方法を使用しています。たとえば、自動車および航空宇宙産業は通常、8D（8分野）と呼ばれるプロセス改善のための8ステップのプロセスを採用しています。これらの8つのステップは、チームの設立、問題の説明、問題の修復、根本原因の特定、是正措置の定義、是正措置の実施、再発の防止、およびチームの努力の認識で構成されます。

FRACASの実装フェーズ

現代の製造会社は大量の信頼性データと情報を蓄積しているため、FRACASデータは通常、データの使用をより便利にするために構造化データベースで管理されます。これは、データ中心のアプローチとして知られています。このプロセス指向の方法は、2つの問題を解決します。関係と責任の混乱を避けるために、多くの人や組織が関与する複雑なタスクを明確に定義することと、管理システム内の必須タスクを定義および規制して、労働者がそれらをする。 Journal of Quality and Reliability Engineering の調査によると 、この方法でのFRACASの実装は、発見、設計、制定の3つのフェーズを使用して行われます。

• 検出フェーズ： 検出フェーズの最初のステップは、各タスクを定義し、誰がタスクの所有権を取得するかを特定することです。次に、プロセスフローを決定する必要があります。これは、手順の設定、承認プロセス、および意思決定プロセスを意味します。次に、障害モード、障害メカニズム、製品仕様、信頼性情報、履歴データなど、その他の情報を定義する必要があります。

  必要な情報がすべて揃ったら、ガイドラインと規制を確認してルールを確立します。最後に、ドキュメントを介してコンポーネントを統合する必要があります。このフェーズを完了すると、次の表に示すようなFRACASプロセスのプロパティが得られます。

  タスク 所有権 情報 障害を観察するユーザーアイテムのデータ、時間、場所、環境障害の症状を文書化するテスト部門障害の説明と予想される根本原因障害を確認するテスト部門チェックリスト疑わしいアイテムを分離するテスト部門失敗モード置き換えられた疑わしいアイテムの再テストテスト部門テストレポート分離された障害を確認する項目テスト部門修理の説明/検証レポート障害分析信頼性部門分析方法とレポート類似の障害履歴のチェック信頼性部門履歴データ根本原因の特定信頼性部門根本原因の特定修正アクションの決定と組み込みFRB分析結果/アクション仕様アクションの有効性の検証FRB有効性の結果
• 設計段階： 設計段階では、プロセスを標準化します。最近の組織では、これはソフトウェアを使用して行われ、組織全体で多数の従業員がFRACASプロセスを簡単に使用できるようになっています。このフェーズのアクティビティは、人間の作業とドキュメントベースのタスクの2種類のアクティビティに分けられます。障害の観察、検証、障害分析などを処理するタスクは、ドキュメントベースのタスクの一種です。基本的に、これらは分析に使用されるレポートです。人間の仕事には、是正措置を組み込むなどが含まれます。 人的作業 ドキュメントベースのタスク 分離失敗の観察再テストドキュメント項目の検証失敗の検証修正措置の決定失敗の分析修正措置の組み込みデータ検索有効性の検証根本原因の分析パフォーマンステスト
• 制定フェーズ： 名前が示すように、制定段階では、FRACASプロセスが実際に実装および実行されます。 FRACASプロセスの参加者には、電子メールやモバイルデバイスなどを介して独自のタスクが与えられます。タスクを完了すると、同じ方法でシステムに報告します。

FRACASプロセスの流れを維持するには、適切な担当者にタスクを提供することが不可欠です。タスクの責任は、設計段階または制定段階のいずれかで定義できます。たとえば、FRACAプロセスが開始する前に従業員を決定したり、上司が誰かを選択して操作中にタスクを割り当てたりすることができます。タスクは、電子メールまたはSMSを介して配信し、進行状況をリアルタイムで更新する必要があります。

FRACASコンプライアンス

FRACASの閉ループプロセスにより、障害の報告と分析を複数の業界標準に厳密に合わせることができます。標準の選択は、業界の要件、コンプライアンスのニーズ、会社の目的などによって異なります。

MIL-STD-2155 FRACAS規格は、FRACASの元となった規格です。それは広く、製品ライフサイクルにまたがる信頼性プログラムの一般的なガイドラインを提供します。この規格は軍事ベースですが、FRACASの実装をガイドするために多くの業界で使用されています。

FRACASは、ISO標準化プロセスの段階に準拠しているため、ISO-9001やISO / TS16949などの複数のISO要件を満たすのにも役立ちます。

• 提案段階： 問題が診断されたら、問題を特定したチームメンバーは、問題の大きさを詳述した提案を作成する必要があります。
• 準備段階： 問題を停止できるようにする手順の準備のために、ただちにアクションが実行されます。
• 委員会の段階： 従業員にはスキルセットに応じて役割を割り当て、それに応じてタスクを委任する必要があります。
• お問い合わせ段階： 提起された質問を調査し、報告された問題について結論を出すことにより、チームメンバーは協力して問題の根本原因を特定し、解決策を見つけます。
• 承認段階： 許可された従業員は、適切と思われるソリューションと適切なアクションを青信号にして、問題を解決する必要があります。
• 公開段階： 最終的なFRACASレポートは、将来のレビューと検討のために閉じてアーカイブすることができます。

FRACASを実装するメリット

FRACASを実装すると、エラーや障害、過去の問題、欠陥、またはプロセスエラーをタイムリーに特定して修正するのに役立つ貴重な情報が得られます。その他のメリットは次のとおりです。

• 障害の適切な調査と適切な是正措置により、FRACASは、工場の手直しや部品/材料のスクラップなどの即時コスト、および顧客の不満などの間接コストも直接削減します。
• FRACASは、信頼性の向上、継続的なプロセスの改善、および効率的なメンテナンスプログラムに寄与する要因となる傾向があります。これは、FRACASによる継続的な監視とデータ追跡によって行われ、これにより、以前の障害の傾向が是正措置によって排除されたかどうかの要約された評価が提供されます。
• FRACASは、信頼性のパフォーマンスの問題を可視化し、継続的な改善プロセスを開始します。
• 根本原因分析を通じて、FRACASは問題を修正するためのエンジニアリング作業を促進し、それが効果的な是正措置につながります。
• FRACASは、問題の履歴に関する知識ベースを組織に提供し、将来問題を回避するのに役立つ多数の問題の前例を提供します。

結論

多くの組織は、障害を防止したり問題を修正したりするための唯一の解決策は、より予防的なメンテナンス手順を追加することであると考えています。これが必要になる場合もありますが、プロセスの再設計を実装することをお勧めします。さらに予防的なメンテナンス手順を追加する場合は、FMEAプロセスまたはRCM分析を実行して、付加価値のない手順をメンテナンスプログラムに組み込まないようにしてください。