Contents

2. Contents • eProcurement Space Maturity Assessment • Introduction • Models & Evolution • Model Overview Matrix • Model Maturity Assessment • Appendix

3. Contents • Introduction • eProcurement Defined • The Current State • Opportunities & Focus • Solution Drivers

4. Introduction • What is eProcurement? • Wiki defines “procurement” as “the acquisition of appropriate goods and/or services at the best possible total cost of ownership to meet the needs of the purchaser in terms of quality and quantity, time, and location”. • Procurement typically involves tasks such as sourcing, requesting, approving, ordering, receiving, and settling • eProcurement is the automation of the those same tasks as well as the integration of all related parties so as to minimize the total cost of ownership to the procuring org.

5. Introduction • The Current State of eProcurement • Models continue to mature, but at slower pace • eProcurement not so much a finished state, more of a continual evolution • Fewer newer eProcurement companies/solutions being created • Fewer existing eProcurement companies/solutions failing • Most dramatic value being created by third-party solutions • Niche software products providing superior tools/functionality • Managed services allowing buying orgs to share resources • External settlement tools allowing buying orgs to reduce invoice/payment labor while simultaneously creating revenue (up to 1.4% of contract spend) • eProcurement’s current advances are less about a technology revolution and more about a business revolution enabled by technologies and managed services • Today’s best practice offerings stable, reliable, 100+ installs, quantifiable and repeatable value proposition across all industries

6. Introduction • Opportunities & Focus • Focus on non-production procurement, > 10% of spend (trillions) • Current CEO & CFO direction driven by increasing value with decreasing amounts of spend and resources • Driving ever-increasing amounts of spend on contract • Reducing order-processing cost and cycle times • Providing intuitive, enterprise-wide access to professionally negotiated content • Empowering desktop requisitioning through employee self-service • Achieving procurement s/w integration with back office systems • Elevating procurement function to strategic importance within organization • Maximizing solution value via alignment; IT, operations, 3rd party partnering

7. Introduction • Solution Drivers • All eProcurement models attempting to solve similar business problems – reduce complexity and overall cost structure (i.e. total cost) while increasing content availability • Increase exposure of spend under management; low-hanging fruit maxed out • Decrease operational support requirements • Supplier information • Content Mgt • Transactional • Managing by transaction rather than exception • Decrease change mgt support requirements • Reduce search algorithm complexity • Reduce org communications for new content • Decrease maverick buying (AKA rogue spend) • Increase and/or generate settlement revenue

8. Contents • eProcurement Space Maturity Assessment • Introduction • Models & Evolution • Model Overview Matrix • Model Maturity Assessment • Appendix

9. Contents • Models & Evolution • eProcurement Model Overview • The EDI Model • Functionality Assessment • Pros/Cons • Scorecard • The Internet Model • Functionality Assessment • Pros/Cons • Scorecard • The Direct Connect Model • Functionality Assessment • Pros/Cons • Scorecard • The Third-Party Model • Functionality Assessment • Pros/Cons • Scorecard

10. eProcurement Model Overview Third-Party Integration Buyer  Third-Parties Supplier(s) Beginning in late 90s buyer used connection tools to integrate ordering process with preferred suppliers. Direct Connect (AKA Hub N Spoke) Buyer  (Hub)  Supplier(s) Internet technologies allowed buyers to connect to supplier directly or via a gateway or “hub” Internet Portals Buyer  Portal Supplier(s) Suppliers and distributors leveraged internet in mid 90s by creating Portals. EDI Buyer  EDI VAN  Supplier TDCC standardized railroad communication format in 1968; later refined into “X12”. Heavy adoption in 80s/90s. Being replaced by XML. 1968 Present High Level Time Line

