設計変更のPLM・ERP連携導入｜版数・適用日・仕掛品をつなぐ実務設計

設計変更のPLM・ERP連携を導入するとき、変更通知をERPへ送るだけでは工場の混乱は止まりません。承認した図面の版が、どの品目、BOM、工程、発注、在庫、製造指図にいつから適用されるかを決め、実行結果まで照合する必要があります。タイ工場の調達と製造を念頭に、ECO/ECNから現場切替までの要件定義、RFP、FAT/SATを具体的に整理します。

設計変更のPLM・ERP連携で解くべき課題

PLMは製品の設計情報と変更承認を扱い、ERPは品目、調達、在庫、原価や製造指図を管理し、MESは現場の作業と実績を記録します。ただし「どのシステムが正本か」は製品名だけでは決まりません。図面と設計BOMの承認はPLM、購買可能な品目と発注はERP、作業時点で使用した部材と工程の証跡はMESというように、情報項目と状態ごとに所有者を決めます。既存のERPと生産管理の連携設計では広い連携範囲を扱いました。本稿は、承認済みの設計変更が量産中の工場へ入る際の切替境界に絞ります。

たとえば部品Aを部品Bに替えるECOが承認されても、ERPが旧BOMで発注を続け、MESが新しい作業手順を表示したら、同じ製造指図の中で設計版と実装版が食い違います。逆に、ERPのBOMを直ちに新しくしても、旧部品を積んだ仕掛品や出荷予定品に変更を遡及させるべきとは限りません。必要なのはデータの単純な同期ではなく、「誰が、何を、どの境界から新仕様にするか」を合意したうえで、各システムが同じ決定を再現できる状態です。

MicrosoftのEngineering change management overviewは製品版、ライフサイクル、変更要求・変更指図を別の要素として説明しています。同社の変更指図の説明は、提案段階では実マスタを更新せず、承認後の処理で反映すること、未処理の製造指図や在庫への影響を評価することを示しています。これは特定製品の画面をそのまま導入すべきという意味ではありません。連携要件を「申請」「承認」「リリース」「適用」「実績確認」に分ける根拠になります。

承認・公開・適用・完了は別の状態

変更が承認された日と、新しいBOMを生産に使い始める日は別です。承認後でも部品の供給が間に合わなければ、調達開始日と現場適用日を分ける必要があります。図面の公開、ERPの品目・BOM更新、MESの作業手順更新を一つの「完了」フラグに丸めると、どの段階で止まったのか追えません。ECO単位の状態に加え、品目・拠点・連携先ごとの配信状態と確認日時を持たせます。

変更通知をメールやAIで素早く届ける話題は、既存のAIを使った設計変更管理で扱っています。通知が届いたことと、生産に正しい版が使われたことは別の確認です。ここでは、承認後のデータ契約と現場での実行結果を中心にします。

ECO/ECNからERP・MESまでの変更単位を定義する

ECRは変更要求、ECOは実行する設計変更の指図、ECNは関係者への変更通知を指すことが多いものの、呼称と役割は企業で異なります。導入プロジェクトの最初に、社内で使う名称、発行条件、承認者、取消方法を定義します。インターフェースのキーを「件名」のような人間向け文字列にせず、変更ID、変更明細ID、品目ID、版、拠点、有効条件を組み合わせます。ECO一件が複数品目や複数拠点を含む場合、全件一括で成功か失敗かを返すだけでは復旧できません。

連携レコードは少なくとも、変更ID、対象品目、旧版・新版、変更対象のBOM行と工程、適用条件、承認状態、リリース状態、発行時刻、送信元、イベントIDを保持します。数量、単位、代替部品、図面参照、作業指示などが変わるなら差分と変更前後の値を明示します。ERPへ送る単位はERPが受け取れるマスタ更新と整合させ、MESには現場に必要な版、手順、検査条件を渡します。CADファイル全体を毎回ERPへ複製する設計は避け、アクセス権を持つ正本への参照を管理します。

