________

Cyberlynx B2B eMarketplace: Lessons Learned

A comprehensive review of the Cyberlynx Marketplace Project.

Timothy Davy 14 September, 2001

Cyberlynx Marketplace Project Review The intent of this document is to provide a review of the Cyberlynx project and to document lessons learned from the implementation, operation and support of the Marketplace. Lessons are grouped under the following headings, with the order of lessons presented not reflecting a ranking of their importance or otherwise. Lessons Cyberlynx Marketplace: Background Cyberlynx Procurement Services (referred to in this document as Cyberlynx) was formed in August 2000, jointly owned by The Commonwealth Bank Group, EDS Australia, Telecom New Zealand (Australia), Woolworths, Lion Nathan, Carter Holt Harvey, and Royal and Sun Alliance. Cyberlynx is a Procurement Service Provider premised on the strength of demand aggregation, driven by the buying strength of the shareholders. That is, the owners of Cyberlynx commit their spend for specific indirect goods and services, which provides the basis for an aggregated 'network' effect. Each new customer of Cyberlynx provides additional purchase volumes that can generate economies of scale and pricing discounts for the other existing participants of the Cyberlynx community. By developing a diverse range of customers across industries, Cyberlynx is able to develop category spend across a wide range of indirect non-strategic products and services. A primary component of the Cyberlynx technology strategy is the deployment of an on-line private eMarketplace. The marketplace is accessible by Cyberlynx shareholders and through it the shareholders can access, review and purchase indirect goods and services sourced on their behalf by Cyberlynx. The online marketplace is based on the Ariba solution called Ariba Marketplace Standard Edition, referred to as AMSE throughout the document. Lessons Learned This document captures lessons learned from the marketplace implementation and operation. Some of lessons relate specifically to the AMSE product, others are general 'business' lessons that may be relevant to other marketplace or e-procurement projects. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Content & Catalogue Management Visibility of Supplier Orders Buyer/Supplier Adoption ACSN AMSE Installation AMSE Transportation Facilities ConnectAriba.Com Training/Educational Resources AMSE Defects, Bugs & Issues Approach to Go Live Buyer v Marketplace Overall Lessons

Timothy Davy, 2001

Page 2

Lessons of Cyberlynx Marketplace

1. Content Management

in most e-procurement systems. Some content, whilst representable in traditional catalogue formats, lost richness and value when constrained into textual catalogues. A possible classification approach to the various forms of 'transactive content' might be as follows: 1 2. 3. Simple Catalogue items Complex Catalogue items Category Specific Solutions

Several issues relating to content management were identified throughout the project. We examine firstly two key concepts relating to content management derived from the project, before examining specific Cyberlynx-related content management issues. 1. Content Management is Complex

The primary lesson learnt was confirmation of the oft-quoted belief that 'content is king' content and content management plays an integral and central role in the successful deployment of an e- procurement/marketplace solution. The reasons for this are many, but at a high level, any e- procurement solution must be viewed by users as the path of last resistance to desired product, goods and services, otherwise the value of the solution is minimal. If users cannot quickly and easily find what they are looking for they will utilise other avenues, resulting in contract leakage, and maverick purchasing. End-user acceptance is vital in the overall success of an eprocurement solution and content management has the capacity to play a role in ensuring this acceptance. Unfortunately, content management is also complex. On the Cyberlynx project, many of the catalogues underwent over thirty revisions until the content was suitable for use in the marketplace. The reasons for this are many and are outlined in section 3 below. The primary lesson derived from this is that adequate time, effort and resources must be allocated to content management within any eprocurement implementation. The importance and effort of content management should not be under-estimated. 2. Different Products/Services have Different Content Requirements

Simple catalogue items are those representable in traditional catalogue formats. The key differentiator between Simple and Complex catalogue items is based on the relative importance or requirement to address specific catalogue patterns in the category. These catalogue patterns include related products (parent/child relationship), substitution between equivalent products, comparative products and configuration. Category Specific Solutions are those nonstrategic products and services that are not easily represented in traditional catalogue formats. Key factors defining a CSS include: significant process benefits can be gained from a technology application; work-flow centric process with multiple stakeholders involved, resulting in a complicated process in order to generate a requisition; enables a standard way for buyers to interact with the supplier market.

