1. E-Commerce @MIT EDUCAUSE 2000 October 11, 2000 Bob Ferrara, Director, I/T Delivery Lorraine Rappaport, E-Commerce Project Manager

2. Agenda - E-Commerce@MIT Overview of MIT’s initiatives Bob Ferrara Electronic Catalog (ECAT) demo Lorraine Rappaport What we have learned Bob Ferrara

3. MIT E-Commerce Goals Strategy based on MIT ReEngineering objectives from mid-1990s Goals included: Consolidate suppliers Reduce paper-based transactions Outsource lab and office supplies Leverage buying power

4. MIT E-Commerce Landscape Buy-side initiatives came first ECAT – two generations of web ordering from partner vendors VIP Card – procurement credit card SAPweb – online web requisitioning No personalized portals, e-marketplaces…yet Infrastructure developed X.509 certificate authority for authentication EDI server deployed for vendor transactions SAP for authorizations and approvals

5. MIT E-Commerce Landscape Sell-side efforts are current focus Online ordering through Internal Providers for intra-MIT transactions Web ordering and online credit card processing for MIT merchants  ShopSite for catalog development  CyberCash and/or other software for credit card processing

6. The Museum Shop

7. VIP Card The VIP Card is a just credit card but… MIT pays the invoices SAP receives daily batch of invoices Approvers may distribute charges Transaction history maintained in SAP and MIT data warehouse Average transactions/month: 6,000+ or 44% of all procurement transactions Average dollar volume/month: $1.2m Average transaction value: $196

8. SAPweb Requisitioning SAPweb is a simpler, home-grown extension of the SAP GUI screens Four functions: Create Requisition Display Requisition List Requisitions Display PO (including payment history) Avoided deployment of SAPgui all over campus Average number of reqs./month: 3,000+ or 25% of all procurement transactions

9. SAPWeb Create Screen Shot

10. SAPWeb Req.1 Screen Shot

11. SAPWeb Req.2 Screen Shot

12. SAPWeb Req. # Screen Shot

13. SAPWeb Display Req. Screen Shot

14. ECAT ECAT (short for Electronic CATalog) is MIT’s system for online ordering from our preferred vendors for commodity items. ECAT is fully integrated with our SAP R/3 system for requisitioning, workflow approvals, and invoicing.

15. ECAT Design Strategy Preferred vendor relationships Vendor-managed product catalogs Vendor capabilities – OBI, EDI Authentication – x.509 digital certificates Integration with SAP for requisitioning, authorizations, approvals, payment processing, reporting, etc.

16. ECAT Implementation First vendor, NECX, rolled out in February, 1999 Office Depot, BOC Gases, and VWR Scientific Products added later Average transactions/month: 2,000+ or approximately 15% of all transactions Discussions underway with four prospective new ECAT partners

17. ECAT demo (or following screenshots)

18. OD main page

19. OD category listing

20. OD subcategory listing

21. OD quick order

22. OD shopping basket

23. OD submit

24. Ecat2req 1

25. Ecat2req 2

26. Req submit

27. Displayreq 1

28. Displayreq 2

29. ECAT Design

30. Why Not Use the VIP Card for ECAT? Many fewer VIP Cards than users with requisitioning authority in SAP (1500 cards vs. 4000 requisitioners) Equipment purchases not allowed on VIP Card VIP Card purchases limited to $3,000 (was $500 when we started) Very limited reporting of VIP Card transactions in SAP Our prices would likely be higher as vendors would pay transaction fees

31. Advantages of the ECAT Model Fully integrated with SAP Modular design Familiar look-and-feel for users Takes full advantage of vendors’ value-added features (e.g., MIT recommended products, MSDS, searches, etc.) Allows procurement staff to focus on vendor relationship management and outreach

32. Disadvantages of the ECAT Model Multiple vendor sites – different capabilities and navigation Direct connections to each vendor Many components to maintain Not scalable to all vendors Back-end batch processing in SAP and at vendor sites mean that order placement is not quite real time

33. The Road from Here Are we having fun yet? Success measures Looking ahead Lessons Learned

34. Are we having fun yet? How do we measure success? Results : Achieved goals; statistical measures Relationships : Vendors - managing relationships has high costs Internal relationships - end-user, centralized / de- centralized experience, communication, training Above all - managing the change issues Process : understand business before technology

35. Statistical Measures

36. Looking Ahead Can commercial solutions fit? Greater aggregation and coherence for customer – catalog experience Individual relationships vs. catalog aggregators and marketplaces Greater influence on vendors: Emphasize de-centralized purchasing Authentication and authorizations Standards – OBI, EDI, and XML Focus and development on internal providers strategies

37. Lessons Learned: if you’re thinking of doing e-commerce “E-business is just business” – understand your business objectives first Don’t be afraid to dabble – you don’t have to get it right the first time Make sure your solution is flexible enough to adapt to evolving technology and user requirements

38. Lessons Learned: continued Interdependencies carry some risks: Reliance on other systems and their schedules, interfaces, and support Communication and collaboration are critical to success Understand the impact of change on vendors, customers, and central office staff Have fun. This is cool stuff.

39. For more information Main SAPweb page: http://web.mit.edu/sapweb Main ECAT page: http://web.mit.edu/ecat ECAT design specifications: http://web.mit.edu/ljr/www/ecat_spec.html This presentation: http://web.mit.edu/ljr/www/presentations/educause2000.html

40. Contacts Lorraine Rappaport, ljr@mit.edu, 617-253-0749ljr@mit.edu Bob Ferrara, rferrara@mit.edu, 617-253-7495rferrara@mit.edu

41. Appendix on e-marketplaces Intriguing concept with many benefits: Access to wide variety of suppliers Easier to add new vendors Some offerings are very expensive for buyers and sellers Integration with buyers’ internal systems still needs work Do they help or hinder vendor partnerships?

42. Appendix on XML We are hoping to experiment with XML with one or two new vendors Expected benefits: XML should lower barriers for small and medium size vendors XML provides ability to use same data in different ways for different audiences Current limitations: Many different and proprietary versions of XML ebXML and RosettaNet initiatives may resolve some problems

43. Appendix on XML (cont.) The ebXML and RosettaNet consortia initiatives may resolve some problems by developing a technical framework for for utilizing XML to exchange business data http://www.ebxml.org http://www.rosettanet.org The two initiatives overlap and are expected to converge