この表は製品固有の標準仕様ではなく、要件定義で埋める責任分界の例です。特に製造BOMをPLMで作るかERPで作るかは既存業務で変わります。SiemensのMBOM管理に関する説明も、設計BOMと製造BOMは目的が異なり、設計変更後に整合を保つ必要があると説明しています。どちらかを無条件にコピーするのでなく、部品代替、組立順、拠点固有の製造用部材をどう承認するかを決めます。

版数管理を「画面表示」から取引の追跡まで広げる

同じ品目番号の版を上げるか、新しい品目番号を発行するかは、互換性、在庫区分、顧客承認、調達条件で変わります。旧版と新版を同じ在庫として扱ってよいかも決めます。Microsoftの版数を取引で追跡するかというFAQは、版を取引ディメンションに含める場合は在庫・計画まで版別に管理できる一方、管理負荷が増すと説明しています。版を取引で追跡しない場合でも有効期間でBOMや工程の適用を制御できますが、「どの出荷にどの版を使ったか」の粒度は別途検討が必要です。

そのためRFPには「版数管理あり」とだけ書かず、仕入先ロットから完成品シリアルまで版を追える必要があるか、混在出荷を許すか、旧版を再製造できるか、サービス部品の供給をどう扱うかを記します。全品目を同じ厳格さで扱うより、製品リスクと顧客要求に応じた分類が現実的です。判定基準の例は互換性、回収・品質調査の必要性、ロットトレース要求です。法的要求については対象製品と市場ごとに確認し、一般論で断定しません。

設計変更の適用日と効果範囲をどう決めるか

「10月から新仕様」と書いても、タイ現地時間のどの時刻か、指図発行日と着手日のどちらで判定するかが決まらなければ再現できません。さらに生産ラインが複数あり、在庫拠点や委託先が異なれば一律の暦日では足りない場合があります。適用条件を日付だけでなく、拠点、製造指図、ロット、シリアル、顧客オーダーなどのうち何で判定するかを業務として決めます。システムが対応しない条件は運用上の確認点として残し、「入力できるから制御できる」と誤解しないようにします。

SAPのEngineering Change Managementの説明は、変更番号を使ってBOM、工程、文書を関係づけ、有効開始日を持たせる考え方を示しています。Oracleの作業定義の編集に関する説明では、品目版と日付に応じて有効な構成品と作業定義を表示し、ECO由来の日付には変更指図番号が付くと説明しています。いずれも「日付があるから安全」という意味ではなく、日付を判定する取引と作業定義の関係を試験すべきことを示します。

切替基準を一文で書けるか

例として「タイA工場の製品Pは、承認済みECO-XXXを受け、指定日以降に発行される製造指図のうち未着手の指図から新BOMを適用する。発行済みで着手済みの指図は旧版を完了する。ただし顧客指定ロットは個別承認する」のように書きます。これはあくまで設計例であり、そのまま使う標準ルールではありません。生産管理、設計、品質、購買が同じ文から同じ対象指図を抽出できることが要件です。

実務では「設計承認」「部品の入荷可能」「ERPマスタ反映」「MES手順反映」「現場教育」「検査治具の準備」という別の時点があります。新仕様の開始時刻は、最も遅い準備完了項目を確認して決定します。承認後に日付を変更した場合は、元の適用条件、変更理由、再承認者、ERP/MESへの再送、未処理指図の再評価を記録します。予定の適用日が過去になった変更は自動適用せず、影響評価へ戻すルールを検討します。

仕掛品・在庫・発注残を切替時にどう扱うか

量産中の変更では、BOMだけを更新しても現場は切り替わりません。旧部品の手持ち在庫、入荷予定、発注残、払い出し済み部材、進行中の仕掛品、完成品在庫を一覧にし、それぞれの処置を決めます。Microsoftの変更指図ガイドも、未完了の販売・製造指図や手持ち在庫への影響評価を説明しています。ERPから照会できる数量と、現物がどこにあるかの確認を組み合わせます。