The key lesson identified here was that different products and services (ie, different content) are best suited to different means of representation. The Cyberlynx business model supported multiple categories of indirect procurement, and each category varied in terms of its propensity to be supported by a 'traditional catalogue' format that is the norm

The lesson here is that marketplace or eprocurement deployments need be aware of the limitations of traditional catalogues to adequately represent the products and services that buyers and suppliers may wish to transact with in the system. As content is a crucial component of any such system, the propensity of the system to adequately present such content may influence the product selection or performance or such system. Cyberlynx Content Management Experiences The pilot phase of Cyberlynx involved the production of electronic Catalogues for four Cyberlynx suppliers (Boise Cascade, National One, Lexmark, and Samsung).

Timothy Davy, 2001

Page 3

The below diagram shows the areas of work involved in this phase of the project:
Area of Work
Supplier Engagement

Description
Involved the process: 1 Approaching a supplier, 2. Informing suppliers on electronic Catalogues and their obligations as a supplier to Cyberlynx

Catalogue Generation

Involved how to proceed with a supplier in generating a CIF 3.0formatted Catalogue, once they committed to participating in the Cyberlynx exchange. Steps: 1. 2. 3. 4. 5.

Training of the supplier's staff on the use of the supplier Catalogue application & tools Consulting in conjunction with the supplier on the configuration of the application (i.e. initial set-up & configuration) Maintenance and management of the Catalogue by the customer Publication of a customised Catalogue in CIF 3.0 format Delivery of CIF Catalogues to Cyberlynx

Catalogue Verification

Once the Catalogue has been published it passes through a process that will allow Cyberlynx to verify the Catalogue for contract compliance and to decide when it is released to the buyers of the exchange

Catalogue Loading

Once the Catalogue was verified for contract compliance, it was loaded into the Ariba Marketplace environment and made available to marketplace buyers.

as to the reason that the data was invalid as well as the specific location in the spreadsheet. During the course of the pilot the following content-related issues were discovered: Catalogue Validation Tools and format, the relationship between various fields and ensuring the uniqueness of specific fields or field combinations. Macros were also developed that allowed the validated Catalogue data to be published in both CIF3, Marketplace and Buyer formats. UNSPSC Attributes Categories and Product Validation of the data included checking minimum and maximum field lengths, field

The biggest issue encountered during the pilot was the difficulty suppliers had in understanding and conforming to the CIF3.0 Catalogue format. Throughout the pilot, undocumented restrictions on content were discovered within the AMSE product. Communicating these discoveries to suppliers and updating their Catalogues to take them into account proved difficult. A tool was required that would allow suppliers to continue working on the Cyberlynx Catalogues in a manner that was independent of the final Catalogue formats. Given the tight timeframes involved, it was decided that an Excel spreadsheet should be used to collect the Catalogue data from suppliers as it would allow macros to be developed that would validate the collected data against the ever increasing list of rules, updated when and as they were discovered. The macros used to validate the data could be invoked by the supplier and provided them with an indication

At the time of this report, Boise Cascade had approximately 50 items that did not map in to any existing UNSPSC categories, and were still awaiting the allocation of suitable categories by the ECCMA. It would be expected this would be an ongoing problem for new suppliers brought into the marketplace. A further complication of most ontologies, including UNSPSC, is that new versions of the ontology set are released on a periodic basis. In order to ensure that commodities are categorised correctly and that they are compatible with the latest as well as the earlier

Timothy Davy, 2001

Page 4

UNSPSC versions, they should be categorised with CID's (Commodity Identifiers) rather than the UNSPSC categories. The CID codes are mapped to an appropriate UNSPSC version when the Catalogue is either published or imported. Unfortunately it is not a common practice by suppliers or procurement systems to use CID's, and as a result it generally falls to the responsibility of the suppliers Catalogue generation application to use CID's internally and to publish to a version of UNSPSC specified by the buyer. It was discovered during the pilot that Ariba Marketplace mandates all commodities to be categorised to the 4th UNSPSC level. It has been common practice that if a suitable UNSPSC category does not exist at the 4th level that the supplier categorise the commodity to the 3rdlevel (This practice is also documented in the "Ariba Buyer Catalogue Format Reference" documentation). This requirement necessitated that both Boise and National One categorise several hundred items to the 4th level, and the ECCMA needed to be called upon to create new categories where necessary. As stated above, Boise Cascade currently has 50+ items with the ECCMA awaiting the creation of new categories. The final UNSPSC issue was related to the use of attributes in the catalogue to allow a finer selection of specific commodities within a UNSPSC category, for example, using the attributes "grade, texture, size" to find a specific type of photocopy paper. There are currently no standards available to ensure a consistent set of attributes within a particular UNSPSC category across all suppliers. The dominant attribute set in use today is a proprietary attribute set designed by "Internat" called SMD (Standard Modified Dictionary). Unfortunately this does not have wide enough industry support to be considered a de facto standard. In an effort to address this issue the ECCMA have formed a working group to define a standard set of attributes for commodities called EIAC (the ECCMA International Attribute Code). In the absence of any International attribute standard it was decided that attributes would be required only for UNSPSC categories with more than 50 items. An arbitrary decision was made that buyers would be able to locate products within a category with less that 50 items by

