モニタリング・OEE1 分で読める

報告業務を増やさずに設備データをシフト引き継ぎに活かす方法

DBR77 Team · 公開日

設備データがシフト引き継ぎを良くするのは、シフトの終わりに人が書いているメモを置き換えるときです。その上に新しい報告書を足すときではありません。良い引き継ぎで扱うのは四つです。シフトの主要なロス、担当者の決まった未完了のタスク、異常な状態にある設備、安全に関する事項。そのほとんどは、誰かが一文字書く前にリアルタイムデータが用意できます。

ドイツ語圏の工場では同じ手順をSchichtübergabeと呼びますが、原則は変わりません。

報告業務を増やさずに設備データをシフト引き継ぎに活かす方法

シフト引き継ぎがうまくいかない理由

引き継ぎは、人と人の間で情報が失われる場所です。英国安全衛生庁(HSE)は多くの事故がシフト引き継ぎ時のコミュニケーション不全によって起きていると述べ、パイパー・アルファ事故の要因の一つにも挙げています。

Ronny LardnerによるHSEの文献レビューは、典型的な失敗のパターンを挙げています(OTO 96 003)。

  • 一方通行の書面メモに頼りすぎ、誤読されたり、まったく読まれなかったりする
  • あるシフトの記録から次のシフトの記録へ情報が引き継がれない
  • 保全作業がシフト交代をまたいで続く
  • 入ってくる人と出ていく人で、プラントの状態についての認識が違う

製造現場では、その代償はたいてい失われる時間です。夜勤が3時間格闘した詰まりは、朝勤がそれを聞いていなかったために朝にまた起きます。速度を落として運転している設備は、誰も伝えなかったためにそのままになります。

DBR77プラットフォームのスクリーンショット:作業キュー(アラートから生成されたタスク)DBR77プラットフォームのスクリーンショット:作業キュー(アラートから生成されたタスク)
DBR77プラットフォームの画面:作業キュー(アラートから生成されたタスク)(デモ工場のデータ)

引き継ぎで扱うべきこと

HSEは、引き継ぎの内容は入ってくる要員の情報ニーズの分析に基づくべきだとしています。ほとんどの生産ラインでは、そのニーズは四つの項目に収まります。

  1. シフトの主要なロス。 時間で見た上位3つのロスと、その理由。
  2. 未完了のタスクと担当者。 何が終わっていないか、誰が担当か、次に何をするか。
  3. 異常な状態にある設備。 速度を落としている、応急処置で動いている、部品待ちなど。
  4. 安全に関する事項。 ヒヤリハット、未完了の作業許可、保全のために外された安全カバー。

構造化された記録も同じ考え方に基づいています。The Keil Centreの仕組みでは、「安全」「保全・技術的問題」「残作業」をすべての記録で必須の区分としていました。

リアルタイムデータで作るシフト画面を見る

30分のデモで、DBR77 IIoTが主要なロス、未完了のタスク、設備の状態を次のシフトのために自動で準備する様子をお見せします。

デモを予約する

リアルタイムデータで進める10分間の引き継ぎ議題

シフト中の事象はすでにシステムにあるので、最後の30分をその書き起こしに費やす必要はなく、会議はシステムが知りえないことに集中できます。

引き継ぎ項目 データ源 説明する人
時間で見た上位3つのロス 設備の状態とオペレーターの理由から作る停止のパレート図 退出するシフトの班長
計画に対する実績 ラインごとのリアルタイムの個数とOEE 退出するシフトの班長
未完了のタスクと担当者 タスクに変換されたアラートとそのステータス 各タスクの担当者、または保全
異常な状態にある設備 現在の設備状態、減速運転、実施中の応急処置 該当設備のオペレーター
安全に関する事項 ヒヤリハット記録、未完了の作業許可 退出するシフトの班長
質問と確認 なし:対話 入ってくるシフトの班長

ラインの画面の前で、対面で、決まった順番で進めます。

  • 0〜3分: 計画に対する実績と上位3つのロス。パレート図を見せ、シフト全体を語り直さないこと。
  • 3〜6分: 未完了のタスク。各担当者が1文でステータスを述べます。
  • 6〜8分: 異常な状態にある設備と安全に関する事項。
  • 8〜10分: 入ってくるシフトの班長が質問し、最優先事項を復唱します。

HSEは、効果的な引き継ぎを双方向のものとし、引き継ぐ側の要員によるクロスチェックを含むものとしています。復唱は1分で済み、二人がまだその場にいるうちに誤解を見つけられます。

