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

E-Commerce @MIT

EDUCAUSE 2000October 11, 2000

Bob Ferrara, Director, I/T DeliveryLorraine Rappaport, E-Commerce Project Manager

Agenda - E-Commerce@MIT

Overview of MIT’s initiatives Bob Ferrara

Electronic Catalog (ECAT) demo Lorraine Rappaport

What we have learned Bob Ferrara

MIT E-Commerce Goals

Strategy based on MIT ReEngineering objectives from mid-1990sGoals included: Consolidate suppliers Reduce paper-based transactions Outsource lab and office supplies Leverage buying power

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

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

The Museum Shop

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 transactionsAverage dollar volume/month: $1.2mAverage transaction value: $196

SAPweb Requisitioning

SAPweb is a simpler, home-grown extension of the SAP GUI screensFour functions: Create Requisition Display Requisition List Requisitions Display PO (including payment history)

Avoided deployment of SAPgui all over campusAverage number of reqs./month: 3,000+ or 25% of all procurement transactions

SAPWeb Create Screen Shot

SAPWeb Req.1 Screen Shot

SAPWeb Req.2 Screen Shot

SAPWeb Req. # Screen Shot

SAPWeb Display Req. Screen Shot

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.

ECAT Design Strategy

Preferred vendor relationshipsVendor-managed product catalogsVendor capabilities – OBI, EDIAuthentication – x.509 digital certificatesIntegration with SAP for requisitioning, authorizations, approvals, payment processing, reporting, etc.

ECAT Implementation

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

ECAT demo (or following screenshots)

OD main page

OD category listing

OD subcategory listing

OD quick order

OD shopping basket

OD submit

Ecat2req 1

Ecat2req 2

Req submit

Displayreq 1

Displayreq 2

ECAT Design

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 CardVIP Card purchases limited to $3,000 (was $500 when we started)Very limited reporting of VIP Card transactions in SAPOur prices would likely be higher as vendors would pay transaction fees

Advantages of the ECAT Model

Fully integrated with SAPModular designFamiliar look-and-feel for usersTakes 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

Disadvantages of the ECAT Model

Multiple vendor sites – different capabilities and navigationDirect connections to each vendorMany components to maintainNot scalable to all vendorsBack-end batch processing in SAP and at vendor sites mean that order placement is not quite real time

The Road from Here

Are we having fun yet? Success measuresLooking aheadLessons Learned

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

Statistical Measures

Paper6%

Partner Flat File

10%

ECAT15%

VIP Card44%

SAP/SAPWeb25%

Looking Ahead

Can commercial solutions fit? Greater aggregation and coherence for customer – catalog experienceIndividual relationships vs. catalog aggregators and marketplacesGreater influence on vendors: Emphasize de-centralized purchasing Authentication and authorizations

Standards – OBI, EDI, and XMLFocus and development on internal providers strategies

Lessons Learned: if you’re thinking of doing e-commerce

“E-business is just business” – understand your business objectives firstDon’t be afraid to dabble – you don’t have to get it right the first timeMake sure your solution is flexible enough to adapt to evolving technology and user requirements

Lessons Learned: continuedInterdependencies carry some risks: Reliance on other systems and their

schedules, interfaces, and support

Communication and collaboration are critical to successUnderstand the impact of change on vendors, customers, and central office staffHave fun. This is cool stuff.

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

Contacts

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

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 sellersIntegration with buyers’ internal systems still needs workDo they help or hinder vendor partnerships?

Appendix on XML

We are hoping to experiment with XML with one or two new vendorsExpected 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

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