searching on the short description, and that categories with more than 50 items would require attributes to allow buyers to further segment the category. Boise Cascade and National One each had about 15 categories with >100 items and another 15 categories with >50 items each. The largest category had over 300 items. In the absence of any standard it was decided to allow the suppliers to define attributes for categories that had >50 items based on the information that they have in their internal systems. The recommendation made to suppliers was to keep the number of attributes and their values to a minimum. This would make it easier to converge on either a locally agreed or international standard when one is developed. By allowing the suppliers to initially determine the attributes, it was possible to provide tightly segmented catalogues without the delays associated with the development of a locally agreed set of standard attributes, and the further delays as suppliers attempt to collect the attribute information to be compliant with the standard attribute set. Supporting products Configuration that require

Many technical products, and in particular IT products such as printers, have configuration requirements that range from simple to complex. Complex products require sophisticated configuration programs, usually hosted on the manufacturers web-site, and hence would require the use of "punch-out" technologies to allow buyers to "travel" to the supplier's web-site, buy from it and return to their requisition via a shopping trolley. In the case of the Lexmark Catalogue the configuration requirements were relatively simple - in order to make it easy for a buyer to select the correct components and options for a printer it would be necessary to be able to group all of the components and options for a particular model together. This requirement was not met by the standard UNSPSC categories as individual components of a printer such as the printer engine, sheet feeders, memory, cables, and consumables all have different UNSPSC categories making them impossible to group together if strict conformance to UNSPSC categories is maintained.

Timothy Davy, 2001

Page 5

For this reason, a decision was made to place all the Lexmark printer components and options in the same UNSPSC category as the printer engine and to use parametric attributes to further segment the printer group by printer model. This allowed a buyer to browse the UNSPSC categories to get to "Laser Printers" and then search the "model" attribute within "Laser Printers" to find all items/components for a particular printer model. The Lexmark Catalogue was further complicated as many of the printer options such as memory or sheet feeders were used across multiple (but not all) printer models. Unfortunately the current version of Ariba Buyer only allows an attribute to have a single value (a future version will support multivalued attributes). This means that to support the Lexmark products in Ariba Buyer they had to be categorised in the same UNSPSC category, as well as items that are used across multiple printer models being added to the Buyer Catalogue multiple times, once for each model that it is compatible with, each with a different "model" attribute to identify the model that it supported. - Price Breaks Many suppliers offer discounts or price breaks for larger orders. Ariba Buyer does not support rice breaks while Ariba Marketplace does. In order to support price breaks in Ariba Buyer it is necessary to enter an item multiple times, once for each price break, each with a different pricing and description. However the description and the price are not fields that are used in Ariba Buyer to uniquely identify an item. In Ariba Buyer, each item is uniquely identified by the combination of the fields "Supplier ID", "Supplier part ID" and "Supplier Part Auxiliary ID". Because the items are repeated in the catalogue the "Supplier ID" and the "Supplier Part ID" are the same. In order to uniquely define each price break the "Supplier Part Auxiliary ID" is set to a string that indicates the price break. For the Samsung Catalogue the "Supplier Part Auxiliary ID" was been set to Vol 1for single unit pricing, Vol l00+ for greater than 100 units, and Vol 500+ for volumes greater than 500 units. The product description in the "Item Description" and "Short Name" have been

