Supplier Management: Strategic vs. Critical

One interesting thing about running a SaaS business is that it gives you a unique perspective on supplier management.

A specific example: we host all of our application infrastructure on Google Cloud Platform. So Google is a pretty important supplier for Vendorful!

Looking at it from the other side, is Vendorful an important customer for Google? Ha. We might be an important customer to our account rep, but not to Google’s overall business.

But here’s the interesting wrinkle: I wouldn’t want to host our infrastructure on any cloud platform where we were an important customer. It would expose us to too much risk should something change about their business or ours.

It’s an interesting dynamic, but not unique to software. If a manufacturing operation is reliant on one supplier of a critical input, and that supplier only has one customer, then that means they don’t have any extra capacity should something go wrong, and the manufacturer has no obvious alternatives to draw from.

On the other hand, some companies have very successfully forged mutually beneficial relationships where both sides are critical to the other. Red Bull and Rauch come to mind.

This is all hinting at a pretty important distinction for optimizing your supplier relationships: a strategic supplier, vs. a critical supplier.

Strategic importance vs. criticality

A strategic vendor is one whose relationship can be a source of competitive advantage to your company. A critical vendor is one where a disruption would have a material negative impact on your business. Those are not necessarily the same thing.

In the case of Vendorful, Google is a critical supplier. A major outage at Google wouldn’t necessarily be disruptive to our customers because of our disaster recovery setup, but it would certainly be disruptive to our business – we would have to invest significant effort to remove all business process dependencies and get completely off of Google.

But Google certainly isn’t strategic to our business – we aren’t likely to get any particular competitive advantage in the marketplace by using Google over (say) AWS.

An example of the opposite – a strategic but not necessarily critical relationship – might be a high-end beef supplier to a restaurant. Odds are very high that the restaurant will be able to find alternative supply on short notice, but if the branding and menus are built around specific locally sourced beef then a disruption to the relationship will have longer-term implications to the business.

Where does spend fit into supplier management?

Let me pause here to make an observation: I haven’t mentioned “spend”. Not one time.

There is a good reason for that – spend might be a proxy for strategic importance or criticality, but it’s only a proxy. And frequently a poor one.

From my perspective, this is the crux of the matter. Spend is just one metric that describes a supplier relationship. It is not the metric. Too many companies are prioritizing their supplier management programs by spend, and not by strategic importance or criticality.

The reason for prioritizing SRM and SXM in this way is simple: it’s easy. Just sort your spreadsheet and off you go. But the suppliers you spend the most with aren’t necessarily the hardest to replace on short notice, nor are they always the ones who can give your company a competitive advantage.

A new approach to segmenting your suppliers

A true strategic supplier is one that can help your company be more successful. They might provide a unique product or service, or they might have some kind of competitive advantage in their market. If they aren’t providing your company with a specific and differentiated source of value vs. their peers, then they are a tactical supplier, not a strategic one.

A critical supplier, on the other hand, is one where a disruption or other incident would have a material negative impact on your business. They might be a supplier of a critical input, they might be the only vendor that can provide a particular service, or they might handle sensitive customer data. If they don’t pose that kind of risk to your business, then they are non-critical.

So instead of thinking in one dimension – spend – I suggest that you segment your suppliers along three dimensions: strategic vs. tactical, critical vs. non-critical, and (of course) spend. This will give you much clearer criteria for understanding your relationships and your supplier management priorities. Then you can direct your limited SRM resources towards measuring and managing those relationships more effectively.

Your Software RFP is Broken – Here’s How to Fix It

Have you ever been involved in a software purchase that failed to meet the stated objectives? That ran way over budget? That launched months or years later than planned? Of course you have. Research shows that only about 30% of digital transformations are successful.

One of the main reasons for this is the way enterprise software is often purchased: through an RFP (request for proposal). On paper, it seems like an RFP is a strong approach: define your goals clearly, evaluate solutions side-by-side on objective criteria, pick the best fit with input from all stakeholders. Unfortunately this approach is fundamentally flawed. It makes a number of incorrect assumptions.

Flawed assumption 1: You fully understand the requirements up-front

You spent weeks building your buying team. You spent months interviewing users. You did your research on the market. You even brought in consultants to help you identify and document your requirements. Surely you know everything you need to know to specify exactly what you need and what you want to buy! Right?

Wrong. You will definitely identify additional requirements – sometimes extremely critical ones! – during implementation. If the project is complex enough to warrant an RFP, then it is too complex to fully document up front. It will affect too many people, touch too many systems, and modify too many business processes for anyone to understand the full impact ahead of time.

Flawed assumption 2: You are picking a static solution

An RFP implies that you are looking for a software solution that will not change. You want to buy a done deal – something that you can install, turn on, and forget about.

In reality, even the best enterprise software solutions are constantly evolving. They have to in order to keep up with the rapidly changing needs of users and the rapidly changing technology landscape. The best enterprise software vendors are constantly innovating and releasing new features and functionality.

And remember: you will miss key requirements in the RFP. Therefore, in order to be successful, the solution you select must be flexible, if only to accommodate the inherent imperfection of the requirements gathering process.

Instead of thinking about a static solution, you should be identifying a partner and platform that can adapt when your own understanding of your needs changes.

Flawed assumption 3: A feature list can define the solution fit

