スマートファクトリーソフトウェアとERPの連携:工場長のためのガイド
Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.
By Mirko Peters ·
スマートファクトリーソフトウェアとERPの連携は、どのデータを、どの方向に、どれくらいの速さで流すかに尽きます。チェックリスト付きの、工場長向けの平易なガイドです。
Automatically translated with AI from the original post. Read the English original
スマートファクトリーソフトウェアとのERP連携とは、計画システムと現場のソフトウェアが定められた方法でデータを交換することを意味します。受注やマスターデータは現場へ流れ、進捗、数量、材料使用量、時間は戻ってきます。難しいのはコネクタではありません。何を、どの方向に、どの頻度で流し、各データオブジェクトを誰が管理するかについて合意することです。このガイドは、そのようなプロジェクトを推進する立場にあり、ITベンダーやIT部門により良い質問をしたい工場長に向けたものです。
重要なポイント
- スマートファクトリーソフトウェアとのERP連携は、まずデータに関する合意です。どのオブジェクトを、どの方向に、どの頻度で流し、誰が管理するのかを決めることです。
- ISA-95は、工場とIT部門が共通の用語を持つための枠組みを与えます。ERPは事業計画のレベルに位置し、製造オペレーション用ソフトウェアはその一段下に位置します。
- 通常、受注はERPから現場へ流れ、着手数、完成数、廃棄数、材料使用量、時間は現場から上位へ戻ります。
- 部品表や工程表などのリファレンスデータは、受注メッセージとは別のフローであり、多くの場合もっとも弱い連携部分になります。
- まず1つのラインと1つの受注フローから始め、エラー処理は意図的にテストし、項目を増やす前に計画と実績を比較してください。
スマートファクトリーソフトウェアとのERP連携は何をカバーするのですか?
まず、各層の全体像を共有することから始めます。ISA-95規格(IEC 62264とも呼ばれます)について、ISAは、事業系システムおよび物流システムを製造制御システムと統合するための国際規格群だと説明しています。Purdue Reference Modelに基づく5層モデルを採用しており、製造部門とIT部門の双方が連携プロジェクトで共通の用語を使えるようにします。
OPC Foundationによ るISA-95の要約では、各層は次のように整理されています。
- レベル0~2は、物理プロセス、センサーとアクチュエーター、PLCによるオートメーションと制御を対象とします。
- レベル3は製造オペレーション管理です。数秒から数日の時間軸で動作し、スケジューリング、作業追跡、品質、在庫の機能を含みます。
- レベル4は事業計画と物流で、数日から数か月の時間軸で動作し、通常はERPシステムで実現されます。
この規格が主に扱うのは、レベル3とレベル4の間の情報交換です。その交換のために、規格は4種類の情報、すなわち材料、設備、物理的資産、そして役割と資格を持つ要員を挙げています。これはそのまま使えるチェックリストです。プロジェクト計画に、この4つのそれぞれが一方からもう一方へどう渡るのかが書かれていなければ、何かが欠けています。
レベル3は通常、製造実行システム(MES)が位置する層です。インダストリー4.0やスマートファクトリーが語られるとき、多くの場合は、これらの層の間のデータがより頻繁に、より少ない再入力で流れることを指しています。「スマート」という言葉が新しい魔法をもたらすわけではありません。良い連携は、従来と同じ規律を、より一貫して適用することにほかなりません。
どのデータをどの方向に流すべきか?
2つのフローを考えてみてください。受注は上から下へ、フィードバックは下から上へ流れます。さらに、マスタデータ用の3つ目のフローがあります。
Microsoftは具体例を公開しています。Dynamics 365 Supply Chain Managementとサードパーティ製の製造実行システム(MES)の統合は、自社の現場機能の代わりに外部MESを使う企業向けです。対象となるプロセスは次のとおりです。
- 生産オーダーのリリースと、その後のステータス変更はERPからMESへ送られます。MESはビジネスイベントを監視します。
- オーダーの開始は、MESからERPへ報告されます。
- 製造数量と廃棄数量はERPへ戻されます。
- 資材消費もERPへ戻され、計画と販売で在庫を正確に保てるようにします。
- 作業に要した時間も同様にERPへ戻されます。
- オーダーの完了は最終ステータスとしてERPへ戻されます。これ以降、数量の報告は届かないものとします。
このページには、実務で重要になる制約も記載されています。製品、部品表、ルート、段取り時間などの参照データは、これらのメッセージでは送信されません。データエンティティを使って別途取得する必要があります。つまり統合ジョブは1つではなく2つ必要で、2つ目は見落としやすい点です。
この一覧を活用するために、Dynamics 365を使う必要はありません。使用しているERPや現場ツールが何であれ、同じ表を作成してください。項目は、オブジェクト、送信元、送信先、トリガー、頻度、担当者です。担当者が空欄の行があれば、それが最初のリスクです。
なぜマスタデータが弱点になるのでしょうか。
受注は取引データです。一方、ルート、部品表、作業時間は製品の作り方を定義するもので、現場ツールはそこに含まれる誤りをすべて引き継ぎます。たとえば、実際には20分かかる作業が12分と登録されていると、現場では永遠に生産性の問題に見えてしまいます。現場がマスタデータと矛盾する情報を報告した場合に、誰が修正するのか、そしてその修正がどれくらい速やかにERPへ反映されるのかを決めておいてください。
データはどのくらいの速さで流れる必要があるのでしょうか。
「リアルタイム」はこの分野で最も乱用されている言葉なので、数値で定義しましょう。
ISA-95自体も、レベルごとに扱いを分けています。OPCの概要では、レベル3におけるリアルタイムとは現場イベントの数秒後を意味し、レベル4では毎日、またはシフト終了後数時間以内を意味します。これらは性質の大きく異なる約束であり、かかるコストも大きく異なります。
各フローについて、どのような意思決定を支えるのかを確認してください。
- ジョブが遅延したときに人員を配置し直す監督者には、数分単位の情報が必要です。
- 明日のオーダーを計画し直す計画担当者には、シフト終了時点のステータスが必要です。
- オーダーのコストを締める経理担当者は、オーダーが完了するまで待つことができます。
意思決定に速度が必要な箇所にはコストをかけてください。それ以外では、スケジュールされた転送の方が運用が簡単で、修復もしやすくなります。
何か問題が起きたときにメッセージがどう振る舞うかも確認してください。Microsoftのドキュメントによると、1つの生産オーダーに関するメッセージは到着順に処理されます。異なるオーダーのメッセージはジョブが並列実行されるため、順序どおりに処理されない場合があります。処理に失敗したメッセージは、失敗としてマークされる前に3回再試行されます。受信メッセージを監視するページもあります。自社のシステムでこの細部まで同じである必要はありませんが、同じ問いへの答えは必要です。つまり、順序、再試行、障害が表示される場所、そしてそれを確認する担当者を明確にしておくことです。
システム同士はどのように接続すればよいのでしょうか。
一般的なパターンは4つあり、多くの工場では複数を組み合わせて使っています。
- 事前構築済みコネクタ: 特定のERPと特定のMESを接続します。最も早く開始できますが、コネクタがカバーする範囲に限られます。
- APIまたはメッセージ層を介したインターフェース: 柔軟性が高い一方で、マッピングとテストは自社で管理する必要があります。
- ファイルまたはスプレッドシートによる転送: 地味ですが、マスタデータや週次の生産能力など、変化の少ないデータには十分な場合が多くあります。
- 手入力による代替手段: 障害時のために用意しておきますが、通常時の前提にはしないでください。
ベンダーの提案を比較する際は、次の点を確認してください。
- インターフェースがどのオブジェクトと方向を対象としていて、どれを対象としていないのか。優れたベンダーは、催促しなくても後者について明確に回答します。
- エラーはどのように報告され、誰が確認し、メッセージはその後どうなるのか。
- 必要なERPのバージョン、ライセンス、設定は何か。たとえばMicrosoftのページでは、統合の前提条件としてライセンスキーが挙げられています。こうした詳細がプロジェクトの期間を左右します。
- ERPが停止している間も現場ツールは稼働し続けられるか、そして復旧後に未送信分を追いつかせられるか。
- 製品ファミリーや新しい作業センターを追加したとき、マッピングは誰が管理しますか。
Dynamics 365 Supply Chain Management にも独自の現場報告機能があり、作業者はリソースごとのジョブ一覧から生産ジョブを選び、作業時間と品目の消費量を登録できます。現場での報告要件がすでに ERP で満たせるのであれば、別途 MES は不要かもしれません。決定する前に、どのような情報を記録する必要があるのかを確認してください。
セキュリティはどうでしょうか。
現場を業務システムに接続すると、これまで隔離されていた機器への新しい経路が生まれます。NIST の Guide to Operational Technology Security(SP 800-82 Revision 3)では、一般的な OT のトポロジ、一般的な脅威と脆弱性、対策を扱うとともに、OT に求められる性能、信頼性、安全性の要件も考慮しています。設計を確定する前に、ご自身で読むか、セキュリティチームに読んでもらってください。
特定の製品を前提としなくても、次の実践的なルールが当てはまります。
- 業務システムと機械ネットワークの間で許可する接続を決め、文書に残してください。
- each 連携ごとに専用のアカウントを用意し、必要な権限のみを付与してください。
- 生産を止めずに、パッチや変更を連携レイヤーへどう届けるかを計画してください。
- 現場のインターフェイスをインシデント対応計画に含めてください。
プロジェクトはどのように進めるべきでしょうか。
小さく始めて、測定可能な形にしてください。
- 1つのラインと1つの受注フローを選んでください。 工場全体ではありません。
- データオブジェクトを一覧化してください。 受注、資材、時間、数量について、それぞれ送信元、受信先、責任者を明確にします。
- そのラインのマスターデータを最初に整備してください。 作業手順、部品表、作業センターが対象です。
- ステータスの定義をそろえてください。「開始」「完了」「終了」が、両側で同じ意味になっている必要があります。
- 失敗を意図的にテストしてください。 誤った数量を送信し、インターフェイスを停止して再起動し、何が起こるかを確認します。
- 数週間、旧プロセスを残したまま並行稼働させてください。
- 計画と実績を比較してください。 ERP が受け取る数値が現場と一致しているかを確認します。
- その後、次のラインへ拡張してください。
よくある間違い
- データを定義する前にコネクターを購入すること。 コネクターは、誤ったデータも含めて、与えられたものをそのまま転送します。
- マスターデータを無視すること。 受注メッセージは正常に流れても、現場と計画が食い違ったままになります。
- すべてにリアルタイム性を求めること。 不要な判断にまでコストを上乗せし、障害の発生箇所を増やしてしまいます。
- エラーの責任者がいないこと。 誰かが在庫の不整合に気づくまで、失敗したメッセージが蓄積し続けます。
- セキュリティを後のフェーズに回すこと。 設計段階で対応する方が、本番稼働後に対応するよりはるかに低コストです。
- 現場の担当者を置き去りにすること。 新しい報告作業が紙よりも遅いと作業者が感じれば、回避策を使うようになります。
Polaris が役立つ場面
ERP の計画と現場の実態の間に主な課題がある場合は、iFAKT Polaris も検討対象の一つになります。iFAKT は Polaris を、生産向けの AI とデジタルツインを組み合わせたもので、ERP、Excel、現場のデータを扱うと説明しています。Polaris Designer モジュールは、ERP データ、部品表、工程時間、リソース構成を、製品・工程・リソースのナレッジグラフに変換します。Polaris Operator モジュールは、最適化された計画を時間単位のタスクとして現場に届け、進捗、遅延、混乱の情報を計画へ戻します。このようなツールを導入するかどうかを決める前に、ご自身の受注フローに対して必ず検証してください。
今後調べると良い関連トピック
- 接続された工場のOTセキュリティ。 機械ネットワークをどのようにセグメント化するか、連携レイヤーへのアクセスを誰が確認するか。
- 現場報告の変更管理。 作業者を失うことなく、新しい報告手順をどう導入するか。
- 計画と実績の比較。 ERP の計画が現場の実態と今も一致しているかを示す、少数の指標は何か。
- 稼働中の生産モニタリング。 監督者が画面で必要とする情報と、管理者が日次レポートで必要とする情報。
- 予知保全のデータ。 予測を計画する前に収集する価値のある機械データは何か。
次のステップ
データ契約を文書で明確にしておけば、スマートファクトリーにおけるERPとの連携はぐっと進めやすくなります。今週中に1つの生産ラインを選び、対象データ、送信者、受信者、データオーナーを一覧表にまとめてみてください。それを次回のIT部門との会議に持ち込めば、議論がずっと具体的になります。