the cyberlynx b2b emarketplace - lessons learned

8/4/2019 The Cyberlynx B2B eMarketplace - Lessons Learned

1/13

________

Cyberlynx B2B eMarketplace: Lessons Learned

A comprehensive review of the Cyberlynx Marketplace Project.

Timothy Davy

14 September, 2001


2/13

Timothy Davy, 2001 Page 2

Cyberlynx Marketplace Project Review

The intent of this document is to provide a

review of the Cyberlynx project and todocument lessons learned from the

implementation, operation and support of the

Marketplace.

Cyberlynx Marketplace: Background

Cyberlynx Procurement Services (referred to

in this document as Cyberlynx) was formed in

August 2000, jointly owned by TheCommonwealth 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 thestrength 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 Cyberlynxcommunity. By developing a diverse range ofcustomers 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 anon-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 on-

line marketplace is based on the Ariba solutioncalled 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.

Lessons are grouped under the following

headings, with the order of lessons presentednot reflecting a ranking of their importance or

otherwise.

Lessons

1. Content & Catalogue Management2. Visibility of Supplier Orders3. Buyer/Supplier Adoption4. ACSN5. AMSE Installation6. AMSE Transportation Facilities7. ConnectAriba.Com8. Training/Educational Resources9. AMSE Defects, Bugs & Issues10. Approach to Go Live11. Buyer v Marketplace12. Overall Lessons


3/13


Lessons of Cyberlynx Marketplace

1. Content ManagementSeveral issues relating to content management

were identified throughout the project. Weexamine firstly two key concepts relating to

content management derived from the project,

before examining specific Cyberlynx-related

content management issues.

1. Content Management is ComplexThe 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 successfuldeployment of an e- procurement/marketplace

solution. The reasons for this are many, but ata 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 e-

procurement solution and content management

has the capacity to play a role in ensuring this

acceptance. Unfortunately, content

management is also complex. On theCyberlynx 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 e-

procurement implementation. The importance

and effort of content management should not

be under-estimated.

2. Different Products/Services have DifferentContent Requirements

The key lesson identified here was that

different products and services (ie, different

content) are best suited to different means ofrepresentation. 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

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 thevarious forms of 'transactive content' might be

as follows:

1 Simple Catalogue items2. Complex Catalogue items

3. Category Specific Solutions

Simple catalogue items are those representable

in traditional catalogue formats. The key

differentiator between Simple and Complexcatalogue items is based on the relative

importance or requirement to address specific

catalogue patterns in the category. Thesecatalogue patterns include related products

(parent/child relationship), substitutionbetween equivalent products, comparative

products and configuration.

Category Specific Solutions are those non-

strategic products and services that are not

easily represented in traditional catalogueformats. Key factors defining a CSS

include:

- significant process benefits can be gainedfrom a technology application;

- work-flow centric process withmultiple stakeholders involved,

resulting in a complicated process in

order to generate a requisition;

- enables a standard way for buyers tointeract with the supplier market.

The lesson here is that marketplace or e-

procurement 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 crucialcomponent 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).


4/13


The below diagram shows the areas of work

involved in this phase of the project:

Area of Work Description

Supplier

Engagement

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. Training of the supplier's staff on the use of the supplier Catalogue application & tools2. Consulting in conjunction with the supplier on the configuration of the application (i.e.

initial set-up & configuration)

3. Maintenance and management of the Catalogue by the customer4. Publication of a customised Catalogue in CIF 3.0 format5. Delivery of CIF Catalogues to Cyberlynx

Catalogue

Verification

Once the Catalogue has been published it passes through a process that will allow Cyberlynxto 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.

During the course of the pilot the following

content-related issues were discovered:

- Catalogue Validation ToolsThe biggest issue encountered during the pilotwas 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 suppliersand 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 independentof 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

as to the reason that the data was invalid as

well as the specific location in the spreadsheet.

Validation of the data included checking

minimum and maximum field lengths, field

and format, the relationship between variousfields 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 Categories and ProductAttributes

At the time of this report, Boise Cascade had

approximately 50 items that did not map in to

any existing UNSPSC categories, and werestill 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


5/13


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 versionwhen the Catalogue is either published or

imported. Unfortunately it is not a commonpractice 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 internallyand 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 hasbeen common practice that if a suitable

UNSPSC category does not exist at the 4th

