E-Procurement Supply Chain Economics

Issue Date: June 1999
Issue Number: 10.01
Category: SCP

While much of the early attention in supply chain management was justifiably placed with inventory items tracked by ERP systems (because they were assembled or processed into final products), many organizations spend hundreds of millions of dollars annually on overhead items such as maintenance, repair and operating (MRO) procurement. Various other facilities services, and employee expenses such as office supplies and corporate travel only add to the burden. Now, even overhead items are finally getting their due attention, and thanks to the web, there is a way to automate procurement from suppliers in a seamless fashion.

Specifically, the web has spurred the distribution of supplier electronic catalogs, which allow customers to place orders on-line. Additionally, workflow software can be appended to those customer-side applications that automatically activate the approval process when procurements exceed certain monetary thresholds. In turn, on the customer side, procurement systems could be linked into the HR, accounts payable, or even the purchasing modules of ERP systems, closing the loop. On the supplier side, incoming orders can be linked into the organization's order fulfillment systems.

This report examines the impacts, costs and potential savings of implementing web-based MRO procurement systems.

SUPPLY CHAIN DREAM AND CHAOS

Seamless, web-integrated procurement sounds so easy and intuitive. On the surface, it appears that using the web as an application deployment environment and economical communications pipeline should resolve most of the obstacles that until recently prevented the extension of enterprise systems to overhead procurement functions. The operating notion was that procurement of incidentals and overhead expenses did not have as great a competitive impact as direct inventory items. Yet, the amounts spent on what a Forbes magazine article deemed 'the purchase of paper clips' do add up. At AMD, the first major user of Ariba's ORMS solution (profiled later), the target universe covered over $100 million of otherwise ill-tracked expenditures annually. Given that AMD competes in a price-sensitive market, every little bit helps.

Technology was formerly an important hurdle. However, with the web and Java, institutional obstacles are proving more formidable.

The challenge is finding a financial model that provides incentives for the customer or buyer to automate and integrate the procurement process, because the cost of such a solution can amount to millions of dollars. Just a few of the issues that arise include:

* Who pays for the software - buyer or seller?
* Are catalog interchange format standards feasible, or must suppliers recreate catalogs for every individual customer?
* Is XML an adequate alternative?
* Will new supplier networks, or 'electronic trading communities' overcome most technical and economic barriers, and if so, what organizations (software vendors, EDI vendors, etc.) are likely to attract critical masses of buyers and sellers?
* Do MRO procurement applications duplicate ERP procurement modules?
* How much work is necessary to interface MRO procurement systems with existing enterprise systems, and which systems should they interact with (e.g., HR, financials/general ledger, HR)?

ARIBA

Ariba Technologies has become one of the best-known players in the e-procurement space thanks to high-profile early adopters at AMD and Cisco. Ariba's system, ORMS (Operations Resource Management System), is a Java-based application that combines several elements:

* Electronic catalog publishing.
* Buyer procurement workflows.
* ERP interfaces (or adapters).

ORMS uses a web-based application architecture that deploys business logic on an application server. Client applications are Java applets downloaded at run time onto a Java-enabled web browser (a simplified HTML client is also available for heads-down users who prefer forms-based interfaces). The back end is also based on a multi-tier Java architecture, featuring an application server and JDBC access to a separate database tier.

The application server itself uses Java components for specific business processes such as MRO procurement, service requests, capital goods requisitions, employee time cards, and employee expense reporting. Depending on the organization, some or all this functionality might overlap or duplicate existing HR or procurement systems. Another component is the process workflow engine; the most frequent example is for purchasing authorizations, where amounts over certain thresholds must be approved by line supervisors or department management. Additionally, there are adapters for linkage to enterprise systems.

For the supplier side, a document creation module is provided which places documents in Catalog Interchange Format (CIF), a standard developed by SGI. Ariba is also looking at XML as catalog format alternative, and claims to be open to other formats of the user's choosing.

The business model initially was that the buyer paid for the software, with suppliers getting catalog publishing software for free, via their customers. With this model, customers had to sponsor their own electronic trading networks.

Ariba is now trying to lift the burden off customer shoulders, forming Ariba.com, its own trading community (although Ariba is not alone in building such communities, it is one of the more prominent ISVs to do so and has attracted some marquee names). With Ariba.com, the buyer (who has installed ORMS software and purchased the license) logs onto the web site and buys from the supplier at generally published prices. Suppliers are not charged for this service.

