テーマ11:情報基盤の理解(ERP / MES / PLM / QMS)
学習週:Week 13
優先度:支援(道具より責任分担の設計が重要)
1. システムの責任分担(ISA-95モデル)
Level 4:ERP(企業レベル)
責任:受注・調達・在庫・財務・原価・人事
代表製品:SAP, Oracle, 弥生
Level 3:MES(製造実行レベル)
責任:製造指示・作業実績・品質記録・トレーサビリティ
代表製品:Wonderware, Siemens Opcenter
Level 2-1:SCADA・PLC(工程制御レベル)
責任:設備制御・センサーデータ収集
─── 別軸 ───
PLM(製品ライフサイクル管理)
責任:図面・BOM・設計変更・製品仕様
代表製品:PTC Windchill, Siemens Teamcenter, Dassault ENOVIA
QMS(品質管理システム)
責任:品質計画・不適合管理・是正処置・監査・文書管理
代表製品:ETQ, MasterControl
2. システム間連携の設計原則
重要原則:
① 各システムが「唯一の真実の源(Single Source of Truth)」を持つ
② 同じデータを複数システムが独立して持たない
③ 連携は明示的に設計する(自動連携 vs 手動連携)
品番情報の例:
PLM → 品番マスターを持つ(唯一の正)
ERP → PLMから品番を取得(参照)
MES → ERPまたはPLMから品番を取得(参照)
2.1 主要な連携パターン
| 連携 | 方向 | 内容 |
|---|---|---|
| PLM → ERP | 設計→生産管理 | BOM・品番・仕様 |
| ERP → MES | 計画→実行 | 製造オーダー・日程計画 |
| MES → ERP | 実行→計画 | 実績・在庫・品質データ |
| PLM → MES | 設計→現場 | 作業手順・設備条件 |
| MES → QMS | 実績→品質 | 検査データ・不適合記録 |
3. 連携方式の使い分け
| 方式 | 使いどころ | リスク |
|---|---|---|
| API(リアルタイム連携) | タイムクリティカルな情報 | システム障害の影響が伝播 |
| CSVファイル連携(バッチ) | 日次・定期の情報更新 | タイムラグ・手動ミスのリスク |
| 手動転記 | 量が少ない・変化が少ない | 転記ミス・工数 |
| DB直結 | 高速・大量データ | 密結合による保守困難 |
4. どのシステムに何を持たせるか
間違えやすい責任分担の例:
× MESで設計変更を管理する
→ 設計変更の正はPLMにある。MESへの反映は連携で行う
× ERP に図面PDFを格納する
→ 図面管理はPLMの責任。ERPは品番の財務情報のみ持つ
× Excelで独自に部品表を管理し続ける
→ PLMとの二重管理になり整合性が崩れる
推奨参考資料
| 種別 | タイトル | 用途 |
|---|---|---|
| 規格 | ISA-95 / IEC 62264 | 製造統合システムの国際標準 |
| Web | PTC: PLM・ERP・MES連携ガイド | 連携設計の実務解説 |
| Web | Siemens: ISA-95フレームワーク層 | 図解でわかる層モデル |
| 論文 | Integration of PLM, MES and ERP(Inria 無料) | 統合最適化の学術研究 |
✅ 実務チェックリスト
このテーマを「理解した」と言えるための確認項目
- ISA-95のLevel 0〜4を自社の製品・設備・部門名で当てはめて説明できる
- 自社のERP・MES・PLMの役割分担と連携方式(API/ファイル/手動)を図示できる
- システム間のデータ連携の現状マップを作れる(どこが自動でどこが手動か)
- 「システム連携の断絶点」(手動入力が発生している箇所)を3箇所以上特定できる
- クラウド・オンプレミスの選択基準(データセキュリティ・応答速度・コスト)を説明できる
💡 ETO製造での適用ポイント
ETO企業では「PLMとERPの間に壁がある」ことが最大の非効率源である。設計BOMと製造BOM・調達BOMが同期していないために、設計変更のたびに各部門が手動でデータを転記する。「設計が変わったのに製造は古い図面で作業していた」という事態は、このデータ断絶が原因だ。DXにおける最優先投資はこの「BOM連携の自動化」であることが多い。
MESは「何をいつ誰が作ったか」の実績記録に特化させ、ERPとはワーク完了実績の連携のみを行うシンプル構成から始めると立ち上げリスクが低い。最初からすべてを連携しようとすると、システム設定の複雑さとテスト工数が膨大になる。段階的な連携拡張が成功の鍵だ。
ETO特有のシステム要件として、「プロジェクト(製番)コンテキストでのデータ管理」がある。同一部品番号でも案件Aと案件Bでは使用条件・検査基準が異なることがある。この「コンテキスト依存性」を扱えるシステム設計が、ETO向けのIT基盤には必要だ。
クラウド移行の判断では、ETO企業特有の「顧客仕様データの機密性」と「ネットワーク不安定な製造現場での可用性」を重視する必要がある。設計データ(図面・仕様書)のクラウド保管には顧客の同意が必要な場合もあるため、契約条件の確認が前提となる。
🔗 関連テーマ
| テーマ | なぜ関連するか |
|---|---|
| ECM/PLM(テーマ4) | PLMはECM機能の中核システム |
| AI活用(テーマ12) | AIはITインフラ上に構築されるため、基盤設計が前提 |
| PoC設計(テーマ13) | PoC実施にはデータ取得インフラの整備が必要 |