ナレッジベース
導入・展開1 分で読める

一つのパイロットから工場標準へ：IoTを全ラインに展開する方法

DBR77 Team · 公開日

成功した一つのIoTパイロットを工場標準にするには、パイロットを機能させた要素を固定します。状態モデル、理由のカテゴリー、アラートの経路、見直しの頻度です。設備の接続、詳細な理由、閾値など、ラインごとに違わなければならないものだけを調整し、担当者が一人決まった手順書に沿って1ラインずつ展開します。

DBR77のPaweł Deraは「1ライン、1パイロット。約束ではなく、測定で」と言います。最初のラインで結果が出たら、次は結果がパイロットを担当した人に依存しないよう、工場全体で対応を仕組み化する段階です。

一つのパイロットから工場標準へ：IoTを全ラインに展開する方法

良いパイロットが1ラインで止まってしまう理由

McKinseyは、多くの企業を悩ませる「パイロット煉獄（pilot purgatory）」について述べています。パイロットはうまくいくのに、規模の大きな価値はいつまでも生まれない状態です。世界経済フォーラム（WEF）とMcKinseyが1,000以上の製造拠点を評価したところ、こうした技術を大規模に導入している先進企業は44社で、2020年にさらに10社が加わりました。そうした先進企業でさえ、拠点網全体に効果を広げようとすると、WEFが「スケーリング・スランプ（Scaling Slump）」と呼ぶ壁に直面しています。

中規模工場でよくある理由は、パイロットのルールが一人の推進者の頭の中にしかなく、なぜうまくいったのかを誰も書き残していないことです。そのため2本目のラインは新しい定義でゼロから始まり、数字は比較できなくなります。

DBR77プラットフォームのスクリーンショット：Data Bridge：デバイス証明書（mTLS）DBR77プラットフォームのスクリーンショット：Data Bridge：デバイス証明書（mTLS）
DBR77プラットフォームの画面：Data Bridge：デバイス証明書（mTLS）（デモ工場のデータ）

パイロットから固定すべきもの

人がどう対応するかを決める要素を固定します。これらはすべてのラインで同一にします。

  • 状態モデル。 稼働、停止、段取り替え、材料待ち、計画停止の定義を共通にします。
  • 理由のカテゴリー。 共通の上位リストです。たとえば機械、電気、材料、品質、運用など8つのカテゴリーです。
  • アラートの経路とエスカレーション。 停止のカテゴリーごとに、シフト内の一つの役割に届けます。5分以内に確認がなければ班長に通知されます。
  • 見直しの頻度。 各シフトの開始時に主要なロスについて10分、それに加えて保全との週次の見直し。
  • KPIの定義。 OEEの計算式と対応時間の定義を一つにします。たとえば広く使われているVorneのベンチマークでは、可用性90%、性能95%、品質99%からOEE 85%を算出します。2本のラインでOEEの計算方法が違えば、比較には意味がありません。

Lean Enterprise Instituteは、標準作業を改善の基準と位置づけています。標準を固定しておけば、4本目のラインでの変更が本当に効果を上げたかどうかが分かります。

ラインごとに調整すべきもの

コピーできないものもあり、無理に合わせると抵抗を生みます。

  • 設備の接続。 最新のPLCがあるラインは直接読み取り、古いラインにはエッジデバイスやカメラが必要です。
  • 詳細な理由。 共通カテゴリーの下に、オペレーターが自分たちの言葉で理由を名付けます。設備の種類ごとに10〜15個です。
  • 閾値。 プレス機と包装機ではチョコ停に必要な制限値が異なるため、設備の種類ごとに設定します。
  • シフトのパターンと担当者。 役割は同じままで、名前とシフトの時間帯が変わります。

複数の拠点を運営している場合は、同じ切り分けを一つ上のレベルで適用します。これについては、記事一つのテンプレートを押し付けずに拠点をまたいでIoTの価値を証明する方法で扱っています。

パイロットを標準にしようとしていますか？

最初のラインで何がうまくいったかをお聞かせください。1回の打ち合わせで、固定すべきものと調整すべきものを切り分け、展開の順序を描くお手伝いをします。

相談する

展開手順書

手順書は数ページの短い文書です。新しいラインごとに、誰が何をどの順序で行うかに答えます。各要素には担当者が一人います。

