OEEとTPMの連携：指標・改善手法・ソフトウェアの役割分担

最初に3つの概念を区別し、相互に代替させない

OEEは時間稼働率、性能稼働率、良品率を通じて設備効率の損失を表し、「損失はどこにあり、どの程度の時間や生産量を失っているか」に答えます。TPMでは、作業者、保全、工程、管理の各担当者が参加し、予防、改善、能力向上の仕組みを構築します。これにより、「誰がどのような方法で損失を減らし、再発を防ぐか」に答えます。

ソフトウェアは、設備状態、アンドン、点検、修理、分析の記録を連携できますが、OEEの計算式そのものでもTPMシステムそのものでもありません。責任、標準、振り返りのサイクルがなければ、どれだけ画面が充実していても単なる表示にすぎません。一方、信頼できるイベントデータがなければ、TPMの振り返りは印象に頼りがちになります。

OEEの損失の枝をTPM活動に対応付ける

対応付けは損失メカニズムから始めるべきであり、個々の損失を機械的に特定の柱へ割り当てるべきではありません。故障停止には計画保全が関係する場合もあれば、清掃・点検の欠落、運転条件の変化、設計上の弱点に起因する場合もあります。チョコ停や速度低下には、作業者と設備・工程の担当者が共同で現場を観察することが必要になることが多くあります。

品質損失も品質部門だけに任せることはできません。設備精度、治工具の状態、立ち上がり条件、作業標準は、いずれも立ち上がり不良や工程内不良に影響する可能性があります。OEEロスツリーは共通の問題一覧を提供し、TPM活動は複数の役割を組織して解決を図り、ソフトウェアは問題の再発と対策の実行状況を記録します。

異常イベントから保全活動までのサイクルを構築する

対策につながるイベントチェーンには通常、設備による自動記録、アンドンまたは手動での呼び出し、応答・到着、暫定的な復旧、原因分析、対策の実行、再発の検証が含まれます。停止時間、修理時間、待ち時間は適切に分ける必要があります。そうしなければ、改善の重点を設備の信頼性と応答プロセスのどちらに置くべきか判断できません。

アンドンは異常を迅速に責任ある対応プロセスへ引き渡すものであり、修理作業指示書と同義ではありません。作業指示書が必要か、誰が完了とするか、いつエスカレーションするか、部品待ちをどう扱うかは、プロジェクト内で定義する必要があります。ソフトウェアのインターフェースは既存の保全システムに合わせて設定できますが、成熟した独立型のTPM製品や設備ライフサイクル製品が標準で付属すると想定すべきではありません。

• 発見：元の設備信号、発生時刻、製品または運転条件のコンテキストを保持する。
• 応答：呼び出し、受付、到着、エスカレーション、必要な連携を記録する。
• 復旧：暫定的なリセット、正式な修理、生産再開の確認を区別する。
• 分析：故障モードと現場の証拠からメカニズムを特定し、「対応済み」と入力するだけで終わらせない。
• 予防：対策を点検、保全、部品、標準、改造のタスクに変換し、再発を再確認する。

点検・保全・修理データをどのようにつなぐか

設備台帳は対象のキーを提供し、点検・保全計画は実施すべき作業を定義し、実行記録は実際の完了状況を示し、修理・故障イベントは異常履歴を説明します。OEEイベントを設備キーと時間軸に関連付けられなければ、損失が点検漏れ、期限超過、繰り返し修理に関係しているかどうかを判断しにくくなります。

データを連携することは、すべての機能を1つのシステムに構築しなければならないことを意味しません。既存の保全プラットフォームを引き続き基幹システムとし、OEEまたはアンドンプラットフォームからインターフェース経由でイベントを提供できます。カスタムの作業指示サイクルを採用する場合は、既存システムとの境界を明確にすべきです。ORPAONでは、設備ライフサイクルおよびTPM領域のモデル拡張をシナリオごとに評価しており、成熟した独立型TPM製品としては位置付けていません。

実践可能な連携導入の進め方

すべての保全モジュールを同時に導入するのではなく、1種類の設備と1つの主要損失から始めることをお勧めします。まず設備キーとイベントの定義を統一し、次に繰り返し発生する故障またはチョコ停を選んでTPM活動を行い、最後にそこで生まれた点検、保全、改善の標準を日常業務に定着させます。

連携の効果はOEEの単一時点の変化だけでは判断できません。製品と計画の境界を固定したうえで、故障の再発、応答プロセス、点検の質、不良の変化を併せて観察する必要があります。データが不十分な場合は、相関関係を因果関係や効果の約束として記載せず、「まだ検証されていない」と明記すべきです。

• ステップ1：OEEの計算式、計画時間、設備状態を照合し、信頼できる損失のベースラインを作成する。
• ステップ2：繰り返し発生する損失を選び、作業、設備、工程、品質の担当者による共同レビューを行う。
• ステップ3：異常、応答、修理、改善の記録を設備とイベントで関連付ける。
• ステップ4：対策を自主保全、計画保全、標準作業の変更へ落とし込む。
• ステップ5：固定した期間で再発とOEE損失を検証し、改善していなければメカニズム分析に戻る。

よくある3つのアンチパターンと修正方法

1つ目のアンチパターンは、OEEを保全部門の評価に使い、停止の過少報告やイベントの早期完了を誘発することです。2つ目は、スキャンによる点検の完了率をTPMの成果とみなし、異常が実際に発見・解決されたかを無視することです。3つ目は、最初に網羅的な大規模ソフトウェアを購入し、その後で当てはめられる管理プロセスを探すことです。

修正するには、指標を問題の振り返りに役立て、保全標準を現場の事実に基づいて決め、ソフトウェアの境界を既存システムと責任の設計に合わせる必要があります。OEE、TPM、ソフトウェアがそれぞれ明確な役割を保つことで、連携が数字遊びに陥ることを防げます。

• 実際の停止時間を短縮する代わりに、記録上の時間を短くして済ませない。
• 点検の有効性と異常の解決の代わりに、点検の提出数で評価しない。
• アンドンダッシュボード、OEEダッシュボード、カスタム作業指示書を完全なTPMシステムと呼ばない。
• 独立したAPS、WMS、QMS、TPM製品がプロジェクトとともに自動的に提供されることを前提にしない。