appended with a string indicating the volume breaks to the buyer Because Ariba Marketplace provides Support for Price Breaks directly, and does not allow items to be multiply listed the spreadsheet needs to take this into account and publishes differently for Buyer and Marketplace. This was further complicated by the fact that while Ariba Marketplace supports price breaks, there is a known bug that prevents price breaks from being loaded via the Catalogue files. Because of this bug price breaks must be manually entered through the Marketplace administration tools. The use of this technique to support price breaks in Ariba Buyer does not allow price breaks to be enforced. It is possible that a buyer could order a single Samsung monitor at the price intended for volumes greater than 500. It is then the responsibility of the supplier to validate pricing, whereas this should be validated by the e- procurement application. Supplier and Manufacturer URL's

Ariba Marketplace provides fields in the catalogue that can contain URL's to both the supplier and manufacturer web-sites. These URL's are displayed along with other product information in the catalogue, and provide a link to suppliers & manufacturers web-sites. This enables the supplier and/or manufacturer to not only provide a picture, but to reference a webpage or pages, and display significantly more advanced and customised information. Some buyers have implemented firewalls that block employee access to the Internet, and therefore block access to the supplier and/or manufacturer web sites. To overcome this will require that the supplier be able to deliver a copy of their web content, customised for their buyer, that can be hosted internally. This then gives rise to other related issues surrounding which technologies are used to build the webpages/websites, as buyers may not be able to support a suitable environment required to display the web content. Assuming that the technology issue is resolved, the next point that would need to be addressed is how a supplier synchronises the delivery of new buyer catalogues with new web-content issues to a buyer and hosted internally.

Timothy Davy, 2001

Page 6

This is an academic point if the supplier cannot provide suitable URL's in the first-place. Suitable URL's ideally should not contain pricing or warranty information, unless the supplier can guarantee that the information presented to the buyer is in compliance with the buyers contract. Both Samsung and Lexmark where able to provide suitable URL's to HTML pages on their respective websites which included not only an image, but also appropriate auxiliary information that extends beyond what is available in the catalogue. Boise Cascade and National One do not have suitable web-sites. As an interim measure they placed the product images on a web server and providing a URL directly to the image. Both companies will need to develop a more sophisticated web site in the future to better differentiate their products. Product Descriptions

strong steeped in 8 bit ASCII. All non nonprintable characters had to be removed. Short Descriptions.

The AMSE Catalogue formats recognised that a product needs to have both a product title (referred to as a short description) 50 characters in length, as well a longer more detailed description 2,000 characters in length. At least one of the description fields must be present. If there is no detailed description, the short description is copied to the detailed description. In the event that there is no short description the detailed description is truncated to the first 50 character. The truncation of the detailed description (if it is greater than 50 characters) can produce a short description that is impossible for a buyer to understand. It is important that any item with a detailed description longer than 50 characters should have a suitable short description. Where possible, validation rules were built in to the developed spreadsheet tool, allowing the suppliers to quickly detect and correct these problems before publishing the Catalogue Product Images

Product descriptions were typically pulled from internal systems that were never expected to be publicly exposed. These descriptions had several problems including abbreviations and jargon, used to shorten the description length, which, while well understood within the supplier, were completely confusing when exposed to the buyer. A mix of full text, jargon and abbreviations, combined with a lack of standardisation across suppliers can make searching for a particular product almost impossible. Capitalisation.

Ariba Buyer does not support the use of images directly, but rather images are provided indirectly via URL's. The link docs not have to be just an image, but can be an entire HTML page, or application. Ariba Marketplace on the other hand, displays an image in the Catalogue. This Catalogue image is either: Embedded in the catalogue when loaded into the marketplace. Supplied as a separate file with the image name/path included in the catalogue A URL linked to an image on a website. (Note: the URL must be the URL of the image, not a page containing the image as is the case with Ariba Buyer).

Inconsistent use of capitalisation across descriptions makes reading a list of products difficult. For this reason Cyberlynx standardised on "first letter" capitalisation across most fields, and standard sentence capitalisation for descriptions. Invalid Characters

Some of the data present in the suppliers systems had been manipulated by Unicode systems with 16 bit characters, which resulted in characters being represented outside the printable ASCII range. Although both Ariba Buyer and Marketplace are able to support multiple languages, the Catalogue formats are

Ideally for each Ariba Buyer or Ariba Marketplace product, images should be available that clearly identify the product. However many vendors already have images of their products that group several items together, such that unless the images are clear and a visible label incorporated with the