level that the supplier categorise thecommodity to the 3rdlevel (This practice is

also documented in the "Ariba BuyerCatalogue 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, BoiseCascade currently has 50+ items with the

ECCMA awaiting the creation of new

categories.

The final UNSPSC issue was related to the useof attributes in the catalogue to allow a finerselection 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 particularUNSPSC 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 considereda 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 andNational One each had about 15 categories

with >100 items and another 15 categorieswith >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 itemsbased 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 toconverge on either a locally agreed or

international standard when one is developed.

By allowing the suppliers to initially determinethe attributes, it was possible to provide tightly

segmented catalogues without the delaysassociated 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 that requireConfiguration

Many technical products, and in particular IT

products such as printers, have configurationrequirements that range from simple tocomplex. 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 totheir 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 togroup 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.


6/13


For this reason, a decision was made to place

all the Lexmark printer components and

options in the same UNSPSC category as theprinter engine and to use parametric attributes

to further segment the printer group by printermodel. 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/componentsfor 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 multi-valued attributes). This means that to support

the Lexmark products in Ariba Buyer they hadto 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 themodel that it supported.

-- Price BreaksMany suppliers offer discounts or price breaksfor larger orders. Ariba Buyer does not supportrice 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 areused 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 Supportfor Price Breaks directly, and does not allow

items to be multiply listed the spreadsheetneeds 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, thereis 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 abuyer could order a single Samsung monitor at

the price intended for volumes greater than500. 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'sAriba 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 productinformation in the catalogue, and provide alink 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 theirbuyer, that can be hosted internally. This then

gives rise to other related issues surrounding

which technologies are used to build the web-

pages/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.


7/13


This is an academic point if the supplier cannot

provide suitable URL's in the first-place.

Suitable URL's ideally should notcontain pricing or warranty information, unless

the supplier can guarantee that the informationpresented 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 respectivewebsites 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 havesuitable web-sites. As an interim measure they

placed the product images on a web server and

providing a URL directly to the image. Bothcompanies will need to develop a more

sophisticated web site in the future to betterdifferentiate their products.

- Product DescriptionsProduct descriptions were typically pulled

from internal systems that were never expectedto 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 whenexposed 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.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 sentencecapitalisation for descriptions.

- Invalid CharactersSome 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

strong steeped in 8 bit ASCII. All non non-

printable 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 moredetailed 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 truncatedto the first 50 character. The truncation of

the detailed description (if it is greater than 50

characters) can produce a short description thatis impossible for a buyer to understand. It is

important that any item with a detaileddescription 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 theseproblems before publishing the Catalogue

- Product ImagesAriba Buyer does not support the use ofimages directly, but rather images areprovided 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 loadedinto the marketplace.

- Supplied as a separate file with the imagename/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).

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


8/13


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 10different biro pens neatly displayed in a fan

arrangement on a velvet cloth. A buyer has noway 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 itemsin 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 thatalready support EDI, and as a direct result will

have existing "unit of measure" data for theirproducts 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 theirproducts, however it is an onerous burden on

suppliers that do support EDI to maintain and

support 2 different UOM standards.

Ideally the catalogue application wouldtranslate the UOM standard used by thesupplier 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 beborn 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 toperform 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 ignoredwhen loaded in to the Marketplace via thecatalogue 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 thecorrection has not been tested.

Supplier part numbers are currentlyrequired 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 containsextra 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 totheir order systems. To overcome thisproblem 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

" 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 importthe catalogues is strips punctuationcharacters 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 representdifferent items.

Product attributes (Parametric attributes)do not load correctly from the catalogue

into the marketplace. To overcome thisissue marketplace catalogue was modified


9/13


such so that each parametric name was

loaded from a separate file.

Date problem- The Marketplace requireseffective & expiry dates for each product,

however it misinterprets the format andtransposing 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 adifferent (non-Ariba) procurement system

will not be able to load the CIF or cXML

Catalogues designed for Ariba Buyer. Thisposes two issues that Cyberlynx need to

address. 1 - Creation of Catalogues in an

appropriate format for non-Ariba

procurement systems. 2 - Compliance ofthe catalogue in each of the different

formats. Different procurement systemswill also require different catalogue

delivery mechanisms

In order to overcome these issues it was

decided that Cyberlynx would, in the

