Interoperability: The Key to Integrating the Supply Chain and Reducing Costs

1. Interoperability: The Key to Integrating the Supply Chain and Reducing Costs Darrell Schwartz, Metaldyne Gene Hopkins, ArvinMeritor Don Guibord, Lear Terry Onica, QAD

2. Agenda • Interoperability Background • Terry Onica, QAD • Interoperability with Inventory Visibility Tools • Darrell Schwartz, Metaldyne • Interoperability with Inventory Visibility Tools and EDI • Don Guibord, Lear • ebXML and Web services Convergence • Gene Hopkins, ArvinMeritor • Panel Discussion

3. Interoperability Background Terry Onica, QAD

4. Inventory Visibility Background • Increasing requirement to cut inventories and lead-time with suppliers • Creation of web-based tools to provide inventory visibility • Current environment: • Multiple proprietary tools providing the same utility • Implementations are customer driven • Significant waste and complexity due to lack of interoperability • EDI may be used as completely or as a complement

5. The Problem with Inventory Visibility Today Customer IV Solution A Customer IV Solution B Customer IV Solution C Supplier’s Enterprise IV Solution A IV Solution B IV Solution C

6. The Problem with Inventory Visibility Today • Good NewsInventory visibility tools are proven to reduce premium freight and inventory • Bad NewsSavings are diminished by the cost to deploy multiple customer solutions • NIST estimates a $5 billion annual penalty for lack of interoperability in the automotive supply chain The various IV tools do not interoperate !

7. EDI and Inventory Visibility Today Source: AIAG IV&I Work Group

8. And it is not just limited to Inventory .. • Quality • Warranty • Purchasing • Finance • Logistics There are 120+ AIAG XML Messages Currently in Process to be Developed in these Areas !

9. The Ideal Solution • Web access visibility to customer data • Data integration capability • Open standards – interoperability • Compatibility with current EDI practices Goal: Visibility tools that talk to each other

10. The AIAG IV&I Solution Customer IV Solution A Customer IV Solution B Customer IV Solution C Supplier IV Solution D IV&I Interoperability (XML BOD Message Exchange)

11. IV&I Deliverables/Artifacts for Phase I IVI Business Processes IVI Business Processes • Min/Max • Kanban • Schedules and Forecast • Sequencing IVI Data Messages (XML BODs) • SyncShipment • SyncQOH • SyncDelivery Receipt IVI Transport (EbXML) IVI Transport (Web services) • PoC Whitepaper Note: Completed item

12. Subsequent Work Subsequent Work . . . . . . Kanban Logistics IV&I Project Status and Future Technical Scope POC-Phase 1 Processes IVI BODs SOAP WS- Security HTTP/S TCP/IP Functional Scope Min/Max Process; QOH BOD