11. EDI - eProcurement Model • The EDI Model • Buying and supplying orgs send/receive standardized “documents” via intermediary network (AKA hub) • No application integration • Revenue per transaction • Period Description (1968 – 1994) • 1968 – Transportation Data Communication Committee (TDCC) standardizes documents specific to moving freight internationally • Mid 80s – Order transmission “documents” further standardized to become “X12” (the prevailing standard used today) • Late 90s – Adoption begins to wane, relative to newer technologies (XML) • Major Players • Current Players: 123EDI, GHX, Gentran, Covalent Networks, True Commerce, 1EDI Source, Kleinschmidt, EC Grids, Pro EDI, Data Masons, Radley

12. EDI - eProcurement Functionality • ERP Supplier and Requester Portals • Not avail within this time frame; neither EDI nor application technologies supported internal or external portals • RFx (RFQ, Buyer & Seller Auction) • Activities were manual, not supported by the technologies available at the time • Content Management • Not Avail - EDI is order trans tech, doesn’t allow for application integration • Order Transmission • Transmits wide range of transactions ranging from orders through invoices • Requisition/content integration not supported • Settlement • Limited settlement support – invoice transmission supported, payment transmission not supported

13. EDI - eProcurement Pros/Cons • Advantages of EDI Model Vs Prior Model • Tested, secure, scalable trans communication tool • Saves money versus manual transaction entry • Disadvantages of EDI Model • Requires specialized relationships • Implementation and maintenance timely/costly • Value Added Network (VAN) performance contracts rigid, inflexible • Limited success adapting to open sourcing, flexible supply chain world • 3rd party integration (content mgt, settlement mgt) non-existent • Limited value – unable to work with newer application integration framework • Antiquated technology; new development focused on application integration

14. EDI – Maturity Scorecard

15. Internet - eProcurement Model • The Internet Model • Buying orgs manually access supplier/distributor portals for contract content • RFQ leveraged for fixed-price, sealed bid functionality • Web site data manually copied into ERP applications • Provider revenue subscription, advertising, and transaction fee based • Period Description (1995 – 1999) • 1995 – larger suppliers (technology, office supplies, etc.) create internet portals displaying products at corporate prices • 1998 – Product aggregation portals appear; display/sell products created and warehoused by manufacturer, handle payment, and allow for one PO from procuring org with aggregator splitting into per-supplier orders • > 97% of Internet players disappear within 5 years • Major Players • Survivors – SciQuest (life-sciences catalog), Ketera, Perfect Commerce, Staples.com, Grainger.com, Amazon, eBay, Priceline.com • Failures – AdAuction, WellBid, Bidcom.com, Freemarkets, VerticalNet, BizBuyer.com, PurchasePro, MediBuy.com, MRO.com, Neoforma, Pets.com, PaperExchange, and over 100 other IPOs/businesses

16. Internet - eProcurement Functionality • ERP Supplier and Requester Portals • ERP portals not avail within this time frame • Application/Internet technologies just beginning to come online in late 90s • RFx (RFQ, Buyer & Seller Auction) • Functionality offered via external web site, buyers/suppliers connect there • No integration with ERP applications • Content Management • Portals allow suppliers to offer content at org-specific pricing • Procuring orgs send one order, aggregator splits and manages shipping • Order Transmission • Order transactions not supported • Settlement • Settlement not supported

17. Internet - eProcurement Pros/Cons • Advantages of Internet Model Vs Prior Model • Online sites allow for buyer/supplier integration • Forward/Reverse auction now possible • Non-Production content available at contract price • Non-Production content requires no support • Disadvantages of Internet Model • Portals “inch deep, mile wide” • Requires specialized relationships • Limited availability/supplier adoption • No 3rd party integration (content mgt, settlement mgt) • Limited value • Content needs to be re-copied into ERP • All reqs must be “re-sourced”, no auto-sourcing, buyer required

18. Internet – Maturity Scorecard

19. Direct Connect - eProcurement Model • The Direct Connect Model • Buyers/suppliers connect to suppliers directly or via third-party “trading exchange” (AKA hub) • Buyers/suppliers connect to third-parties for content and settlement • Suppliers manage own data via external portals (self-service) • Requesters mange own transactions via internal portals (self-service) • Hub & settlement provider revenue per transaction or per catalog • Period Description (2000 – 2006) • 1999 – Ariba buys TRADEX as stock market floods connectivity toolset companies with cash. • > 47% of Direct Connect players disappear within 5 years • Major Players • Survivors – Ariba • Business Model Transformation – SciQuest, Ketera, Perfect Commerce; re-invent themselves as SaaS (strategic procurement applications/services) • Failures – Opensite, Requisite Technologies, CommerceOne, Vignette, WebMethods, workspace, Exterprise, and over 30 other IPOs/businesses