処置の選択肢には旧版を使い切る、新版へ手直しする、代替を承認する、隔離する、廃棄する、仕入先に変更を依頼するなどがあります。どれが正しいかは互換性、品質・顧客条件、部品供給、コストに依存します。選択した処置は対象ロット・指図と承認者に紐づけ、ERP上の在庫状態とMESの作業実績にも反映させます。「旧版在庫を使い切る」という口頭判断だけでは、次のシフトで新旧が混ざる恐れがあります。

WIP例外は開始前に試験ケースにする

指図が未着手、部材払い出し済み、組立中、検査待ち、完成後の五状態にある場合を想定します。各状態について、変更の自動適用を許すか、保留して現場判断するか、旧版で完了するかを表にします。部材払い出し済みでもまだ取り付けていない場合、単純な「着手済み」フラグだけでは判断できません。工程と材料消費の実績を確認できるかが鍵になります。

この表も設計用の叩き台です。MESが実装版を追跡できなければ、ERPの指図版だけで正確なas-builtを保証できません。作業者が実際に読んだ手順版、スキャンした部材ロット、検査記録を結びつける要件が必要です。反対に、すべての作業に過剰な入力を課すと現場の記録品質が落ちます。変更の重要度に応じて必須チェックを限定します。

PLM・ERP・MES連携のデータ契約をRFPに落とす

RFPでは「API連携可能か」だけでは比較できません。各イベントの発生条件、必須項目、所有システム、応答、再送、重複処理、失敗時の復旧手順を具体的に記述します。ECOの承認イベントとリリースイベントを混同しないこと、ERP側でBOM更新に失敗してもPLMの承認を取り消さないこと、MESへの反映が遅れたら生産開始を止めるかどうかを決めます。同期方式がAPIでもファイルでも、業務上の完了確認は必要です。

最低限の連携契約として、変更IDと版の不変性、イベントIDによる重複排除、受信順序が前後した場合の扱い、時刻のタイムゾーン、再試行上限、失敗キューの監視、手動復旧時の監査ログを求めます。BOMの親子関係、構成数量、単位、代替品、工程との対応、拠点別の差はサンプルデータで提示します。マスタコードの変換表だけでなく、旧コードから新コードへの移行と廃止の条件も含めます。図面添付の閲覧権限やデータ保管先は委託先を含めた実際の利用者で確認します。

ライセンス費用だけでなく、設計BOMと製造BOMの整備、既存品目の版付け、拠点別ルール、API開発、移行、FAT/SAT、教育、運用監視を同じ範囲で比較します。製品の標準機能と追加開発の境界は、ベンダーの宣言ではなく上記シナリオで確認します。システムの得意分野は構成によって変わるため、ここでは特定製品の適合や費用相場を断定しません。

タイ工場で確認したい拠点差

設計本部とタイ工場で品目コード、単位、工程名、シフト、タイムゾーン、承認権限が違う場合、同じECOでも拠点ごとに受信後の処理が異なります。仕入先が複数国にいるなら、変更通知の言語と回答期限も現場運用に合わせます。これはタイ固有の規制についての主張ではなく、多拠点の連携設計として確認する項目です。グローバルな設計承認を各工場の採用判断へどう落とすか、どの差分を工場側で許すかをRFPに明記します。

FAT/SATで「変更が通った」をどう証明するか

FATではテスト環境で代表的な変更を端から端まで通し、SATではタイ工場の実マスタに近いデータ、権限、ネットワーク、作業手順で再確認します。画面に新版が表示されたことだけを合格とせず、指定した指図へ正しい版が適用され、旧指図は意図した版を維持し、MES実績から追跡できることを確認します。テストデータの製品とロットは特定できる架空値にし、本番の顧客情報を無断で持ち込みません。

最低限の試験は、通常の将来日付変更、直前変更、承認後の取消、同一品目の連続変更、二重イベント、受信順序の逆転、ERP停止中の送信、MES更新遅延、拠点ごとに異なる適用条件、WIPの保留を含みます。各試験で「期待する対象指図」「期待するBOM/工程版」「旧版在庫の扱い」「失敗時の通知先」を事前に固定します。成功画面のスクリーンショットだけでなく、PLM送信ログ、ERP受信結果、MES実績、現物確認の記録を同じ変更IDで結びます。