Currently, there are no transaction fees, since Ariba has not made this into a general-purpose, public EC site.

The upside of Ariba.com (or similar trading communities) is that the formation of trading communities is lifted off the buyer's shoulders. The drawback is that pricing is standard, and not subject to advantageous contracts that the buyer might otherwise negotiate with the supplier independently. (Ariba claims that prices on its network are low because it is a high-volume marketplace.)

In other developments, Ariba is also working with Visa and Verifone for on-line payment mechanisms that would close the loop.

Currently, Ariba has about 30 customers, almost all of which are Global 2000-size organizations; since it has concentrated on large enterprise customers, entry prices are still high. Ariba estimates that installations may run from $500,000 up to $10 million, ranking it as another ERP-scale application. It has not yet announced a strategy for more modest-priced licensing for midsize companies, although we expect that will be likely within the next year. Because MRO ordering in some areas (e.g., office supplies) lends itself to standardization, we believe that a simplified approach with more rudimentary approval workflow capabilities, combined with pay-as-you-go transaction pricing, could make this affordable for smaller companies.

Ariba considers that the big ERP vendors-not competitors such as Commerce One-as its ultimate rivals.

AMD: Ariba's first user site, the impetus for the project was that Ariba's approach to procurement was similar to an idea that the former supply management (procurement) vice president had developed at a previous company. The initial implementation went live in only three months, in August of 1997. As a beta site, Ariba staff took care of most system implementation work, while procurement staff configured the workflows and managed catalogs.

As a beta site, the economics are not necessarily directly applicable to a normal paying customer. AMD was not at liberty to disclose how much the project actually cost to implement, but as a beta site, we would assume that Ariba probably absorbed some of the development costs.

Nonetheless, the degree of utilization indicates that the system would have been a successful investment even if the project hadn't been a beta. In 1998, AMD processed $5 million of orders. By Q1 of 1999 the cumulative volume had soared to over $10 million, and the number of supplier catalogs tripled. According to Alex Brown, acting director of corporate supply management, that represents about 7% of AMD's non-inventory procurement. There are over 80 suppliers now linked to the system.

AMD currently has two people (one full-time equivalent or FTE total) managing implementation and catalogs. The task does not require IT staff, except for special requests. However, they expect to require IT services and Ariba consulting when they upgrade to release 5.x (which will involve phasing in Ariba.com). Brown did not have any estimates as to how much this would cost.

But he did estimate the savings. The cost of processing each manual purchasing transaction ranges from $85-$125. The goal was to chop at least 50% or more off these internal operating costs and 15-40% in material savings though the use of catalogs. AMD placed 234 orders though Ariba in 1998 and an additional 236 in Q1 of 1999.

Based on AMD's current utilization, we'll estimate the costs and savings for a similar installation at another company. The assumptions would include;

