Category Archives: Technology

Best Practice Technology Vendor Selection for True Multi-Nationals Part IV: Open the Doors for a Truly Successful RFX

In the first three parts (I, II, and III) of this series we discussed the proper RFX process to follow when attempting to select a technology(-based) solution provider (for e-Procurement and e-Sourcing 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) and too little on 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 reviewing those vendors with a track record that suggests that the vendor 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 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, make sure that the vendor has solutions (technology, services, or a combination thereof) that address each of the must-solve problems and most of the nice-to-solve problems. The vendor is not right for you unless it is a global, cultural fit that brings the right solutions. (There’s no checking of 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 solutions with Supplier Information Management, Supplier Portal, or Supplier Network functionality that a vendor will charge your suppliers an access fee. 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 quarter 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 backroom of the club where Wall Street mega deals really happen. This is 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 or more. 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 penalized for false answers. Remember, good vendors are honest, especially about the occasional (big) mistake that they made, learned from, and put measures in place to prevent ever repeating it.

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

In order to get you started, if you are a multi-national looking to roll-out an e-Procurement solution in a multiple countries and languages, want a single solution provider with a global presence that can manage all aspects of the solution implementation including integration to the back-end ERP and supplier on-boarding and support, and has a proven track record of delivering globally, your short list should probably include: Wallmedien, Hubwoo, and Capgemini/IBX. If you are looking for e-Sourcing, your short list should probably include BravoSolution, GEP (Global eProcure), and growing up-start iValua.

* Nothing to do with tennis, folks!

Best Practice Technology Vendor Selection for True Multi-Nationals Part III: RFX – You’re Missing the Most Important Point!

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


What is the ultimate goal of your organization’s technology acquisition project? To get an e-Procurement/e-Sourcing system? No. To increase efficiency / save money / get more spend under management? No. To get satisfaction? No.

The ultimate goal is your organization’s success. That’s the only metric you care about when initiating the technology acquisition project (TAP) dance . And if your organization is a global multi-national, then your organization’s success depends on the vendor’s ability to deliver globally. Not how many boxes the vendor can check on some random feature / function check list. Because, 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.

One thing that your organization needs to be aware of is that this is not 2002, this is 2012 and both e-Sourcing and e-Procurement functionality is more-or-less commoditized among the established vendors. Sure, some will have features G, H, and I while others have features J, K, and L, but they all have critical features A through F. And 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 six months nowadays, and if a feature 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? These are important, but often overlooked, questions. Don’t forget them.

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.

Some Legal Considerations When Outsourcing to India

A recent article over on Outsource Magazine had a good article on “legal considerations when outsourcing to India” that addressed core legal issues that should form the basis of your Master Services Agreement when outsourcing to India. The four issues addressed could be very problematic if not covered by your agreement.

Lex Contractus
This refers to the governing law, or proper law, of the contract. While the parties of a contract can choose the governing law, as the author notes, due to the fact that a major proportion of the services are to be rendered in India, consideration for services will be received in India and the Indian party may sign the contract in India, the applicability of Indian laws cannot be excluded by contract. So, even if the Indian party agrees to the governing law being a foreign law, it is possible that in case of any dispute, the Indian party could approach a court in India to seek appropriate relief and the court could also entertain the dispute on the basis of factors set out above. Keep this in mind when considering outsourcing to India. In addition, should you choose arbitration, Indian law mandates that for a foreign arbitral award to be directly enforceable in India, the award must meet the following conditions: the award must have attained finality in the country it has been passed; it must conform to and must not conflict with Indian law or public policy; both the parties and the arbitration venue should belong to a New York or Geneva Convention signatory country.

Data Protection and Privacy Laws
While India has been slow on the uptake with respect to data protection and privacy laws, compared to the US which has a number of industry specific federal laws and state laws (that also restrict cross-border transfer of personal and sensitive information) and the EU which has the European Data Protection Directive, it has moved quickly to catch up in an effort to insure it keeps the outsourced work that it has acquired. Since the Information Technology Act of 2000 didn’t have enough enforcement teeth in the eyes of the US or EU, the biggest outsourcers to India, it quickly passed the Information Technology Rules in 2011 that defined what would constitute “Sensitive Personal Data or Information”, laid down obligations for the data collector and data processor, and defined reasonable security practice and procedures. This may not be strong enough for extremely sensitive data, but is a great start. Just make sure you also insist on adherence to the IS/ISOIEC2700 as well.

Employment Issues
It’s important to explicitly state that the service provider complies with all the necessary laws and that the overseas outsourcing company may not be threatened by any kind of claim by employees of the Indian company.

Licensing, Copyright in Database and Infringement Issues
Remembering that the outsourcing company is creating, developing, and processing data for you, the client, it is essential that you state that all data, product, programme, software, designs, and compilations constitute IP and that all IP rights are protected and assigned back to you, the client. Note that, in Indian law, the supplier will hold the copyright interest in the software developed by it but Indian law also provides for the assignment of the copyright interest by the service provider in favour of the client, by entering into an separate assignment agreement.

If not properly handled in the agreement, each of these could come back to bite your organization in its organizational behind if something goes wrong. Think it through, and get some expert legal help.

Best Practice Technology Vendor Selection for True Multi-Nationals Part II: RFX – You’re Not Asking for the Right Information!

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

In yesterday’s post we reviewed the traditional RFX process at a high-level, which is 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. 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 are good solutions for the organization.

If you’re a multi-national organization, you have to start with the reference interviews. 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, Russian, Portuguese, for e.g.),
  • has suppliers that speak six more languages (Mandarin, Cantonese, Vietnamese, Thai, Korean, and Japanese, for e.g.),
  • and has to support customers in over forty countries

then not every vendor in the space is going to be able to support you. In fact, despite the plethora of companies in this space even after the recent M&A frenzy, the number of pure-play best-of-breed companies that will be able to support your global e-Procurement or e-Sourcing 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.
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.

In other words, unless you have been convinced beyond a reasonable doubt that the vendor can 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. And that’s a very simple determination, as we’ll discuss in the next post.

Best Practice Technology Vendor Selection for True Multi-Nationals Part I: RFX – You’re Asking for the Wrong Information!

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.