Issue

The previous KDD066 established the principle of simplifying and standardizing EDI platforms by defining that each business process must have:

• One Primary EDI system

• One (optional) Secondary EDI system, allowed only by exception

However, at the time of KDD066 approval The Primary and Secondary EDIs listed in the table were indicative and are based on the conceptual Design understanding. As part of Detailed Design (SyWay), there is now a need to revisit each process from the KDD066 table and evaluate the options and Finalise the Primary and Secondary EDI. Along with that there is a need to establish a governance process in case any new EDI is required.

Recommendation

Summarise the recommendation being made for the reader, leaving the pro/con evaluation and exact decision-making process to the subsequent sections.

Background & Context

KDD066 established a strategic direction to simplify and standardise EDI platforms by:

• Defining a Primary EDI per process

• Allowing Secondary EDI only by exception

• Reducing fragmentation and long-term operational complexity

  KDD066 - EDI platforms in the f…

Since then, SyWay Detailed Design has delivered:

• A clear To-Be integration architecture centred on SAP Integration Suite, APIs, events, and controlled legacy EDI coexistence for 3PLs

  3PL SyWay TO BE Final

• A clarified supplier collaboration strategy, including Ariba Network, Supplier Portal, and phased onboarding models

  Ariba Network

• Confirmed bank connectivity decisions (e.g. continued SWIFT Bureau usage)

  SyWay - Workshop_ MBC recommend…

As a result, the indicative EDI assignments in KDD066 no longer reflect the executable To-Be design and must now be formally confirmed or adjusted.

Assumptions

Clearly describe the underlying assumptions which informed or limited the choices available, or impacted the decision: cost, schedule, regulatory requirements, business drivers, country footprint, technology, etc. Include links as necessary. This section is important because a future change in circumstances might invalidate some key assumptions, which then prompts a decision to be revisited. 

Constraints

Capture any constraints or limitations inherent to the recommended option. This could be aspects which, if changed or removed in future, could cause the decision to be revisited or invalidated. For example, a constraint might be that a new product has significant gaps in important functionality, which caused an older alternative to be recommended. If those gaps are closed in future, this might cause the decision to be invalidated.

Impacts

Describe the impact of the decision on other aspects such as other processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.

Financial Impact

Explain the financial impact of adopting the recommended option. This must explain both the implementation and operational aspects, i.e. both the effort & cost of implementing and operating longer-term. 

Business Rules

The decision may translate into business rules which enforce the decision and will require configuration. List these business rules here. For example, "An Outline Agreement cannot be created via the RFQ process. An awarded RFQ can only result in a Purchase Order". 

Options considered and Evaluation

Sales

Commerce Portal – Primary EDI

Description

• Customer- and distributor-facing digital channel supporting end-to-end Lead-to-Cash interactions.

• Enables product discovery, pricing, cart & checkout, order tracking, document access, and support through a single portal.

• Integrated in real time with SAP and CRM, designed as the strategic digital front door for customers.

Why Primary

• Aligns with SyWay and ERP Rebuild To-Be architecture and digital ambitions.

• Provides a single, standard onboarding channel for new customers and distributors.

• Supports real-time, transactional processing rather than document exchange only.

• Reduces manual handling and dependency on legacy EDI platforms.

• Enables future capabilities (self-service, AI support, analytics, digital revenue growth).

• Ensures consistent customer experience across GBUs (“One Syensqo”).

Elemica – Secondary EDI

Description

• VAN-based B2B integration platform used for structured exchange of orders, shipping, inventory, and settlement documents.

• Currently supports a set of key and strategic customers with established, high-volume integrations.

• Provides stable, proven connectivity for customers with long-standing Elemica dependencies.

Why Secondary (and not Primary)

• Several key and strategic customers are already deeply integrated with Elemica and have explicitly indicated no appetite to migrate to a new EDI or portal channel.

• Forcing migration would introduce commercial risk and potential disruption to critical revenue streams.

• Elemica ensures business continuity for these customers without impacting ongoing operations.

• However, Elemica is not aligned with the long-term SyWay / ERP Rebuild strategy, which favors SAP-native, API-driven, and portal-based interactions.

• Retaining Elemica as Primary would:

  • Prolong dependence on a VAN-based model

  • Increase long-term cost and complexity

  • Slow down adoption of standardized digital channels

• Positioning Elemica as Secondary allows:

  • Protection of strategic customer relationships

  • Controlled, exception-based usage

  • Prevention of further expansion of the Elemica footprint

Recommendation:

• Commerce Portal is the Primary EDI, as it is scalable, reusable, and applicable to all customers.

• Elemica remains Secondary, as each onboarding requires a dedicated project and some strategic customers are unwilling to migrate.

Procurement

Supplier Portal – Primary EDI

Description

• SAP-integrated, API-based supplier collaboration channel enabling purchase order exchange, order confirmations, and document sharing.

