EBOM management: performance impacts of central contract splitting on call-off processing speed

We’re experiencing performance degradation in our EBOM call-off processing after implementing central contract splitting functionality in SAP PLM 2020. Background: we split large framework contracts into smaller call-offs based on EBOM item quantities. This creates better procurement visibility but has significantly slowed our call-off creation process.

Before splitting implementation: creating call-offs for 500-item EBOM took 2-3 minutes. Now: same operation takes 15-20 minutes. Our EBOM tables have grown substantially (3x size in 6 months) and we’re seeing database query timeouts during peak hours.

The contract splitting logic involves complex criteria (supplier capacity, lead times, min/max order quantities) which seems to be creating database performance issues. Curious if others have encountered similar challenges with central contract splitting and EBOM management? Any insights on optimizing contract splitting criteria, database indexing strategies, or managing EBOM table growth?

The contract splitting criteria complexity is likely your bottleneck. If the splitting logic evaluates multiple criteria (supplier capacity, lead times, quantities) for every EBOM item, you’re running hundreds or thousands of database queries per call-off creation. We optimized by pre-calculating splitting eligibility in a nightly batch job. Each EBOM item gets a pre-computed ‘splitting profile’ stored in a custom table. Call-off creation then just reads the profile instead of recalculating criteria every time. Cut our processing time by 70%.

The 3x table growth in 6 months is concerning. Contract splitting creates additional records for each split call-off, which multiplies your EBOM line items substantially. Check your database table statistics and ensure they’re being updated regularly. Outdated statistics lead to poor query execution plans, which could explain your timeout issues. Also verify that your EBOM tables have proper archiving configured to move old completed call-offs to archive storage.

EBOM table indexing is critical for splitting performance. The splitting queries typically join EBOM items with contract headers, supplier data, and material master. You need composite indexes that support these join patterns. Specifically, create indexes on (EBOM_ID, ITEM_NUMBER, SUPPLIER_ID) and (CONTRACT_ID, MATERIAL_ID, VALID_FROM). Without proper indexes, the database does full table scans which get exponentially slower as tables grow. For a 500-item EBOM with 3x table growth, you’re potentially scanning millions of rows per query.

Database growth management is essential for long-term performance. Implement a comprehensive archiving strategy for completed call-offs. After call-off is fulfilled and closed (typically 90-120 days old), archive to secondary storage. This keeps your active EBOM tables lean. We archive quarterly and it keeps table size stable even with high transaction volume. Also implement table partitioning - partition EBOM tables by year or quarter. This allows database to prune irrelevant partitions during queries, significantly improving performance for recent data access.

I’ve optimized EBOM and contract splitting performance for several large-scale implementations. The 15-20 minute call-off creation time for 500 items is definitely addressable through systematic optimization across all three key areas.

Contract Splitting Criteria Optimization: The performance issue stems from evaluating complex splitting logic at runtime for every EBOM item. Your current approach likely queries supplier capacity, calculates lead times, and checks min/max quantities for each of 500 items during call-off creation. With database queries for each evaluation, this becomes the primary bottleneck.

Implement pre-computation architecture:

  1. Create a nightly batch job that evaluates splitting criteria for all active EBOMs
  2. Store results in a ‘Splitting Profile’ custom table with fields: EBOM_ID, ITEM_ID, OPTIMAL_SPLIT_SIZE, PREFERRED_SUPPLIER, LEAD_TIME_CLASS
  3. During call-off creation, read from this profile table instead of recalculating

This shifts expensive computation to batch processing (off-peak hours) and makes call-off creation a simple table lookup operation. We’ve seen this reduce call-off creation time by 65-75% for similar scenarios.

Additionally, simplify your splitting criteria where possible. Instead of calculating exact supplier capacity in real-time, use capacity bands (LOW/MEDIUM/HIGH) that are updated weekly. The marginal accuracy loss is negligible compared to the performance gain.

EBOM Table Indexing Strategy: Your 3x table growth without corresponding index optimization is causing query performance degradation. EBOM tables need specific indexes to support contract splitting queries:

Create these composite indexes:

  • EBOM_ITEMS: (EBOM_ID, ITEM_NUMBER, MATERIAL_ID, SUPPLIER_ID)
  • EBOM_HEADERS: (EBOM_ID, STATUS, CREATED_DATE)
  • CONTRACT_SPLITS: (CONTRACT_ID, EBOM_ID, CALL_OFF_NUMBER, STATUS)
  • SUPPLIER_CAPACITY: (SUPPLIER_ID, MATERIAL_GROUP, VALID_FROM)

These indexes support the typical query patterns in contract splitting logic - joining EBOM items with contracts and suppliers, filtering by status and dates. Without these, database performs full table scans which scale poorly as tables grow.

Also implement filtered indexes on frequently-queried subsets. For example, create filtered index on EBOM_ITEMS where STATUS=‘ACTIVE’ since most queries only care about active items, not historical closed ones.

Database Growth Management: Uncontrolled table growth is a long-term performance killer. Implement comprehensive data lifecycle management:

  1. Archiving strategy: Archive completed call-offs after 120 days. This moves historical data to archive tables while keeping active working set small. Configure SAP PLM archiving objects for EBOM and contract data. We typically see 60-70% reduction in active table size after initial archiving run.

  2. Table partitioning: Partition EBOM tables by created date (quarterly or yearly partitions). This allows database to perform partition pruning - queries for recent call-offs only scan relevant partitions. For a query on last 30 days of call-offs, database scans single partition instead of entire table.

  3. Purging old split metadata: Contract splitting creates intermediate calculation data that’s often not cleaned up. Implement periodic purge of split calculation logs and temporary data older than 30 days. This prevents unnecessary bloat.

  4. Regular table maintenance: Schedule weekly database statistics updates and monthly index rebuilds. As EBOM tables grow and change, statistics become stale and indexes fragment. Regular maintenance keeps query optimizer making good decisions.

Additional Optimization - Splitting Granularity: Review your splitting logic granularity. Creating 50-100 small call-offs from a 500-item EBOM generates excessive database records and processing overhead. Implement minimum call-off size thresholds:

  • Minimum 10 items per call-off
  • Minimum value threshold (e.g., $5,000 per call-off)
  • Maximum split factor (e.g., don’t split into more than 20 call-offs)

This keeps splitting benefits while preventing over-fragmentation. We’ve found that optimal splitting typically creates 8-15 call-offs from a 500-item EBOM, not 50+.

Implementation Roadmap: For immediate impact (implement first):

  1. Add critical database indexes (1-2 day effort, immediate 40-50% improvement)
  2. Implement splitting profile pre-computation (1 week effort, 30-40% additional improvement)

For sustained performance (implement within 30 days): 3. Configure archiving for completed call-offs (2-3 day effort) 4. Implement table partitioning (3-5 day effort) 5. Optimize splitting granularity thresholds (1-2 day effort)

With this comprehensive approach, your 500-item EBOM call-off creation should complete in 3-5 minutes instead of 15-20 minutes. We’ve deployed similar optimizations for clients processing 2,000+ item EBOMs with sub-10-minute call-off creation times.

Consider the splitting granularity too. If your logic creates very small call-offs (splitting 500 items into 50-100 call-offs), you’re creating excessive overhead. We implemented minimum call-off size thresholds - don’t split if resulting call-off would be less than 10 items or below certain value threshold. This reduced our call-off volume by 40% while maintaining procurement visibility benefits. Fewer call-offs means less database records and faster processing.