Timothy Davy, 2001

Page 7

image, it is not possible for the buyer to discern which of the items is the product that they are looking for. An example is a photo offered by Boise Cascade which had 10 different biro pens neatly displayed in a fan arrangement on a velvet cloth. A buyer has no way to identify which of the pens displayed is the item that they have selected. For this reason it is necessary for a supplier to provide single item images, or to clearly label the items in the image. If the items are labelled then an agreement on images size would need to be reached otherwise the labels will become illegible if the image needs to be scaled down. Units of Measure Many of the prospective suppliers to Cyberlynx will have existing systems that already support EDI, and as a direct result will have existing "unit of measure" data for their products based on the EDI X12 UOM (Units of Measure). The internal UOM used by Ariba Buyer and Marketplace are based on the UN/UOM (United Nations Unit of Measure). Suppliers that don't currently support EDI will need to define UN/UOM data for each of their products, however it is an onerous burden on suppliers that do support EDI to maintain and support 2 different UOM standards. Ideally the catalogue application would translate the UOM standard used by the supplier to the UOM standard expected by the buyer. Due to the constraints of the pilot project it was not appropriate (although possible) to perform UOM translation in the spreadsheet application developed. As a result the responsibility of UOM translation must be born by cither the supplier or the buyer. Because the Ariba Buyer and Marketplace systems have the facilities to support UOM translation it was felt that for the short term it would be appropriate if this was used to perform any UOM translation that would be required. In order to avoid having to support UOM translation for a large number of UOM standards it has been decided that only the EDI X12 and UN/UOM standards would be accepted in Cyberlynx catalogues. Marketplace Software Bugs

During the course of the pilot several software bugs in the Ariba Marketplace where discovered which impacted the Catalogue format. These included: Price Breaks information was ignored when loaded in to the Marketplace via the catalogue files. Fortunately the only Catalogue effected by this was the Samsung Catalogue, and this was the smallest of all the Catalogues. Two versions of the Catalogue where maintained, one with price breaks for Ariba buyer, and one without price breaks for Marketplace. The price break information was then entered manually in to the marketplace. Version 7.5.1 corrected this problem, however at the time that this report was written the correction has not been tested. Supplier part numbers are currently required to be unique across all suppliers. Since there is no way to ensure that different suppliers do not use the same part numbers, it is necessary to modify a suppliers part number so that it contains extra information that will guarantee that it is unique. Orders placed on a supplier will need to have this "extra" information removed so that they are presented with the correct part number for entry in to their order systems. To overcome this problem and ensure that no modifications where required to the marketplace or supplier systems it was decided to prefix the supplier pat number with the string "<supplier short name> part#". This added string would not need to be stripped when passed to the supplier, as the order entry staff will intuitively separate the correct part number. The translation software used to import the catalogues is strips punctuation characters from the pat numbers. This means that the following part-numbers are identical when loaded in to the marketplace: ABC123, ABC-123, ABC/123.Each of which should represent different items. Product attributes (Parametric attributes) do not load correctly from the catalogue into the marketplace. To overcome this issue marketplace catalogue was modified

Timothy Davy, 2001

Page 8

such so that each parametric name was loaded from a separate file. Date problem- The Marketplace requires effective & expiry dates for each product, however it misinterprets the format and transposing day and month values. To overcome this the dates were hard coded at effective date =01 /01 /2001, expiry date = 01/12/2001 Cyberlynx members who implement a different (non-Ariba) procurement system will not be able to load the CIF or cXML Catalogues designed for Ariba Buyer. This poses two issues that Cyberlynx need to address. 1 - Creation of Catalogues in an appropriate format for non-Ariba procurement systems. 2 - Compliance of the catalogue in each of the different formats. Different procurement systems will also require different catalogue delivery mechanisms In order to overcome these issues it was decided that Cyberlynx would, in the immediate future, endorse the one procurement platform, Ariba and the ACSN. In the future this may have been extended to other platforms once the issues were resolved. However, contract compliance procedures need to be defined and implemented for the Ariba platforms before they could be extended to other procurement systems. In the short term it was Cyberlynx's intention to leverage the facilities of the Ariba Marketplace for suppliers who do not wish to implement an Ariba Buyer solution today. In order to allow members to use other procurement systems, it might be necessary for Cyberlynx to outsource the contract compliance to a Supplier Hub or other 3rd party, who is in a better position to manage and manipulate the catalogue formats The Ariba Connect Program is also addressing issues of non-Ariba e-procurement and eMarketplace systems connecting to the ACSN. This program is producing off-the-shelf "adaptors" or connectors that allow non-Ariba products such as Commerce One's BuySite to connect to the ACSN. The adaptor will perform translations between the Ariba and Commerce One format for catalogues and