13. Where to Find More Information • AIAG web site ( http://www.aiag.org ) • QAD web site ( http://www.qad.com ) • QAD Supply Visualization Web Site (http://www.mfgx.net ) • QAD representative Terry Onica ( tjo@qad.com ) • IV&I POC Phase II • QAD IV&I Whitepaper (at www.qad.com) • IV&I Demo Brochure • Materials Replenishment OAGIS BODs (XML Messages)

14. Interoperability with Inventory Visibility Tools Darrell Schwartz, Metaldyne

15. Current Situation: Without Interoperability Intermet S Metaldyne SV with data from ERP C IV Tool A

16. Inventory Visibility Without Interoperability Intermet View of Metaldyne Data

17. Case Study • Inventory reduction • Opened 6000 feet of floor space • Raw inventory cut by $500,000 with one supplier with consignment and inventory visibility • 15% reduction in administrative time due to faxing • Decrease in data entry due to increase in ASNs from suppliers

18. Intermet S Current Situation: Without Interoperability Metaldyne SV with data from ERP IV Tool A C1 IV Tool B Ford data from legacy system C2

19. AIAG IV&I POC Scenario:With Interoperability Metaldyne data from ERP QAD SV C1 Intermet S SyncQOH BOD (XML) iConnect IV Tool Ford data from legacy system C2

20. Inventory Visibility with Interoperability

21. iConnect Exchange Web Screen Shot

22. IV&I SyncQOH BOD Data

23. What Does Interoperability Mean for My Company Today? • Move from push to pull fulfillment Reduced Lead Time • Reduce inventory and premium freight Increased ROA • Better decision support for suppliers Integrated suppliers • Increased inventory accuracy Fewer surprises • Enable exception management Removing NVA Work Goal: Better connected supply chains at a lower cost

24. Interoperability with Inventory Visibility Tools and EDI Don Guibord, Lear

25. “Before-After” Scenario Description: • An OEM customer buys parts supplied by Lear [Warren], Lear [Marshall], Johnson Controls and Collins & Aikman. The Lear [Warren] location sequences & coordinates all parts to sub-assemble and ship to OEM’s plant. This requires Lear [Warren] to maintain inventory for parts until a demand broadcast is received from the OEM. All participants are EDI capable and exchange EDI information as much as possible to speed information, however, key portions of the data flow are still executed manually and depend on FAXes

26. C&A JCI Legend Lear(Marshall) DELFORRequirementFax QOHASN (856)Shipment OEM Lear(Warren) Current Data Flow FAX FAX FAX Shipment Each location compares their inventory levels @ Lear with quantities requested by OEM for the following day. The difference determines the quantity to be shipped that day to Lear Warren.

27. Process Before IVI BODs • Lear Warren must send faxes to JCI to indicate how much quantity Lear has on hand. Many manual steps by multiple business functions at all locations Lear(Warren) JCI • JCI manually computes shipment to Lear by comparing the fax with the OEM’s DELJIT. ASN is sent electronically to Lear indicating Shipment. JCI Lear(Warren)

28. Faxed / EDI Data

29. Data Flow After Automation JCI Legend DELJITSyncQOHShip ConfirmRequirementASN (856) Shipment OEM Lear(Warren) Suppliers can view demand adjusted inventory data consolidated on a single screen. XML QADSV iConnect All data flows are automated, regardless of format, closing the loop for payment upon consumption Proprietaryflat files FTP L e a r EDI C & A

30. After Automation • Suppliers have choice of any interoperable Inventory Visibility tool • ASN to Lear can be created automatically • No more daily faxes • No more data entry errors • No more computational errors • Partners can leverage existing systems with new technology to improve the business processes

31. Benefits of Streamlined Process • When Lear(Warren) adopts this methodology it will enable them to: • Reduce phone calls and associated costs caused by errors in data entry • Achieve full automation of data flow • It will allow JCI/Lear(Marshall) and Collins & Aikman to: • Eliminate 300-500 hours of manual computation and data entry time • Reduce/eliminate expedited shipment charges • Better manage Lear Warren’s inventory

32. ebXML and Web ServicesSOA Convergence Gene Hopkins, Director B2B Communications ArvinMeritor, Inc.

33. What about EDI? • EDI has been a great B2B Integration tool, and will not go away for some time yet • However, EDI is a simple Data Integration Tool that relies upon many coordinated Batch Processes • With the need for faster, more integrated, even real-time B2B solutions, EDI will become less used and Web Services will begin to infiltrate our lives more and more • EDI is a DATA integration tool, while Web Services is a PROCESS integration tool. • It’s an evolution, not a revolution!

34. The Enablers of Web Services • So why are Web Services now becoming such a big deal? • The internet has become almost a “utility” in almost every company • Everyone has email, which brought the needed connectivity • The need for “Real-Time” processing is being driven by the market (the 5 Day Car example from the Big 3) • The maturation of XML has simplified the data integration component. Soon, we may no longer need EDI translators IF the application vendors XML enable their products • Emergence of SOAP (Simple Object Access Protocol) as a SOA (Service Oriented Architecture) component now allows any platform to talk to any other platform • (Don’t count our chickens on this yet, but it CAN happen)

35. Background • First, understand that there are really two definitions of Web Services, depending upon who you are talking with: Web Services used Generically - Automated connections between people , systems and applications that expose elements of business functionality as a software service and create new business value.Forrester Research Web Services used Specific to Microsoft Solutions – Some people incorrectly infer that .NET solutions and Web Services are one in the same. In reality, .NET solutions use Web Services standards.

36. Service Oriented Architecture (SOA) • A "service oriented architecture" is not one component or technology, it is an approach to designing an enterprise architecture consisting of multiple infrastructure and application components • Web Services and ebXML are not single technologies but a set of capabilities defined by open standards that can be used to construct architectures or applications

37. Advantages of SOA • Allows the promise of reuse inherent in SOA to be realized • Build once, use often • One place to make one change - brings encapsulation from the object world to the Enterprise world • Lower development, operations and maintenance costs • Interface by contract • Loosely couples Publisher and Consumer so each can vary independently • Integration is explicitly defined and thus better understood at the application and Enterprise level

38. The Web Services “Stack” • Exchange of information via the internet still requires all of the same considerations as any other distributed application • Security / Authentication - Determine the identity of the sender • Authorization – Is the sender allowed to perform this function? • Integrity – Verify that the data has not been compromised • Confidentiality – ensure that unauthorized parties cannot get to the content • Non-Repudiation – Proving that the transaction occurred, and who participating the transaction. • Transport – Moving the payload from sender to receiver • Payload – the actual message content. Could be any type of data, including XML, drawings or other attachments, and even EDI

39. Example of a Web Service App • “Request for Quote” Web Service • Atomic Web Service “GetPartNbr” • Atomic WebService “GetPONbr” • Atomic Webservice “GetPrice” • Atomic WebService “GetInvOnHand” • “ProcessOrder” Web Service might use the same Atomic level Web Services • Atomic Web Service “GetPartNbr” • Atomic WebService “GetPONbr” • Atomic Webservice “GetPrice” • Atomic WebService “GetInvOnHand”

40. Web Services Standards? Not yet • Two sets of competing “standards” are being used for B2B integration in the Big 3 Automotive OEM’s • ebXML developed by OASIS at GM • Web Services standards emerging through W3C, WS-I, OASIS, at Ford • Similar, but different … • Both leverage XML-based technologies • But, the two are largely incompatible • Both support Service Oriented Architecture (SOA) but with different paradigms

41. ebXML – Expanded view All aspects of B2Bi Model are fully supported by ebXML Business Content Industry Vertical Content OAGi Business Object Documents Universal Business Content Registry/Repository Three Primary Specifications from ebXML: Business Process—Workflow Management Business Process Spec. Schema Security Partner Profiles Collaboration Party Agreement Reliable Messaging Message Service Handler Core XML Standards Network/Transport Platform/OS/SOA

42. Web Services “Stack” Atomic Composite Discovery, Negotiation, Agreement Components Choreography Grouping ReliableMessaging Security Quality of Service Transactions Coordination Policy Interface + Bindings Description Messaging XML Non-XML Transport Transports

43. Risks of Non-Standardization • Only option to standards-based approach: • Proprietary solutions with high out-of-band requirements • Companies like ArvinMeritor, with customers in the OEM, Retail Aftermarket, and Dealer Parts markets will suffer greatly if we are forced to implement non-standard and proprietary solutions. • Higher costs & vendor lock-in. Lord help us! • While convergence is expected through “evolutionary” forces • It is not happening fast enough (Yet) • Further entrenchment of competing standards through continued investments • Participation in Industry Workgroups, such as AIAG is essential!!!

44. Risks of Non-Standardization • Higher complexity & cost • Some suppliers and OEMs forced to implement multiple standards • Slower rate of adoption • Low “consumer confidence” – Some suppliers are in a “wait and see” mode • Solution providers “hedging” their bets • Bottom Line • NIST estimates a $5 Billion* annual penalty due to lack of interoperability in the automotive supply chain

45. The Result • In other words – Similar but Different Approaches to the same problem

46. Why is EDI Perceived as Difficult & Expensive? • Started in mid-1980’s with a goal of Industry Standards • But soon evolved to “standards be damned” • This variation in standards leads to redundant mapping expense and the need to support multiple standards / versions • And again, EDI is great at integrating data, but the inherent batch nature of EDI makes it less favorable as a Process Integration tool.

47. What is Different this Time? • Namespace, communications protocol and interface definition language based on simple, existing, implemented, open standards • TCP/IP, XML, HTTP, … • Ubiquitous support • We made the right choices this time • Loose coupling - from EAI technologies • Integration by contract, implementation by whatever - from CORBA, OO • Keep it simple, stupid - from the Web • Work together on it - from J2EE, HTTP, XML, HTML etc. • Broad industry support • e-Businessdriving convergence of the Web and IT

48. Questions ?