Design Pattern Collection
Engineering Change Management × Supply Chain Management
Specialized content for manufacturing IT designers and architects
July 2026 Paddy&Water Inc.
Chapter 1: Basic Concepts and Pattern Classification of ECM × SCM Integration Design
1.1 What Is a Design Pattern?
This document systematizes ECM×SCM integration using the “Design Pattern” methodology. A design pattern describes a proven solution to a design problem that recurs repeatedly in a specific context, expressed as a named template. Just as with the GoF design patterns (in software design), this document records “reusable design knowledge” for manufacturing integration design as 16 patterns.
Each pattern is composed of five sections: [Context], [Problem], [Solution], [Results/Effects], and [SAP Implementation Example]. Readers should select and combine the patterns that apply to their own situation while cross-referencing them against their company’s circumstances.
1.2 The Five Major Design Domains of ECM × SCM Integration
| Design Domain | Design Issues Addressed | Pattern Numbers in This Document |
| BOM Conversion & Synchronization | EBOM→MBOM conversion, variant BOM, effectivity management | Pattern 1-4 |
| Change Propagation Control | ECO→SCM automatic integration, inventory changeover planning, Open PO control | Pattern 5-8 |
| Supplier Collaboration | Design of change notification distribution, acceptance confirmation, compensation calculation | Pattern 9-11 |
| Emergency Changes & Recall Response | Immediate propagation of safety changes, identification of affected products, recall response | Pattern 12-13 |
| Multi-System Integration Architecture | Integration design combining PLM + ERP + MES + Ariba, API gateway design | Pattern 14-16 |
1.3 The Taxonomy of Change Objects in Manufacturing
As a prerequisite for ECM×SCM integration design, it is necessary to accurately understand the “taxonomy of objects (data) involved in change.” ECM contains multiple change objects, each with a different scope of impact on SCM and a different integration design.
| Change Object | Abbreviation | Definition | Main Impact on SCM |
| Engineering Change Request | ECR | An “application/request” object for a design change. Describes the necessity, background, and scope of impact of the change. Because it is in the unapproved phase, it is not directly reflected in SCM. | Input for preliminary SCM impact estimation. Advance change notice (FYI stage) to purchasing and production. |
| Engineering Change Order | ECO | An “approval/instruction” object for a design change. Finalizes the change content, effectivity conditions, and old/new BOM. Becomes the trigger for SCM integration after approval. | Starting point for BOM updates, order plan changes, and disposition of old inventory. The most important ECM×SCM integration object. |
| Engineering Change Notice | ECN | A change notification document to external parties (suppliers, customers). The formal notice issued after ECO approval. | Basis document for requesting specification changes/changeovers from suppliers. Trigger for distribution to the supplier portal. |
| Part Obsolescence Notice | PON / PDN | Notice of part obsolescence (end of manufacture/end of sale). A change instructing migration to a replacement part. | Registration of procurement for the replacement part; run-out planning for the old part. |
| Deviation / Waiver | Deviation / Waiver | Temporary permission to use nonconforming product. Limited approval to use parts/materials that deviate from quality specifications. | Traceability records (serial/lot) for the scope of the deviation. Coordination with quality records is essential. |
Chapter 2: BOM Conversion & Synchronization Design Patterns (Pattern 1-4)
2.1 Understanding the Structural Differences Between EBOM and MBOM
The single biggest hurdle in ECM×SCM integration design is handling the “structural differences between the EBOM (Engineering BOM) and the MBOM (Manufacturing BOM).” The EBOM represents “what it is made of (functional configuration),” while the MBOM represents “how it is made (manufacturing process sequence).” Because these two are fundamentally different in structure, they cannot be integrated through simple data copying.
| Comparison Item | EBOM (Engineering BOM) | MBOM (Manufacturing BOM) |
| Owning Organization | Design department / PLM system | Manufacturing department / ERP system (SAP CS01/MM01) |
| Structural Perspective | Organized by function, subsystem, and assembly unit (electrical system BOM, structural system BOM, etc.) | Organized by manufacturing process, assembly sequence, and manufacturing site (Process 1: painting → Process 2: assembly, etc.) |
| Item Types | Design items (Design Item), including phantom items (Phantom) | Finished product items, semi-finished items, purchased items; differ by production version |
| Variant Management | A single BOM including options/variations, controlled by configuration rules | Variant BOM (LO-VC) or proliferation of material numbers, expanded into a form that is easy to manufacture |
| Effectivity Conditions | Design change history (ECO number, date) | Date-based / lot-number-based / serial-based |
| Obsolescence & Substitution | Management of design obsolescence (Superseded) | Old part run-out planning / inventory adjustment required |
| Pattern 1 | EBOM→MBOM Transformation Gate Pattern (Two-Stage BOM Transformation) |
| Context | A manufacturing environment where the EBOM is managed in PLM and an MBOM is required in ERP/SAP. The MBOM must be updated every time a design change (ECO) is approved. |
| Problem | If the EBOM is imported into ERP as-is, item hierarchies, phantom items, and design options that are unsuitable for manufacturing get mixed in, causing MRP to generate incorrect plans. Conversely, if the ERP side manages the MBOM independently, the EBOM and MBOM diverge whenever a design change occurs. |
| Solution |
After ECO approval, install a “BOM Transformation Gate” between PLM and ERP. The transformation gate performs the following: ① Expansion of phantom items (Phantom BOM): among the intermediate assemblies in the EBOM, expand and remove those that are not actually inventory-managed ② Item type conversion: convert design items (D items) into purchased items (B items) / manufactured items (F items) ③ Assignment of the production version: determine the combination of site, process, and BOM ④ Conversion of effectivity conditions: convert the ECO’s design effectivity conditions into the MBOM’s date-based/serial-based effectivity conditions |
| Results/Effects | Design changes are accurately propagated to the MBOM, allowing MRP to always plan using the latest manufacturing BOM. Removing phantom items prevents erroneous MRP-driven orders. |
| SAP Implementation Example | After approving the ECO in SAP Engineering Change Management (ECM), a BIP batch job or a BTP Integration Suite API between PLM and SAP automatically calls SAP CS01 (BOM creation) to update the MBOM. Effectivity conditions are managed in the SAP change master (Engineering Change Master: CA01). |
| Pattern 2 | Effectivity Triangle Pattern |
| Context | A complex change environment where multiple effectivity conditions (date/serial number/lot number) coexist for the same item and plant. Products requiring unit-level tracking, such as aircraft, medical devices, and automobiles. |
| Problem | Mistakes in setting effectivity conditions (incorrect dates, overlapping serial ranges) cause the old and new BOMs to fail to switch over at the correct timing, resulting in products shipped with a mixture of old and new parts. |
| Solution |
Adopt a design that explicitly manages effectivity conditions along three axes: “Date Effectivity,” “Serial Number Effectivity,” and “Lot Effectivity.” Define priority rules for the three axes at the design stage: ·Date effectivity: applied to mass-produced products and standard changes (the most common) ·Serial number effectivity: applied to products requiring individual unit tracking (medical devices, aircraft parts, power equipment) ·Lot effectivity: applied to batch products (chemicals, food, pharmaceuticals) Set the same effectivity condition uniformly across all SAP BOMs, routings, and purchasing info records, and implement a rule that automatically validates for inconsistencies in effectivity conditions before ECO approval. |
| Results/Effects | Mixing of old and new parts due to effectivity condition setting errors is prevented. The “BOM that was effective at that point in time” can be reproduced 100% from the manufacturing serial/lot number, ensuring traceability for regulatory compliance and recall response. |
| SAP Implementation Example | Select the effectivity condition type for each ECO in the SAP change master (CA01). SAP S/4HANA PP-SFC: automatically selects the effective BOM for serial-managed items in the production order. In IBP integration, the plan switchover date at the Date Effectivity level is used as the confirmed MPS date. |
| Pattern 3 | Variant BOM × SCM Integration Pattern |
| Context | A configure/engineer-to-order (CTO/ETO) environment where configurable items are managed via LO-VC (Variant Configuration). A design change is valid only for a specific characteristic value (e.g., only the 200V power supply specification). |
| Problem | A change that should apply only to a specific characteristic-value variant is mistakenly applied to all variants. Or the change notification is sent to suppliers incorrectly as an “all-variant change,” causing unnecessary inventory disposal and procurement changes. |
| Solution |
Set a “Change Applicability Condition” on the ECO and link it to the variant BOM’s dependency. ① Approve the ECO with characteristic-value conditions (e.g., the change is valid only when COLOR=RED and VOLTAGE=200V) ② Add the changed part to the MBOM’s variant BOM dependency under that condition ③ Control the impact on the SCM procurement plan so that it only occurs when an order is actually confirmed for that characteristic value ④ Distribute the change notification to suppliers as a conditional ECN specifying the applicable variant |
| Results/Effects | Prevents unnecessary expansion of the change’s impact scope. Reduces erroneous notifications to suppliers and unnecessary inventory disposal costs. Significantly improves change accuracy in a CTO environment. |
| SAP Implementation Example | Set the ECO effectivity condition in the SAP LO-VC dependency using the KECO dependency language. Link the change master and the VC dependency to the same ECO to change the BOM (CS01). In IBP/MRP, plan changes are executed triggered by the configuration instance confirmed after order entry. |
| Pattern 4 | Multi-Plant BOM Sync Pattern |
| Context | A global manufacturing environment in which the same product is manufactured at multiple plants (domestic and overseas), with the MBOM independently managed at each plant. |
| Problem | Because change notifications to each plant after headquarters’ ECO approval are handled manually, the timing of MBOM updates varies across plants. Plants that lag behind continue manufacturing to the old specification, causing quality variation and non-conformance among finished products. |
| Solution |
Design a “multi-plant synchronization mechanism” that updates the MBOM at all target plants simultaneously, using the ECO approval event as a single trigger. ① At ECO approval, automatically extract the list of all plants using that BOM (leveraging SAP’s CS15: BOM where-used inquiry) ② Simultaneously notify each plant’s BOM owner (production engineering staff) → launch approval workflows in parallel ③ Batch-update all MBOMs automatically after approval is complete at all plants (or on a specific schedule) ④ Visualize the update results (success/failure/pending) in real time on a management dashboard ⑤ If the BOM update at a particular plant is delayed, automatically trigger an alert and interim measures (deviation permit) |
| Results/Effects | Change synchronization across all plants is guaranteed, preventing quality variation between plants. Automatic detection of update delays eliminates “unnoticed neglect.” |
| SAP Implementation Example | Obtain the list of plants using SAP’s CS15 (BOM Where-Used). Implement parallel approvals using SAP Workflow (SWDD). Execute simultaneous BOM update APIs to multiple plants via BTP Integration Suite. The SAP change master allows setting an effective date per plant. |
Chapter 3: Change Propagation Control Design Patterns (Pattern 5-8)
3.1 The Three Flows of Change Propagation
| Automatic Integration Flow After ECO Approval (Design) |
|
Flow ①: BOM update flow ECO approval → PLM BOM finalized → automatic MBOM update (SAP CS01) → MRP recalculation triggered → automatic generation of a purchase requisition (PR) for the new part / generation of a cancellation candidate list for the old part Flow ②: Inventory changeover planning flow ECO approval + effectivity confirmed → automatic calculation of old-part inventory quantity and the number of units that can be run out → calculate the old part’s “run-out completion date” → determine the changeover procurement start date for the new part Flow ③: Supplier notification flow ECO approval → automatic generation of an ECN (change notice) → distribution to target suppliers (Ariba Network / portal) → supplier acceptance confirmation → reflect the old/new part delivery changeover date in SCM |
| Pattern 5 | ECO Approval Trigger Pattern |
| Context | An environment where integration with SCM systems (ERP, purchasing, supplier portal) after ECO approval is performed manually. |
| Problem | Because integration after ECO approval relies on email, Excel, and manual operations, missed integrations, delays, and data-entry errors occur. In particular, when approval happens at night or on a holiday, integration is delayed until the next business day. |
| Solution |
Set the PLM system’s ECO approval event as a webhook or API-call trigger, and automatically and sequentially execute the following: ① Extract ECO data (old/new BOM differences, effectivity conditions, applicable scope) from the PLM API ② Convert and transmit to SAP ERP via a BTP Integration Suite iFlow (CS01 BOM update, MM60 usage activation) ③ Automatically generate a cancellation candidate list for open POs/PRs from SAP master data and notify the purchasing staff ④ Trigger recalculation of the IBP demand and supply plan (generate the procurement plan for the new part) ⑤ Record success/failure logs for all processing in BTP monitoring The only point where a human is involved is the gate where “the purchasing staff approves the candidate POs/PRs for cancellation.” |
| Results/Effects | Integration to the entire SCM is completed within a few hours of ECO approval. Missed integrations and transcription errors are structurally eliminated. Approvals at night or on holidays are also processed automatically. |
| SAP Implementation Example | Implement PLM webhook → SAP ERP OData API integration via BTP Integration Suite (iFlow). When capturing the ECO approval event from within SAP using SAP Business Events, use SAP Event Mesh (BTP). |
| Pattern 6 | Open Purchase Order Control Pattern |
| Context | An environment where, after ECO approval, open POs already placed against the old part remain outstanding, causing receipt and inventory buildup of the old part. |
| Problem | Because open POs for the old part are not automatically canceled after ECO approval, the supplier continues to ship the old part, which is received and stocked as-is. This generates scrap inventory costs and supplier compensation costs. |
| Solution |
Automatically control the handling of old-part open POs based on the ECO effectivity condition, using the following logic: Case A (immediate obsolescence change): all open POs with a delivery date on or after the effective date are automatically flagged as cancellation candidates → the purchasing staff confirms and then executes the cancellation via ME22N/ME28N Case B (run-out change): calculate the “run-out required quantity” considering current old-part inventory and safety stock → only open POs exceeding the run-out required quantity become cancellation candidates; the rest retain their delivery date and quantity Case C (emergency change): for safety changes/recall changes, immediately freeze all open POs and escalate to the purchasing manager It is also effective to use SAP’s MRP exception message (MD06) to automatically extract “open POs exceeding the post-change demand.” |
| Results/Effects | Prevents unnecessary receipt of the old part and reduces scrap inventory. Consolidates the cancellation decision into a single purchasing-staff approval gate, eliminating processing gaps caused by manual dependency. |
| SAP Implementation Example | Extract excess open POs after the change using SAP’s MD06 (MRP exception list). Execute cancellation via ME22N (PO change) / ME28N (release cancellation). Implement an automated sequence in BTP linking the ECO approval event, MRP recalculation, MD06 extraction, and the approval workflow. |
| Pattern 7 | Inventory Run-out Planning Pattern |
| Context | An environment where old-part inventory and WIP remain after a design change, requiring a decision and plan for whether to scrap or run out the stock. |
| Problem | Without a “run-out plan” that comprehensively considers old-part inventory quantity, WIP in manufacturing, and existing sales orders, the decision to scrap or run out is made intuitively, maximizing scrap costs. Alternatively, waiting too long for run-out completion delays the changeover to the new part. |
| Solution |
Automatically execute the following calculation model at ECO approval to generate the optimal run-out plan: ① Retrieve the current old-part inventory quantity (QtyOH) from SAP MB52 ② Retrieve the old-part quantity incorporated into WIP (incomplete production orders) (QtyWIP) ③ Calculate the number of units that can be run out using open sales orders that consume the old part: Qty_runout = QtyOH ÷ old-part quantity used per unit ④ Run-out completion date: Current Date + Qty_runout ÷ average daily production quantity ⑤ Compare with the earliest possible receipt date of the new part (calculated from the procurement lead time) ⑥ Decision logic: Run-out completion date ≤ new part’s earliest possible receipt date → run-out is recommended Run-out completion date > new part’s earliest possible receipt date → consider partial scrapping or diverting the old-part inventory to another product/site Automatically distribute the calculation results as an “ECO Inventory Impact Report” to purchasing, production control, and finance. |
| Results/Effects | Minimizes scrap costs and optimizes the changeover timing between old and new parts. The finance department can forecast and provision for scrap losses in advance. |
| SAP Implementation Example | Extract data from SAP MB52 (inventory list), COOIS (production order list), and MD04 (stock/requirements list) via BTP and implement the calculation logic on BTP Application Runtime. Visualize the results in SAP Analytics Cloud (SAC). |
| Pattern 8 | Change Buffering Pattern |
| Context | An environment where design changes occur frequently and change integration to SCM becomes excessive, destabilizing MRP and the procurement plan (common among electronics and telecommunications equipment manufacturers). |
| Problem | Design changes occur dozens of times per week, and MRP recalculation and procurement plan updates run every time, causing MRP to recalculate all day long and destabilizing the procurement plan. Planners fall into a situation where “today’s MRP result is different tomorrow,” making planning impossible. |
| Solution |
Adopt a design pattern that intentionally “buffers (accumulates)” the timing at which design changes are propagated to SCM, then processes them in periodic batches: ① Classify urgency by change category: CRITICAL (safety changes, regulatory changes) → immediate integration (real time) after approval HIGH (quality issues, functional defects) → integration within 24 hours of approval MEDIUM (cost improvements, design improvements) → integrated together in a weekly batch (Monday overnight) LOW (minor design optimizations) → integrated in a monthly batch ② When multiple ECOs conflict for the same part during the buffering period, implement merge logic that propagates only the final state ③ Before the buffered integration timing, proactively distribute a “list of this week’s planned SCM integration changes” to purchasing and production planning staff |
| Results/Effects | Significantly improves MRP stability and eliminates the confusion of planners chasing a constantly moving plan. CRITICAL changes are still handled immediately. |
| SAP Implementation Example | Implement an architecture in which change events are received and queued via BTP Event Mesh, then processed by iFlows on different schedules by category. Design the SAP MRP run (MD01N) to be triggered only after the change batch integration. |
Chapter 4: Supplier Collaboration Design Patterns (Pattern 9-11)
4.1 Design Principles for Supplier Change Collaboration
The cost incurred when design changes are not communicated to suppliers accurately, promptly, and reliably (old-part compensation, quality claims, procurement delays) is, along with scrap inventory cost, the largest cost factor in failed ECM×SCM integration. In supplier collaboration design, three elements are key: “immediacy of push notifications,” “reliability of acceptance confirmation,” and “recorded agreement on the changeover schedule.”
| Pattern 9 | Supplier Push Notification Pattern |
| Context | An environment where change notifications to suppliers after ECO approval are sent manually by email or fax by the design or purchasing staff. |
| Problem | The timing of notification depends on the staff member’s work schedule, and approvals at night or on holidays delay notification until the next business day. The content of the notification (change specification, effective date, response deadline) varies by staff member. There is no way to confirm delivery of the notification. |
| Solution |
Design a mechanism that automatically distributes the change notice (ECN) to suppliers, triggered by the ECO approval event: ① Automatically generate a templated ECN (change notice) — a standard format including before/after specifications, effectivity conditions, and response deadline ② Layer the distribution channels: Priority ①: Electronic ECN distribution via Ariba Network (for EDI-enabled suppliers) Priority ②: Upload to the supplier portal (SAP Business Network) with an acceptance button Priority ③: Email (structured change details in HTML format) + read receipt Final: phone confirmation (if unconfirmed within 24 hours of distribution) ③ Manage the distribution status (delivered/opened/accepted/rejected) in real time, linked to the vendor master in the SCM system |
| Results/Effects | Change notification is automated and standardized without manual effort. Automatic tracking of unconfirmed suppliers eliminates missed notifications. Notification records are retained as legal evidence. |
| SAP Implementation Example | Distribute the ECN to suppliers via SAP Ariba Change Order. Implement portal distribution and status tracking via BTP Integration Suite + SAP Business Network. Design a custom field to append the change response status to the SAP MM vendor information record (ME1L). |
| Pattern 10 | Bi-Directional Acknowledgment Pattern |
| Context | An environment where, even after sending an ECN, no acceptance confirmation or response on feasibility is obtained from the supplier, leaving it unclear whether the change is actually being addressed. |
| Problem | It cannot be determined whether the supplier has received the change notice or has actually begun manufacturing to the new specification, and the changeover date arrives with the old specification still being delivered. Response delays for urgent safety changes translate directly into recall risk. |
| Solution |
Implement a bi-directional acknowledgment design that structures and manages supplier responses after ECN distribution: Requirements to the supplier (specified in the ECN): ① Receipt confirmation: click to accept on the portal within 48 hours of ECN receipt ② Implementation plan: respond via the portal with the first shipment date under the new specification, the transition inventory quantity, and any technical concerns ③ Objection: if there is a technical problem with the change content, file an objection with the reason within the deadline Manufacturer-side follow-up logic: Unconfirmed after 48 hours → send an automatic reminder Unconfirmed after 96 hours → escalation alert to the purchasing staff Objection filed within the deadline → urgent referral to the Change Control Board (CCB) Confirmation complete for all target suppliers → automatically generate a change transition report and distribute it to procurement, quality, and production |
| Results/Effects | Confirmation of change implementation is structurally guaranteed. Supplier concerns and technical issues surface early, allowing early revision of the change plan. The record of the entire process functions as an audit trail. |
| SAP Implementation Example | Add a custom questionnaire form to the SAP Business Network supplier portal. Use the SAP Ariba task assignment feature to set deadlines and automate escalation. |
| Pattern 11 | Change Compensation Calculation Pattern |
| Context | An environment for calculating and negotiating compensation when a design change forces a supplier to scrap old-specification work-in-process or already-procured materials. |
| Problem | Negotiations with suppliers drag on because the basis for calculating the compensation amount is unclear. Or the supplier’s claimed amount is accepted as-is, resulting in excessive compensation costs. Because compensation calculation is not standardized, judgments vary by staff member. |
| Solution |
Adopt a design that applies a standardized compensation calculation formula after grasping the supplier’s inventory and WIP as of the ECO approval date: Classification of compensation targets: ① Inventory already delivered (in the manufacturer’s warehouse): scrapped as the manufacturer’s responsibility (not eligible for compensation, but the scrap cost is recorded) ② Finished-goods inventory at the supplier: eligible for compensation up to the ordered quantity (bought back at the purchase price) ③ WIP at the supplier: compensated for processing cost equivalent (material cost + value-added cost × percentage of completion) ④ Raw materials at the supplier: material cost compensated only if there is no alternative use Compensation calculation flow: At ECO approval → request the supplier to declare inventory/WIP via the ECN (in a specified format) After receiving the declaration → the purchasing staff performs an independent check (cross-referenced against expected receipts and outstanding orders) After calculation → approved by the Change Control Board → a credit note is issued (FI-AP processing) Contractual measures: specify the ECO compensation cap, calculation formula, and declaration deadline in the procurement contract |
| Results/Effects | Compensation negotiations are accelerated based on a standardized calculation formula. Excessive compensation is prevented. Compensation costs become predictable from the time the ECO is raised. |
| SAP Implementation Example | Extract outstanding supplier orders and expected receipts from SAP’s ME2M (purchasing document list) and MB52 (inventory). Implement the compensation calculation logic on BTP Application Runtime. Process the credit note in SAP FI-AP (FB65). |
Chapter 5: Emergency Change & Recall Response Design Patterns (Pattern 12-13)
5.1 Design Principles for Emergency Changes
In safety changes and recall response, failure of ECM×SCM integration leads directly to legal risk and risk to human life. Emergency change design patterns do not apply the normal change propagation patterns (such as buffering) at all, and are implemented as a special design that guarantees the highest-priority, fastest possible propagation.
| Pattern 12 | Emergency Safety Change Pattern |
| Context | An environment where a design change related to safety (a defect, recall, or regulatory response) occurs and must be handled faster than the normal ECO process can manage. |
| Problem | Going through the normal approval workflow (multi-stage approval, buffering) takes days to weeks for the change to propagate, during which manufacturing and shipment of the defective product continues. |
| Solution |
Design a dedicated fast-track approval and immediate propagation flow for emergency safety changes: Fast-track approval flow: ① Raise an urgent ECR (emergency flag ON) → skip the normal multi-stage approval and shorten it to two-party approval by the quality manager and the manufacturing manager ② Delegation of Authority (DOA): pre-register alternate approvers who can grant emergency approval even at night or on holidays ③ Approval deadline: stipulate approval of an urgent ECR within a maximum of 4 hours (set as an SLA in internal rules) Immediate propagation after approval (buffering prohibited): ④ Shipment hold for the affected product: automatic block on the SD shipping document (VL02N: shipment stop) ⑤ Freeze of production orders in progress: a change-hold flag on the PP production order (hold before TECO) ⑥ Immediate ECN distribution to all target suppliers (with an emergency flag: 24-hour acceptance required) ⑦ Automatically launch the affected-product market inventory identification flow (Pattern 13) |
| Results/Effects | Emergency changes propagate across the entire supply chain within a few hours. Leakage of defective product is structurally prevented. Enables compliance with regulatory change-reporting deadlines (e.g., the 10-day report under FDA 21 CFR Part 806). |
| SAP Implementation Example | Create an emergency change flag in the SAP change master (CA01: Emergency Change flag). Route to a priority queue via BTP Event Mesh. SAP SD: set the block in VL06O (shipping monitor). PP: change the system status to PRCL in CO02. |
| Pattern 13 | Impact Tracing Pattern |
| Context | An environment where, when a safety change or recall occurs, it is necessary to accurately and quickly identify “which products use the affected part.” |
| Problem | Because the linkage records between the product’s manufacturing serial/lot number and the version/lot of the parts used are incomplete, identifying the recall target takes weeks. Because the scope is unclear, a full recall is issued preemptively, incurring excessive cost. |
| Solution |
Build a system capable of immediate identification when an event occurs, by pre-designing and accumulating three layers of traceability data: Layer 1: Linkage record between the product serial number and the lot of parts used → Upon completion of the production order (CO01), record the part lot → finished-product serial linkage using SAP QM batch management (MSC1N) → The MES (Manufacturing Execution System) records scans at each process step, synchronized with SAP PP-SFC Layer 2: Linkage record between the finished-product serial number and the shipping destination → At SD shipment (VL02N), record the finished-product serial number together with the destination customer and shipping date → For exports/imports, also link with customs data (GTS) Layer 3: Records of the location of consignment inventory and market inventory → Track consignment stock (special stock K) using SAP’s subcontractor inventory management (MB5B) → Manage customer warehouse (consignment) inventory via sales information records Identification query design (executed at the time of a recall): Input: the affected part’s material number + the affected lot number/version Output: ① a list of affected finished-product serial numbers ② the current location of each finished product (own inventory/shipped/by customer) ③ the estimated recall target quantity and target customer list (with contact information) |
| Results/Effects | An accurate list of affected products and their locations can be identified within hours of a recall occurring. Both excessive recall cost overruns and legal risk from under-recalling are prevented. |
| SAP Implementation Example | SAP QM: MSC1N (batch creation), MB56 (batch history tracking). SAP LO: MBGR (batch usage inquiry). Combination of SAP serial number management (IQ09) and batch management. A custom BTP BI application implements high-speed cross-referencing. |
Chapter 6: Multi-System Integration Architecture Design Patterns (Pattern 14-16)
6.1 Criteria for Selecting an Integration Architecture
In ECM×SCM integration, the optimal solution for which systems to connect, and how, differs depending on “the type of PLM system,” “the ERP version,” “real-time requirements,” and “change volume (items/day).” The following three patterns represent typical integration architectures.
| Architecture Pattern | Applicable Conditions | Key Integration Technology | Representative Manufacturing Sectors |
| Pattern 14 SAP PLM + S/4HANA Native Integration | PLM uses SAP PLM (formerly cFolders/DMS/ECM); MBOM management is consolidated in S/4HANA; single-vendor environment | SAP change master (CA01) SAP BOM conversion (CS01/CS40) SAP ECO → MM automatic integration | General-purpose machinery, industrial equipment Process industries (chemicals, food) |
| Pattern 15 Non-SAP PLM + SAP ERP API Integration | PLM uses Siemens Teamcenter / PTC Windchill / Dassault ENOVIA; ERP/SCM is S/4HANA | BTP Integration Suite (iFlow: PLM→SAP conversion) IDoc / REST API / OData | Automotive, electrical equipment, aerospace Heavy industry using CATIA/NX design |
| Pattern 16 PLM+ERP+MES Three-Layer Full-Stack Integration | Integrates the three systems of PLM, ERP, and MES (manufacturing execution); realizes Closed Loop Manufacturing | BTP Event Mesh, MES-proprietary API + SAP PP integration IoT→BTP→SAP integration | Semiconductors, electronics Companies driving smart factory initiatives |
| Pattern 14 | SAP PLM + S/4HANA Native Integration Pattern |
| Context | An environment where both PLM and ERP are SAP products, and there is a desire to complete the process from ECO approval through MBOM update and MRP integration entirely within SAP. |
| Problem | Even though SAP PLM and S/4HANA are within the same SAP ecosystem, there are configuration and design pitfalls where the PLM BOM object and the ERP BOM object (CS01) do not synchronize directly. Also, effectivity condition design often ends up independent on the PLM side and the ERP side, resulting in duplicate management. |
| Solution |
Design the SAP change master (Engineering Change Master: CA01) as the “single change management hub,” linking the same change master to the PLM, BOM, routing, and purchasing info records: Design Principle ①: Raise the change master (CA01) first Create the change master before ECO approval and finalize the effectivity condition (date/serial). All subsequent design changes are performed under this change master number. Design Principle ②: Cross-object management under a single change master Link BOM changes (CS01), routing changes (the routing section of CA01), purchasing info record changes, and quality inspection plan changes to the same change master → The effective date is managed centrally, and all objects switch simultaneously when MRP is executed Design Principle ③: Automating Material Master (MM01) updates Automatically update MM01’s MRP-related fields (safety stock/source of supply) via a batch job when the ECO effective date arrives Design Principle ④: Appropriate timing for MRP plan execution Rather than running MD01N (total MRP) immediately after a BOM update, combine with the Change Buffering Pattern (Pattern 8) and update the plan in an overnight batch |
| Results/Effects | The process from design change through to updating the procurement plan is automated entirely within S/4HANA. Duplicate management of effectivity conditions is eliminated. Basic integration can be achieved without additional external tools (such as BTP iFlow). |
| SAP Implementation Example | Manage the same change master across SAP CA01 (change master), CS01 (BOM), and CA01 (routing). Uniformly configure the effectivity condition type and defaults via the ECM settings in SPRO (the OPUP parameter). S/4HANA 2023 and later: the Change Impact Analysis feature can visualize an ECO’s scope of impact in advance. |
| Pattern 15 | Non-SAP PLM + SAP ERP API Integration Pattern (Heterogeneous PLM-ERP Integration) |
| Context | The most common manufacturing IT environment, combining a non-SAP PLM such as Teamcenter / Windchill / ENOVIA with S/4HANA. |
| Problem | Because PLM and ERP are systems from different vendors, the BOM structure, data model, and definitions of change objects do not match between the systems. Building up point-to-point connections causes connections to break with every system update, halting change integration. |
| Solution |
Adopt a hub-and-spoke integration architecture with BTP Integration Suite as the “hub,” consolidating the PLM-ERP conversion logic in iFlows: Architecture design: [Non-SAP PLM] → (iFlow-1: PLM → standard format conversion) → [BTP Event Mesh] ↓ (iFlow-2: SAP BOM update) ↓ [SAP S/4HANA] Key design points for implementation: ① BOM conversion mapping design: document and version-manage, as a “conversion mapping specification,” the conversion rules from a PLM BOM node (EBOM) to an SAP BOM line (CS01 component) ② Item number synchronization: implement a cross-reference table in BTP when the PLM part ID (Part Number) differs from the SAP material number (Material Number) ③ Delta Detection: rather than sending the entire BOM every time, export only the delta from the previous version on the PLM side to minimize transfer volume ④ Error handling: detect BOM update failures on the SAP side (validation errors, authorization errors) and immediately notify the PLM and purchasing staff. After 3 automatic retries, move the item to a manual-handling queue |
| Results/Effects | Achieves a loosely coupled connection between PLM and ERP, ensuring maintainability such that only the conversion logic needs to be modified if either system is upgraded. Consistent integration design can be applied even with non-SAP PLM systems such as Teamcenter. |
| SAP Implementation Example | Leverage BTP Integration Suite’s pre-built integration packages (SAP × Teamcenter / SAP × Windchill). For custom deltas: implement delta detection and conversion logic in a proprietary iFlow. Using SAP LT Replication Server (SLT) to feed real-time SAP data into BTP is also an architectural option. |
| Pattern 16 | PLM+ERP+MES Three-Layer Full-Stack Integration Pattern (Closed Loop Manufacturing Pattern) |
| Context | A smart-factory environment that fully integrates PLM (design), ERP (planning/procurement), and MES (manufacturing execution) to realize a closed loop of “design change → planning → manufacturing → results feedback → design improvement.” |
| Problem | PLM→ERP integration is in place, but the MES is isolated, and ERP BOM updates are not reflected in the MES’s work instructions (BOP). Work continues on the shop floor under the old procedure, and the effects of the change never reach actual manufacturing. Also, because manufacturing results (yield, quality, labor hours) do not flow back to PLM or the planning systems, the PDCA cycle for design improvement does not turn. |
| Solution |
Realize the three-layer integration with the following data-flow design: [Downstream flow: design → planning → manufacturing] PLM ECO approval → BTP Event Mesh (issues the change event) → ① S/4HANA MBOM update (CS01), production order (CO01) update → ② Automatic MES BOP (routing/work instruction) update (sent to the MES API via a BTP iFlow) → ③ Automatic switchover of work-instruction display on MES worker terminals (tablets/RF scanners) → ④ Automatic switchover of EWM warehouse task (WT) picking instructions to the new part [Upstream flow: manufacturing → planning → design, Closed Loop] MES production results collection (yield/defect count/labor hours/process parameters) → IoT gateway (OPC-UA / MQTT) → BTP IoT Service → ① Automatic entry into SAP PP: production confirmation (CO11N) → ② Automatic quality notification (QM01) raised in SAP QM upon quality deviation → ③ Labor-hour results fed into SAP CO’s actual costing (ML) → ④ Feedback to PLM: automatically raise QM notifications/labor-hour deviations as an ECR (the starting point of an improvement change) MES selection and integration API design: because the available API differs by MES, design a unified interface at BTP’s API Management layer, adopting a loosely coupled design that accounts for MES replacement. |
| Results/Effects | Realizes Closed Loop Manufacturing, automating the design→manufacturing→design-improvement PDCA cycle on the information systems. Manufacturing quality data automatically feeds back into design improvement, accelerating quality improvement for next-generation products. Resolves the “delayed penetration of changes to the shop floor” caused by MES isolation. |
| SAP Implementation Example | For SAP S/4HANA + Embedded MES (SAP ME/MII): leverage standard integration. For non-SAP MES (Siemens Opcenter / Rockwell FactoryTalk, etc.): connect via a BTP iFlow + MES REST API. IoT: SAP BTP IoT Service / Azure IoT Hub → integrated to SAP via BTP. |
Chapter 7: Design Anti-Patterns — Common Failures and How to Avoid Them
This chapter records the “failure patterns (anti-patterns)” repeatedly observed in ECM×SCM integration design. Knowing the anti-patterns is the shortest path to avoiding design landmines in advance.
| Anti-Pattern Name | Symptom (What Happens) | Root Cause | Correct Design (Corresponding Pattern) |
| Full BOM Blast | The entire BOM is transferred to ERP every time a single ECO occurs; enormous data volume, processing delays, and timeouts | No delta-detection design; the mistaken design of “sending everything for safety” | Implement delta detection as in Pattern 15. Export only the ECO delta on the PLM side |
| No Effectivity Cliff | The ERP BOM is rewritten the moment the ECO is approved, and production orders with WIP in progress can no longer order the old part | Omission of effective-date setting; impatience to “switch right now” | Always set an effectivity condition. Design the switchover effective date to be after WIP completion (Pattern 2) |
| Notification CC Flood | All purchasing staff and all quality staff are CC’d when the ECN is issued; staff stop reading ECNs (the “boy who cried wolf” effect) | No design for narrowing the distribution target; “CC everyone because missing someone is scary” | Pre-design an item-owner mapping and distribute only to the relevant supplier’s staff (Pattern 9) |
| MRP Trigger Storm | MD01N (total MRP) is run for every single ECO; MRP runs all day, and the procurement plan never stabilizes | No buffering design; the misconception that “MRP should be run immediately after a change” | Apply Pattern 8 (Change Buffering); consolidate to an overnight-batch MRP run |
| Excel Duct Tape | Part of the PLM→ERP BOM integration is supplemented with Excel; when the Excel administrator moves on, the integration stops | A design that patched the “remainder” after partial automation with Excel; a compromise due to tool budget/schedule shortage | Inventory the points where Excel-based integration occurs and roadmap the migration to a BTP iFlow |
| Serial Blind Shipping | It is unclear whether the affected part was used in a shipped product; investigation takes weeks at the time of a recall | Serial number management omitted to save cost; not implemented due to the effort involved | Prioritize designing Pattern 13 (Traceability). The cost of serial management is less than one-tenth of recall cost |
| Change Volume Underestimate | The PoC assumed 10 changes per month, but production volume grew to 300 per month; the system becomes a bottleneck and purchasing staff are overwhelmed | The mistaken assumption that “there won’t be that many changes”; underestimating the scale difference between the PoC environment and production | Design system load based on the peak value (maximum monthly count) of expected production change volume. Estimate counts by change category using 3 years of historical data |
Chapter 8: ECM × SCM Integration Implementation Roadmap and Priority Design Patterns
8.1 Recommended Phased Implementation Approach
| Phase | Duration | Patterns Implemented | Goals to Achieve |
| Phase 1 Foundation Building | 1-3 months | Pattern 2 (Effectivity condition design) Pattern 13 (Traceability foundation) Pattern 14 or 15 (BOM sync foundation) | Complete unified effectivity condition design. Enable manufacturing serial/lot management. Establish the basic PLM→ERP BOM integration path. |
| Phase 2 Change Propagation Automation | 3-6 months | Pattern 5 (ECO approval trigger) Pattern 6 (Open PO control) Pattern 7 (Run-out planning) Pattern 9 (Supplier push notification) | Operate the automatic integration flow after ECO approval. Realize automatic control of old-part POs. Begin electronic ECN distribution to suppliers. |
| Phase 3 Advancement & Optimization | 6-12 months | Pattern 1 (BOM transformation gate) Pattern 3 (Variant BOM × SCM) Pattern 8 (Buffering) Patterns 10 & 11 (Bi-directional acknowledgment & compensation) | Fully automated BOM transformation flow. MRP stabilization. Standardization of supplier compensation. |
| Phase 4 Realizing the Closed Loop | 12-24 months | Pattern 12 (Emergency change) Pattern 16 (Three-layer integration) IoT→PLM feedback implementation | Propagation of emergency changes within a few hours. Completion of the MES→PLM closed loop. Establishment of the smart-factory foundation. |
8.2 Pattern Selection Matrix (A Selection Guide Based on Your Company’s Environment)
| Your Company’s Situation | Priority Patterns to Apply | Patterns That Can Be Skipped |
| SAP-only environment (both PLM and ERP are SAP) | Pattern 2, 4, 5, 6, 7, 14 | Pattern 15 (non-SAP PLM not needed) Pattern 16 (MES integration is Phase 3) |
| Non-SAP PLM + SAP ERP (Teamcenter/Windchill + S/4HANA) | Pattern 1, 2, 5, 6, 9, 15 | Pattern 14 (native SAP PLM integration not needed) |
| Low change volume (20 or fewer per month), small/mid-size manufacturer | Pattern 2, 5, 6, 9 | Pattern 8 (buffering not needed) Pattern 15 (manual integration may suffice) |
| High change volume (100 or more per month), rapid model-change manufacturer | Pattern 5, 6, 7, 8, 9, 10 | Pattern 16 (once scale grows) |
| Aerospace, medical, automotive (individual unit traceability required) | Pattern 2 (serial effectivity) Patterns 12 & 13 (emergency change & recall) | Pattern 8 (buffering is prohibited for emergency changes) |
| Complex supply chain (Tier 1-3, global multi-site) | Pattern 4, 9, 10, 11, 15 | Pattern 14 (if not an SAP PLM environment) |
| 5 Self-Check Questions Before Starting Design |
|
Confirm the following five questions as a team before starting design: Q1: Do you accurately know your company’s ECO volume (monthly average and peak month)? → It is dangerous to proceed based on a “gut feeling” of “it’s not that many” without actual data (Anti-pattern ⑥) Q2: Is there agreement on which system — PLM, ERP, or MES — is the “starting point of change” and the “authority (source of truth) for change”? → If the starting point is unclear, duplicate management and contradictions will occur Q3: Is the effectivity condition management method (date/serial/lot) unified across all systems? → If not unified, prioritize designing Pattern 2 (Effectivity Triangle) first Q4: Is the processing route for emergency changes (safety/recall) explicitly separated from normal changes? → If not separated, design Pattern 12 first Q5: Are the linkage records between manufacturing serial numbers and the lots of parts used fully accumulated? → If not accumulated, prioritize building the foundation for Pattern 13 above all else (before you regret it when a recall occurs) |
End of document
Have a question about this article?
Ask the author directly — no sales pitch, just an answer.