SATの終了条件は、重大な未解決不具合がなく、対象業務の責任者が処置表と運用手順を承認し、再送と差戻しを当番者が実行できることです。初期稼働後は一度で全品目へ広げず、旧部品の在庫がある品目、変更頻度が高い品目、現場で検査が必要な品目を含む小範囲で監視します。停止基準を先に決めておけば、連携エラーが出た際に「とりあえず生産を続ける」判断を避けやすくなります。

導入順序と担当をどう組み立てるか

第一段階では、過去のECOを数件選び、承認から現場実績までの実際の経路を追います。データがどこで手入力され、誰が旧版の使用を許可し、どの記録で顧客へ説明できるかを確認します。システム図だけでは作業の例外が見えません。第二段階では正本と適用条件の責任者を決め、変更ID、品目、BOM、工程、指図、ロットの対応をモデル化します。第三段階で一つの製品群と一拠点を対象に連携を実装し、WIP例外と障害復旧を先に試します。最後に他拠点・他製品へ展開する際は、現地のコード体系と権限を差分として再評価します。

担当の切り分けも重要です。設計は変更内容と互換性、品質は特採・検査条件、購買は仕入先・発注残、生産管理は指図切替、ITはデータ契約と監視、現場は使用実績を担います。いずれか一部門に「連携後は自動で判断される」と押しつけないよう、例外時に決定する人と期限を定めます。変更会議の議事録よりも、個々の変更IDから承認、適用条件、処置、実績へ辿れることが運用の基盤になります。

導入判断に使えるチェックリスト

• PLMのECOが承認されても、ERP/MESへのリリースを保留できるか。
• 品目・BOM・工程の新旧版と適用条件を、同じ変更IDから確認できるか。
• 発注残、在庫、WIP、完成品の影響を拠点別に抽出できるか。
• 版を取引で持たない場合、必要なas-built粒度を別の記録で満たせるか。
• 二重送信、順序逆転、受信停止から安全に復旧できるか。
• FAT/SATで変更前後の指図と現場実績を示せるか。
• 初期稼働の停止・差戻し・再承認の責任者が決まっているか。

一つでも答えが曖昧なら、製品のデモより先に業務ルールを一枚にまとめるのが有効です。特に「適用日」は入力欄があるだけでは不十分で、指図とWIPのどの状態に効くかをサンプルで確認します。現場で再現できる切替ルールが、PLM・ERP連携の導入可否を決めます。

変更の取り消しと再リリースを設計から外さない

承認済み変更でも、量産準備の途中で部品不良や顧客条件の変更が見つかれば、実施を延期または取り消すことがあります。このときPLMのECOを「取り消し」にするだけでは、ERPに配信済みのBOMやMESの作業手順が戻るとは限りません。変更がまだ有効化されていない場合、すでに新仕様の指図が発行されている場合、新仕様で完成品ができている場合を分け、許される戻し方を決めます。データベースを過去の状態へ直接書き戻すのではなく、再変更として履歴を残す方式が適切な場合もあります。実装方法は使用製品と監査要求で確認します。

連携先が一つだけ失敗した場合にも同じ考えが要ります。ERPが新版BOMを受信し、MESだけが旧手順のままなら、再送を試す間に対象ラインの作業開始を止めるか、旧版で継続するかを現場責任者が判断します。後で再送が成功しても、既に進んだ指図へ自動適用しない条件を設定します。変更IDごとの配信先一覧に、送信時刻、受信応答、実際の適用状態、確認者を分けて残すと、障害中の判断を監査できます。

KPIは「通知速度」より実装の一致率を見る

導入後の評価では、ECO承認から通知までの時間だけを追っても、現場の正確さは分かりません。変更IDごとに、予定した適用境界と実際の指図版が一致した割合、未処置の影響対象件数、連携失敗の復旧時間、旧版部材の隔離漏れ、as-built記録の欠落を確認します。ただしこれらの数値には会社ごとの定義と測定方法が必要であり、本稿は目標値を断定しません。最初に一つの製品群で現状値を取り、業務担当者が実際に改善できる項目を選びます。

