What is a Good Foundation for S2P Tech?

A couple of weeks ago in our posts on What Elements Should You Be Looking For In A Platform (Part I and Part II) we outlined some of the key platform requirements we are looking for in the new Spend Matters SolutionMap (where Sourcing, SXM, Analytics, and the vast majority of Common Platform requirements were defined by the doctor) to give you a hint, but it’s a lot to take in.

And might be more than you need today when you just need to solve a few major pain points and advance on your S2P journey, especially if you still don’t have any dedicated modern technology or are still on Procurement 1.0 when most of your peers are on Procurement 2.0 and the leaders are starting on the Procurement 3.0 journey. (As per another recent post, while there’s a lot of talk about Procurement 4.0, we won’t see it for another 8 years based on history. 1.0 started around 97 with FreeMarkets and the emergence of stand-alone players. 2.0 started around 2007 with the first mini-suites [S2C or P2P]. 3.0 began around 2017 with the rise of the true [mega] S2P suites and integration that allowed for the pursuit of value where the whole is greater than the parts. 4.0 will began around 2027 based on the rate of historical development.)

But it’s not necessarily more than you will need in time. Especially if you want to reach the height of Procurement 3.0 with your peers when it materializes later next decade.

But we do recognize that you won’t need it all today. So what do you really need to look for in the first go-round? Especially if you can’t have it all or can’t become enough of an expert to evaluate it all?

While the most important capabilities do depend on the specifics of the technology you’re buying and the problem you need to solve, there are a few general capabilities that need to be there regardless, and these * capabilities in particular must be there in every solution you buy if you want to have any hope of “future-proofing” your platform.

  • Configurable Workflow
    Preferably with RPA support. Let’s face it, whatever process you use today won’t be the process you use tomorrow, especially as you mature in your processes and best practices, the partners you work with change, and governmental regulations continue to change the way you have to report.
  • Open / Extensible API
    that supports both 3rd parties integrating with your platform and the development of interfaces to integrate with third party platforms through their open API. Your platform will never do everything, no matter how much you want it to. It’s software, not sorcery. So the ability to extend it with ease is critical.
  • Dynamically Extensible Data Model
    that you can do, not a third party or the provider. Because you never know every piece of data you’re going to need until you need it.
  • Globalization Support
    including the ability for a user to select their language and overrides, the organizing to define new currency exchanges and projections, and IT to define where the application instances are hosted and where the data is stored (which may need to be segmented for a global organization)

This is not to say that other technical requirements are not important, but that without these, the life expectancy of your platform is limited, to say the least.