Finding the ideal or close-to-ideal vendor is a less-than-perfect process that can result in entering into an adequate transaction rather than an ideal or desired transaction. A company will determine its requirements and then seek a business or service provider that matches those requirements within a certain acceptance range. However, the resources available to find an ideal or desirable entity are limited. There are various B2B methods, processes, and procedures that assist a company in procuring the resources required. Forging the vendor–customer relationship can be highly people-intensive at one extreme or can be fully automated at the other. The steps involved in building a B2B relationship include:

This process can be very effort-intensive, especially when sourcing a new requirement. Each time a new requirement for raw material, services, or supplies arises, the process described earlier to establish B2B relationships ensues. As a result, many companies create specially skilled and dedicated teams, positions, or roles to develop and manage vendor relationships. Often, these roles are called business planners.

Figure 2.1 depicts the iterative nature of this process. The business planner is generally responsible for managing this process. Of course, the business planner must take into account not only the requirements to be filled but also the interest, influence, and constraints of the enterprise. These are the guidelines that help the business planner through this process. Influence could be factors such as special discounts available from certain vendors. Interest could be factors such as a long running history with a vendor. Finally, constraints are factors such as a requirement that a vendor must not have a relationship with a competitor. Within this decision space, the business planner must find a vendor to meet the basic requirements. Each iteration of this process results in a list of potential vendors that must be investigated and perhaps negotiated with. Steps 4 and 5 will always remain people-intensive, because technology cannot replace trust-built relationships. In this chapter, we demonstrate how automating earlier steps can result in a more efficient way to search for the right vendor or service provider.

Figure 2.1. Vendor discovery process.

Consider a business planner, Jeff, at ConstructNow. ConstructNow is a global construction giant based in San Francisco. Jeff is responsible for sourcing cement, among other construction materials, for ConstructNow. He has the contacts and processes quite streamlined for efficiency. However, ConstructNow has won a major government contract to build a military installation. This military installation needs a different grade of cement — military-grade. Military-grade cement has greater heat resistance versus the regular industry-grade version. An expert at sourcing industry-grade cement, Jeff realizes he will have to spend a significant amount of time and effort to find the most synergistic source.

Hit and Miss

In this example, ConstructNow is faced with increased demand. Having negotiated cement contracts at the start of the quarter, ConstructNow needs to make arrangements for additional cement to proceed with the nonplanned construction contracts. However, Jeff wants to ensure the extra cement is available at a reasonable price and quality prior to accepting the contracts. Of course, the time available to Jeff is limited and he needs to secure the extra cement within a week. ConstructNow’s first tier vendors are unable to satisfy the extra demand.

Like most companies, ConstructNow has categorized its vendors into three tiers. The first tier vendors usually are the preferred vendors because of previously negotiated prices and quality. First tier vendors are vendors that a company prefers to interact with because the right understanding of each other’s business processes and electronic connectivity already exists. Second and third vendors are vendors that can fulfill demand; however, this usually is accompanied by compromise on several parameters, such as time of delivery, price, and quality. They are generally not as electronically connected with the company as first tier vendors. Naturally, there will be several “unaffiliated” vendors that a company rarely does business with.

Second and third tier vendors may not always provide exactly what ConstructNow needs, but can be alternatives to fulfill impromptu and important demands. After several phone calls to second and third tier vendors looking for the additional cement supply, Jeff finally negotiates the desired quantity. However, the eventual supplier, CementEtc, has not always delivered cement on time and also charges an extra service fee for rush orders. The less-than-perfect process, as explained earlier, results in a transaction for ConstructNow that was adequate but not ideal. These tiers are depicted in Figure 2.2.

Figure 2.2. Finding cement vendors.

The less-than-perfect process for matching requirements with business or service providers may result in paying an “unwarranted” higher price or perhaps settling on the quality obtained. In our example, additional effort by Jeff may have resulted in finding the ideal vendor but, for all practical purposes, Jeff needs to make a decision in a time-bound fashion forcing him to accept adequate terms.

An analysis of the situation shows that seeking out vendors manually is an inefficient procedure. It is:

• Time consuming

• Hit-and-miss

• Potentially cost ineffective

• Forcing compromise

• Based on a limited vendor network

Once a vendor is found and selected, the next challenge is to determine the best way to interact with it.

As a company transacts with its vendor network, there are still more obstacles to smoothen. If we examine the established vendor network closely, we see that there are vendors with whom enterprises interact electronically, semi-electronically, and manually. A spectrum of processes, procedures, and technologies support these varying levels of interaction mechanisms. Each vendor has an access point that the enterprise uses to interact with it. This could be as simple as a phone number to a single point of contact or as complex as an electronic access point that a packet of specially formatted data is sent to. Organizing, cataloging, and sharing these access points becomes a process in itself. In addition, knowing how to interact with all the vendors of an enterprise can be a monumental task as well. Cataloging such access points is generally a company-specific, and potentially fragile, process.

