コンベヤのOEE：WCSデータから本当の停止要因を見つける

結論から。コンベヤのOEEは3つの数字の掛け算だ——稼働率 × 性能効率 × 品質率。式自体は自明で、難しいのは各数字にどのWCSのフィールドを流し込むか、時間窓をどう切るか、そして停止の1分1分を誰のものとして計上するかだ。まったく同じ失敗を3回見た。3つの倉庫、同じコンベヤ構成、同じ月——OEEは91%、74%、63%と出た。設備が違ったわけではない。定義が違ったのだ。

タグを1つ取る前に、定義を固め切れ。

稼働率 = 実稼働時間 / 計画生産時間。計画生産時間 = シフト長 − 計画停止。コンベヤに金型交換はないが、ウェーブ切り替え時のラインクリア、定期点検、食事休憩はある——これらは計画停止であり、分母の外、ペナルティなしだ。

性能効率 = 実績ユニット数 / (実稼働時間 × 理論タクト能力)。理論タクトはメーカーの最新スペックから取る。確信がなければ、7シフト連続で目標達成した実績ピークの90%を使い、文書化して、全員に同じ数字を使わせる。

品質率 = 初回通過ユニット数 / 実績ユニット数。コンベヤにおける「不良」とは厳密に3つのことだ。スキャン失敗、重量異常、振り分け不良。この3つだけだ。リトライ後の再スキャンで通ったユニットは初回通過にカウントしない——それは手直しだ。

なぜWCSを唯一の真実にしなければならないか。WMSはウェーブが何件の注文を出荷し、時間通りに出荷したかは知っている。ラインがなぜ47分も止まっていたかは知らない。WCSはモーターの起動/停止イベント、フォトアイのカウント、スキャンヘッドの読み取り、アラームコードを持っている——停止時間の帰属分析の生データはすべてWCSにある。WMSの仕事は定義を決めることだ。シフトをどう切るか、ウェーブ開始をいつとみなすか、どの停止を計画停止にするか。私はWMSコンサルタントだが、どの現場でもこう言う。OEEの数字が合わないとき、10回中9回は定義の問題であり、設備の問題ではない。

手順は4ステップだ。

ステップ1。WCSデータの取得リスト。まずこの6つのデータ区分を揃える。1つでも欠けたら、下流はすべて推計になる。

1. 設備状態イベント。モーター起動/停止、ドライブのアラームを秒単位のタイムスタンプで。サブ秒は過剰、1分単位は粗すぎる。
2. フォトアイとカウンタのデータ。重要ポイントでのユニットカウント——最低でもインフィード、ディスチャージ、そしてすべてのダイバートで。区間別のカウントがなければ、どの区間が止まったか特定できない。
3. スキャンデータ。バーコードの読み取り成功/失敗の記録と失敗理由コード。これは品質率の分子であり分母だ。
4. アラームコードマップ。WCSアラームコード → 平易な意味 → 帰属カテゴリ。この表は資本資産だ——1回作って3年使い、変更はプロセス経由で行う。
5. シフトカレンダー。シフト開始/終了、計画停止（食事、メンテナンス、ウェーブ切り替えのクリア）。WMSで維持管理し、WCSでは読み取り専用とする。
6. 速度とタクトの設定。現在のライン速度、理論タクト。性能効率の分母はここから来る。

ステップ2。停止時間の帰属分類。すべての停止はまず計画停止か非計画停止かのゲートを通る。非計画停止は6つのバケットに入る。

グレーゾーンには文書化されたルールが必要だ。私のは3つ。1つ目。5分未満でアラームコードのない停止はすべて微停止に入れる。独自カテゴリとして追い、「設備故障」に無理やり入れない。まったく同じ失敗を3回見た——微停止が「設備故障」に塗り広げられ、メンテナンスが1か月かけて機械を修理し、OEEは1ポイントも動かない。2つ目。インフィードが空でWMSにウェーブリリースがある場合は供給不足。インフィードが空でウェーブリリースがない場合はWMSのウェーブ計画の問題——別枠で追い、設備OEEには計上しない。3つ目。同じアラームコードが24時間以内に3回以上出たら反復故障に格上げし、独自に追う。

ステップ3。WMSとWCSの定義を揃える。4項目。これが済むまでOEEは信頼できない。

1. 時刻基準を1つに。WCSイベントのタイムスタンプとWMSのウェーブ時刻を同じタイムゾーン、同じNTPソースにする。7分進んだWCSを見たことがある——シフトをまたぐ停止はすべて間違ったシフトに帰属された。
2. シフト定義を1つに。WMSのシフト開始/終了 = WCSの計画生産ウィンドウ。日をまたぐ夜勤には厳格なルールを——開始時刻で帰属し、全員が守る。
3. 計画停止リストを1つに、1か所で管理する。WMSが持ち、WCSが読む。リストが2つあればいずれ乖離する。時間の問題だ。
4. 初回通過の定義を文書化する。スキャンに失敗しリトライで通ったユニットはWMSで例外処理として締め、WCSの初回通過にはカウントしない。