リリース前のレビューでは、各部門が同じサンプル変更を読み、影響対象リストに差がないか確かめます。設計部門は図面、購買は発注残、倉庫は旧部品ロット、生産管理は指図、MES担当は手順と実績を確認します。対象件数が合わなければ、機能追加の前にキー、版、日付、拠点の定義を見直します。この照合作業そのものが、PLM・ERP・MESの境界に潜む認識差を早期に見つける試験になります。

データ移行時に旧変更履歴をどう扱うか

導入時には、過去の図面やBOMの版をすべて新システムへ移すべきかが問題になります。全履歴を移すと作業量と検証範囲が大きくなる一方、現在有効な構成だけを移すと、旧版の完成品に対する調査に必要な根拠が見つからない場合があります。対象製品、保存すべき期間、顧客への説明に必要な粒度を品質部門と確認し、「現在有効なマスタ」「未完了の変更」「参照用の過去履歴」に分けて移行方針を決めます。参照用履歴は編集可能な現行マスタと混同しない表示にし、変更ID、図面版、BOM版、承認記録、適用期間を検索できるか確認します。

移行テストでは件数一致だけでなく、親子BOM、代替部材、単位、工程、拠点、日付の境界を比較します。旧システムの時刻が現地時間で保存され、新システムがUTCで保存するなら、変換後に適用日の前後で別の版が選ばれないかを試します。旧品目コードと新品目コードの対応が一対一でない場合は、単純な置換表だけでは不足します。統合された品目、分割された品目、廃止品目に対する履歴の参照方法を定めます。

移行完了を判定するためには、設計担当が図面を、購買が発注残を、生産管理が指図を、品質が過去ロットを、それぞれ同じ変更例で検索します。ある画面だけで一致しても、関連する取引へ辿れなければ運用上は未完了です。移行後しばらく旧システムを参照専用として残す場合は、閲覧者、保存期限、正本との関係を決め、二つのシステムで別々に更新が進まないようにします。

連携監視を日常業務へ組み込む

本番稼働後は、単にAPIの成功率を監視するだけでなく、変更の業務状態を確認します。PLMでリリースされた変更のうちERP未受信の件数、ERP反映済みだがMES未確認の件数、予定日を過ぎても処置が未確定のWIP件数などを、担当者が行動できる一覧にします。アラートには変更ID、対象品目、拠点、失敗段階、再送可否、判断が必要な指図を載せます。技術ログのエラーコードだけを現場へ渡しても、止めるべき生産を判断できません。

毎日の引継ぎでは、未解決変更を変更IDで確認し、影響する発注・指図・ロット、暫定処置、次の確認時刻を共有します。運用開始後に例外が増えたら、個別の手作業を増やし続けるのではなく、共通する原因がマスタ、版、適用条件、権限のどこにあるかを見直します。こうした監視と改善を要件に含めることで、導入後に「通知は届くが、工場で使えない」という状態を避けやすくなります。

具体例：代替部品へ切り替える変更を追う

ある組立製品で、調達難の部品Aを互換性を確認した部品Bへ切り替える場面を考えます。まず設計部門は、Bが使える製品版、必要な図面・検査条件、Aとの混在可否をECOに記します。品質部門は顧客承認や追加検査の要否を確認し、購買部門はAの発注残とBの供給開始を調べます。生産管理は、すでに発行済みの指図、次週に発行する指図、Aを払い出した仕掛品を分けます。こうした影響を確認する前に「Bを即日有効」にすると、ERPの計画数量と現場の現物がずれる可能性があります。

この例では、Bの初回入荷と受入検査の完了を適用の前提にします。PLMのECOが承認されても、ERPへの製造BOM配信は準備完了まで保留します。配信後はERPで新しい指図にBが展開されるかを確認し、旧指図にAが残ることも確認します。MESではBのバーコードを読んだとき新しい作業手順と検査項目が出るか、Aを読んだとき意図しない指図では警告が出るかを試します。Aをすでに取り付けたWIPは旧版で完了するのか、分解してBへ置き換えるのかを、製品と顧客条件に基づいて個別に判断します。