The absence of a strong cataloging process results in several problems. First, business planners could have a difficult time in determining the point of contact within a vendor’s organization. This would require an extra amount of effort to navigate the organization of the vendor to find the appropriate person. Secondly, this problem is exacerbated when a company is trying to escalate within the vendor network. It is critical to know and capture the escalation path to invoke when a problem arises. During the course of history developed with the vendor network, a strong cataloging process could capture the efficient interaction mechanisms. For example, a company could catalog whether it is best to send a Purchase Order via email or use the online order Web site. This organizational learning could help increase the efficiency in interacting with vendors.

Interacting with vendors also involves incorporating them into the process flow of a company. For effective interactions between a company and a vendor (from its vendor network), the process flows need to “blend” together within both organizations. For example, if a company’s purchasing business process dictates that payment be made in 45 days, then a vendor’s collections process should not trigger “past-due” notices after 30 days. In a well-blended process, the payment terms would be the same — at least between the two concerned parties.

One common procedure in the business world is to outline the requirements in an “invitation” and make it available to potential suppliers, vendors, and service providers. Such an invitation is called a Request for Proposal (RFP). Amidst the vast amount of information available on the RFPs, noteworthy is the level of complexity or simplicity possible in structuring RFPs. RFPs generally provide detailed and specific terms that assist vendors in preparing their responses.

RFPs provide companies a reprieve from scanning the entire market for a suitable vendor. RFPs put the onus on potential vendors to respond to a need. If “published” in a very visible and accessible manner, RFPs can actually bring attention to potential vendors — especially those that may not have been on the radar of the business planner. It also provides an efficient mechanism to share the detailed requirements; the efficiency results from the idea that vendors can review requirements and determine whether responding is beneficial or not. However, this is still a very manual process that limits the vendor reach to those that “see” the RFP. It is important to note that RFPs are free-formatted.

The simplest version of an RFP could be a Web page form with an email address. This is cost-effective and can significantly increase the reach to potential vendors. Looking at RFPs from the point of view of a potential vendor, we see a significant drawback. Several RFPs may describe requirements in a variety of ways. Because of limited resources, vendors need to not only evaluate each RFP on its own merits, but also in comparison to others and determine response. This laxity requires potential vendors to thoroughly analyze each RFP very closely to determine whether to respond or not. Finally, RFPs are effective in bringing together customers and potential vendors but do not provide support for subsequent intercompany transactions.

Another process that has evolved is the ability of a customer to request a potential vendor to submit a quote (the amount of resources required to complete a task). This is known as a Request for Quote (RFQ). While an RFP is an invitation to vendors to respond, an RFQ is an entry point provided by vendors to allow potential customers to “request” a quote for products or services.

RFQs, like RFPs, can be a very cost-effective way to reach a “cognizant” audience. However, the onus is still on the customer to compile a list of potential vendors. We learned in Section 2.1 that this is an iterative process fraught with inefficiencies and is very time-consuming. Again, a well-placed RFQ can assist a vendor in drawing attention to itself, helping those business planners in their search for an ideal vendor.

Electronic Data Interchange (EDI) is a standard format for exchanging business information over an electronic network. Specially formatted electronic messages are used to represent business information, such as price, product number, and so forth. A company and its vendors may deploy an EDI network to exchange business information that reduces the need for manual intervention once the initial relationship and contract are in place. Parties who exchange EDI transmissions are referred to as trading partners.

Unlike RFPs and RFQs, EDI networks do not relieve business planners from the pain of discovering ideal vendors. In fact, EDI networks are only deployed among trading partners limiting the customer’s vendor reach. The efficiency gained from EDI networks is really in the interaction and transactionality. Because transactions are broken down into information exchanges, preformatted information can be shared to transact business with minimal human intervention. However, these EDI networks are very expensive to deploy, maintain, and support and thus are limited in their potential because many smaller vendors may not participate.

E-marketplaces are a phenomenon of the Internet and of the desire to make finding the right partner more efficient. An e-marketplace is a generic term that represents the installation of various Internet technologies between vendors and customers. E-marketplaces are found in two major flavors: consortium-run and privately-run.

A disadvantage of all the present technologies and processes described earlier, is that there is no central location to go to and identify potential vendors or service providers to fulfill a company’s needs. Relying on a Web site that holds an RFP or RFQ process, is still very hit-and-miss, as it assumes that a potential vendor or service provider is actively monitoring that location. This also raises the issue of dependency on a manual search process. The importance of human interaction cannot be fully replaced by any technology construct; however, these technologies can help to concentrate human involvement to a later stage in the process — a stage when negotiations or commitment is required. The business planner can interact with a smaller subset of vendors, thereby saving time.

Another disadvantage is that many of these technologies require a heavy investment in time, resources, and training to set up. Thus, they cannot be employed for immediate or infrequent needs. For example, in most cases a company’s EDI network will not reach out to the second and third tier vendors. In such cases, companies resort to manual processes for transacting business with these vendors. For example, Jeff would need to manually process purchase orders to send to CementEtc.

