| Status | |
| Owner | The person responsible for driving this decision and documenting it. Type @ to mention people by name |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
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.
Summarise the recommendation being made for the reader, leaving the pro/con evaluation and exact decision-making process to the subsequent sections.
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.
| Area | Transaction | Primary EDI | Secondary EDI |
| Sales | Quotation | None | |
| Sales Contract | None | ||
| Sales Order | Elemica | Esker | |
| Billing | Customer Portal | Elemica , Tungsten, E-Invoicing, ARKHINEO | |
| Complaints | None | ||
| Procurement | RFx | None | |
| Catalogs | Ariba Catalogs | ||
| Contracts | None | ||
| Purchase Orders | Ariba Network | Elemica | |
| Order Confirmation | Ariba Network | Elemica | |
| ASN | Ariba Network | Elemica | |
| Service Entry Sheet | Ariba Network | Elemica | |
| Invoice | Ariba Network | Fedex , ProMaster , Synchro , Xerox , Ariba Network , E-Invoicing , Citibank , OpenText | |
| TM | Freight Orders | None | BluJay , Transwide, CASS |
| Invoices | None | CASS , TMS/CHEMLOGIX | |
| Truck Weight Update | None | Weighbridge Systems: Selfy Weighbridge, LAS, Weightbridge - Tecsidel, APAC Weighbridge Systems, Qbit Portaria | |
| Transport Event Update (via SAP BNL) | None | Selfy, Simba, Project 44, FDTMS | |
| Logistics | Inventory Management (Inc. Goods Receipt, Stock Transfer, Goods Issue, Stock on Hand etc.) | 3PL Template Interfaces | Arcese, Katoen Natie, Sunland Infor, Kenco, Mitsui Soko, PML CN, DHL CN |
| Inbound | None | Elemica | |
| Outbound | None | Elemica | |
| Goods Reciept | None | Elemica | |
| Finance | Payment | Swift | Swift , Bank Portals |
| GTS | Customs | None | Seeburger , COMEX , Jet etc.. |
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.
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.
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.
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.
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".
Sales
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.
Option A | Option B | Option C | Option D | |
|---|---|---|---|---|
| Criterion 1 |
|
|
|
|
| Criterion 2 |
|
|
| |
| Criterion 3 |
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.
