ダウンタイム追跡ソフトウェア: OEEを動かす8つの停止理由コード
ダウンタイム追跡ソフトウェアは月額200ユーロのものから月額20,000ユーロのものまであります。価格を見ても、月曜の朝にラインが止まり、次の部品がコンベアに到達するまでにシフトリーダーがタブレットに入力できる時間がわずか30秒しかないとき、それがどれだけ役立つかはわかりません。
重要なのは、現場の作業者が正しい停止理由を選べるようソフトウェアが助けてくれるかどうかです。仕事はそれに尽きます。理由コードが曖昧すぎれば、月末のOEEレポートには「ラインは14時間停止した」とだけ書かれ、その原因は誰もわかりません。理由コードが細かすぎれば、作業者は諦めて80%の確率で「その他」を選びます。結局、何も記録できないシステムにお金を払うことになります。
本ガイドは実践版です。中小規模工場で実際にOEEを動かす8つのダウンタイム理由コード、無視して問題ない30以上のコード、iPhoneベースのダウンタイムフィードが稼働中にどう見えるか、そしてデモに惑わされずにダウンタイム追跡ソフトウェアを選ぶ方法を扱います。
ほとんどのダウンタイム追跡が的を外す理由
新規顧客のダウンタイムデータを監査すると、3つのパターンが繰り返し現れます。
1つ目は「その他」の肥大化です。ある工場では24の理由コードを使っていました。頻度トップ3は「計画外停止」「軽微な問題」「その他」で、合わせて記録されたダウンタイムの62%を占めていました。このデータでは根本原因分析はできません。ラインが止まったことはわかっても、何を直すべきかは何もわかりません。
2つ目は二重計上です。作業者はMESに停止を記録し、保守システムに別の停止を記録し、シフト引き継ぎのために紙のログブックに3つ目を記録します。数値はけっして一致しません。工場長は生産会議で展開したい主張に合う情報源を選ぶことになります。
3つ目は入力遅延です。ラインが9時12分に止まり、作業者がタブレットに戻った11時47分に記録します。その時点では実際の8分14秒ではなく「だいたい20分」として記憶しています。リアルタイム監視は事後の語り直しになります。
解決策は理由コードを増やすことではありません。理由コードを減らし、ラインが止まった瞬間に十分な背景情報とともに記録し、次の担当者が行動できるようにすることです。
重要な8つの理由コード(と、無視してよい30コード)
過去18ヶ月でお付き合いした約40の工場全体で、同じ8つの理由コードが全ダウンタイム時間の85〜92%を占めていました。ベンダーがデフォルトテンプレートに入れたがる他の30以上のコードは残りを占めるだけです。8つを追跡し、残りは自由記述にするか「その他」にまとめてください。
OEEを実際に動かす8つのコードは次のとおりです:
- 資材枯渇。 インフィードに部品がない状態。上流があなたのラインより遅いか、キットが時間通りにステージされていないかのどちらかです。
- 資材の詰まりまたは上流の品質不良。 インフィードに部品はあるが、誤った部品・損傷品・引っかかっている状態です。枯渇とは原因も対処も異なります。
- 工具交換またはレシピ切替。 SKU間の計画的な切替です。計画外ダウンタイムを汚さないよう、別カテゴリで追跡してください。
- 機械的故障。 機械の物理的部品が故障した状態。ベアリング、ベルト、空圧系など、技術者の対応が必要なものです。
- 電気または制御系の故障。 機械部品は問題ないが、PLC・センサー・ドライブがエラーを出した状態です。トラブルシュート経路が異なります。
- 作業者不在または休憩。 ラインは稼働可能だがステーションに誰もいない状態。シフト引き継ぎの隙間や計画外休憩を含みます。
- 品質ホールド。 直近数個の部品が検査で不合格となり、誰かが処置を判断する必要があるためラインが止まっている状態です。
- 上流または下流のブロッキング。 あなたのラインは問題ないが、包装が遅れていてコンベアが満杯、または倉庫が追加パレットを受け入れられない状態です。
以上です。8つのコードでOEE数値を動かす要因の大部分をカバーできます。それ以外は、いずれかの下位カテゴリか、月1回自由記述で記録してOEEレビューで確認すればよい末端事象です。
なぜこれで機能するかというと、8コードそれぞれが異なる行動につながるからです。資材枯渇は計画担当に、機械的故障は保守チームに、品質ホールドは品質チームに連絡します。理由コードが「誰に連絡すべきか」を作業者に教えてくれないなら、それは間違った理由コードです。
iPhoneベースのダウンタイムフィードはどう見えるか
OEE計算ガイドをお読みいただいた方は、ダウンタイムデータが稼働率に直結し、稼働率がOEEの3本柱の1つであることをご存じでしょう。データはラインが止まった瞬間に記録されてはじめて意味があります。
従来のアプローチはPLCに配線したタブレットです。PLCが停止イベントを発生させると、ポップアップが作業者に理由コードを選ばせます。これは機能しますが、ハードウェアと統合作業でライン1本あたり4,000〜8,000ユーロかかり、最初に選んだPLCベンダーに縛られます。
iPhoneベースの方式はPLC統合を完全に飛ばします。リファービッシュ済みiPhoneを各ステーションに設置し、単一のアプリを実行します。カメラがラインを監視し、部品の流れが設定した閾値(通常8〜15秒、サイクルタイムによる)を超えて止まると、アプリが検知し、作業者が画面上で8つの理由コードから1つを選びます。操作全体は5秒未満です。
これが5年前は機能しなかったのに今は機能する理由は3つあります。1つ目は、iPhoneカメラが工場照明下でも別途センサーなしにサイクル停止を信頼性高く検知できる性能になったこと。2つ目は、オンデバイス処理によりデータがプライベートで、クラウド往復による遅延がないこと。3つ目は、作業者がすでにインターフェースに慣れていること。「理由をタップする」以外の教育コストはありません。
この方式でラインを稼働させるハードウェアはステーションあたり1,000ユーロ未満に収まります: リファービッシュiPhone、マウント、リングライト、データ転送用イーサネットアダプタ。3ラインのダウンタイムフィードを午後だけで構築できます。
ログから行動へ: シフト単位のダウンタイムワークフロー
データを記録するのは仕事の半分です。残り半分は、データがシフト終了前に何かを引き起こすようにすることです。
実際にOEE改善が進んだ工場で一貫して機能しているワークフローは次のとおりです。直近1時間に記録された理由コードがすべて共有シフトダッシュボードに表示されます。シフトリーダーは15分の現場巡回中にそれを一瞥します。2時間で資材枯渇が3回記録されていれば、木曜の次の計画会議ではなく昼食前に計画担当へSlackメッセージが飛びます。1台の機械で機械的故障が集中していれば、次の予定PM枠を待たずに保守担当が呼ばれます。
ダッシュボードは凝った作りである必要はありません。8コード、現在シフトの件数と分数、先週との比較トレンドのスパークラインを1ページにまとめれば十分です。重要なのは、シフトリーダーが実際にそれを見ていること、そして見るという行為が会話を引き起こすことです。
各シフト終了時、リーダーは引き継ぎに2文を書きます: 最大のダウンタイム要因は何だったか、それに対して何をしたか。これが金曜の生産会議で実際に使われるデータになります。壁に貼り出されたOEE数値は遅行指標です。2文の引き継ぎは先行指標です。
このワークフローのカメラベース版についてはカメラによる生産モニタリングをご覧ください。ビジョンパイプラインを詳しく解説しています。このデータと組み合わせるシフト引き継ぎテンプレートについては、プロセスエンジニア向けシフト引き継ぎの記事をご参照ください。
ダウンタイム追跡ソフトウェアの選び方
ダウンタイム追跡ソフトウェアを評価する際、多くのデモはダッシュボード、AIアシスタント、予知保全モジュールであなたを眩惑します。デモは無視してください。5つの質問をすればよいのです。
1つ目: ラインが止まってから停止を記録するまで何秒かかるか? 回答が1イベントあたり作業者時間で10秒を超えるなら、1ヶ月以内にデータは遅れと欠損まみれになります。
2つ目: デフォルトでいくつの理由コードが設定されており、8つに減らせるか? 40コードの分類体系を譲らないベンダーは、実際の現場での機械ダウンタイム追跡を理解していません。
3つ目: PLC接続なしでシステムは動くか? ダウンタイムを記録する唯一の経路が制御システム統合なら、データを目にする前に3ヶ月の導入プロジェクトを買うことになります。カメラベースまたはボタンベースの記録は、追加販売ではなく標準機能であるべきです。
4つ目: 生のデータはどう見えるか? 既存顧客の1週間分のダウンタイムイベントを匿名化してCSV出力してもらってください。ベンダーが5分でそれをできないなら、データはダッシュボード内に閉じ込められており、自前の分析がしたくなったときに取り出すのに苦労します。
5つ目: 初年度のライン総コストは、ハードウェア、統合、研修、サブスクリプションを含めていくらか? 多くのチームはライセンスだけを予算化し、残りを忘れます。月額200ユーロのサブスクリプションに統合費12,000ユーロが乗るなら、それは年間2,400ユーロの判断ではありません。
適切なダウンタイム追跡ソフトウェアとは、シフトリーダーが言われずに使い、保守チームがデータを信頼でき、CFOが2年目に減損計上する必要のないものです。
よくある質問
ダウンタイム追跡とOEEソフトウェアの違いは? OEEソフトウェアは稼働率・性能・品質を使って完全なOEE値を計算します。ダウンタイム追跡ソフトウェアは、ラインが止まった理由を記録することで稼働率の柱に特化します。多くのチームは両方必要ですが、ダウンタイム追跡は単独で運用し、性能と品質の要素を後で追加することもできます。完全な計算についてはOEE計算ガイドをご覧ください。
理由コードはどのくらい細かくすべきか? 8〜10コードが最適です。6未満では計画問題と機械問題を切り分けられません。12を超えると2週間で作業者は「その他」を選ぶようになります。会議で誰かが提案するたびにコードを追加したくなる衝動は抑えてください。
PLCなしでダウンタイム追跡はできるか? はい。設置したiPhoneを使うカメラベース記録は、現代的PLCを持たない工場や旧式ラインの後付けに最もクリーンな選択肢です。ステーションに物理ボタンを置き、ラインが止まったときに作業者が押すボタンベース記録も機能しますが、1イベントあたり約2秒の作業者時間が追加されます。
ダウンタイム追跡ソフトウェアはどのくらい速く立ち上げられるか? iPhoneベースの記録システムなら、1ラインを午後で稼働させ、8〜12ラインの工場全体を1週間未満で稼働させられます。PLC統合システムは通常、テストを含めてライン1本あたり6〜12週間かかります。
ダウンタイム追跡ソフトウェアはCMMSを置き換えるか? いいえ。CMMSは作業指示、部品在庫、PMスケジュールを扱います。ダウンタイム追跡はリアルタイムイベント記録と理由コード付与を扱います。両者は連携すべきで、ラインで記録された機械的故障がCMMSに作業指示の下書きを自動作成するようにします。しかし解決する問題は異なります。
よく出る枠組みの質問は、ダウンタイム追跡ソフトウェアが広範な総合設備効率(OEE)レポートにどうつながるかです。ダウンタイムフィードはOEEに入力される稼働率データです。計画外と計画停止の双方にクリーンな情報源がなければ、週次OEEレポートの稼働率数値は推測に過ぎず、チームは修正ではなくどのラインが最悪かを言い争うことになります。クリーンなフィードがあれば、同じ数値があらゆる根本原因分析の出発点になり、週次レビューは責任追及から学習へ移行します。理由コード付きイベントは、シフトリーダーが最大の損失要因から優先的に取り組めるデータを得ることで、四半期単位で稼働率を引き上げます。
定着する報告サイクルは、理由コードのパレート図に紐づいた週次ダウンタイムレポートで、平均修復時間(MTTR)とOEEスコアをライン別の生産損失と並べて推移表示するものです。設定する理由カテゴリは、設備故障・サイクル低下・品質問題・計画保守を別個にカバーし、週次レビューでどのカテゴリが最も急速に拡大しているかを見られるようにすべきです。このデータを使う継続的改善プログラムは、最も声の大きい問題ではなく最大の損失要因に焦点を保ち続けます。クリーンなフィードで週次レビューの筋肉を鍛えたチームは、四半期内に違いを実感します。
今週中にダウンタイム追跡を稼働させる
1ラインで金曜までにダウンタイムフィードを動かしたいなら、最速の道はリファービッシュiPhone、マウント、無料のEnaoアカウントです。工場に合う8つの理由コードを選び、カメラをラインに向ければ、1時間以内にデータが流れ始めます。PLC統合なし、12週間のプロジェクトなし、5桁の請求書なし。
無料で始める、またはコミュニティに参加して、同じ取り組みをしている他のプロセスエンジニアと理由コードテンプレートを比較してみてください。