PO's. This would allow Cyberlynx to continue to leverage the offerings of the ACSN for non Ariba players. Visibility of Supplier Orders Issue In order to offer a range of value added services to both the buyers and suppliers, Cyberlynx would need to gain visibility of all orders placed via the member's Ariba Buyer procurement systems. The easiest way to achieve this would be for Cyberlynx to be configured as the supplier to each of the members. In this way they would receive the orders as if they were the suppliers. While this would appear to be an acceptable solution the shortcoming is that the orders will not be separable into separate "real suppliers" by the buyers procurement systems, destroying their ability to provide a break down of spend across each real supplier. Further discussions with Ariba are required to resolve this issue. It is not practical to rely on the services of a Supplier Hub to provide the reporting required back to Ariba, and this approach would become unworkable when there are numerous supplier hubs in operation. Unless one is nominated as the "primary" hub and takes on added responsibilities including contract compliance, and as such will be the recipient of all Catalogues form all other supplier hubs. Buyer/Supplier Adoption Issues Buyer and Supplier adoption had a greater emphasis placed on it in the Cyberlynx project than might be expected from a walk-up solution such as AMSE. This was for a number of reasons. 1. Cyberlynx did not have an formal approach/methodology to buyer/supplier adoption Different users had different expectations of the marketplace and expected the marketplace to fulfil their expectations Integration was important to many marketplace participants.

2.

3.

Lessons

Timothy Davy, 2001

Page 9

The reason that Cyberlynx did not have a formal methodology regarding buyer/supplier adoption was that Cyberlynx's approach was to defer the development of such a methodology until a buyer or supplier was actually 'adopted' into the marketplace. This would drive the process and reveal the underlying issues.

the functionality, etc, that they promise. It should be the market-makers rather than the participants driving the marketplace. Integration was a key issues for many participants in the Cyberlynx marketplace. The AMSE solution was originally positioned as a on-ramp solution for users, with the only 'integration' requirement being a web browser. It became clear that most users were interested in ,or had been promised, direct integration from the marketplace to their back-end systems. Once again, this could be seen as a fault of the marketmaker in the way they positioned and communicated the marketplace and marketplace capabilities. It also revealed a lack of understanding of the positioning of the marketplace by the marketplace members, which can once again be related back to the market- makers role in managing the users. The AMSE product is not positioned by Ariba as having integration capabilities though Ariba has foreshadowed AMSE ERP adaptors in future releases of AMSE (yet to be confirmed).Integration is not difficult in a technical sense - business documents within AMSE are created as cXML documents and can be sent to a users back-end system for integration, or via the ACSN as cXML/EDI/Fax/E-mail, etc. What might prove more difficult (this is covered in detail in the CHH integration scoping document) is that different users will require different information from the market-place and, due to the nature of the AMSE product, it can not be customised for each user. Therefore, user 1 may want accounting information including GL and Cost Centres, whereas user 2 may want Item Codes and Project codes, etc. The users need to be aware of this, and this is something that once again, needs to be driven by the market-maker. AMSE Installation (7.5.x) Issues There exist several components of AMSE that are configured during the initial installation of the product and that once configured cannot be later changed. The configuration of these components has a direct impact on the functional operation of the marketplace system

EDS completed preparatory work on creating an adoption strategy that revolved around the user's 'technical' adoption into the marketplace. This was a template based approach that captured information need to accurately and effectively create the users in the marketplace environment and to ensure that the users had the required infrastructure to access the marketplace. The approach did not address any of the business issues related to their adoption.

It is of interest to note that Ariba does not have any enablement/adoption methodology or collateral. Their sum of such seems to currently consist of an early draft of the adoption strategy mentioned above that was forwarded to Ariba for review.

