Automated manufacturing collaboration workflow using BOPF enhancements for multi-site approval routing

PLM SAP PLM
, , , , , , , ,
1

I wanted to share our implementation of an automated manufacturing collaboration workflow in SAP PLM 2021 that significantly improved our multi-site approval efficiency. We have five manufacturing plants globally, and engineering changes required manual coordination across sites for impact assessment and approval.

We built a BOPF enhancement framework solution that automatically routes change notifications to affected manufacturing sites based on product BOM structure and plant assignments. The system analyzes which plants produce the affected components and creates parallel approval tasks with configurable routing logic.

The BOPF enhancement hooks into the standard change management process and adds custom status logic for manufacturing site coordination. When an ECO is released, our custom BOPF node triggers automated workflow tasks to each plant’s manufacturing engineering team. The implementation reduced approval cycle time from an average of 12 days to 4 days by eliminating manual routing and enabling parallel reviews.

I’ll share the key technical details and lessons learned from this project for others considering similar workflow automation using BOPF enhancements.

2

The BOPF enhancement framework is powerful but complex. One thing to watch out for is performance when analyzing BOM structures for large assemblies. If you’re traversing deep BOMs to identify affected plants, the determination can become a bottleneck. Did you implement any caching or optimization strategies for the plant identification logic? Also curious about error handling - what happens if one plant’s workflow task fails to create?

3

From a workflow architecture perspective, parallel approval routing can get tricky when you need to aggregate results. How did you handle the scenario where some plants approve and others reject? Is there a master workflow that waits for all plant responses, or does each plant workflow independently update the ECO status? We’ve seen implementations where the coordination logic becomes more complex than the original manual process.

4

Great questions - let me provide comprehensive implementation details covering all three focus areas:

BOPF Enhancement Framework: We created a custom BOPF business object called ZCL_ECO_MFG_COLLAB that extends the standard engineering change order object. The architecture uses three key BOPF components:

  1. Custom node ECO_MFG_ROUTING with attributes for plant assignments, routing status, and approval tracking
  2. BOPF action ROUTE_TO_PLANTS that triggers on status change
  3. Determination class ZCL_ECO_PLANT_DETERMINATION that executes the routing logic

The BOPF enhancement is registered in transaction BOBX and linked to the standard ECO business object through an association. This allows our custom logic to execute without modifying SAP standard code.

Key implementation pattern:

* BOPF Action Implementation
METHOD /bobf/if_frw_action~execute.
  " Get affected plants from BOM analysis
  CALL METHOD determine_affected_plants
    EXPORTING io_eco = io_modify
    IMPORTING et_plants = lt_plants.

  " Create workflow tasks for each plant
  LOOP AT lt_plants INTO ls_plant.
    CALL FUNCTION 'SAP_WAPI_CREATE_EVENT'
      EXPORTING objtype = 'ECO_MFG'
                event = 'PLANT_APPROVAL_REQUIRED'.
  ENDLOOP.
ENDMETHOD.

Automated Workflow Triggers: The workflow integration uses event-driven architecture rather than synchronous BAPI calls. When the BOPF action executes, it raises business events for each affected plant. These events are subscribed to by workflow definitions that create approval tasks automatically.

The event coupling provides loose integration - if workflow task creation fails for one plant, it doesn’t block the others. We implemented a monitoring dashboard that shows workflow creation status and alerts administrators to failures.

For the parallel approval coordination that Lars asked about, we use a master workflow with a multi-step task pattern. Each plant’s approval is a separate workflow task, and the master workflow uses a fork-join pattern to wait for all responses. The aggregation logic is:

  • All plants must approve for ECO to proceed to implementation
  • Any single rejection triggers a review state where engineering can revise and resubmit
  • Timeouts are configurable per plant (we use 48 hours default)

The master workflow maintains a status table tracking each plant’s response. This table is exposed through a Fiori app so project managers can see real-time approval progress.

Custom Status Logic: To address Raj’s question about status synchronization, we created a hybrid approach. The BOPF node has a custom status attribute ZSTATUS_MFG that tracks manufacturing-specific states (ROUTING_IN_PROGRESS, AWAITING_PLANT_APPROVAL, PLANT_APPROVED, PLANT_REJECTED). This status is separate from the standard ECO status.

We built a BOPF validation that ensures status consistency:

METHOD /bobf/if_frw_validation~execute.
  " Validate custom status aligns with standard status
  IF is_eco-status = 'REL' AND ls_mfg_status NE 'ROUTING_IN_PROGRESS'.
    " Raise validation error
    APPEND VALUE #( severity = 'E'
                    message = 'Invalid manufacturing status' )
           TO et_failed_key.
  ENDIF.
ENDMETHOD.

The validation prevents status conflicts and ensures the BOPF-managed state stays synchronized with standard change management status.

For Susan’s performance question, we implemented significant optimization. The BOM analysis for plant identification was indeed a bottleneck initially. We added:

  1. Cached plant-material assignments refreshed nightly
  2. BOM explosion limited to 3 levels (configurable) - deeper structures use cached data
  3. Parallel processing for large BOMs using ABAP parallel processing framework
  4. Database view that pre-joins material-plant assignments with BOM data

These optimizations reduced determination execution time from 8-12 seconds for complex assemblies to under 2 seconds.

Error handling is comprehensive. The BOPF framework’s transaction management ensures atomic operations. If workflow creation fails for any plant, the entire BOPF action is rolled back and the ECO status doesn’t change. We log failures to application log (transaction SLG1) and send email alerts to workflow administrators. A background job retries failed workflow creations every 30 minutes.

One lesson learned: BOPF’s change document integration required custom configuration. We needed audit trails showing which plants were routed to and when. We implemented BOPF change document enhancement (transaction BOBD) to capture routing events in standard change document tables. This provides compliance audit support.

The implementation took about 12 weeks with a team of 3 developers. The results have been excellent - approval cycle time reduction from 12 days to 4 days, and manufacturing teams report much better visibility into pending approvals. The automated routing eliminated the manual coordination emails that previously caused delays and confusion.

For anyone considering this approach, my key recommendations:

  1. Start with BOPF framework training - it’s powerful but has a learning curve
  2. Design your custom status model carefully before coding
  3. Invest in performance optimization early, especially for BOM analysis
  4. Build comprehensive monitoring and error handling from the start
  5. Use event-driven workflow integration for loose coupling

The BOPF enhancement framework is ideal for this type of workflow automation because it provides transaction safety, state management, and clean extension points without modifying standard code.

5

This sounds like exactly what we need. Can you share more details about how you integrated BOPF with the standard workflow framework? Did you use BOPF actions to trigger workflow tasks, or did you build a custom determination that calls workflow BAPIs?

6

We used BOPF actions combined with custom determinations. The key was creating a BOPF action called ROUTE_TO_PLANTS that executes when the ECO status changes to ‘Released’. This action calls a determination class that analyzes the BOM structure, identifies affected plants from material plant assignments, and then invokes workflow creation BAPIs to generate approval tasks. The BOPF framework handles the transaction consistency and rollback logic automatically, which was much cleaner than trying to code this in a user exit.

7

Interesting approach. How did you handle the custom status logic? BOPF nodes have their own state management, but SAP’s standard change management also has status fields. Did you create a custom status attribute in your BOPF node, or did you map to the standard status tables? We’re struggling with keeping BOPF-managed state synchronized with standard SAP status in a similar project.