この変更を「成功」と呼ぶ条件は、三システムの画面にBが見えることだけではありません。Bを使うべき指図にBが予約・払い出し・実装され、Aで完了すべき指図が勝手に更新されず、どちらの完成品もロットやシリアルから経緯を説明できることです。購買側ではAの残発注を変更したか、Bの初回入荷が予定どおりかも確認します。ECOの承認記録、ERPの指図と在庫処置、MESの使用実績を同じ変更IDで照合すれば、変更の途中でどの部門が次に動くべきか明確になります。

ベンダーデモで見せてもらう順序

最初に、同一品目の旧版と新版、旧部品と新部品を含む小さな実データに近いサンプルを渡します。ベンダーには、PLMで変更を申請して承認する画面から、ERP側の影響対象一覧、承認後のデータ反映、MES側の指図と実績まで通して見せてもらいます。次にBの入荷が遅れたケースを入れ、適用日を延期したとき、すでに送った情報をどう再評価するかを確認します。最後に同じイベントを二度送信し、障害後に再送してもBOM行や指図が二重にならないことを確認します。

ベンダーが標準画面だけでできる操作、設定で対応できる操作、追加開発や手作業が必要な操作を分けて記録します。画面遷移の速さよりも、変更ID、版、適用条件、例外処置が一貫して残るかを重視します。工場側の担当者にも操作してもらい、実際のシフト交代時に未解決変更を見つけられるか、誤った版での作業を止められるかを確かめます。この結果をRFPの回答とFAT/SATの判定表へつなげれば、見栄えのよいデモだけで採用を決めずに済みます。

よくある質問：設計変更 PLM ERP連携の導入前に

ECO/ECNをERPへ送ればBOM版数管理は完了しますか？

いいえ。通知の到達とBOMの適用は別です。旧版と新版の品目・構成・工程がどの指図に適用されるか、旧在庫をどう処置するか、MESの手順と検査が追従するかを確認します。完了の定義には、配信結果だけでなく対象指図の判定と現場実績を含めます。

設計変更の適用日はPLMとERPのどちらで持つべきですか？

設計上の承認日と工場での実施日を分けて所有者を決めます。どちらが適用条件を最終決定するかは業務構成によります。PLMで拠点別の有効条件を承認しERPが指図へ適用する方式も、ERP側で現地の実施日を確定する方式も考えられます。重要なのは双方の日時と対象が矛盾したときに止めて確認できることです。

仕掛品に新しいBOMを自動適用してよいですか？

一律に適用すべきではありません。払い出しや加工の進度、互換性、品質・顧客条件で判断が変わります。未着手と着手済みを分け、必要なら工程と部材消費まで確認します。自動変更してよい範囲と保留すべき範囲をFAT/SATの具体例で決めます。

RFPで最優先に確認する機能は何ですか？

一般的な機能数より、現場の切替境界を再現できるかが重要です。変更IDと版の対応、拠点別の適用、WIP・在庫の影響評価、失敗時の再送、MESでの実績照合を一つのシナリオで見せてもらいます。標準機能か追加開発か、運用手作業がどこに残るかまで確認します。

まとめ

設計変更のPLM・ERP連携導入では、ECO承認からERP更新、MES適用、現場実績までを一本の変更IDで辿り、版と適用条件を指図単位で検証します。仕掛品、在庫、発注残の処置を業務として決め、連携エラーからの復旧を試験することが、工場で使える仕組みへの近道です。製品比較より先に切替規則と受入基準を作ると、RFPとFAT/SATの議論が具体的になります。

タイ工場で設計変更の切替ルールやPLM・ERP・MESの連携範囲を整理中でしたら、TOMAS TECHへご相談ください。要件定義の初期段階から、対象品目と実際の変更例をもとに検討できます。

参考情報

• Microsoft Learn: Engineering change management overview
• Microsoft Learn: Manage changes to engineering products
• Microsoft Learn: Engineering change management FAQ
• SAP Help: Engineering Change Management in Document Management
• Oracle Fusion Cloud SCM: How You Edit Work Definitions
• Siemens Teamcenter Manufacturing: MBOM Management