ステップ4。OEEを計算し、ボトルネックを見つける。アウトプットは3つ。OEEトレンド表（シフト粒度）、停止時間パレート（カテゴリ × 分）、微停止リスト（5分未満の全イベント）。順番に読む。まず稼働率の最大の切り分けを見つけ、次に性能効率を見る。経験則。コンベヤのOEEが動かないとき、問題の70%は稼働率に隠れている——そして稼働率の問題の70%は微停止と待ちだ。

ケース1。誰も見ていなかった47分。2024年11月、中国東部の大手ECの配送センターで、1日約80,000件の注文を処理していた。メインソーターのOEEは3週連続で71–73%に張り付いた。メンテナンスは何も壊れていないと断言し、データも同意した——3分を超える停止は1つもなかった。そこでWCSイベントを数えた。1日120回以上の微停止、合計47分、そのすべてが「シュートフル → 後工程の人員が時間内に片付けられない → ライン停止 → 片付け → 再起動」。1つも故障として数えなかったが、毎日ほぼ1時間の計画生産時間を食っていた。対策に設備費はゼロ。シュートフル警告フォトアイの追加と、シュート片付け専任の作業員を1名配置しただけだ。2週間後、OEEは83%になった。

ケース2。1か月にわたる定義の争い。2025年3月、中国南部の3PL倉庫。WMSはウェーブ時間内完了率98%を報告し、WCSはコンベヤOEE 62%を報告した。両チームが1か月言い争った。根本原因。WMSのシフトは8:00–20:00で回っていたが、WCSの計画生産ウィンドウは1時間の昼休みと15分のウェーブ切り替えクリア2回を除外していた。さらにWMSはウェーブリリースの遅れを生産時間に含めていた。定義を揃えた後、OEEは79%に再計算され、本当のボトルネックは11:30と16:00のウェーブ切り替え時の供給不足——コンベヤの問題ではなく、WMSのウェーブ計画の問題だった。

金額の計算。時間あたり6,000ユニットの能力のラインで、フルロードのソートコストが1ユニットあたり約$0.11（人件費＋設備償却、オーダーとして）とする。

微停止は1件では最も無害に見えて、合計では最もコストがかかる。だからステップ2では微停止を独自バケットに置くのだ。リストに載せなければ、平均の中に永遠に隠れる。

直感に反する判断、3つ。1つ目。OEEが85%を超えても、自動的に吉報ではない。コンベヤはシステムの1つのリンクに過ぎない。1ラインが95%というのは、上流があなたの数字を守るために貨物を溜めている可能性がある——バッチが揃ってからでないとユニットを放流せず、ラインは見事に見え、注文のリードタイムが犠牲になる。OEEは必ずウェーブ時間内完了率と併せて読む。単体では自己欺瞞だ。2つ目。性能効率が何週間も100%に張り付くのは、ラインが良いからではなく、理論タクトが低すぎるのだ。健全な性能効率は90%から95%の間で揺らぐ。恒久的な満点は、目標がないということだ。3つ目。コンベヤで最適化する価値が最も低い率は品質率だ。スキャン失敗を2%から1%に下げるより、微停止を10分減らすほうが効果が大きい。ボトルネックを回せ、きれいな数字を追うな。

締める前に、よくある失敗ポイント。1つ目。手書きの停止理由がWCSイベントと矛盾する。シフトリーダーは「設備故障」と書き、WCSはシュートフルを示している。対策。一次原因はWCSイベントが決める。手書きメモは補足に過ぎない。2つ目。メインラインだけを測ってシステムを測らない。ソーターのOEEは88%なのに、インフィードラインは毎日供給不足になる。OEEはシステムレベルで計算する——メインライン＋インフィード＋梱包をまとめてだ。3つ目。アラームコードマップが古くなる。新しいスキャンヘッドが稼働し、そのコードがマップに入らず、3か月後に帰属表が「不明」で埋まり、OEEトレンドが壊れる。マップの変更は変更プロセスを通す。4つ目。月平均OEEで作業チームを評価する。平均は微停止を飲み込む。微停止の件数＋帰属のクローズ率で評価し、OEEはトレンド参照にだけ使う。

OEEは壁に貼る数字ではない——次の削減をどこに入れるか決めるものだ。WCSが生データを与え、WMSが定義を与え、両者が結びつけば、停止時間に隠れる場所はなくなる。

Lin Xiao（WMS導入コンサルタント）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。