Before we begin, it must be clearly stated that this series relates to the selection of technology and technology-based vendors to provide enterprise software platforms, and/or implementation services, back-office (processing) functions, or technology-driven consulting services for your multi-national organization. While some of the best practices contained herein may also apply to the selection of (strategic) suppliers for high-value and/or complex products and/or services, this series particularly relates to the selection of a vendor to provide an enterprise software backbone, and, in particular, a backbone for e-Procurement and/or e-Sourcing technology for your Supply Management organization. Furthermore, no claims, express or implied, are made with respect to any other vendor selection process and, in fact, if you’re only buying paper and pencils, some of the best practices contained herein will, in all likelihood, be overkill.

Now that the preamble is out of the way, let us begin by noting that the traditional RFX processed is well understood, and well documented in many places, including in the e-RFx for Total Value Management wiki-paper, co-authored by the doctor over on the e-Sourcing Wiki. And, in the wiki-paper in particular, the high-level process is more-or-less correct.

As per the wiki-paper, you start with a three-stage RFI before an RFP, which is solution focussed (and not cost or contract focussed), which is issued before a final RFQ, which is when you collect quotes and start the actual selection / negotiation process. Specifically, the high-level process is:

1. RFI #1: Stakeholder Requirements
2. RFI #2: Vendor Interest
3. RFI #3: Vendor Pre-Qualification
4.    RFP: Solution Inquiry
5.    RFQ: Clearly-Defined Specifications

So what are you doing wrong, especially if you’re a Multi-National? To answer that, let’s look at how this is typically translated:

1. Product Needs, Service Needs, Preferred Vendors
2. Vendor Info. Request, Vendor Interest, NDA
3. Product & Service Capability Profiles
4. Solution Design Request
5. Explicit requirements, process definition, and bid request

See the problems?

1. Stakeholders typically don’t know what they need in a solution. They aren’t technology experts. They aren’t supply management experts. They are domain experts. It doesn’t matter what they think they need in a product or a service, it matters what problems they are having today. You need to ask them what problems they need to solve, so that you can ultimately select a vendor with the solution that solves as many of your stakeholder’s pain points as possible.
2. A preferred vendor is one that can offer you the best product or service from an organizational perspective, not a single stakeholder’s perspective. For example, a stakeholder might rate a vendor A+ because the representatives always responds quickly. But this is not necessarily indicative of great service. If the answer is always “we’ll send someone to fix that in a week”, and you need the machine up 80% of the time, that’s poor service.
3. Asking a vendor if they can provide you with the necessary functionality or service levels after you have shortlisted them as a possibility based upon a review of their collateral is not likely to get you anything other than a “yes we can”, especially if the vendor also offers consulting or “value added services”. One has to remember that most (big) consulting (and value-add) organizations are driven by a greed for dollars and the reps are told to always say yes and take on as much work as possible, leaving the question of how to get it done (if the organization is already stretched or weak in that area) until after the ink is dry.

Which brings us to the biggest problems with the current selection process, which we will discuss in Part II.