This is a repost and reprise of a series that last ran (for the second time) in 2015. It’s as relevant, and important, today as it was then, if not more so, thanks to the I2O Hype and AI BS!

In the first three parts of this series we discussed the proper RFX process to follow when attempting to select a technology(-based) solution provider (for e-Procurement, e-Sourcing, and Supply Management solutions in particular) as a true multi-national. We noted that while most companies more-or-less understand the high level process, most get the implementation wrong, focussing too heavy on feature-function checklists (that are usually put together by vendors, even if they are obtained from third parties), technology buzzwords (like AI, Intake, and Orchestration) and too little on the core processes that need to be effectively supported and a vendor’s global implementation and support capabilities.

If your organization follows the advice presented, starts with the customer references, and only spends time and energy conducting a detailed review of those vendors with a track record that suggests that the vendor has a solution that will support your core processes and could meet your global implementation and support needs, then your organization is off to a great start. But this isn’t the only best practice that your organization should be following in the selection of a vendor for your global technology needs. In this post we’ll cover five more.

The Core Solution Litmus Test
Once the vendor has passed the core process and customer litmus test, the next litmus test is the core solution requirement litmus test. After dividing all of the stakeholder problems into must solves, should solves, and nice-to-solves, re-validate that the vendor has solutions (technology, services, or a combination thereof) that address each of the must-solve problems and most of the should-be-solved problems. The vendor is not right for you unless it is a global, cultural fit that brings the right solutions. (Remember, there’s no checking feature/function boxes at this step!)

Third-Party Claim Verification
Most vendors will make big claims in terms of their platform capabilities. Just like a vendor’s ability to serve your organization globally should be challenged and verified with customer references, so should its ability to fill your technology gaps. Not only should you talk to their partners, but talk to analysts, bloggers, and other third-parties they have interacted with and whom have seen (part of) their solution.

Open Book Negotiations
In addition to third-party claim verification, don’t be afraid to force a vendor to prove every claim, statement, and assumption. This should not stop at current, successful, customer references. The vendor should let you speak to analysts it has relationships with, consultants who have implemented their solutions, auditors to verify their financial stability, and even ex-customers if asked.

End-To-End Total Cost of Ownership Elucidation
What is the true cost of the solution to your organization AND your supply chain? This goes beyond the end-to-end platform cost, as discussed in this classic post on Cost Model Calculations in SI’s “Enterprise Software Buying Guide” series, but also includes any costs that will be borne by your supply base. It’s often the case with e-Sourcing/e-Procurement/Supply Management solutions with Supplier Information Management, Supplier Portal, or Supplier Network functionality that a vendor will charge your suppliers an access fee, which can sometimes be hefty. An access fee that is just going to hit your organization with interest in a year when your suppliers raise their prices to cover the fees you caused them to incur. In Procurement, a penny saved today at your supplier’s expense often translates into a dime spent tomorrow. (And if you don’t believe me, then you need to work on understanding the cost of capital throughout your supply chain. Remember that sound, conventional financial management is NOT good for supply chains.)

Open Finals^*
Typically, the final negotiations in this space are more secret than what goes on beyond closed doors at Area 51, scientology headquarters, and the back room of the club where Wall Street mega deals really happen. This is dumb. Really, really dumb! Blind auctions may be okay when buying commodities, but it’s the last thing an organization should do when buying a critical piece of functionality where a failed implementation will cost (tens of) millions of dollars or more in overspend and opportunity costs. Not only should each vendor be aware of whom it is up against, but vendors should be asked to promote their strengths and counter their opponents weaknesses. They should be instructed to tell the truth, even when asked tough questions (about customer retention and defection to a competitor), and (severely) penalized for false answers (and if they try to bypass you by going straight to the CFO or CEO, they should immediately be disqualified from the competition).