* Some $10 million of MRO procurements are placed electronically each year.
* Processing cost for MRO requisitions place manually is $100/each (data from Transamerica Corp., another Ariba user, makes this estimate conservative (see later); Ariba generates savings up to 50%.
* Software license costs are $250,000, plus $50,000 annual maintenance.
* Implementation requires one staff year (including two consultants and two internal staff, for three-month full-time commitments); cost rates for consultants are $1,000/day while staff time (burdened) is $50/hour. The total cost is $170,000.
* Training, applied to a staff of 100 people, takes about two hours apiece. We'll assume a staff burdened cost of $35/hour, resulting in a one-time cost of $3,500. Training is taught by the staff member in charge of maintaining the system, and would be accounted for as part of his or her system maintenance duties.
* Configuring the software (e.g., the workflows) requires about three hours per staff person, for a one-time cost of $10,000.
* Ongoing maintenance requires one FTE at $50/hour (burdened), which equals $100,000 annually.

Based on these arbitrary figures, we came up with four scenarios:

* Scenario 1: Large POs (purchase orders), low utilization. Average MRO procurements are $20,000 apiece (this is close to AMD's pattern), with utilization at a modest $10 million annually, involving 100 users.
* Scenario 2: Large POs, high utilization. Average MRO procurements are $20,000, with utilization growing at a steady rate from $10 to $70 million annually (AMD's expected future utilization level), impacting up to 300 users.
* Scenario 3: Small POs, low utilization. Average MRO procurements are $5,000, with constant $10 million/100 user utilization.
* Scenario 4: Small POs, high utilization. Average MRO procurements are $5,000, with utilization growing from $10 to $70 million annually, and 300 users.

ITEM	LOW USAGE/ LARGE AVERAGE POs	GROWTH SCENARIO/ LARGE AVERAGE POs	LOW USAGE/ SMALL AVERAGE POs	GROWTH SCNARIO/ SMALL AVERAGE POs
Annual MRO procurements (total)	$150 million	$150 million	$150 million	$150 million
Year 1 MRO procurement (web)	$10 million	$10 million	$10 million	$10 million
Year 2 MRO procurement (web)	$10 million	$42.5 million	$10 million	$42.5 million
Year 3 MRO procurement (web)	$10 million	$70 million	$10 million	$70 million
Average MRO procurement	$20,000	$20,000	$5,000	$5,000
Processing cost/ procurement (paper)	$100	$100	$100	$100
Processing cost/ procurement (web)	$50	$50	$50	$50
Savings/web procurement	$50	$50	$50	$50
Year 1 Supplier contract savings	$2 million	$2 million	$2 million	$2 million
Year 2 Supplier contract savings	$2 million	$8.5 million	$2 million	$8.5 million
Year 3 Supplier contract savings	$2 million	$14 million	$2 million	$14 million
Software license	$250,000	$250,000	$250,000	$250,000
Software annual maintenance	$50,000	$50,000	$50,000	$50,000
Implementation	$170,000	$170,000	$170,000	$170,000
Usage (employees)	100	400	100	400
End user training and configuration	$14,000	$42,000	$14,000	$42,000
Ongoing IT maintenance	$300,000	$300,000	$300,000	$300,000
Total costs (3 years)	$784,000	$812,000	$784,000	$812,000
Total savings (3 years)	$6.1 million	$24.5 million	$300,000	$25.7 million
ROI (without supplier contract savings)	10 years	5 years	3 years	1.5 years
ROI(with supplier contract savings)	Less than 1 year	Less than 1 year	Less than 1 year	Less than 1 year

Note: Based on actual utilization of a high-tech organization. However, there are several caveats that we believe would make the real ROIs more conservative:

1. Implementation costs: They do not factor in any additional implementation complexity for the high-utilization cases. Neither do they account for the cost of integrating the web procurement solution with back end ERP systems.

2. Supplier contract savings: They are achieved by negotiating better discounts that are based on volume and the savings in migrating to electronic procurement. These are 'soft' savings that will vary by organization.

The paybacks ranged from a dismal 10 years to a respectable 18 months (see Table 1), if you account for 'soft' factors such as supplier discounts. These discounts are likely with web procurement because of two factors:

* Volumes can be more easily aggregated since they are better tracked.
* The supplier's cost of processing electronic procurements should also be dramatically lower.

However, as we note later, this assumes a standalone solution, without systems integration costs, and it doesn't factor any added complexity if the system served more users. Therefore, we believe that actual paybacks of the hypothetical cases would be longer.

We don't know what the actual economics at AMD have been. We do know, however, that by Q3 of this year, AMD hopes to dramatically ramp up Ariba use to half of its MRO purchasing (that would be five times its current level of use). The initiative is part of a '50/50' program, which identifies the top 50 suppliers and user (buyer) departments, by purchase order volume and requests, and coincides with a corporate 'super distributor' program aimed at consolidating suppliers. Much of this will hopefully leverage Ariba.com; they hope that Ariba will sign up the right distributors for the program. This is not an edict from above, but an internal selling campaign.

But, as AMD ramps up its Ariba utilization to critical mass levels, it needs to integrate Ariba into its back end systems, which include PeopleSoft for HR and Baan for manufacturing and financials. For any enterprise, the integration point would pose the following dilemma: do you use HR or the financial system as your primary point of integration? That depends on which system embeds the rules for PO authorizations (it could be either). AMD has yet to resolve under which jurisdiction this will reside. Brown has no idea how much the systems integration effort will cost, although Ariba's adapters (which are already available for PeopeSoft) may provide an adequate starting point.

The other implementation challenge, said Brown, is validating all the purchasing workflows (e.g., the amounts for which the staff member can place without special authorizations, and to whom approvals are routed). When the job is left to individual staff members, the results could be inconsistent. AMD does not yet have any process for HR staff to validate the workflows entered by end users.

Transamerica Corp: An operational audit recommended significant savings were possible if purchasing was centralized. That would amount to potential savings of several million for a $6.4 billion enterprise.

The challenge was that the company was highly decentralized; although it has one dominant business unit (the life insurance company, which accounts for 60% of overall revenues). Business groups based around product families have long exercised their own autonomous practices. There is though a corporate procurement organization, which is responsible for developing services that are used by business unit procurement groups.

Excluding the national accounts program, each business group conducted its own procurement. For national accounts, procurement staff could gain access via the intranet. That provided a valuable operational precedent when Ariba ORMS was later implemented in the first target-the life insurance unit.

Other than national accounts procurement, the process was highly labor-intensive, involving lots of redundant data entry and faxing. 'It was ugly,' according to vice president of control and services (which includes IT) Maureen Breakiron-Evans. If Transamerica's procurement process was like that of typical companies, Breakiron-Evans would have probably been guilty of understatement.

With the release of the study, a core procurement group was given a few months to specify a solution. 'We wanted to become a corporate utility,' according to Peter DeWolf, vice president of corporate purchasing. The study's release had fortuitous timing, because at that point, a number of Internet software providers were beginning to early releases of web procurement products. Transamerica viewed demos from Ariba, Netscape, Commerce One and others. Of the products, Ariba was considered the most mature, having fully operable reference sites at AMD, Cisco and several others, which largely drove the product's selection.

Nonetheless, there was the question of who would bear the costs of maintaining supplier catalogs. While some other products shifted the burden to suppliers, Ariba ORMS placed this in the customer's lap. That wasn't a major drawback, said Breakiron-Evans, because other schemes with ISVs maintaining the catalog site could have involved transaction costs that would not be economical for such a high-volume user as Transamerica. (As noted earlier, Ariba does not currently have plans to levy transaction costs for Ariba.com.)

The next step was driving internal consensus, with Breakiron-Evans serving as the champion, and the operational study as the spark. Armed with the study, Breakiron-Evans successfully sold the web procurement concept to CFOs at each major Transamerica business unit. 'There was no rational way to keep justifying scattered purchasing,' she noted, adding that the idea was hardly controversial. 'There's nothing strategic about paper clips,' she said.

An executive steering committee comprised of the Breakiron-Evans and CFOs was subsequently formed to review progress toward meeting the goal (the group meets for about an hour every six weeks).

It was estimated that the adoption of Ariba would likely cost between $1-2 million. Against that the group conservatively estimated 5-10% savings. Given the size of the target, they figured that the system should achieve payback in less than a year. The gains were not based on labor savings, she emphasized. Instead, the payback would come in economies of scale. Procurement personnel would simply redirect their efforts to higher-level management of relationships, rather than pushing paper.

Not surprisingly, the ROI for automated procurement is also far more tangible and attainable compared to ERP. 'There's obvious savings there,' said DeWolf. The key performance indicators are the cost per requisition and the increase of spending that is coming through central purchasing (via the new system).

Implementation amounts to a 'mini ERP' effort, according to DeWolf, because it often requires reengineering to achieve the best results. But, added Breakiron-Evans, in magnitude and 'scariness,' the project was nothing like ERP. 'This is so much easier,' she noted.

For instance, implementation patterns are different. For ERP, progress is usually incremental whereas for automated procurement, said DeWolf, it can be exponential. 'Getting the first 250 users live is tough, but the next group of 100 becomes easy,' said DeWolf. The benefits and advantages of a simplified, web-based approach can easily spread by word of mouth. For a large enterprise, DeWolf estimates that a phase that extends from month 2 to month 14 is a reasonable timeline, with the expectation that it would take about six to nine months to achieve critical mass.

At Transamerica, while the initiative originated at the corporate senior management level, the project quickly became owned by corporate procurement, which at the time was undergoing reengineering itself to build broader services. The corporate procurement group was setting itself up to 'sell' more services, pitching them to the rest of the enterprise (accounting for roughly 8,700 staff), and the 30,000-person independent agent network. During this period, about half the 22-person corporate procurement staff members had just joined the group. 'We were looking for sharp buyers,' said DeWolf.

For the Ariba project, three 'commodity' teams were formed, including a five people team for printing, three people for IS, and three more people for office supplies who could help configure the application and maintain catalogs. Additionally, three Ariba consultants were engaged as project consultants (at the time, they had not yet established extensive relationships with integrators). Implementation took four months of full-time effort.

As the team set up the core application, end users set up their own workflows (e.g., identifying what they are authorized to procure, their supervisors, and what are the dollar thresholds that require higher-level authorizations). The way was paved for the end user effort, since it dovetailed with a PeopleSoft project that included an employee self-service HR intranet application.

The project indirectly benefited from the fact that a PeopleSoft 6.0 implementation was partially complete and in progress at the time. Most Transamerica business units were already using PeopleSoft HR. Additionally, the life insurance business unit was adding general ledger, accounts payable, and purchasing modules as part of its Y2K compliance strategy. (Ironically, while PeopleSoft had its own procurement module, it was far more difficult to use than Ariba's, and it could not support the 30,000-agent affiliates.)

However, the team did not use staff organization hierarchies for PeopleSoft because none were yet input to the HR system. Admittedly, that gap will be rectified in the PeopleSoft system soon, according to Breakiron-Evans. Besides Ariba, there are a number of other projects underway, such as the HR self-service intranet, travel and expense reporting, travel booking, etc., that could also use the data.

Nonetheless, Breakiron-Evans admits that having the hierarchies in the HR system first would have avoided some redundant effort creating workflows in Ariba. What's interesting is that in this report, Transamerica wasn't alone; as we noted earlier AMD was also going back to do the same work. Evidently, getting a quick payoff with an on-line procurement application is often adequate impetus for getting projects off the ground. And integration with ERP systems is never simple, although Breakiron-Evans expects the job won't be traumatic for them for two reasons:

* Ariba already has a PeopleSoft adapter.
* Transamerica's implementation of PeopleSoft purchasing was pretty vanilla.

Even with the effort of inputting workflows, initial efforts to get 200 users live at several sites required only about 10 days to go live, according to project manager Jean Loomis.

Loomis reported that the project has been live for nearly three months, with roughly a dozen suppliers enrolled and utilization by about 700 steady users. One person is dedicated full-time to maintaining supplier catalogs. Although the emergence of Ariba.com may lift some of the catalog maintenance burden, Transamerica will have to stay involved in catalog work.

Given that the company is in the midst of being acquired, there are no firm timetables yet for rolling Ariba out to the rest of the enterprise. However, with the initial 700-person group relying on the system for almost all of their procurement (from enrolled suppliers) it's clear that the system is already generating savings that have yet to be tallied.

ORACLE

Ask Ariba who the competition is, and the company will answer that the real threats come from the established ERP vendors. From a marketing standpoint, that makes sense. ERP vendors have mature markets and, therefore, the resources and motivation to add new functionality. And it is a logical extension for them-by definition, ERP have procurement modules. But, as one Ariba user noted earlier, the procurement module of PeopleSoft was considered far too complex for the casual user. And, the nature of MRO vs. MRP (the materials portion of ERP) procurement is that MRO requesters are likely to come from a much broader cross section of the enterprise.

So some ERP vendors, such as Oracle, have begun offering simplified web procurement extensions to their core systems. From an implementation cost standpoint, the additional expenses for web MRO procurement are marginal. Oracle claims that web procurement could generate savings of 10% or more, while cutting turnaround times by 50% through automated authorization workflows. Obviously, it does not account for what happens on the supplier's end. Unlike Ariba, Oracle does not offer supplier catalog modules. However, it has an alliance with TPN Register, the on-line manufacturing equipment buying community offered through a joint venture of General Electric Information Services (GEIS) and the Thomas Register. Oracle says that it could also integrate with other content providers or trading communities.

Oracle's web requisitions application is offered as a web extension of Oracle Financials. It allows users to post RFQs to suppliers, offers a rules-based engine governing supplier agreements, and embeds authorization workflows (that are also used with the core procurement portion of Oracle Financials), and supports contract and catalog purchasing.

Additionally, Oracle has added web procurement to its FastForward rapid implementation offerings targeted at small-midsize businesses (by contrast, Ariba does not yet target smaller organizations). It provides a 60-day rapid implementation program covering the following modules:

* Oracle Self-Service Purchasing: Enables employees to initiate purchasing requests on their desktops by searching electronic catalogs for good and services.
* Oracle Purchasing: Helps purchasing employees to receive, track and process purchasing requests.
* Oracle Payables: Allows employees to process supplier payments.
* Electronic Catalogs: Offered through Oracle partner Requisite Technology, includes content from Corporate Express and W. W. Grainger.

Like other Oracle FastFoward programs, the web procurement module prepackages training and support (four days of on-site training, and one year of 24-hour telephone support).

San Francisco Newspaper Agency (SFNA): The back office business and printing arm of San Francisco's two daily newspapers, SFNA migrated over the past 15 months from the mainframe-based Geac AMAPS system to Oracle Financials (accounts payable, general ledger, and purchasing). Nearly a year ago, they went live with Oracle Self-Service web purchasing for MRO items. They have just begun implementing Oracle's HR and payroll modules.

They currently use templates that may be blank (for free-form ordering) or pre-formatted (for popular items; e.g., the template for buying pencils shows the available quantities and prices). They do not currently use electronic catalogs, and are still deciding if that would be cost effective.

Implementation costs were 'marginal,' since the company was already implementing procurement as part of Oracle Financials. According to David Jew, SFNA controller, the cost was about 10% of the amount for the ERP project so far (he was not at liberty to disclose ERP project costs).

Two consultants were engaged for a couple days per week over two months (that's equivalent to roughly 30 consulting days at a rate that we would estimate at $1,300/day, or $39,000 total). Additionally, three internal staff spent on average 1-2 days per week over the same two months to conduct internal training sessions for 250 users in sessions of 10 persons apiece; our estimate: about 40 staff days at $50/hour, or about $16,000 total, not counting end user time. (At the time, two other consultants were engaged for related projects.). The workflows were adapted from what was already embedded as part of Oracle Financials. 'The hard part was having managers decide who must approve what, at which cost level,' said Jew.

No additional infrastructure was required for the project, since the Pentium II PCs (200 MHz, minimum) were acquired as part of a Y2K strategy; additionally, the web procurement application resided on a Sun Enterprise 3000 server reserved for other Oracle application modules.

Rudimentary time and motion studies were conducted four years ago on the procurement process. The number of levels of approvals could be as many as five for high-ticket items, with cycle times ranging from 2.3-7 days. The audit estimated that the cost of a processing a purchase order was $90.

Since going live at the end of June 1998, they have processed 750 purchase orders per month, and estimate that they've cut processing time by about 30%. Today, average cycle times for electronic POs range from 1.5-2.5 days. 'I've heard no complaints about speed,' noted Jew. But, does the 30% savings in processing time equate to 30% less labor? SFNA has not conducted any follow-up studies, nor has it tracked whether employees are using their freed-up time for more productive tasks or longer coffee breaks.

Given that the cost of the effort was a modest add-on to an existing ERP project, Jew considers the returns more than adequate. They include faster cycle time, better accountability (no more questions of who's holding up a PO), and expanded use of a system to 250 users - which he estimates is a ten-fold increase over the number that would have used the regular, more complex Oracle Financials-based procurement system.

SAVINGS LOOK TEMPTING

It's hard to argue against automating the procurement of incidentals. The conventional wisdom is that these items are so trivial that savings are likely to be marginal. Admittedly, if the solution concerned paper clips or office supplies alone, that would likely be the case. However, overhead in most organizations often consumes large ticket expenses such as internal (non-client) travel, or maintenance and repair (MRO) items. These purchases start venturing in on the levels associated with MRP items.

However, there's a price to pay for the automation of overhead procurement. Currently, the cost of entry is significant. Either you already implement an ERP system and place overhead procurement as an add-on, or you implement a standalone solution that will likely cost well into six figures, with results dependent on how vigilantly procurement workflows are entered and validated. And, the ultimate payback comes when procurement systems are integrated with ERP-opening the way to larger costs, and the issue of where the system of record should be: in HR or purchasing. Here, if organizations are not careful, the outcome will boil to politics rather than technology or logic.

As we noted in the AMD case, much of the savings will be indirect. As a result of installing the system, the buyer will be in better position to negotiate aggressive savings with suppliers. As we also noted, this is a 'soft' cost factor that in many ways resembles the 'soft' benefits of ERP systems: organizations that track their business transactions better get the better deal. Fortunately, unlike ERP, these savings don't have to come at terrible costs or organizational upset.

It is a sign of the market's immaturity that vendors such as Ariba have not yet devised solutions for smaller organizations. In fact, the market initially resembles EDI, which for years looked unaffordable for smaller organizations due to the costs of setup and message charges imposed by the proprietary value-added networks (VANs).

In both cases, the Internet forms part of the solution (see Computer Finance, October and November 1996). For procurement, the emergence of on-line trading communities such as TPN Register, or Ariba.com and CommerceOne.com, may offer the answer. Here, the contracts are already pre-negotiated, eliminating much of the time- and labor-intensive supplier negotiations. And, a per-transaction cost that, ironically, follows the old EDI model might prove economic for smaller firms-as long as the costs are not as outrageous as the bad old days of EDI. We'll be looking at closer at this aspect of on-line trading communities in an upcoming report.

© 1999 ComputerWire Inc