These processes, procedures, and technologies do not assist in consistently describing a vendor’s offerings. For example, when looking through the telephone directory, Jeff could search for several cement providers before finding one that provides exactly the kind of cement that ConstructNow requires. Some cement providers may not have the required quality level. Predictable description frameworks help vendors describe themselves consistently. These frameworks offer businesses the ability to make an educated assessment and avoid an “apples to oranges” comparison. Without consistent descriptions, Jeff may find that cement can be procured at a very low price but only upon further discussion discovers that the heat resistance property is only industry-grade. You will recall that Jeff needs military-grade heat resistance for the government construction project. A structure to help companies describe their offerings in a consistent fashion could have avoided this confusion.

Table 2.1 summarizes the advancements in bringing together buyers and sellers. We compare these advancements on characteristics such as the degree of manual effort, implementation cost, and degree of vendor reach. Note that no one solution is the silver bullet for enterprises and business planners. Each advancement has its own strengths and weaknesses as each technology or process would. Despite the challenges described, it is important to note that various industries have adopted one or more of these processes and developed sophisticated technologies to support them. For example, for enterprises with information technology (IT) needs, the RFP framework has become an accepted way to invite system integrators and consulting services companies. These adopted processes are continuously evolving. Note that a combination of the aforementioned processes, procedures, and technologies can be used in conjunction with each other to deploy a framework that does increase the efficiency of customer-vendor interactions. Business registries are not meant to displace any of these adopted practices, but to provide an ability to collect services together intelligently, capturing some information around access points, interaction procedures, and escalations points to name a few.

Business registries are not only a phenomenon of these improvements, but also an effect of the latest technological innovation — Web services. A simple “Google” search on Web services results in a plethora of information about what they are, how they are used, and the technologies they are comprised of and so forth. Chapter 3 provides a brief overview on Web services. However, the working definition that we use throughout the book is:

Web Services: Web services are services or business assets (either electronic or human) that are made available via a company’s infrastructure. Customers can access some Web services via peer-to-peer communication or via a central hub.

Web services are most notably known for their ability to be deployed using a variety of Internet standards.

Large enterprises provide employees with easy access to the employee service network. Many business to employee (B2E) technologies use standard Internet technologies to assist enterprises in presenting employees with all the information they need. One can probably think of many services that employees use during their employment history with a company. However, we present a partial list in this example to show the breadth of transactions that employees enter into.

Enterprises continue to simplify access to such services for employees. Human Resource (HR) departments started off with an employee file that was essentially a manila folder with notes. Over time, employees could access HR experts’ help via phone. The HR representatives would be able answer questions and interact with the employee files to resolve any issues. Eventually, the manila folders and hard copy forms were replaced with electronic documents (and scanned copies).

Employee portals based on Internet technologies are the latest advancement in this area. These portals are a set of Web pages and scripts that give employees access to information that resides on scanned files or in employee databases. They also provide services that allow employees to perform frequent transactions, such as recording vacation time. This collection of information and services could be considered a business registry. Today, most employee portals are browser-based. However, programmatic access to these services could remove the requirement of direct employee interaction in cases where it is not absolutely required. For example, employees may check the performance of their 401(k) portfolio either through browser-based or service-based programmatic interaction. Service-based programmatic interactions can bring the necessary information automatically to an employee, without manual effort. Moreover, other services can use this information for subsequent processing. For example, an employee’s personal accounting software can obtain 401(k) data automatically and prepare a monthly financial performance report.

A business registry, regardless of whether it contains Web service entries or brick-and-mortar entries, is a platform where potential customers and vendors meet. It provides capabilities that assist a customer in finding the elusive ideal vendor. It also provides capabilities to assist a vendor in presenting and describing their offerings to potential customers. In essence, business registries can be any number of the following:

Business registries can be constructed to serve a select group of entities. Often, these are restricted and only entities that have met certain criteria can obtain access. The employee portal described previously is an example of a restricted registry. The notion of restricted registries leads us to different variations of registries that are characterized by access control levels.

The features of a business registry primarily depend on its type. We mentioned that business registries can be discovery, publishing, and transactional platforms, but the degree to which a registry supports each of those broad categories of activities varies. Generally, there are some basic features that a rich registry technology must provide:

Some registry technologies also provide a hub for interaction and act as a transaction platform; however, this is not absolutely required because many transactions happen at the application-to-application level and not via a central hub.

As business registries mature, value-added services will become key differentiators for registry platform vendors. These value-added services will fall under a few major categories: ease-of-use tools, community building, quality of service, and revenue-models.

The technological challenges around the business registries revolve around security and information integrity.

Intangible challenges are those challenges that are not necessarily related to the technological infrastructure that registries are deployed using. These challenges pertain to the realities of how business is conducted and how relationships are formed.