ダウンタイム追跡: データの潜在能力を引き出す5つのステップ

プロセスが稼働していない場合、製品を生産していないことになるので、機器のダウンタイムを追跡することは重要です。ダウンタイムデータを収集および追跡する際、有用な情報が生成されることを保証するためのこつを紹介します。

ダウンタイムの追跡と監視の自動化

ダウンタイムを手動で追跡することは可能ですが、手動データは通常正確ではなく、タイミングよく使用することは困難です。たとえば、オペレーターは時間を記録するのに向いていません。オペレーターは問題を解決して機械を稼働させるのに忙しく、ダウンタイムの継続時間は不正確な推測値になります。ダウンしていたのは30分だったかもしれませんが、1時間ダウンしていたと思うことは簡単です。仕事中にそろそろ昼休みだと思って時計を見たら、まだ午前10時だったということが何度ありましたか?

さらに、手動で記録するデータは、間違って書き写すことや紛失することもあり、正確な集計が難しいことがあります。イベントに何も割り当てられていない場合、何に取り組むべきかがわかりにくいですが、不正確なデータはさらに事態を悪化させる可能性があります。また、オペレーターが、過剰なダウンタイムを隠すために、わざと不正確な時間を記録する可能性もあります。

意味のあるイベントの作成

最終的に知りたいのは機械が稼働しているかどうかですが、ダウンタイムを細分化して機械の状態も収集しておくと役に立ちます。主な状態を以下に示します。

• 稼働中 – 機械は製品を生産している
• ダウン – 計画外の問題により、機械は製品を生産していない
• 予定なし – 稼働が予定されていないため、機械は製品を生産していない
• 欠品 – 上流の機械がダウンしているため、機械は製品を生産していない
• 渋滞 – 舌流の機械がダウンしているため、機械は製品を生産していない

機械制御システムで状態を決定するのが理想的ですが、ダウンタイム追跡ソフトウェアの計算で決定することも可能です。その場合、機械の状態によってダウンタイムイベントをトリガーでき、開始時刻と終了時刻が記録されます。

ダウンタイムをドカ停とチョコ停に分けるのも良いアイデアです。メンテナンスの必要がない5分未満のダウンタイムは、チョコ停と見なされます。チョコ停には、詰まり、ブロックされたセンサー、微調整などが含まれます。5分以上のダウンタイムイベントはドカ停と見なされ、故障または交換のどちらかとして特定する必要があります。

ダウンタイムの理由の割り当て

ダウンタイムイベントが作成されたら、理由を特定して割り当てる必要があります。問題を解決するには、機械がダウンした理由を知ることが不可欠だからです。一部のシステムでは、機械からのエラーコードに基づいて理由を自動的に割り当てることができます。オペレーターは、自動生成された理由を確認すること、または事前設定されている一般的な原因のリストから適切なダウンタイムの理由を選択することができます。中には、機械の制御部分に理由選択機能を直接組み込んで、装置を再稼働させる前にオペレーターに理由を選択するよう要求する企業もあります。これはすべてのダウンタイムイベントに理由が割り当てられることを保証する方法ですが、オペレーターは機械を再稼働させたいだけなので不正確なデータを入力したりイライラしたりする可能性があり、注意する必要があります。

管理しやすく、焦点を絞ったダウンタイム理由のリストを作成するようにする。

有用な情報を得るためには、適切な理由のリストが必要です。理由リストは、短く、機器のタイプごとに標準化する必要があります。すべてを同時に作業することはできません。ほとんどの場合、上位の3～5つのダウンタイムカテゴリーを優先して取り組むと思います。30個の理由を用意することに何かメリットがあるでしょうか。ほとんどのイベントに理由が割り当てられて、「その他」に分類されないようにするために、十分な長さのリストを作成する必要があります。通常は、10～12個の理由を選択できるリストで十分です。また、オペレーターが理由ツリーで正しい理由を見つけるために何階層も下がる必要がないようにします。システムで4つのレベルを使用できるからといって、すべて使用する必要があるわけではありません。

理由ツリーの作成

ダウンタイムの理由ツリーを作成する際、以下の点に留意する必要があります。

• 理由は明確であること。同じ直接の原因に対して、一部の人々がある理由を選択し、別の一部の人々が別の理由を選択するということがないように、オペレーターにとって該当する理由が明らかである必要があります。
• 理由は症状であること。理由は、根本原因ではなく、直接の原因を表すものである必要があります。問題解決のための活動を何もしないで、オペレーターに根本原因を決定するよう求めてはいけません。たとえば、機械のダウンタイムの直接の原因は、ベアリングの故障かもしれません。ベアリングの故障の根本原因は注油不足かもしれません。最終的には、これは設備の注油プログラムに不備があることを意味する可能性があります。
• 頻繁に発生する理由のみを含めること。頻繁に発生しない理由は含めないでください。なぜなら、適切な理由を見つけるのが難しくなるだけだからです。「その他」という理由を使用する場合、それが最上位の原因になってはいけません。本当の原因を把握するために、新しい理由をリストに追加する必要があります。

ダウンタイムイベントの属性の収集

ダウンタイムデータを有用なものにするために、収集することを検討する必要がある追加のデータがあります。収集するデータの一部を以下に示します。

• プロセス区域または生産ライン
• 機械名または機械番号
• 製品名または製品コード
• 機械の故障/エラーコード
• イベント継続時間
• シフト番号
• 生産日時
• オペレーターのコメント(是正措置を含む)

基本的には、すべてのダウンタイムイベントについて、当事者、日時、場所、内容、および原因を特定するのに役立つ可能性がある情報をすべて収集することをお勧めします。これは、将来的にダウンタイムの削減に役立つ重要な情報です。また、そのイベントと講じた是正措置について、オペレーター自身の言葉で記述したコメントを収集することも有用です。最も正確なコメントが得られるのはイベント発生時であり、これがただちに連絡することにもつながります。上位の問題を特定するには理由のカテゴリーを使用できますが、根本原因を特定しようとする場合はオペレーターのコメントが非常に貴重です。練習とコーチングによって、情報満載のコメントを得られるようになります。

リアルタイムの情報を提供してリアルタイムに問題を解決

情報の収集および問題の解決に最適なタイミングは、問題が実際に発生しているときです。事後のレポート作成および問題解決は、あまり効果的ではありません。ダウンタイムデータをどのように、そして誰がそれを見るのかは、改善を推進するために重要です。データは常に使用可能であるべきであり、長時間経過した後に手動で複雑なレポートを作成する必要はありません。

ダウンタイムの原因を特定し、それに対処する方法はいくつかあります。パレートチャートは、ある期間におけるダウンタイムの原因の上位を時間またはイベント数で視覚的に表示する一般的なツールです。パレートチャートのトップまたはそれに近い位置にある頻発する問題に体系的に対処するプロセスを策定することは良い習慣です。

トレンドとガントチャートも、ダウンタイムイベントの現在のタイムラインを表示する優れた視覚的ツールです。

トレンドでは、ダウンタイムイベント(理由やコメントを含む)をイベント発生時のプロセスデータと並べて表示できる。

ダウンタイム情報が有効であるためには、データは、収集しやすく、理解しやすく、適切に問題を解決するために十分な情報を提供するものである必要があります。dataPARCがどのようにして、ダウンタイムを追跡し、その削減に取り組むために必要なすべてのツールを提供しているかについて、確認してください。