20. Direct Connect - eProcurement Functionality • ERP Supplier and Requester Portals • New “SRM” application front-ends allow for both supplier/requester portals • RFx (RFQ, Buyer & Seller Auction) • All RFx activities now available via portals, fully integrated • Content Management • XML technologies now allow for connection to external catalogs (supplier and aggregators) • Remaining content created and managed internally • Order Transmission • All prior EDI transaction documents now able to be transmitted via XML • Settlement • Real time 3rd party settlement tools leverage new technologies and allow procuring orgs to create significant revenue streams by connecting to third-party services

21. Direct Connect - eProcurement Pros/Cons • Advantages of Internet Model Vs Prior Model • Reductions in content mgt, supplier mgt, and transaction support costs • Single sourcing / auto-sourcing • Requesters able to configure products • Disadvantages of Internet Model • Limited requester adoption; confusion over search algorithm • Limited supplier adoption; only certain types offer internet-accessible content • Decrease in content control; changes to scope and pricing without consent

22. Direct Connect – Maturity Scorecard

23. Third-Party Integration - eProcurement Model • The Third-Party Integration Model • Provide value added services to increase “stickiness” • Next generation / hybrid cataloging constructs – “proxy” catalogs, self-managed catalogs, “live price call”, forms (all linked to contract id) • Business changes driving revolution; procuring organization, supplier contracts, sourcing process, content mgt & settlement processes re-designed to leverage new technologies/services • Product search becomes change mgt tool (“single-search”) • Centralized applications and managed services drive value • Creation of significant revenue streams via third-party settlement tools • Period Description (2006 – Present) • Applications and services continue to mature, but at slower pace • Business evolution and app/service integration/adoption create the value • Major Players • Leaders – SciQuest, Bank of America ePayables • “Fast Followers” - Ariba, Ketera, Perfect Commerce, Emptoris, GHX, JPMC Xign

24. Third-Party Integration - eProcurement Functionality • ERP Supplier and Requester Portals • New “SRM” application front-ends allow for both supplier/requester portals • RFx (RFQ, Buyer & Seller Auction) • All RFx activities now available via portals, fully integrated • Content Management • XML technologies now allow for connection to external catalogs (supplier and aggregators) • Remaining content created and managed internally • Order Transmission • All prior EDI transaction documents now able to be transmitted via XML • Settlement • Real time 3rd party settlement tools leverage new technologies and allow procuring orgs to create significant revenue streams

25. Third-Party Integration - eProcurement Pros/Cons • Advantages of Third-Party Model Vs Prior Model • Outsourced content mgt & improved content mgt tools reduce procuring org support costs • Portals reduce supplier information support costs • Single-search reduces transaction support costs, rogue spend; increases requester adoption and satisfaction • Single-sourcing, auto-sourcing decrease buyer transaction support • New cataloging constructs (hosted catalogs, proxies items, live price calls, self-managed catalogs) increase content control, allow for more spend to be driven on contract • Integration technologies and UNSPSC coding allow for Contract ID, Item ID assignment to marketplace purchases; improving contract spend reporting & facilitating inventory/production support • External settlement vehicles allow firms to create impactful revenue streams (procurement cost centers becoming cash centers); up to .5% of total spend • Disadvantages of Third-Party Model • Procuring data external to SRM/ERP application • Duplication of production content

26. Third-Party Integration – Maturity Scorecard

27. Contents • eProcurement Space Maturity Assessment • Introduction • Models & Evolution • Model Overview Matrix • Model Maturity Assessment • Appendix

28. eProcurement Model Overview Matrix

