MES、ERP、SCADAの境界：部署ではなくオブジェクトの主責任で線を引く

3層のシステムは、それぞれ異なる問いに答える

ERPは何を生産し、どの資源が必要で、経営の結果をどう計上するかに関心があります。MESは製造オーダが具体的なラインとステーションでどう実行され、現在の進捗と異常をどう協調するかに関心があります。SCADAは設備が今どの状態にあり、工程量がどう変化し、警報と履歴をどう再生するかに関心があります。

これらの責任は重なり合いますが、重複は同じ状態を繰り返し保存することを意味しません。1つの製造オーダは、ERPで計画の主責任を持ち、MESで実行分解と現場状態を持ち、SCADAでは設備に関連するタスクの文脈としてだけ表示できます。各システムが保存する項目と状態を明確にし、同一の項目を勝手に双方向から書き換えてはなりません。

オブジェクト主責任マトリクスで「全員が管理」を解消する

主責任マトリクスは、少なくとも製造オーダ、材料、製品またはロット、工程バージョン、設備、品質結果および計画カレンダーを網羅すべきです。各オブジェクトについて、作成者、一意の識別子、変更が許される状態、下流の利用者、および削除・無効化の規則を列挙します。

例えば、材料コードはERPで管理し、MESは実行に必要なスナップショットとロット消費を保存し、SCADAは必要な設備の文脈だけを利用する、という分担が考えられます。現場で一時的な材料代替を認める場合は、明確な業務プロセスで承認して結果を返す必要があり、作業者が任意の層でマスターデータを直接変更できるようにしてはなりません。

APS、WMS、QMSを既定でMESの中に押し込むべきではない

APSは制約を考慮した計画とスケジューリングに、WMSは在庫、ロケーションおよび倉庫作業に、QMSは品質計画、検査および品質プロセスに重点を置きます。それらはMESと緊密に協働できますが、独立したシステムとして構築するかどうかは、既存システム、業務の複雑さおよび責任の境界によって決まるのであり、MESが最初からすべての能力を含むわけではありません。

ORPAONはプロジェクトに合わせて、生産スケジューリングのアルゴリズム、WMSインターフェース、品質トレーサビリティなどの統合・受注開発を請け負えますが、これをもって成熟した独立したAPS、WMSまたはQMS製品をすでに持つと示唆するものではありません。提案書では、顧客の既存システム、サードパーティのシステムまたは本プロジェクトの受注開発範囲のいずれが担うかを項目ごとに明記し、「一体化」という言葉で空白を覆い隠すことを避けるべきです。

• 計画の境界：誰がキャパシティと材料の制約を考慮し、誰が計画を承認し、誰が現場の特急オーダを処理するか。
• 倉庫の境界：誰がロケーションと在庫帳を管理し、誰が材料呼び出し、配達および返却を実行するか。
• 品質の境界：誰が検査規格を維持し、誰が判定と合格出庫を行い、誰が発生過程を記録するか。
• 保全の境界：誰が保全と修理の主プロセスを管理するか。アンドンとOEEは必要なイベントだけを提供する。
• 分析の境界：誰が生の工程データを保持し、誰が業務指標を計算し、誰が口径の版を管理するか。

インターフェース設計には契約、補償および突合が必要である

インターフェースは項目一覧にとどまりません。トリガーのタイミング、メッセージまたは呼び出しの一意識別、べき等の規則、タイムアウト、再試行、順序、権限、エラーコードおよび手動補償の入口を定義する必要があります。とりわけ製造オーダの指示出しと完了報告では、重複実行や状態の消失を防がなければなりません。

突合はインターフェースのループの一部です。システムは双方の主要オブジェクトの数量、状態および版を比較し、差異を表示できるべきです。通信断絶中にどちら側の作業続行を許すか、復旧後にどの順序で補送するかも、業務と制御のリスクに基づいて共同で決めなければなりません。

1本のエンドツーエンド業務チェーンで境界を検証する

すべてのアーキテクチャ図を先に描いてから用途を探すべきではありません。製造オーダの指示出し、材料確認、設備実行、品質判定および完了報告のような代表的な業務チェーンを1本選び、オブジェクトの主責任、状態の変化および例外処理を段階的に書き込めば、本当の境界が見えてきます。

テストは正常経路に加えて、インターフェースのタイムアウト、重複メッセージ、マスターデータの取消、現場での手直し、設備の断線および手動による追記も網羅すべきです。例外経路にまで責任と復旧の方法がなければ、システム境界は実装されたとは言えません。

• 現状の棚卸し：既存システム、版、インターフェース、データの所有者および運用上の制約。
• オブジェクトマトリクスの作成：項目ごとに主責任を確認し、部門名でシステムの責任を代替しない。
• 最小インターフェースの定義：選定した業務チェーンを優先して支え、全データの一括同期を避ける。
• 例外経路のリハーサル：再試行、補償、突合、断線および手動承認を検証する。
• 運用契約の確立：監視、当番、変更および版管理を受入と運用に組み込む。

一体化、リアルタイム化、双方向同期の落とし穴を避ける

「統合プラットフォーム」はすべての機能を同一のシステムで担うことを意味せず、「リアルタイム同期」もすべてのデータをミリ秒レベルで伝送することを意味しません。経営の受注、ロットの実行および高速な工程信号は時間スケールと整合性の要求が異なり、混ぜれば不要な複雑さを生みます。

双方向同期が既定で最適というわけではありません。同一のオブジェクトに対して複数の側が自由に変更することを許すと、更新の循環と責任の不明確さを招きやすくなります。より安全な方式は、主責任、一方向の公開および管理された書き戻しを明確にし、すべての例外に承認と監査を残すことです。

• ソフトウェアの名称で責任の定義を代替しない。
• 項目数でインターフェースの完全性を測らない。
• SCADAに、未評価の企業業務トランザクションを直接担わせない。
• MESに、既存の制御と安全の境界を迂回して高リスクの動作を直接指示させない。
• 未確定のAPS、WMS、QMSまたはTPMの機能を、標準の既存製品として書かない。