Remember, good vendors are honest, especially about the occasional (big) mistake that they made in the past, learned from, and put measures in place to prevent ever repeating it. And the best vendors will get up and walk away as soon as they realize they are not the solution for you (because they thought you needed primarily e-Sourcing functionality and they are mainly e-Procurement for example) and that it would take too long or cost to much to tailor it to your needs. (And these are the first vendors you should go back to as soon as you have needs that they can fulfill. As we said in a prior post, there is no perfect solution, or even anything close, but a vendor who is completely honest about what they do and willing to work with you to solve your problems is the best vendor for you, not the vendor with the most extensive system today [who may have stopped new development entirely and is just selling what they have].)

If your organization implements the best practices covered in this series, then chances are that it will have no choice but to prepare for success!

^* Nothing to do with tennis, folks!

This is a repost and reprise of a series that last ran (for the second time) in 2015. It’s as relevant, and important, today as it was then, if not more so, thanks to the I2O Hype and AI BS!

In this post we continue our series on best-practice vendor selection for your enterprise e-Procurement, e-Sourcing and Supply Management solution. As per our first post, this series specifically relates to the selection of technology(-based) vendors for your enterprise software needs, and e-Procurement, e-Sourcing, and Supply Management solutions in particular.

What is the ultimate goal of your organization’s technology acquisition project? To get a Spend Analysis/e-Procurement/e-Sourcing/S2C/P2P(/I2P/AP)/S2S/S2P/SXM/TPM/CLM/I2O system? No. To increase efficiency / save money / get more spend under management? No. To get satisfaction? No. (If you believe you will ever be satisfied, then I suggest you break out your record player, pull out “Out of Our Heads” by The Rolling Stones (US Edition), flip it to the B-Side, and repeat track one over and over, screaming with Mick Jaggar at the top of your lungs that [I Can’t Get No] Satisfaction until you believe it!)

The ultimate goal is your organization’s success. That’s the only metric you care about when initiating the technology acquisition project (TAP) dance. If your organization is a global multi-national, then your organization’s success depends on the vendor’s ability to deliver globally. (And if it’s just regional, on its ability to serve mid-size organizations effectively at a cost point that is affordable so that you can buy the system and grow.) Not how many boxes the vendor can check on some random feature / function check list. As we discussed in our last post, where large-scale roll-outs are concerned, there are only a few standalone best-of-breed sourcing and procurement technology vendors that will make the shortlist for a given organization.