手順書の要素 内容 担当者
状態モデルとKPIの定義 固定された定義、OEEの計算式、対応時間 標準の担当者（継続的改善またはオペレーショナル・エクセレンスの責任者）
理由のカテゴリー 共通の上位リスト、ラインごとの詳細 標準の担当者とラインの責任者
接続調査 設備リスト、設備ごとの接続方式、ネットワーク 保全とIT/OT
アラートの経路とエスカレーション 停止カテゴリーごとの役割、エスカレーションまでの時間 ラインの責任者
ベースライン 2週間分の対応時間、「不明」の割合、主要なロス ラインの責任者
教育 設備の前での理由入力、アラートへの対応 班長
見直しの頻度 毎日のシフトでの見直し、保全との週次の見直し 製造課長
稼働開始の判断 下記のチェックリスト、8週目の成功基準 生産本部長

新しいラインの稼働開始前に、次を確認します。

  1. 対象範囲のすべての設備が状態を報告しており、現場で検証済みである。
  2. オペレーターが自分のラインの詳細な理由リストを確認した。
  3. 夜勤を含むすべてのシフトでアラートの経路をテストした。
  4. ベースラインが記録され、承認されている。
  5. 成功基準が文書になっている。たとえば8週目までに対応時間10分未満。

ラインの順序の決め方

次のラインは、価値、類似性、オーナーシップで選びます。ボトルネックのラインは最も大きな価値を生み、パイロットと同じ種類の設備を持つラインは作業の大部分を再利用できます。ラインの責任者自身がシステムを求めている場合も、展開はかなり進めやすくなります。

製品の立ち上げ期間中にラインを始めるのは避けてください。1〜2ラインずつの波で展開し、標準の担当者が毎週見直せる数を超えてラインを並行させないでください。ペースの参考として、一般的な既存設備の工場をモデル化した基本ケースでは、約3週間で13台中11台の設備が接続され、見える化されます。計画の目安として使い、自社のラインと照らし合わせてください。

各ラインはそれぞれのベースラインと比較して測定します。ある段ボール包装工場のパイロットラインでは、停止への対応時間が24分から9分に短縮しました。2本目、3本目のラインはそれぞれ独自の数字になります。ラインごとに追跡すべき項目は、最初の90日間の記事に挙げています。

標準を管理する方法

標準の担当者を一人決め、版管理を行ってください。固定された要素の変更は、何を変えるか、なぜか、どのラインに影響するかを記した短い申請を通します。理由のカテゴリーは四半期ごとに見直し、誰も使わないものは削除します。

DBR77によるCMMIとデータ成熟度の解説では、定義された標準プロセスを、大規模な自動化の入口と位置づけています。

複数のラインが見えるようになったら、DBR77 IIoTからDBR77 IRISへと引き継ぎます。IRISは、それらすべてのラインでの対応を、一つの閉じた、繰り返し可能な実行ループとして運用します。このステップについては、記事IoTを繰り返し使えるオペレーティングシステムにする方法で説明しています。

よくある質問

一度に何ラインを展開すべきですか？

1回の波で1〜2ラインです。制約になるのは設置の速度ではなく、標準の担当者が各ラインを毎週見直せる時間です。

ラインごとの違いが非常に大きい場合はどうすればよいですか？

それでも状態モデル、理由のカテゴリー、アラートのロジック、見直しの頻度は固定してください。違いは接続、詳細な理由、閾値に持たせます。そうすれば、ライン間で数字を比較できます。

標準の担当者は誰にすべきですか？

製造部門か継続的改善の担当者です。IT/OTは接続とセキュリティを担当します。標準とは、生産がどう対応するかについてのものです。

展開がうまくいっているかどうかは、どうすれば分かりますか？

各ラインが数週間以内に、対応時間と「不明」の停止時間で自らのベースラインを上回るはずです。そうでなければ、まずアラートの経路と毎日の見直しを確認してください。

IRISはいつ導入しますか？

複数のラインが見えるようになり、工場がそのすべてにわたって、タスク、保全、品質、安全のための一つの実行ループを求めるようになったときです。

まとめ

標準の大部分はすでにパイロットラインにありますが、多くの場合、それを担当した人たちの頭の中にしかありません。2本目のラインを選ぶ前に、そのチームに上の手順書の表を埋めてもらい、標準の担当者を決めてください。そのうえで次のラインで2週間分のベースラインを記録し、8週目の目標、たとえば対応時間10分未満を文書にしておきます。

ラインをまたぐ展開を計画する

パイロットの結果を確認し、貴社と一緒に手順書の草案を作り、次に展開するラインの順序を決めます。

お問い合わせ

出典

ナレッジベースデモを予約