immediate future, endorse the oneprocurement 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 definedand implemented for the Ariba platformsbefore 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 manageand manipulate the catalogue formats

The Ariba Connect Program is also addressing

issues of non-Ariba e-procurement and e-

Marketplace 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 theorders as if they were the suppliers.

While this would appear to be an acceptablesolution 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 aSupplier 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 onadded responsibilities including contractcompliance, and as such will be the recipient

of all Catalogues form all other supplier hubs.

Buyer/Supplier Adoption

IssuesBuyer 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 formalapproach/methodology to buyer/supplier

adoption

2. Different users had different expectationsof the marketplace and expected

the marketplace to fulfil their expectations

3. Integration was important tomany marketplace participants.

Lessons


10/13


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 methodologyuntil a buyer or supplier was actually 'adopted'

into the marketplace. This would drive theprocess and reveal the underlying issues.

EDS completed preparatory work on creatingan 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 hadthe 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 marketplaceand expected the marketplace to conform totheir 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, bypoor 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 andpositioning.

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

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. TheAMSE 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 interestedin ,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 alsorevealed a lack of understanding of the

positioning of the marketplace by the

marketplace members, which can once againbe 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 atechnical 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 provemore difficult (this is covered in detail in theCHH 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 includingGL 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


11/13


but are not documented in the AMSE

documentation.

For example, the character set used for theOracle database the marketplace sits on

directly determine whether XML documentscan 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 entiremarketplace 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 sandpitAMSE environment. Due to the gap between

completion of the sandpit environments andcommencement 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 projectthese 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, consultCyberlynx documentation to familiarise

project team with already identified issues

2. Plan on at least two iterations of thesandpit environment (if possible).

3. Pressure Ariba to include and highlightsuch issues in their documentation

AMSE Transportation Facilities

Issues

Due to the immature state of the AMSEproduct 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

All changes made must be tested thoroughly

on all AMSE environments used in the project.

This can prove somewhat difficult in theproduction environment once it has gone live

as there maybe issues which prevent testingcertain 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 dateto 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 anenhancement 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 shortcomingofconncct.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 willneed 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. Pressure Ariba to change thefunctionality of connect.ariba.com

2. Before spending time addressing AMSEissues, first check with Ariba whether

other users have reported the issue, and

whether Ariba has already

addressed/resolved the issue.

Training/Educational Resources

Issues

There is a lack of training and education

resources addressing Ariba's product lines


12/13


available. This is both for developers, with the

majority of AMSE training held both

sporadically and overseas, and also for end-

users, including 'train-the-trainer', etc. TheEDS/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.

Product Defects, Bugs and Shortcomings

Issue

There were defects, bugs and shortcomings

identified in the AMSE product roll-out. Manyof 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 levelbelow.

- 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 InterfaceOne 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 databasenormalisation, 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

Issue

A lot of issues involved in a marketplacedeployment will not become clear until the

project has gone live, i.e., how do we enable asupplier, 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 allissues they perceived as outstanding were

addressed, including issues which had no

operational impact - for example,

Americanised spelling of 'catalog' in the

marketplace environment.

Lesson

We should encourage the client to "go live",even with a pilot since this will reveal practical

issues (and in some marketplace cases, evendisprove 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 streamlinedistribution 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

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


13/13


mechanism, to allow the delivery of business

documents to marketplace participants.

Lesson

ACSN should not be relied upon or expectedto 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 membersdifferent degrees of uncertainty over the roles

of Ariba Buyer and Ariba Marketplace. The

Cyberlynx experience was as follows:

- Although there are many similaritiesbetween 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-to-

many" means one buying organization per

instance connecting with its many

suppliers. Ariba Marketplace can serve

many buyers and suppliers, thus loweringthe market maker's maintenance costs ofits customers.

- The functionality (and the look and feel) isvery 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 geteverything 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, catalogueorganisation, etc. There are certain

aspects of a marketplace that have tobeset up the same way for everyone.

Some companies will want a greater

ability to make it their own.

- product and supplier access: AribaMarketplace 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 functionalbut as a matter of control. Some buyers

may not want to rely on a shared

marketplace to provide their users onlywhat they want them to see.

- Single application serving internalneeds: 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 toserve 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 thesuccessful 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 'AMSEenvironment, 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

[email protected]

the cyberlynx b2b emarketplace - lessons learned

Documents