Different users of the marketplace (Samsung, Lexmark, Cater Holt Harvey, etc) had different expectations/requirements of the marketplace and expected the marketplace to conform to their requirements. Due to the inherent nature of a marketplace, this is not feasible, as a marketplace cannot be customised for each user. The reason for conflict was driven, largely, by poor positioning of the marketplace by Cyberlynx. Different messages were communicated to different players by different Cyberlynx personnel, such that different players ended up with different views of the marketplace operation, functionality and positioning. The lesson from this is that the market-maker needs to play a strong role in positioning the marketplace and both driving and managing the expectations of the marketplace members. A consistent message needs to be communicated by all market-maker members to all potential members of the marketplace. The market-maker should be careful as to the expectations they create and

Timothy Davy, 2001

Page 10

but are not documented in the AMSE documentation. For example, the character set used for the Oracle database the marketplace sits on directly determine whether XML documents can be exported from the marketplace (essential if any form of integration is required). If the wrong character set is chosen and integration is required, then the entire marketplace will need to be re-installed to resolve the problem. This problem is heightened in that the default Oracle character set is not the AMSE required character set. Lessons These issues were discovered during the initial phase of the Cyberlynx project in the sandpit AMSE environment. Due to the gap between completion of the sandpit environments and commencement of the development/production environments due to contractual issues, there was time for the project team to complete a new installation of the marketplace with these issues addressed and to then test the effect of such changes. In the course of a normal project these changes would have to have been made in the development/production environments and then tested. This would not be an ideal situation. 1. On future AMSE project, consult Cyberlynx documentation to familiarise project team with already identified issues Plan on at least two iterations of the sandpit environment (if possible). Pressure Ariba to include and highlight such issues in their documentation

All changes made must be tested thoroughly on all AMSE environments used in the project. This can prove somewhat difficult in the production environment once it has gone live as there maybe issues which prevent testing certain functionality, such as creating, routing, denying a purchase order, etc. Even if testing is done in the production environment before it has gone live, any changes made at a later date to the testing or development environments will need to be replicated in the production environment. This may cause difficulties and the project team needs to be aware of this. The availability of transportation facilities in the AMSE product has been requested as an enhancement but Ariba has stated they have no intention of providing this functionality. connect. Ariba.com Issues http://connect.ariba.com is Ariba's portal for knowledge and support. Developers report issues with the Ariba product through connect.ariba.com. A shortcoming ofconncct.ariba.com is that users are restricted to viewing issues that they have posted themselves. This means that although an AMSE issue may already have been discovered and addressed by a certain user, other users will not be aware of this and will need to go through the process of addressing and submitting the issue themselves. This can prove frustrating when a user spends a large amount of time trying to resolve an issue only to discover it's already been reported to Ariba, classified as an issue and resolved. Lessons 1. 2. Pressure Ariba to change the functionality of connect.ariba.com Before spending time addressing AMSE issues, first check with Ariba whether other users have reported the issue, and whether Ariba has already addressed/resolved the issue.

2. 3.

AMSE Transportation Facilities Issues Due to the immature state of the AMSE product there are currently no transportation facilities present in the product. This means that when multiple instances of the project are installed, such as development, test and production environments, any changes made in one environment must be manually replicated in the other environments, rather than being automatically ported through a transportation facility. Lessons

Training/Educational Resources Issues There is a lack of training and education resources addressing Ariba's product lines

Timothy Davy, 2001

Page 11

available. This is both for developers, with the majority of AMSE training held both sporadically and overseas, and also for endusers, including 'train-the-trainer', etc. The EDS/Cyberlynx team was unable to access any Ariba training or educational collateral. Lessons Be aware of this issue and plan accordingly. Be aware that training may not be a trivial exercise if EDS is require to create training collateral as it will be creating it from scratch.

Issue A lot of issues involved in a marketplace deployment will not become clear until the project has gone live, i.e., how do we enable a supplier, adopt a buyer, what integration issues are going to be important, what do different users expect from the system, etc. Cyberlynx as a client were not willing to go live until all issues they perceived as outstanding were addressed, including issues which had no operational impact for example, Americanised spelling of 'catalog' in the marketplace environment. Lesson