29. Contents • eProcurement Space Maturity Assessment • Introduction • Models & Evolution • Model Overview Matrix • Model Maturity Assessment • Appendix

30. eProcurement Model Maturity Assessment ** Although one large US health care firm is planning for a multi-marketplace model, none are in existence at this point. While it is being referenced, no data, implementations, or success stories are available at this time of this report. In fact, at least one was denied (State of Georgia) due to technology limitations, overall expense, and lack of marketplace participants. In short, it is too expensive and will not be supported by the current marketplaces (see the Appendix for more on Marketplace Model).

31. Contents • eProcurement Space Maturity Assessment • Introduction • Models & Evolution • Model Overview Matrix • Model Maturity Assessment • Appendix

32. Appendix – Multiple-Marketplace Model • The Multiple-Marketplace Model • Creating customized requisition pages within PS tools to aggregate content across internal, punch-out, and multiple marketplace catalogs • Option 1 – cache external content in PeopleSoft and customized requisition pages to search, display, and link to these external content stores • Option 2 – customize PeopleSoft requisition pages to make real time calls out to external content stores, wait while they compile the results, display the results as they are returned, and then link out to the remote catalogs in order to complete the purchase • NOTE both options require marketplaces and punch-outs to agree to development and being accessed “under-the-covers”; this was designed, but was abandoned due to inability to even prototype - technology limitations and lack of marketplace participants • Period Description (NA) • None – this would be bleeding edge if it even worked • Major Players • None – too risky, too expensive, doesn’t add relative value beyond current Third-Party Model.

33. Appendix - Multi-Marketplaces Functionality Assmnt • Functionality Assessment • This model would provide NO additional functionality that could not be obtained via a best of breed marketplace. • This model would provide NO additional content that could not be enabled via a best of breed marketplace. • NOTE: although different marketplaces do specialize in different types of content, all content connections use the same technology. It is much easier to deploy best of breed marketplace and enable new content, than to integrate with multiple marketplaces. • NOTE2: marketplace vendors such as GHX, Ariba, Ketera, and Emptoris are not best of breed. Their content data structures, content management tools, and search functionality are far less appealing then best of breed SaaS vendors such as SciQuest.

34. Appendix - Multiple-Marketplaces Pros/Cons • Advantages of Multiple Marketplaces Vs Prior Model • None. While there are potentially more “out of the box” enablements by using another marketplace, the cost and complexity would delay them for years. They would ultimately be scrapped as management was replaced. Far easier, cheaper, and faster to have one best of breed marketplace enable the connections on its own – that is what you pay them for. • Disadvantages of Third-Party Model • Bleeding edge technology. Sounds smart, but has never been successfully built before – has been attempted, but was discontinued for multiple reasons • Requires massive customization to the PS req pages (similar customizations took 3-6 months due to the requisition page-let); upgrade…time to re-design everything; marketplaces changes/upgrades, more re-designs (SaaS vendors add functionality every three months or so) • Marketplaces unlikely to cooperate – they want eyes on their application; hope to convert firms from legacy apps to their SaaS down the road • IF marketplace vendors were to change their application (big “IF”), the process would be slow • Item search likely to be VERY slow (must await results form all marketplaces)

35. Multiple-Marketplaces – eProcurement Cons Cont. • Disadvantages of Multiple-Marketplaces Model • Requester confusion will be massive and limit adoption; content now lives internally, remotely at “X” number of punch-outs and remotely at “X” number of marketplaces and NO ability to cross-compare? • Item search to be incomplete; marketplace results do not include punch-outs, when does requester even know that all sites have been searched? • 20+ search UIs (marketplaces, punch-outs, PS internal), multiple content mgt processes, multiple tool sets, data structures, search rules, etc • Limited ability to leverage managed services • More islands of content (punch-outs, marketplaces); one of the issues marketplaces are designed to eliminate • Forms (very helpful for highly dynamic content), proxy cats, self-managed cats, etc. would be difficult to deploy • Potentially limited ability to tie requested items back to their contracts (easily accomplishable if one single best of breed marketplace was deployed).