In an RFP, you are essentially comparing feature lists. Yes, you will ask about customer references, support, security, and so on. But to compare functionality, you’re going to ask about a long list of features.

However a feature is not a solution. A feature is just a tool that might or might not be helpful in solving your specific problem.

The challenge is figuring out how all of the features fit together to provide an overall solution that meets your needs. This can be extremely difficult to do in an RFP, because you are not actually seeing the software in action. You are just reading about it.

The only way to really understand how well a solution fits is to see it in action and use it yourself. This is why trial programs are so important (more on that later).

Flawed assumption 4: You can evaluate user experience from a demo

A demo is not the same as using the software. In a demo, you are seeing a pre-planned, rehearsed, and polished presentation of the software. The vendor controls what you see and how you see it. They are carefully selected to show you only the very best parts of the software. Even when you think you have dictated the demo script to the vendor, it is the vendor that is ultimately constructing and driving the demo, not you.

In reality, enterprise software is complex. It is used by lots of different types of users for all sorts of different purposes. There are bound to be areas that are confusing or difficult. The only way to really understand the user experience is to try the software yourself in a real-world setting.

Flawed assumption 5: User experience shortfalls aren’t important

You made your product comparisons. You thought about information security. You considered vendor financial viability. You saw a great demo. You got pricing that you’re happy with. So you make your selection. And most surprising of all, implementation goes right on schedule and according to plan! Then you go live and… users revolt.

What happened?

In the last section I talked about not being to evaluate user experience from a demo. You might have read it and thought to yourself “So what if it’s a little clunky to use? If it does everything we need at the right price it will still be worth it.”

Here’s the thing: User experience shortfalls kill user acceptance, and low user acceptance kills IT projects.

Think about it this way: you can have the most technically perfect, feature-rich, and secure software in the world. But if people can’t figure out how to use it, or don’t like using it, they are not going to use it. And if they’re not using it, you’re not going to get any value from it.

User experience should be one of your top priorities when selecting enterprise software, not an afterthought. And user experience is impossible to evaluate in an RFP.

There is a better way to buy enterprise software

The good news is that there is a better way to buy enterprise software.

Step 1: Use short RFIs to reverse-engineer requirements and eliminate poor fits

An RFI (Request for Information) is a common first step in an RFP process. It is usually a short questionnaire that vendors fill out to provide information about their products.

You can use RFIs to do more than just gather information, though. You can also use them to help reverse-engineer your requirements.

Start by taking a close look at your current pain points. What processes are you trying to improve? What problems are you trying to solve? Then, translate those into broad requirements. Once you have a list of requirements, you can use RFIs to eliminate vendors that are obviously not a good fit.

For example, let’s say you have a requirement that the software must integrate with your existing CRM system. You can use an RFI to ask vendors if their software integrates with CRM systems, and if so, which ones. This will help you quickly eliminate any vendor that does not support your specific CRM system.

There’s a benefit on both sides: Vendors don’t have to fill out lengthy evaluations where they could have qualified themselves out in a couple of questions, and you don’t have to process long, complex responses where a critical mismatch is buried away in hundreds of questions.

Step 2: Run a lengthy trial program with simple user feedback

After you’ve used RFIs to eliminate the obviously poor fits, it’s time to start evaluating the remaining vendors. The best way to do this is with a trial program.

A trial program will give you a chance to try the software in a real-world setting and get feedback from actual users. To make sure you get meaningful feedback, make the trial long. “Long” will vary depending on specific solution you’re looking for – it could range from several weeks to several months, or even a full year if it needs to capture a full financial cycle. And be sure to include a meaningful cross-section of future users in major and minor roles, not just a handful of “power users”.

Throughout the trial program – not just at the end – ask each user to fill out a simple feedback form. NPS (Net Promoter Score) is a great option, but you can also use a short custom form with questions about specific pain points and whether or not they were addressed. Whatever form of feedback you use, make sure it is painless for the end user to provide and easy for the buying team to process – the most important thing is to gather feedback from as many people as possible, even if it’s basic.

Also, the trial isn’t just about you! You’re giving your prospective vendors the opportunity to work with you and develop a much deeper level of understanding of your needs than they could get by looking at a requirements document in an RFP.

Step 3: Identify a very small set of finalists for infosec and pricing evaluations

After you’ve collected feedback from the trial program, you should have a good idea of which vendors are the best fit. From there, you can identify a very small set of finalists to move on to the next stage of evaluation.

At this point, you’ll want to do a more thorough evaluation of information security and pricing. You should also have a much better idea of what you need, so you can make sure the finalist vendors are able to meet your specific requirements.

You’ll also get better responses from your vendors at this stage than you will by opening with a lengthy RFP! The remaining vendors will have a much clearer understanding of your needs thanks to the trial, and since they know they’re on the shortlist they will be willing to invest more time in thoroughly answering your questions and also putting their best foot forward on pricing.

Take the plunge

If you’re still using an RFP to buy enterprise software, it’s time to ditch it. The RFP process for enterprise software is broken. It just doesn’t work in this space. While RFPs not the only reason a majority of digital transformation projects fail, it definitely doesn’t help.

The good news is that by following the steps outlined above, you’ll be able to avoid the most common pitfalls of the RFP process and give yourself a much better chance of selecting best partner for your enterprise software needs. Give it a try on your next project!