Product Defects, Bugs and Shortcomings Issue There were defects, bugs and shortcomings identified in the AMSE product roll-out. Many of these impacted upon the Cyberlynx AMSE deployment, and the EDS team was required to create work-arounds for several of these defects. These have been documented in detail in the supporting Cyberlynx AMSE documentation but are listed at a high level below. Attribute Enumeration Date Format Conflict Field Length Restriction Price breaks Import Internal Part Number Uniqueness Missing UNSPSC Segments Image loading mechanisms Out of date Branding Spec's Reporting Functionality GST/Sales Tax Applet-based Administrator Interface We should encourage the client to "go live", even with a pilot since this will reveal practical issues (and in some marketplace cases, even disprove business models before the client has sunk too much capital into the technology). ACSN Issue ACSN is a product offering from Ariba that is used to differentiate their product offerings. The foundation services of ACSN were to include: Catalogue Services - Tools to streamline distribution and management of supplier catalogues Transaction Management - Reliable, secure transmission and processing of business documents Directory and Registration - Creation, configuration, and management of relationships with trading partners Commerce Services Integration Platform Basic processes underlying commerce services, workflow to integrate services into transaction processes, integration across commerce services

One of the biggest issues with the AMSE product is the database that underlies the product. There are currently a large number of inconsistencies in terms of database normalisation, primary keys, etc. These inconsistencies are the root cause for number of defects and issues present in the AMSE product. Although resolving these inconsistencies would not be difficult, Ariba has not expressed any interest in doing so. The suggestions for addressing this issue can be found in the response to the AMSE Ballot Roadmap 7.5.3. Approach to Go Live

As it currently exists, very few, if any, of these services are available. ACSN functionality is weak and poorly explained. There are a lack of ACSN players in the APAC region, and costs associated with it are unclear. The only success experienced with ACSN on the Cyberlynx project was as a transaction

Timothy Davy, 2001

Page 12

mechanism, to allow the delivery of business documents to marketplace participants. Lesson ACSN should not be relied upon or expected to deliver promised functionality, and as such, ACSN-related functionality should not be offered to clients as part of a marketplace deployment/project. Buyer v Marketplace Issues There existed amongst the Cyberlynx members different degrees of uncertainty over the roles of Ariba Buyer and Ariba Marketplace. The Cyberlynx experience was as follows: Although there are many similarities between Ariba Buyer and AMSE, a fundamental difference remains in that Ariba Buyer is a "one-to-many" architecture and Ariba Marketplace is a "many-to-many" architecture. "One-tomany" means one buying organization per instance connecting with its many suppliers. Ariba Marketplace can serve many buyers and suppliers, thus lowering the market maker's maintenance costs of its customers. The functionality (and the look and feel) is very similar. Users are able to search for products, create requisitions, send them through workflow, receive products, etc. At this time, however, the Marketplace "buyer" functionality is not as robust as that of Buyer. A good example of this is in the area of workflow. The positive of Marketplace is the ease of remote and distributable administration of workflow. But it cannot do things such as ad-hoc routing. Also, areas like integration are weaker. A company may not be able to get everything they want out of a Marketplace as they can from their own Buyer application. This stems from being part of shared environment. While AMSE is highly customisable per marketplace, there are limitations to how much it can be -

customised for each buyer on the system. Some examples are: cost centre accounting, catalogue organisation, etc. There are certain aspects of a marketplace that have to beset up the same way for everyone. Some companies will want a greater ability to make it their own. product and supplier access: Ariba Marketplace offers features to enable individual buyers to sec only the products, suppliers and prices that are specific to them. But there are limitations to this, not just functional but as a matter of control. Some buyers may not want to rely on a shared marketplace to provide their users only what they want them to see. Single application serving internal needs: if T&E, e-Forms and other internal products and services are positioned as part of the value proposition for Ariba Buyer, it's an area that Ariba Marketplace isn't going to serve on behalf of their clients.

Overall Lessons The Cyberlynx Marketplace team were able to deliver a fully enabled, ACSN-ready, Marketplace instance based on the AMSE product in under five weeks. Many of the issues that would limit the successful deployment of an AMSE marketplace have been encountered, resolved and/or documented. Its feasible that the current Cyberlynx AMSE set-up be packaged as 're-useable 'AMSE environment, used to enable clients considering an eMarketplace to 'go live' with a 30- day pilot to reveal practical issues and test business models before the client has sunk too much capital into the technology.

Timothy Davy 14 September, 2001 tim.davy@gmail.com

Timothy Davy, 2001

Page 13