この原則はトヨタ生産方式のアンドンに近いものです。異常は全員に見えるように点灯するので、誰も覚えておく必要がありません。

信号と理由の定義をすべてのシフトでそろえる

データが引き継ぎに役立つのは、すべてのシフトが同じ言葉で同じことを意味している場合だけです。夜勤が材料待ちを「その他」と記録し、日勤が「材料待ち」と記録すれば、パレート図は一つのロスを二つに分けてしまいます。

たとえば一般的な3シフトのラインで、ある班長にとって「チョコ停」は2分未満、別の班長にとっては5分未満を意味することがあります(説明用の例)。二人は同じ画面を見て、違う結論を出します。

これは一度、中央で決めてしまいます。

  • 設備の種類ごとに一つの理由リストを持ち、担当者を一人決める
  • 「停止」「チョコ停」「減速運転」「計画停止」の定義を文書にする
  • リストの変更は、すべてのシフトの引き継ぎで告知する
  • 毎月、「その他」と、あるシフトがまったく使わない理由を確認する

理由を比較可能にするコンテキスト項目については、記事コンテキストのない設備データはなぜ役に立たないのかで扱っています。あるシフトがデータを拒む場合は、オペレーターがまだIoTの信号を信頼していないときにすべきことをご覧ください。

やめるべき手作業の報告

設備の状態と理由が停止時に記録されるようになると、いくつかの報告は重複になります。典型的なのは、各設備にある手書きの停止記録表、シフト終了時のExcelファイル、設備がすでに報告している個数の手作業カウント、翌朝のOEE再計算です。

システムが見えないことについては、短いメモを書いて残してください。物流との口頭での取り決め、品質上の懸念、早退したオペレーターなどです。HSEは口頭と書面の両方によるコミュニケーションを推奨しています。リアルタイムデータがあれば、書面の部分はシステムの記録と2〜3行のメモになります。

報告は一つずつやめてください。データを2週間並行して運用し、班長たちが正しいと認めてからです。まだ頼りにされている報告をなくすと、影のスプレッドシートが生まれます。

1ラインから始める方法

2〜3シフトで運用していて、引き継ぎを短くしたいと考えている班長がいるラインを一つ選びます。導入前と導入後の2週間ずつ、二つのことを測ってください。引き継ぎにかかる時間と、退出するシフトが知っていた問題に入ってくるシフトが驚かされる頻度です。

DBR77 IIoTのオペレーターアプリを使えば、オペレーターは設備の前で理由を入力できるので、引き継ぎ画面はシフト中に埋まっていきます。既知の問題が間に合うように伝われば、対応も早くなります。なぜ最初に対応時間が変わるのかは、記事リアルタイムデータでダウンタイムを減らす方法をご覧ください。

よくある質問

シフト引き継ぎにはどれくらい時間をかけるべきですか?

1ラインであれば、データが自動で準備されていれば約10分で十分です。長期不在の後、シフトをまたぐ保全作業中、異常運転中の引き継ぎはリスクが高く、より多くの時間が必要です。

引き継ぎは書面と口頭のどちらで行うべきですか?

両方です。HSEのガイダンスは、書面の記録に支えられた対面での引き継ぎを推奨しています。リアルタイムデータがあれば、書面の記録はほとんどシステムから得られます。

退出するシフトの班長がいない場合はどうしますか?

入ってくる班長が一人でシフト画面を確認し、未完了の安全事項について退出した班長に電話します。このケースは事前に計画しておいてください。

シフトをまたいで理由リストを管理するのは誰ですか?

一人の担当者で、通常はラインの責任者か生産技術エンジニアです。班長が変更を提案し、各変更は引き継ぎで告知されるので、すべてのシフトが同じ日から使い始めます。

まとめ

シフトの終わりには、引き継ぎ内容の大半がすでにシステムに入っています。そのため実際の作業は、定義をそろえることと重複した報告をなくすことです。2週間は、ラインの画面の前で10分間の議題を従来の報告と並行して進めてください。班長たちがデータは正しいと認めたら最初の手作業の報告をやめ、退出するシフトが知っていた問題に入ってくるシフトが驚かされる回数を引き続き数えてください。

1ラインでデータに基づく引き継ぎを試す

30分のデモを予約いただければ、貴社と同様のラインでシフト画面、タスクの担当者、理由リストをお見せします。

デモを予約する

出典