E-procurement: how and why buy online?
Online procurement, also often referred to as e-procurement, is one of the major challenges facing the Internet. Unlike more traditional ways of procuring, which have obviously been "electronic" for many years, e-procurement refers specifically to procurement that is based, in whole or in part, on the use of Internet or intranet technology. Ultimately, the final direction will involve all players (users, testers, suppliers) working in a connected way, but not all suppliers have dropped products requiring specialized desktop software.
E-procurement: definition
E-procurement, also known as e-procurement, is a method of purchasing raw materials, goods and finished products based on an information system connected to the Internet. E-procurement connects buyers and sellers over the Internet, simplifying transactions between them.
Why is e-procurement important?
The reasons for e-procurement are obvious. Organizations are turning to e-procurement to reduce administrative costs, improve production and help them exercise control over inventory and spending. E-procurement systems also provide new supply channels, and can help to obtain lower prices on purchased goods. It's no surprise that, according to a survey conducted by Purchasing magazine, 95% of purchasing professionals make e-procurement a must-have channel. The market for e-procurement tools is expected to grow from less than $200 million in 1998 to $20 billion by 2020.
How do you source goods on the Internet?
At the other end of the spectrum, the sources of e-procurement are not so obvious, as e-procurement needs to be approached in a way that is quite distinct from most other applications. For most applications, although there may be interactions between the outside and inside of the company (receiving inputs and sending data), the heart of the application - in the sense of its location - lies within the company itself. With e-procurement, it's all about the transaction that links two different organizations.
If e-procurement were organized around just two different players - a buyer and a seller - it wouldn't be so interesting or difficult. But each actor is really the center of a star: the buyer deals with many sellers and, conversely, the seller deals with many buyers (see image 1). Consequently, the question of where e-procurement takes place is neither trivial nor self-evident:
E-procurement management systems
An e-procurement system can be located at the seller's end, at the buyer's end, or halfway between the two. Image 2 shows the first case. In this sell-side model, the buyer is like a shopper strolling down Main Street, New York's largest shopping avenue, visiting different stores of interest to find out about offers and prices. The seller installs software that allows each buyer to browse and purchase. This is clearly a sell-side, sales-oriented model.
The opposite case is illustrated in image 3. In this situation, the sellers have to bring their goods to the buyers, as did the street vendors of the early 20th century. This is a buy-side model.
In the last scenario (image 4), third parties set up large stores to bring buyers and sellers together. This is known as the marketplace model, the portal model or, in the case of a vertical marketplace, the vortal model.
Advantages and disadvantages of different sourcing models
Each model has advantages and disadvantages for the buyer (and, of course, the seller). Important questions revolve around who creates and maintains the catalogs that show product availability, how well the procurement functions integrate with business procedures and back-end systems, and how useful the result is for the buyer's employees.
The Main Street model
In the Main Street model, each supplier sets up its own catalog, possibly on an extranet. A company partnering with such a supplier can ask its employees to visit the supplier's site with their Internet browsers to make purchases. No catalog maintenance is required on the part of the purchasing company, making the adoption of such a system cheap and easy. However, integration with back-end financial systems will not be easy. Standards are being developed, mainly new generations of EDI based on XML, which in theory will make it easier to eliminate all documents resulting from a purchase by existing systems or ERP. The success of this approach remains to be seen, as the various standards proposed are still being studied to determine which will be retained. Some of the major suppliers, such as Ariba and Commerce One, have their own standards, as does Microsoft. The Main Street model also suffers from problems related to comparison shopping and control. In order to compare stores, a buying agent has to browse several supplier websites, each with its own interface, packaging and shipping arrangements and discounts. Controlling out-of-contract purchases is almost impossible. The Main Street approach works best for small purchasing organizations and in cases where the supplier's product is fairly specialized. An example of this model is a new initiative by Eastman Chemical. Eastman provides low-cost Dell computers and Internet access via UUNET to enable its customers to shop on the Eastman site.
The traveling salesman model
At the other end of the spectrum is the Traveling Salesman model. In this scenario, suppliers reach the buyer through the data they provide, with which the buying company creates and maintains its own catalog. And there are many advantages for the purchasing company. Indeed, since it controls the catalog, it can rigorously select the products that go into it, and even offer certain employees certain selections of products in limited quantities. In this way, purchasing capacity can be present on every individual's desktop, and employees have a single interface at their disposal. On the other hand, the creation and updating of catalogs can involve a significant editing effort. One of the suppliers in this market, PurchasePro, installs its software on buyers' sites. Using PurchasePro's software, customers can make purchases on vendor sites and marketplaces. One of PurchasePro's customers is the Meristar hotel chain.
The marketplace model
At their core are marketplaces, third-party sites that bring buyers and sellers together in their marketplace. Marketplace sites provide a single catalog, but are less integrated with the back-end systems and specific policies of the buying company. Naturally, many suppliers in this space go to great lengths to ensure that their solutions are, as far as possible, buy-side solutions.
In reality, there are two types of marketplace. One is the vortal, the vertical marketplace. One example is ChemConnect, which brings together buyers and sellers in the chemical industry. One estimate predicts that 15% of this $1.6 billion industry will move online over the next three to five years.
The other type of marketplace covers a wide variety of product types. The leader in this field is MRO procurement - Maintenance, Repair and Operating supplies - which can account for up to 35% of a company's total expenditure. What's more, MRO purchasing is a frequent cause of "wildcatting" - i.e. purchases not made with regular suppliers. It is estimated that up to 40% of MRO purchases are impulse buys, which could mean up to $10 million a year in lost revenue for the typical billion-dollar company. There are a number of players in this world. The leaders are Ariba and Commerce One, who actively solicit suppliers and sell their solutions to buying organizations. Others include Concur Technologies, Intelsys and many smaller players. There is also competition in this field between large ERP vendors such as SAP and Baan, Oracle, IBM, HP and others.
One way of implementing a marketplace model is to rely entirely on the Internet, especially on the buyer's side. This means that no software is installed on the buyer's computers, and all operations are carried out using browsers. A second approach is to install specialized software on the desktop computers of the buying company's employees, but host the supplier network centrally on the Internet.
Comparing procurement models
The image below provides a clear comparison of these three approaches. It shows graphically how the different models behave according to certain important criteria. But as always, the problem lies in the details, which change daily in this product space. For example, integration into back-end systems should theoretically be more difficult with the marketplace model than with the Main Street solution, since the latter is installed and customized on the buyer's site. But there's no reason why a particular supplier can't make a sufficient investment to ensure that its marketplace model integrates easily with your back-end systems. In fact, all the major marketplace suppliers promise such a capability.
Conclusion
In view of the significant potential savings, e-procurement is the most critical area of application for organizations in the short term. Using e-procurement to order MRO products can generate savings of 5-20%. The same study revealed that the cost of order processing could fall by 70%.
We believe that, due to the cost of catalog maintenance, pure buy-side solutions, where the buying organization creates its own catalogs, will be a rarity in the short term, accounting for no more than 15% of the total purchasing market and only a few percent of MRO purchases. It won't make sense for most companies. However, once there is more standardization on the XML form used for supplier catalogs, it could become a viable option again, perhaps in three to five years' time. We believe that most purchasing organizations will gravitate towards a marketplace model, at least in the sense that they will use centralized vendor networks with centralized catalogs. Vendors of these products are focused on building both their vendor networks and their technology to make this an attractive option. We expect that more than half of all users will shop via the Internet, but that specialized shopping software installations will be present on at least 30% of computers. Potential users should make a careful analysis of functionality and, in particular, the degree of integration they need with their back-end systems.