Moreover, and you’ve probably been wondering about this, this success metric has NOTHING to do with AI, and neither does your RFX. Depending on what you need, the best solution might be AI, it might be rules-based RPA, it might be guided workflows, it might be a simple data processing and reporting app, or it might be an alert to dust off the handset, pick up the phone, and call the supplier rep to hash out a problem. The reality is that it is usually the case that you don’t need AI and Agents, you need solutions that solve your problems. The best solution is an Augmented Intelligence solution (which is the best type of “AI” solution that actually exists, because, as we’ve repeatedly told you, there is no real Artificial Intelligence, AI Employees Aren’t Real, and if you truly want a good RFP response, the #1 phrase you should ban in your RFP response is AI!)

Great results come from applying the best tech for the problem at hand, not from forcing experimental AI where it doesn’t belong. If a traditional technique can automate 95% of the tactical and data processing workload with 100% accuracy, that’s what you want. (Your CEO and CFO might want a dystopian society where they replace all the workers with artificial agents to maximize profits and minimize the need to actually comply with laws and regulations, but that’s not a reality that is within reach — so they will have to settle for a reality where the white collar workforce is optimized as every worker is 2, 3, 5, or 10 times as productive with the right Augmented Intelligence application supporting them, and every worker they bring on contributes to company growth and success.)

Furthermore, this success metric has NOTHING to do with Intake to Orchestrate either! (We’ve said it before, and we’ll say it again. Spend Orchestration is Clueless for the Popular Kids when what you really need is Revenge of the Nerds!) Intake is NOT NEW. Coupa had full intake on Procurement Independence Day in 2006! (But everyone forgets because as soon as Robbie took over the Coupa factory, they switched from an organizational-size pricing model to a per-seat pricing model and that resulted in many organizations limiting non-Procurement seats.) Moreover, on its own, intake is totally useless. What’s the use of centralizing requests you can’t do anything with? For that matter, neither is (web-based) Orchestration. The World Wide Web was invented by Tim Berners-Lee at CERN in 1989, and CORBA (the first web middleware) was released in 1991 — almost 35 years ago! (And that’s all Orchestration is, Middleware 3.0!)

All you care about is that the platform you are buying can connect to the other platforms it needs to connect to in order to pull data in and push data out as part of an enterprise process, with the ability to be launched by, or launch, other programs in the process workflow. As long as the platform you are buying has a (secure) fully open API for data injection and extraction, process initialization, and connection to your other platforms (either by modules offered by one of the vendors, a third party vendor, or customer integration), that’s all you need.

Your organization needs to remember that this is not 2005, or even 2015, but now 2025 and not only are Spend Analysis, e-Sourcing, e-Procurement, SXM, 3PM, CLM, and I2O functionality becoming more-or-less commoditized among the established vendors, but any decent-sized vendor will be able to check-the-box against any publicly available check-list. (And it’s not “AI” that is enabling this rapid progress, but huge open source libraries and ready-made stacks that encapsulate rules-based workflow and automation and easy plug-in of traditional ML/AI technologies that have been proven to work.) Sure, some vendor platforms will have features G, H, and I while other vendor platforms have features J, K, and L, but all of the vendor platforms will have critical features A through F. As for features G through L, if they are valuable, the other vendors will catch-up, and the time it will take them is usually less than three to six months nowadays, and if a core feature or function is made a contingency of a deal, the catch-up time is probably shorter still!

Another thing your organization needs to be aware of is that starting with a short-list of vendors that it is fairly certain can meet its needs will not only significantly reduce the length of the evaluation process (as it is no longer a question of “can the vendor meet my needs” but a question of “is this the best vendor to meet my needs”), but also significantly reduce the organization’s risk. If the organization needs to operate in forty countries and twenty languages, and doesn’t do it’s homework, it could end up wasting six months evaluating three vendors who don’t have a reference outside of the US and UK and who don’t support customers in a language other than English. If it has a deadline of nine months, what does it do? Either it takes the last vendor in the pipeline, if any are left, or rushes out to find another one, with no time to consider how appropriate the vendor it is for its needs or its organizational culture.

Which is another point that is often missed in the traditional implementation of an RFX cycle. Cultural considerations are typically ignored in technology selection, ignoring the fact that people have to use these systems — people who work, think, act, and like to conduct business in a certain way (and like to interact in a certain way with technology and technology / service providers). As a result, good technology selection is not just a matter of check-the-box when a strong vendor interaction is required. If two or more vendors are more-or-less equal from a functional/process selection, the tie-breaker should be cultural alignment. Does the vendor have the same goals? Work to the same metrics? Conduct itself in a similar manner? Give your customers and suppliers the same respect? Have a system with a workflow that can be tuned to organizational processes (and not force the organization to shoe-horn into processes and workflows that don’t support it’s efficient, best-practice, workflows)? These are important, but often overlooked, questions. Don’t forget them. (And much more important than how many “AI” boxes a vendor checks.)

In our next post we will dive into more best-practices to truly take your technology acquisition project to the next level now that your RFX process is back on the rails.

This is a repost and reprise of a series that last ran (for the second time) in 2015. It’s as relevant, and important, today as it was then, if not more so, thanks to the I2O Hype and AI BS!

Today we continue our series on best-practice vendor selection for your enterprise Spend Analysis, e-Procurement, e-Sourcing, or Supplier Relationship / Third Party management solution. As per yesterday’s post, this series specifically relates to the selection of technology(-based) vendors for your enterprise software needs, and Supply Management solutions in particular.

In yesterday’s post we reviewed the traditional RFX process outlined at a high-level in the e-RFx for Total Value Management wiki-paper over seventeen years ago, which is still more-or-less correct, and then reviewed how this process is typically interpreted, which is where the problems begin, especially where multi-nationals are concerned. We noted that there are three big problems with the standard interpretation of the process, which occur in the first part of the RFI process. In particular, we noted that most supply management project managers ask for the wrong information when they:

• ask stakeholders for product/service requirements
• ask stakeholders for preferred vendor recommendations
• ask vendors for capability information and self-assessment

This last request in particular is especially futile as the last thing a vendor who wants your business is going to do is say that they can’t meet your request, even if their chances of success are dismal. You need to start by verifying that the vendor has the potential to serve you, independent of the vendor’s response or self-assessment. To do this, you need to start the process where an average organization ends it. In particular,

Start with the Reference Interviews

Too many organizations do this:

• Collateral-Driven Vendor Identification
• Request for intent to bid
• Request for proposal and quote
• Shortlist
• Negotiations
• Final List
• Reference Interviews

By the time a typical large organization gets to the reference interviews, it’s too late. Months have been spent on the project, which needs to be wrapped up shortly. As a result, the buyer gets stuck with one of the finalists, even if none of the finalists end up being good solutions for the organization.

If you’re a multi-national organization, you have to start with the reference interviews. Your goal here is two fold.

1. To ensure the vendor can successfully support an organization of your size and scale.
2. To ensure the vendor has a track record of problem solving when needs arise.

If you’re a small company, only do business in one or two countries, and only conduct official business in English (and all your international suppliers are Chinese with english-speaking reps), then it doesn’t matter because just about every vendor can serve you. But if you’re a multi-national that:

• has offices in over twenty countries,
• conducts official business in seven languages (English, French, Spanish, Italian, German, Mandarin Chinese, Portuguese, for e.g.),
• has suppliers that speak five more languages (Cantonese, Vietnamese, Thai, Korean, and Japanese, for e.g.),
• and has to support customers in over forty countries

then not every vendor in the supply management technology solution space is going to be able to support you. In fact, despite the plethora of companies in this space even after the last four rounds of M&A frenzy, the number of pure-play best-of-breed companies that will be able to support your global e-Procurement, e-Sourcing, or Supplier Relationship / Third Party management initiative is likely countable on your fingers, thumbs optional.

And the only way you can have any assurance that a vendor is going to be able to support such an initiative is to start with reference interviews with customers who are similar in size, scope, and needs. (Note that this does not mean they have to be in the same vertical as you. As long as they are about the same size, do business in about the same number of countries, require multi-language support, need a cross-section of similar direct and indirect category support, etc., that’s good enough to start. If the company you are looking at is your direct competitor’s best kept secret, they are certainly not going to tell you that.)

While this doesn’t mean that the vendor has to have offices in each country that you are in, support every language that you need supported, and have a success story for each of the forty countries you are selling into, it does mean that the vendor needs to have a global presence, should support at least a dozen languages (that meet a majority of your language requirements) with a track record of being able to add new languages quickly, and should be in dozens of countries with a history of successful roll-out initiatives to new countries.

Then, you need to know that the vendor truly believes in the customer success that they preach. It’s one thing to say they are 100% committed to customer success, it’s another thing for the vendor to drop everything on a Friday night to fix a crashed system when you need to be ready for a Monday morning signing halfway around the world. Or to step up and meet a government imposed deadline to get your invoices clearance ready in a country which introduced legislation to the fact and the vendor didn’t realize their platform wasn’t compliance ready for that country (as they broke from the norm) or that any customers needed it when they signed you and they now have 2 months to make some major changes. Or to work with you to design entirely new workflows or functions to support key business processes you need to continue to use the system beyond the initial contract period. You’re looking for references to say that the vendor stepped up when the system fell short, got them through the rough patch, and then built a better solution then they could have ever dreamed of. No system is perfect, and, in fact, no system will come close to meeting all of your wants, or even needs, but a vendor who will step up when something is critical and get it done, somehow, is worth more than whatever system a competitor is selling where the competitor’s view of software sales is pump it (marketing) and dump it (no support beyond minimum maintenance once the contract is signed and the invoice has been paid).

In other words, unless you have been convinced beyond a reasonable doubt that the vendor can, and will do what they can, to support your organizational needs, they shouldn’t even get a detailed RFI. Because it’s not about who can survive the funnel, it’s about who deserves to even be in the funnel. That’s a very simple determination, as we’ll discuss in the next post.

This is a repost and reprise of a series that last ran (for the second time) in 2015. It’s as relevant, and important, today as it was then, if not more so, thanks to the I2O Hype and AI BS!

It’s that time of year again. Your budget is about to be approved — a few months later than you’d like — and you’re ready to begin the process of obtaining that Spend Analysis, e-Sourcing, e-Procurement, Source-to-Contract (S2C), Procure-to-Pay (P2P), Source-to-Pay (S2P), Supplier Management (SXM), Third Party Management (TPM), Intake-to-Orchestrate (I2O), or some other system you’ve been dreaming of that you believe is going to revolutionize your Sourcing and Procurement.

You think you know what you want, but you have to go through an RFP and, more importantly, you know that you’ve only had time to look at a few options while building the business case as you were doing it evenings and weekends on your own time because the project wasn’t approved. Now you want to go to market and either verify that you’ve identified the best solution or find the best solution to meet your needs. Since you are a sourcing organization, that process demands an RFP. However, this RFP is not like your RFP for direct materials or indirect spend. This is a very specific technology solution RFP for a platform to meet your needs and support all of the other RFP / sourcing / procurement / supply management processes of the organization. It’s crucial to get it right.

That’s what we are going to discuss in this series — the proper process and approach to acquiring the right Spend Analysis / e-Sourcing / e-Procurement / S2C / P2P (I2P/AP) / S2S / S2P / SXM / 3PM / CLM / & I2O solution for your needs. Furthermore, let us clearly state that this series is specific 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 should 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. As one size does not fit all where RFX and category selection processes are concerned, 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 on the classic e-Sourcing Wiki (now only available on the WayBackMachine) over seventeen years ago. And, in the wiki-paper in particular, the high-level process is still more-or-less correct almost two decades later.

As per the wiki-paper, you start with a two-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 #0: Stakeholder Requirements (collected internally)
2. RFI #1: Vendor Interest
3. RFI #2: 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. And if you ask them what they want, you are just going to get whatever the vendor spending the most on marketing is saying they need, or whatever they can find in a “Free RFP” (and There are NO Free RFPs). 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 those solved, not an array of feature/functions that will never be used! You need to ask the stakeholders what the problems they need to solve are, so that you can ultimately select a vendor with the solution that solves as many of your stakeholder’s pain points as possible. (And if you need that translated into more technical requirements that the vendors will understand, you hire a neutral consultant who does NOT have any vendor partnerships and does NOT do implementations, specializes in Project Assurance, and whose sole goal, and continued compensation, is based on your success (not the vendor’s and not the implementation partner’s).
2. A preferred vendor is one that can offer you the best product or service from an organizational perspective, not from a single stakeholder / department perspective. For example, a stakeholder (team) might rate a vendor A+ because the representatives always responds quickly. But this is not necessarily indicative of great service (and is often indicative of desperation for a sale, which is never a good sign). If their answer to every system issue is always “we’ll get someone to fix that with 72 hours“, and you need the software up 95% of the time, that’s still poor service if the software crashes regularly because 3 days downtime every few weeks will not support an operational level of 95%.
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” (or the rep desperately needs to make a sale to keep his job because the company took too much funding at too high a valuation and everyone’s job is on the line). One has to remember that most (big) consulting (and value-add) organizations are driven by partners with a strong desire for as many dollars as possible, and the associate’s job security is dependent on constant sales and up-sells, 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 on the contract is dry.

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