A question that keeps coming up in the procurement world is: What is the better technology strategy, investing in a broader suite (think source-to-pay) or a collection of specialist providers? This article is the first in a series examining the key considerations to make the best technology choices for your procurement organization. Today, we frame the decision.
Why “Best-of-Breed” is a Misnomer
Before we dive into that question, let me provide a side comment: Specialist providers are also commonly referred to as best-of-breed, but I don’t like that term. Just because a provider focuses on a narrower scope does not mean that it offers the best of anything. And by definition, it would mean there could only be one best-of-breed solution provider in any given space. Only one can be the best, right? So, I prefer the term “specialist provider,” meaning a vendor that specializes in one or a few areas.
Anyway, back to the question. What is best: a suite or a collection of specialist solutions? As you might expect, there is no single answer. Let’s look at both sides.
A Single Suite … for Everything
The theory is that a single suite provides a common UI that improves adoption, and, more importantly, a common data model without having to integrate different solutions. This means that contracts can automatically be populated with data from sourcing events and supplier profiles; supplier performance can be monitored and compared against contracts; sourcing events can be automatically triggered by a surge in demand/requisitions or a supply disruption; and so on. These are all fantastic capabilities, except for one problem: these examples don’t really work in larger and/or more complex organizations. There are simply too many different stakeholders with different needs and opinions for it to work seamlessly. Additionally, every suite has its stronger and weaker modules/functional areas. And, of course, there are too many weird little (or sometimes big) categories of spend that require very specific functionality or data to be managed efficiently.
The argument for a common UI is also a bit nebulous. First of all, you have to differentiate between UI (user interface) and UX (user experience). A common UI is fairly easy to achieve, relatively speaking, even if your suite is comprised of acquired solutions. A common UX is more relevant but much harder to achieve since it requires much more logic in how the solutions are designed and actually work (especially if the suite is a collection of acquired solutions and not natively-built). But at the end of the day, how many stakeholders do you have that work across multiple modules? Probably not as many as you think. And the ones who do are often power users, or at least more than just casual users, who are technically savvy and have few problems working with different solutions (so long as they are reasonably intuitive and designed, while solving the business problems at hand). As often stated, people are happy enough to use hundreds of different apps on their phones, so they clearly don’t mind different UX’s as a principle.
Sometimes, I hear the argument that a suite is cheaper than the corresponding collection of specialist solutions. This is by no means always true. And even if it is true (which should be the case with some rudimentary negotiation skills), it’s not a good argument. The focus must be on value. A heavily discounted module that isn’t fit for purpose and unused is still a lower value than a higher priced solution that is utilized and solves your business problem.
Specialist Solutions … for Everything
On the other end of the spectrum, the idea is that a focus on a narrower scope provides deeper solution functionality and more differentiating innovation. And by combining specialist solutions that are more focused, procurement teams are more likely to get solutions that meet end-user needs and solve business problems in a superior way. And as noted in last week’s article, you are likely to find specialist solutions for almost any need nowadays.
Another benefit is that specialist providers don’t have to worry about intra-suite integration and dependencies, and there is less risk that an entire functional area goes without attention and development for a significant amount of time. This means that, as long as you pick a certain provider for its core solution/use case, it will keep developing and improving the solution to make your processes even more efficient. That is until it’s acquired by another entity, at which point all bets are off.
Without any overall strategy, this is where many companies end up: Different stakeholders pick different solutions — sometimes with more or less the same functionality (you’d be surprised by the number of times the same customer logo appears on different solution providers’ customer slides). This might give you the best possible functionality but will be a nightmare to integrate and manage. Another common issue with this setup is that some users end up spending a lot of time pulling together data from different systems for reporting and presentations.
As you can see, there are potential issues with both approaches. If you look beyond most high-level marketing spiel, no one is really arguing for the extremes. Suite providers are offering app stores and partner networks that the specialist providers are often part of.
Stay tuned for the next couple of articles where we will dive deeper into the pros and cons of suites and specialist providers. And then wrap it up with an article on finding the right balance.
RELATED RESEARCH
Magnus Mondays: The Proliferation of Procurement Solutions
The Criteria for Selecting Spend Analysis Technology
CPO Rising Listicle: Five Reasons to Embrace New Technology
