There are many rapid changes occurring these days in the world of SAP EDI and B2B support. This article provides a view on the traditional approach and how this is quickly changing.

If you are an SAP customer, the traditional approach to implementing EDI looked as follows:

1. Purchase a third party EDI system
2. Purchase and install servers (development, testing and production servers)
3. Hire EDI experts
4. Train EDI staff on EDI system
5. Hire software developers to integrate SAP business processes with the EDI system
6. Identify priority customers and suppliers for on-boarding
7. Contact all trading partners to understand and document the EDI or B2B files they are willing to support
8. Scope the on-boarding project
9. Design, develop and deploy integration scripts between SAP and your EDI system
10. Now map all of these business processes from the EDI system to hundreds of different combinations of data formats and communication protocols that your trading partners demand
11. Set-up EDI and IT Custom Service helpdesk
12. Kick-off multi-year on-boarding project

The traditional EDI implementation scenario is represented in these 12 steps. It is also typical, that as soon as one department begins to implement EDI or B2B data exchanges, then 11 other departments suddenly MUST have it. EDI is often required in the following areas:

• Supply Chain (SAP SNC, SRM, etc)
• Transportation Management (TM and Inbound and outbound Logistics)
• Procurement
• Inventory and Warehouse Management
• Production Planning
• Manufacturing Execution
• Sales Order Management
• HR Benefits (insurance, 401k, etc.)
• Global Trade Services
• Financial Supply Chain
• Treasury (electronic funds transfers, etc)
• Much, much more...

Each of these departments have their own high priority trading partners and business deliverables that are suddenly reliant on the EDI department to on-board all of their key trading partners immediately.

An additional challenge, many departments are asking for support of different EDI and B2B standards. Treasury wants electronic banking messages, the supply chain wants XML B2B standards, customers want traditional EDI, small customers can only send flat files, etc.

The EDI department now has a "combinatorial explosion" to manage. The traditional approach to this problem is to throw more IT budget, software, hardware and FTEs at the problem, but that doesn't work these days.

SAP is changing the traditional approach to EDI now. They are uniquely positioned to be able to solve many of these traditional EDI challenges for their entire SAP customer base. They have studied where efficiencies, cost savings and economies of scale could be gained, and after much work and research they announced they had invested in and become a co-owner of an EDI and B2B exchange that utilizes SAP technology. This exchange operates on the SAP NetWeaver platform and utilizes NetWeaver PI and other SAP technologies to simplify EDI and B2B for all SAP users.

The EDI/B2B Exchange's use of canonical data models at the hub, powerful software tools that enable rapid alignments of complex data formats across thousands of trading partners provide efficiencies never possible before. All companies connected to this SAP-centric exchange can now reuse the maps and connections to over 40,000 other companies (this number grows daily).

As a result of SAP's recent investment in this exchange, there are now multiple joint development projects underway that are advancing the strategy of Business Network Transformation, a phrase used often by SAP CEO Leo Apotheker. This phrase describes the concept of taking a macro-view of all SAP users, and looking for efficiencies that SAP can introduce across their entire customer base. This can also be called a network view. A network view looks at services that can be performed that add value to the entire network or customer base. Often these network-centric services (e.g. EDI/B2B) can be provided in a cloud computing environment, on SAP technology, and integrated with all SAP users through pre-defined enterprise services. A method of extending eSOA outside the four walls of the enterprise.