Auctions

Sunday, October 4, 2009

Enterprise Resource Planning: Bridging the Gap between Product Vision and Execution

Such acquisitions are unlikely to stop as Infor continues to look for solutions that would fill out its current product suites (e.g., a transportation management system [TMS], plant management/enterprise asset management [EAM], product configurator, etc.). The skill and technology set from acquisitions could be adapted by Infor to meet specific industry requirements and be marketed to the diverse installed base. They can also be adapted and sold outside the install base as standalone, best-of-breed solutions.

According to its upper management, Infor's acquisitions can be divided into two categories: value driven acquisitions and growth acquisitions, and all were conducted after thorough, metric-based evaluations. This strategy appears to be working, even when compared to the strategies of Infor's awesome competitors like SAP and Oracle. Infor cites its organic ("same store") growth to be seven percent over the past fiscal year, driven by over 460 brand new customers (not existing customers or divisions of existing companies that are already customers that buy additional modules or Infor solutions) in the last fiscal year. These have been, in great part, driven by the sales of some "super breed" products, especially SupplyWEB. The maintenance retention has been between 95�98 percent, without any maintenance price increases (which is typical after acquisitions), and includes winning back some departed customers, but excludes any brand new business.

Why has Infor been successful at tacitly nurturing and growing acquired companies when many more noisy competitors have not? Its vertical focus makes solutions functionally richer than even those of its larger competitors; it is financially stable and has a global presence; and it does not rely on large deals to close the quarter (Infor's average deal is reportedly around $300,000 USD). However, there is another reason. It puts continuous investment in research and development (R&D). Eighteen percent of revenues goes into R&D, which is high, given the industry standard is 14 percent or so. Infor also willingly supports and modernizes products on multiple platforms. While the vendor has been converging vertical solutions on one source code written in either Java 2 Enterprise Edition (J2EE) or Microsoft .NET environment, customers will not have to go through a costly and painful de-implement to re-implement upgrade process.

So, how does Infor plan to quickly converge innovative vertical solutions while protecting manageable, upgrade paths without forcibly marching customers towards change? To meet its goal, Infor has created its own internal development and integration environment, codenamed Corestone. Cornerstone has all but entrenched the following processes: drive enhancements by vertical differentiation, embrace leading technology platforms (i.e., J2EE and .NET) that leverage open standards, and embark on product development will use service oriented architecture (SOA) principles. Third-party applications might be used for non-core applications or functionality.

The deliverables of Corestone will eventually include a universal client framework that will provide a common user interface (UI), navigation method, and messaging standards for all Infor products. The environment will also provide unified development standards for more efficient global development teams and for database independence of all future products; enterprise java beans (EJB) will not be used. Stored procedures written in structured query language (SQL), which are operations that are stored with the database server, will not be used either. Instead Infor will move business logic to an application layer of its products, opening up the use of Web services, and allowing clients of all types to consume business logic, as needed.

Corestone will also create a library of re-useable utility components, such as single sign-on, authentication, licensing, printing, workflow management, reporting, enterprise service bus (ESB), etc. Rapid application development will be enabled through the development environment and UI design tool. Also, the Infor Business Integration Server (IBIS) platform will cater for eased integration with other Infor and third-party applications and services. Looking at the Corestone assembly environment, the top layer will consist of a raft of supported clients, such as Microsoft, Linux, and Macintosh smart clients. Microsoft IE 6.0 (and later), Mozilla Firefox rich browsers, and any commercially available regular browser will also be supported. Telnet and HyperText Transfer Protocol (HTTP) will represent mobile clients.

On the other hand, all brand new solutions, the so-called Corestone-enabled applications, are being written in J2EE or .NET. Therefore, although Corestone may have many similarities with the SAP NetWeaver or Oracle Fusion platforms. The major difference is that these appli-structure platforms that are being developed by SAP, Oracle, IBM, Fujitsu, and Microsoft are, after all, proprietary, either in terms of database, and operating system (OS), or application server or both. Thus, Infor's technology roadmap will allow applications to be built in primordial third generation language (3GL) languages and outdated environments like RPG or Computer Associates' OpenRoad to use new services and functionality written in J2EE or .NET. Also, the SOA-enablement of business logic should allow existing business logic to be reused across multiple applications.

The use of Open Applications Group Integration Specifications (OAGIS) and e-business extensible markup language (ebXML) standards allows Infor to integrate modules and functionality into existing applications, assembling the best solution for its customers. Then, the UI integration will bring a common look-and-feel to all diverse applications, while single sign-on and authorization model should support tighter integration to other applications and common navigation between applications.

Further, CoreApps will eventually simplify integration and support multi-company installation strategies via the CoreITEM (for the item master and product data management [PDM] data provision) and CoreCV (for the customer and vendor master data provision). Last but not least, like in case of Lawson Landmark, Infor's applications will go through regular code regeneration for reasons of continuous code improvement. Infor will focus on further breaking down existing applications into more granular services and to write new applications and modules using SOA, whereby existing services will be occasionally replaced by new ones.

An example of Infor's work underdevelopment is an iSeries-based automotive enterprise resource planning (ERP) application called XPPS (coming from former Brain). It is based on the RPG language and on IBM DB2 database, and has received a new Corestone Smart client interface and Corestone-enabled functional extensions, like manufacturing execution system (MES) functionality and cross-divisional Infor Global Financials (coming from Varial Software). Many other similar products based on iSeries and pre-.NET Microsoft technologies are to follow suit. The pace at which Corestone will be applied to Infor product lines will be determined by individual Infor business units, which have their own product development, product management, and development organization. It will also have the responsibility to drive industry-specific functionality into products.

Managing Your Supply Chain Using Microsoft Navision

The starting point of the book Managing Your Supply Chain Using Microsoft Navision is that supply chain management requires effective use of an integrated enterprise resource planning (ERP) system. Its central theme focuses on using Microsoft Navision for managing supply chain activities in manufacturers and distributors. Its target audience includes those individuals implementing or considering Microsoft Navision as their ERP system. The book addresses an overall understanding of how the system fits together to run a business, expressed in generally accepted terminology. This mental framework—in combination with hands-on experience and training courseware—can accelerate the learning process, and an overall understanding leads to more effective system usage.

Usage of any ERP system—including Microsoft Navision—is shaped by many design factors that make it easier (or harder) to learn and use. For example, consistency and symmetry in the user interface make an ERP system easier to learn and use. The same holds true for the consistency and symmetry in standardized functionality across integrated applications, and in extended functionality stemming from customizations and independently developed software. System functionality and e-commerce integration also shape usage in different manufacturing and distribution environments.

Many of the design factors related to Microsoft Navision have been covered in previous chapters. This final chapter summarizes the design factors shaping system usage and hopefully provides the capstone of an overall understanding about how the system fits together to run manufacturing and distribution businesses. The design factors are segmented into those related to the user interface, customization capabilities, and system usage in manufacturing and distribution environments. Additional design factors include those related to integration with e-commerce, relationship management, service management, and accounting applications.

The user interface within Microsoft Navision provides consistency across all windows that assists ease-of-learning and ease-of-use. In addition, a graphical user interface supports user-defined work flows so that a user can select the desired step and access the relevant window. A few illustrations are provided below about the basic types of windows comprising the user interface.

Card versus List Format. Records can be viewed individually in card format or all together in list format, where the list format works very much like a spreadsheet. Customer master data, for example, can be viewed and maintained in card format for a single customer or viewed in list format for all customers. Both formats support access to related information and forward/backward browsing. The card format often segments data into tabs, while records in a list format can be copied and pasted into a spreadsheet.

Some windows with header and line item information employ a combination of card format and list format. A sales order, for example, consists of header information in card format and line items in list format. The header information for all sales orders can be viewed in list format.

Find Capabilities. Find capabilities can be based on any string of embedded text in a record identifier (such as customer number) or its attributes.

Filtering and Sorting. A filter limits the displayed records based on values in one or more fields, with sorting based on any field. The user can browse forward and backward through the subset. Filtering logic includes equal to, different from, greater than, less than, intervals, and wild cards.

Drill-Down Analysis. The system supports several drill-down approaches, such as drill-down to the source transactions and drill-down to the details comprising a summarized value.

Customizations range from the simple to the complex. Complex customizations typically entail significant changes to system functionality and logic. Simple customizations typically involve minor changes to the user interface and reports, and do not impact system logic. Several tools support simple customizations as illustrated below.

Customizing Window Layout for the List Format. The list format allows an end user to tailor window layout by selectively hiding, showing, and sorting fields via drag-and-drop. This provides a simple approach to customizing window layout and the system remembers each end user's preferences. In addition, an end user can view all available fields (and their values) in the table related to a record.

Customizing Window Layout for the Card Format. The card format can be changed with an easy-to-use forms designer, such as changes to field labels, to show or hide fields, and to rearrange fields on tabs.

Customizing Reports and Documents. The format and content of reports and documents (such as an invoice) can be customized using a report designer tool. The tool also supports export/import for exchanging spreadsheet data. Customizing via Additional Fields. New fields can be added to tables with immediate visibility in list format windows and availability for customizing card formats and reports.

The object-oriented design also supports more complex customizations. Numerous case studies throughout the book illustrated some of these customizations.

Primary Engine for Coordinating Supply Chain Activities. Planning calculations synchronize supplies to meet demands and generate suggested action messages on worksheets. Replenishment logic within the planning calculations includes time-phased order point, DRP, and MRP logic.

Symmetry of Sales and Purchasing Functionality. Sales and purchasing both handle documents for quotes, blanket orders, orders, invoices, returns and credit memos, with parallel approaches for handling cross-reference identifiers, prices and discounts, special charges, and order-related text. Symmetry is also apparent in the definition of customer and vendor information, and the handling of special orders and drop shipments.

Variations in Sales. Sales order line items can identify material items (including special orders, drop shipments, and kits of components) as well as resource time, special charges, and text. Pricing and discounting schemes can reflect product and customer groups, quantity breakpoints and date effectivity, and discounts based on total order value. Sales can be forecasted to drive purchasing requirements.

Symmetry of Warehouse Functionality for Inbound and Outbound Shipments. The same functionality for handling outbound shipments applies to sales orders, transfer orders, and returns to vendor. Similar functionality for handling inbound shipments applies to purchase orders, transfer orders, and customer returns.

Variations in Warehousing. Shipping activities can focus on individual orders or a pick document, while receiving activities can focus on individual orders or a receipt document and an optional put-away document. Put-away suggestions can optionally account for bin location considerations, such as location preferences and capacity constraints. Movement within a warehouse can reflect bin replenishment policies, such as replenishing bins from a bulk storage area.

Modeling Variations in Multi-Site Operations. The system supports different types of multi-site operations, including autonomous sites within a company and a distribution network with transfers between locations. Costs and replenishment methods can be defined by item and location, where the replenishment method can identify the preferred ship-from location (and transportation lead time considerations) to model a distribution network. Transfer orders coordinate movement between locations. Sales order line items indicate the ship-from location, while purchase order line items indicate the ship-to location.

Are Spend Management (or SRM) Apps Suited for the Mid-market? – Part 1

Universal Supply (Chain) Issues

I could think of at least the following five key issues and challenges that in turn lead to tremendous opportunities to save money, time, and bolster the bottom line of companies of all size.

Issue #1 is excessive spending for direct and indirect goods and service
—i.e., more than a company should for it needs. The opportunity here is to reduce the company’s spending by minimizing maverick purchasing practices, reducing transaction costs, and leveraging the aggregated (collective) purchasing power of the enterprise to negotiate more favorable pricing, service, and contractual terms and conditions.

Issue #2 is a lack of visibility and accountability. Many companies are not exactly sure what they are currently spending their money on. The pertinent historical and snapshot data is lacking and is likely inaccessible. Questions like, “How much are we spending? With what suppliers? On what categories? Who is spending it? How long does the approval take? Are we within the budget? What suppliers are (or are not) fulfilling orders on time? Should we rationalize our supplier base? Are there spikes or trends in our spending patterns that require action?” and so on require constantly changing answers.

The opportunity here is for all managers and executives to monitor spending (via personalized interactive analytics and alert messages) by category, location, cost center, department, project, you name it. These metrics should be known/viewed as transactions are happening, instead of only after they are booked to the general ledger (GL).

One way to solve this conundrum could be via procurement data marts that provide prepackaged spend analysis over a few dozens metrics and dimensions for fast answers to the above questions. These answers should be based on fresh (real-time, or close to real-time) data rather than on “rearview mirror.” This hindsight speed-of-thought spend analysis should measure and optimize savings via packaged buyer analytics, key performance indicators (KPIs), and proactive control and supplier collaboration.

Issue #3 is that most companies have a legacy of too many vendors that supply disparate operations and manual approval processes that make it impossible to exercise reasonable control. The opportunity here is to have an overarching system that enforces controls, drives requisitioning and purchasing clerks to preferred suppliers and items, and makes an approval workflow a snap. Essentially, the idea is to make it patently easy for everyone to do the right thing consistently time and again.

Issue #4 is that many existing procurement and payment processes are labor-intensive and fraught with errors and rework. As a result, too many people are spending too much time on clerical tasks. The opportunity here is to lift that burden and focus the company’s human resources (i.e., requisitioners, managers, and purchasing professionals) on more strategic activities.

Finally, Issue #5 is fragmented enterprise systems (and islands of information), which are difficult to navigate and almost always require duplicate data entry. Astute integration technologies should solve this problem without costly IT input, even if the enterprise is integrating diverse solutions (i.e., procurement and sourcing with different front-office and back-office solutions). There is often a need to integrate procurement to accounts payable (A/P), GL, and inventory management systems, whereas both procurement and sourcing systems often have to be linked to supplier catalogs, Web sites, and sales order management systems.

SRM or Spend Management?

As said even back in 2003 in a TEC article, “The Hidden Gems of the Enterprise Application Space,” the supplier relationship management (SRM) software category has been important and valuable for companies of all sizes. The SRM market is evolving due to related emerging areas such as e-procurement, strategic sourcing, spend analysis, etc.

For example, the payback and value of running a sourcing event before awarding a contract is a given, and we can see companies like Ariba and Emptoris doing that well these days. However, they are selling to the high-end market, against SAP and Oracle enterprise resource planning (ERP) installations. It is interesting that the SRM moniker, which really revolved around the supplier collaboration theme, has lately lost some of its popularity (possibly after SAP and Oracle commandeered the term within their respective SAP SRM and Oracle PeopleSoft SRM suites).

Ariba came out in the early 2000s with the “spend management” moniker based on how procurement always talks about spend. It was a whole “find it, get it, keep it” campaign. In addition to procurement and sourcing, a full-fledged spend management or SRM suite typically includes contract (lifecycle) management software and business performance management (BPM) analytic capabilities (e.g., dashboards, scorecards, etc.).

Ariba and some procurement-oriented ERP vendors argue that spend management means transactions too, such as electronic invoice presentment and payment (EIPP). Supply chain management (SCM)-oriented vendors might also argue that it touches on supplier connectivity and supply chain visibility (SCV) or supply chain event management (SCEM) as well.

For example, ERP providers are seeing a strong push to consolidate and streamline A/P as the tail end of the transactional process. Thus, some vendors offer automated A/P matching (“hands-free A/P”) as a way to accomplish consolidation by matching electronic invoices to electronic receipts and generating payments for matches within preset tolerance limits.

I feel strongly, though, that effective spend management must also cover spending that occurs outside of e-procurement. Face it, no company has ever (or will ever) put all of its spend under management. That’s why it is critical to gather those expenditures that occur outside of procurement (including even financial books showing expenses transferred from one account to another), and to show them to requisitioners and approvers during the requisition process.

Some ERP vendors call that capability “budget and commitment checking” and do it very well because they have comprehensive integration to the back-office applications, including A/P, purchasing, and GL. Without that, users, vendors, and pundits just keep harping on getting 100 percent of spend under total control, without ever getting there in real life.

What About Small to Medium Enterprises (SMEs)?

A smart person once said that a major difference between large companies and SMEs is that in a small company a single person has to wear several hats (and perform a number of tasks). Otherwise, large and small companies undergo many similar business processes.

To that end, there are extremely few mid-market companies that have a CPO per se. More likely, one will run into vice presidents (VPs) of purchasing, or sometimes just directors. Some mid-market companies don’t even have a full-time buying staff and clerks; there, purchasing is managed within departments like IT and facilities.

Regarding “spend management” versus “SRM”–it’s as much about marketing as it is about solutions per se. As said earlier on, Ariba (and some bloggers and pundits like Jason Busch) started chanting the “spend management” mantra around 2002 or 2003 to try to establish a footprint that justified a best-of-breed versus enterprise suite investment.

But “SRM” and “spend management” are pretty generic phrases that practitioners toss around in various forms veritably interchangeably. Truth be told, the mid-market never really caught on to the term SRM, and some incumbent vendors have responded by simply talking about their individual SRM solutions (for procurement, sourcing, and spend analysis).

Even the terms “sourcing” and “strategic sourcing”
—like “SRM” or “spend management”
—fail to resonate with the majority of mid-market companies. For sure, they have buyers and they source stuff, but as a software application, it’s a term that just doesn’t seem to gel.

Now, if Tier One SRM vendors like Ariba, Emptoris, SAP, or Oracle choose to dumb-down and reprice their SRM offerings for the mid-market, they are going to have to do something extra to reduce the operational costs of the model too. Namely, having a stable of savvy category buyers and sourcing experts (consultants) available at all times for all customers is not cheap (and Ariba might heavy-heartedly admit that).

As pointed out earlier, in the mid-market there are many companies that don’t have full-time buyers at all; they get along fine without them and don’t see much benefit in paying for them as contractors. That will be a hard mentality to get over.

Software as a Service (SaaS) and business process outsourcing (BPO) arrangements might be attractive for some SMEs, but certainly not for all (and maybe not even for most). Some of them will not go for such offerings at any price, at least not in the near future. Namely, there are still too many risks (whether real or perceived) for them to wrap their heads around.

Are Spend Management (or SRM) Apps Suited for the Mid-market

Generally speaking, sourcing is the process of identifying a company that provides needed goods or services. APICS Dictionary further defines strategic sourcing as “The development and management of supplier relationships to acquire goods and services in a way that aids in achieving the immediate needs of a business. It is entirely aligned with the sourcing portion of managing the procurement process.”

In other words, strategic sourcing is the continuous evaluation of preferred suppliers, goods, services, price, and non-price attributes to achieve the optimal mix of all parameters. The group of (preferably electronic) “request for” documents collectively called “RFx,” which entails requests for quotation (RFQs), requests for proposal (RFPs), and requests for information (RFIs), facilitates the supplier evaluation efforts.

Actual buying or selling (sourcing) takes place via a number of auction events that will be described shortly. Purchases can be direct or indirect, depending on whether they entail direct or indirect materials.

Direct materials are materials that become part of the final product in measurable quantities. These are raw materials for manufacturers, and finished goods and components for distributors. Conversely, indirect materials are materials used in manufacturing that are not normally charged to finished production, such as cutting and lubricating oils, machine repair parts, glue, or tape.

Indirect materials also include maintenance, repair, and operations (MRO) supplies, or items used in support of general operations and maintenance such as maintenance supplies, spare parts, and consumables used in the manufacturing process and supporting operations. Office supplies, computer equipment, professional and temporary services, catering services, facilities services, travel, internal suppliers (e.g., computer, telephone), and so on are other examples of indirect purchases.

There is a third kind of sourcing/purchase, spot purchase, which is a purchase made for standard off-the-shelf material or equipment, on a one-time basis (”on the spot”). Spot purchase could apply to non-catalog items requisitioned through the procurement module and also to single sourcing events for large purchases that warrant competitive bidding. In the first case, the sourcing module logically must be integrated with the procurement counterpart.

The sourcing process starts from an actual requisition for a certain material or service that follows the creation and posting of an event, bidding, evaluation of bids, selection, and approval of the winner, and transmitting the actual purchase order (PO) or contract to the winning supplier.

(A Plethora of) Sourcing Auctions/Events

In sourcing, one can distinguish between two main categories of events (auctions): forward events and reverse events. A forward event, also called a seller-centric event (because it is posted by a seller), offers products or services for sale. A reverse event, or a buyer-centric event, is a request to buy products or services from suppliers.

Within these two types of events, commercially available sourcing products typically support the following event mechanisms (in addition to an event pack, which is a group of individual events):

* Posted offer (forward “for sale”) and posted bid (reverse “wanted to buy”) events are similar to advertisements in the classified section of a newspaper, with the discretion of the seller to sell (or not) to whomever they see fit.
* An English event is an open ascending-price event; as time goes on, the price is bid up by buyers who are willing to pay more than other bidders. In contrast, a reverse English event is a descending price event because the price is bid down by sellers willing to sell for a lower price than a previous bidder.
* A Dutch event is an open descending-price event, while a reverse Dutch event is an ascending-price event. In a forward Dutch event, a seller posts a description of the item to sell, along with a starting price (traditionally set above the item’s true value) and the minimum acceptable price, which is the lowest price the seller is willing to sell the item for. The price continues to decrease by a seller-specified amount at seller-specified intervals until either a buyer stops the event by bidding at the currently displayed price, or the price drops below the minimum acceptable price, in which case there is no winner.
* A uniform price auction is a mechanism used to sell a fixed quantity of identical items, and derives its name from the fact that all event winners pay the same amount, but the highest bidder is eligible for his/her desired quantity (and so on until everything is sold). The price is dependent on the least best bid amount up to the total quantity of items available. If the event owner has specified a reservation price, then the amount paid depends upon whether the nth highest bid (where n = the number of units for sale) is above the reservation price and whether the seller uses the all-or-none option.
* A discriminatory price auction is quite similar to the uniform price event, except that all winners pay exactly what they bid. Higher bidders buy the first available items.
* A first-price sealed-bid (FPSB) auction is an event (either forward or reverse) where the bids (or quotations in reverse events) are hidden from everyone during the bidding process (until the event expires).
* A Vickrey, also called a second-price sealed-bid event, is a forward event that is operationally equivalent to the sealed-bid event except that instead of the highest bidder paying what he/she actually bid, he/she pays the second highest bidder’s price (unless there is only one bidder, in which case he/she pays the reservation price). This sort of event is a demand-revealing event because it entices bidders to bid what they value the item to be worth.
* Weighted request for bid (RFB) sourcing allows the creation of reverse requests for RFQs and forward RFBs with user-defined weighted attributes. These features could be special qualities or factors that could drive the selection of a buyer or seller by means other than price alone. Some examples of attributes are proximity of manufacturer, lead time, color, ISO compliance, delivery speed, options, manufacturing and engineering tolerances, etc. What this kind of sourcing auction does, in effect, is give the event owner a way to ask questions of bidders and have those answers electronically and impartially evaluated.
* A batch event is one in which a seller posts a quantity of identical items with a pricing step function. As the number of items that have been bid on increases, the individual item price drops as a function of the quantity. While the actual steps are not shown on the bidding page, event owners have the option of revealing their price function in the event’s details field.
* Dynamic events are an enhanced version (and combination) of the above-mentioned English and weighted-attribute events. Like an English event, a dynamic ascending event is an ascending price event because as time goes on, the price is bid up by buyers who are willing to pay more than other bidders. Similarly, like a reverse English event a dynamic descending event is a descending price event because as time goes on, the price is reduced by sellers who are willing to sell an item for less than other bidders. But also like the weighted-attribute event, dynamic events allow for the creation of user-defined weighted attributes (special qualities or factors that can drive the selection of a buyer or seller by means other than price alone).
* Single-price RFBs and single-price RFQs are respectively forward and reverse events that use only one predefined weighted attribute of price.
* Finally, sourcing RFB and sourcing RFQ events are those in which sourcing agents are called upon to assist in the actual purchase or sale, or to provide defining information. Agents can, in turn, create another event from the original one as needed. Frequently, companies use this event type when they are unsure about exactly what it is they are buying or selling and they need some assistance defining it. In a manner of speaking, TEC is sn example of an agent helping companies source enterprise applications.

Be There or Be Square? David and Goliath Team on bCentral Auction Site

FairMarketSM, Inc. (NASDAQ: FAIM proposed) and Microsoft, Inc (NASDAQ: MSFT) announced the addition of auctions to the Microsoft bCentral portal for small and growing businesses. Product categories range from Business Machines to Uniforms/Business Dress. Auctions are only one aspect of bCentral, which also provides information to small businesses on subjects ranging from how to build a web site to how to recruit employees. The auction capability is linked to other Microsoft and FairMarket auction networks.

Auction capabilities are a small addition to bCentral. The link is one of sixteen on a two-inch by four-inch section of the bCentral home page. While the categories themselves have a small business orientation, a quick trip through some listings suggests that the auction list has been seeded with a variety of items from other auction sites. Of course the beauty of an auction site is that many unlikely goods will find the person or company who needs them.

At present, however, we think there are too few items of real value to small businesses among the hodgepodge of games and CD's whose photos are stamped "Bundled Software Must Not Be Sold Separately From Approved Hardware." We believe that this kind of content is not likely to endear the site to potential small business users.

This may be a startup phenomenon that will disappear as the site gets a more focused population of goods and services. However, if the product listing does not focus naturally, it would be quite labor-intensive, and a difficult public relations problem, to try to monitor it to focus the content manually, even with automatic aids.

While a drop in the bucket for Microsoft, the announcement may be quite important for FairMarket. Currently preparing for a public offering, any mention of the company's name in the news is good, especially when that name is linked with part owner Microsoft. (Microsoft owns 21 percent of Fair Market, of which 17 percent is in warrants.) However, in the long run FairMarket needs transaction revenue rather than name recognition, thus involvement with any site that does not efficiently convert visitors to buyers can be doubly costly. The obvious cost is the opportunity cost of devoting resources to a low-value site.

The subtler cost is in the fine print of FairMarket's contracts with Microsoft (and with Excite, Inc, a 15% owner). These call for sharing of transaction revenue, with enforced minimums based on Internet traffic. That is, if Microsoft sends a certain number of visitors to FairMarket then, regardless of whether they generate transaction fees, FairMarket will owe Microsoft a minimum transaction fee. In total, these fees - taking both Microsoft and Excite into account - range from approximately $5.8 million in 2000 to approximately $28.4 million in 2004.

Given that FairMarket's revenues in the first three quarters of calendar year 1999 were $900,000 and essentially zero for the preceding two years, these agreements do represent some real risk. Note that for Accounting reasons FairMarket will not recognize transaction revenue generated from visitors sent from Excite or Microsoft until the minimums have been paid or the traffic levels have been unable to meet the trigger points. This makes the first few quarters especially hazardous. If FairMarket doesn't generate the transaction revenue from Microsoft and Excite very early in the year, they will be in an uncertain position - the kind that Wall Street analysts and investors particularly dislike.

Oh, Right. E-commerce is About Buying and Selling, Isn't It

FreeMarkets, Inc. (NASDAQ: FMKT) runs a marketplace that enables large competitive auctions for the purchase of industrial parts and raw materials. Unlike most digital market makers whose goal is to create completely digital marketplaces, FreeMarkets provides value by combining technology with labor-intensive services.

When buying a thousand rolls of standard sized paper towels it is efficient to look in a catalog and choose vendors based on price, delivery times, and reputation. When buying millions of cubic feet of natural gas or a family of PC boards, a different approach is definitely called for.

FreeMarkets works with purchasers to help them craft detailed product specifications. These requests are prepared by specialists in the product, materials, or service being acquired. Preparation of a specification might take between four and ten weeks.FreeMarkets also helps buyers identify potential bidders on the contract. FreeMarkets then works with the suppliers to train them in the use of the system. The bidding takes place in an electronic market that shows all suppliers the current bids in real time. The marketplace supports multiple currencies and a host of specialized features. Buyers typically save between 2% and 25% on a single acquisition.

The Postal Service is the nation's largest civilian employer, largest shipper, and tenth largest commercial enterprise. Its complex contracts for shipping services, equipment and repair, and raw materials make it a natural for the specialized procurement services that FreeMarkets provides. FreeMarkets recently signed a partnership agreement with American Management Systems, Inc. (NASDAQ: AMSY), which will bring FreeMarkets other public sector clients.

At present FreeMarkets has little overlap with other marketplaces, such as those being created by Commerce One or Ariba. As digital marketplaces become more crucial to the supply chain - as is beginning to happen in the automotive industry and ether verticals - these marketplaces will undoubtedly begin to encroach somewhat on the lower end of FreeMarkets' space. However, it is not efficient for such markets to attempt to develop the depth of product specific knowledge that FreeMarkets has in 70 different verticals.

Similarly, while FreeMarkets could use its position in these verticals to build digital exchanges for more routine procurements, there is no compelling reason for them to do so. In the increasingly competitive world of electronic purchasing FreeMarkets has the enviable position of being able to make money while sitting well above the fray.

VerticalNet was an early entrant into the vertical B2B market business. It entered the space when digital markets were still in the future and set up as a content provider, with dozens of individual vertical sites. However, its "marketplaces" tend to be based on fairly simple models, while other verticals have been offering much more robust digital marketplaces. Also, the leading life sciences vertical, Chemdex, recently announced that it would rename itself as Ventro and devote itself to launching new verticals in a variety of industries, which was a clear threat to VerticalNet.

Once VerticalNet has successfully integrated Tradeum's digital marketplaces their vertical offerings will be much bigger draws. The question is whether they can make the change before the Chemdex folk launch their new offerings and capture significant market share.