• Designed as a lightweight, scalable entry point for suppliers without requiring heavy onboarding.

• Access managed via email-based authentication, allowing rapid enablement of suppliers.

Why Primary

• Can be used by any supplier, regardless of size, volume, or technical maturity.

• Requires no formal onboarding project, reducing time, cost, and dependency on suppliers.

• Aligns with SyWay detailed design and SAP-standard integration patterns.

• Acts as the default collaboration channel for non–Ariba suppliers.

• Avoids forcing small or low-volume suppliers into complex platforms.

• Supports gradual, controlled adoption of more advanced platforms where justified.

Ariba Business Network – Primary EDI (Selective)

Description

• SAP-managed B2B network supporting structured, system-to-system procurement transactions.

• Provides M2M integration for purchase orders, confirmations, ASN, service entry sheets, and invoices.

• Widely adopted by large, high-volume suppliers with existing enterprise licenses.

Why Primary (Selective)

• Preferred channel for high-volume, digitally mature suppliers already active on Ariba.

• Enables straight-through processing with minimal manual intervention.

• Leverages existing supplier investment in Ariba licenses and integrations.

• Covers a significant portion of total PO volume through a limited number of suppliers.

• Avoids unnecessary duplication of integration channels for suppliers already optimized on Ariba.

Transportation Management – EDI by Mode of Transport

Road Transport

Primary EDI:

• BN4L

Secondary EDI (Transition / Exception):

• Transwide (Europe – transition)

• BluJay / TMS4S (US & Canada – transition)

Rationale

• BN4L provides global road carrier collaboration with a single operating model.

• Transwide and BluJay remain only where migration is still in progress.

• Target state is one global platform for road freight collaboration.

Ocean Transport

Primary EDI:

• BN4L

Secondary EDI:

• None (target state)

Rationale

• BN4L will cover carrier collaboration for ocean freight, including the USA and Canada where no collaboration tool is currently integrated

  TM

  .

• Eliminates gaps and manual processes in ocean freight execution.

• Aligns with the global standardisation objective.

Air Transport

Primary EDI:

• BN4L

Secondary EDI:

• None (target state)

Rationale

• BN4L enables air carrier collaboration, currently not supported by an integrated platform.

• Provides consistent visibility and execution across regions.

• Reduces dependency on emails and manual coordination.

Summary Table – TM EDI by Mode

Logistics – 3PL Integration Decision Model

(3PL Integrated vs No Integration)

Context

SyWay defines a standardized, scalable approach for integrating third-party warehouses with SAP S/4HANA, while also recognizing that not all external warehouses justify or require system integration

3PL SyWay TO BE Final (1)

.

The To-Be model therefore supports two clear scenarios:

1. 3PL with system integration

2. No system integration (manual / SAP-only execution)

Option 1 – 3PL Integrated

Description

• The 3PL WMS is system-integrated with SAP S/4HANA via SAP Integration Suite.

• Supports outbound, inbound, and warehouse execution processes through APIs (primary) or EDI (secondary).

• Real-time or near real-time exchange of delivery, inventory, and status information.

When this applies

• High or medium transaction volume

• Operational dependency on the 3PL for execution

• Need for inventory visibility and reconciliation

• Strategic or long-term warehouse partner

• Regulatory or service-level requirements

Characteristics

• Standard SyWay interface set (DI01–DI06, PU01–PU02, IM01–IM02)

• Event-driven processing from SAP

• Status acknowledgements from 3PL

• Central monitoring via AIF + Fiori

• Plug-and-play onboarding with controlled adaptations

Key Benefits

• Real-time visibility of warehouse operations

• Reduced manual effort and errors

• Standardized execution across 3PLs

• Scalable onboarding of new providers

• Improved SLA monitoring and issue resolution

Option 2 – No Integration (SAP-Only / Manual)

Description

• No system-to-system integration between SAP and the external warehouse.

• Warehouse execution is handled outside SAP, with postings performed manually or via periodic updates.

• SAP remains the system of record, but without automated message exchange.

When this applies

• Low transaction volume

• Temporary or short-term storage

• Non-strategic warehouses

• 3PL has no WMS or no integration capability

• Cost or effort of integration not justified

Characteristics

• Manual creation and confirmation of deliveries and goods movements

• No real-time inventory visibility

• No automated status or acknowledgment messages

• Operational reliance on procedures rather than interfaces

Key Benefits

• Zero integration cost

• Faster short-term setup

• Suitable for exceptional or transitional scenarios

Comparison – 3PL Integrated vs No Integration

KDD Decision Positioning

• 3PL Integration is the default choice where volume, criticality, or visibility requirements justify it.

• No Integration is an accepted exception, not a target state.

• The decision must be taken per warehouse, based on business and operational criteria.

• Where integration is chosen, API-based integration is primary and EDI is secondary, per SyWay standards.

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log