This week on the Procuretech podcast, I’m joined by Source-to-Pay (S2P) and implementation specialist Joël Collin-Demers, all the way from Montreal.

Source-to-Pay today – Market trends, Roadmaps, and Best-of-Breed vs. Full Suite

Today we’ll be talking about the dynamics of the source-to-pay application market, how to craft a transformation roadmap in that space, and where we see this market going in the future. But before that, I ask Joël to introduce himself. Once he’s given us some fascinating insights into his favourite vegetable (it’s eggplant, if you were curious), Joël goes on to speak about his twelve years of experience in the procurement space. He started off his career working for IBM, working on implementing procurement modules. He then progressed to implementing for direct and indirect materials, and looking specifically at source-to-pay applications that sit on top of ERP. For the last three years he’s been running his own independent consultancy, addressing exactly the kind of issues we’ll be talking about today.

"Sauce"-to-Pay

Joël mentions the classic ‘pasta sauce’ metaphor for consumer choice: There was a time when there were only two or three kinds of pasta sauce on the shelf, and no-one felt bad about their decisions. Nowadays, breadth of choice creates option paralysis - it’s almost impossible to know if what you’re buying is really the best deal out there. I point out that twelve years ago (2010) would’ve been around the time that Ariba, Coupa, Jaggaer - all the big suites - were just starting to mature and come onto the market. I ask Joël to talk about what it was like at this time, when all-in-one suites were hugely in vogue. He mentions SAP purchasing Ariba in 2012. For a while they didn’t do anything with it, but over time they integrated. Adoption in the market for these big suites really didn’t begin until a little later, maybe 2015 - at least from what Joël saw in the Canadian market. Many providers in this time were trying to buy up smaller solutions so that they could offer full suites covering the full procurement process.

Developing bespoke applications in-house. Is it worth it?

I bring up contract management and SRM, along with newer concepts like KYS. Going back to Joël’s “pasta sauce” analogy. I put it to him that I actually make my own pasta sauce - which, jokes aside, leads me on to asking if there’s any sense to companies building their own SAP tool. Cearly this isn’t viable for mid market businesses, but at the enterprise level, does it pay off to build things from scratch. What are the pros and cons here? Joël says that sometimes you need to make your own pasta sauce - on the shelf solutions might not fit your exact needs. Despite this, he’s never quite seen anyone build out their own application, in his twelve years of experience. But what he does see, is large amounts of customisation, or enterprises building out their own little bits of functionality that a core suite may be lacking. He compares it to a pyramid. ERP is at the base, this connects to other functions, then you add applications for specific use cases to build on top of that, then you may go and get specific applications for one specific vertical. If you can’t find something cost-effective on the market, this is when it pays to build things yourself. I ask if this is still a viable strategy now. Looking at Ariba and Coupa, and their app stores full of best-of-breeds that can be easily integrated, does this diminish the case for building an in-house app? Joël thinks so. He expects to see a funnelling down of use-cases where building your own app will be a viable strategy. Niche spaces are being increasingly served. But then again, there are always gaps to fill. Niche apps are still being developed, and not every niche has been colonised just yet.

ERP, Data, and Single Source of Truth

I ask Joël if we still need all-in-one suites to provide a single source of truth. Is he seeing a move away from the suite-based approach, towards people using something like TealBook as somewhere to store their supplier data, contracts, and so forth, then P2P can be a separate tool that fits into that..? He says that he has started to see this, but it depends what kind of data you’re dealing with. The vendor master is important. Single source of truth needs to be thought of, as you craft a roadmap. But it also comes down to cost - what is the maturity of your organisation? How much spend do you have? All of these applications cost. Joël thinks that plugging in a large number of best of breeds is a perfect solution - if you don’t have financial constraints. But most companies do! If you’re making decisions from this position and having to make trade-offs, then data needs to be a priority. But you might choose to handle this in different ways depending on your specific needs. For example, if you only have a couple of thousand vendors, versus ten of thousands, you’re going to prioritise differently. You might choose to support an ERP vendor master data process with a smaller MDM suite. But you’re always going to have a tug and pull between ‘purist’, IT-driven applications, versus function-specific applications like TealBook. It’s an ongoing conversation within the business, and ultimately, this all comes back to cost.

How would Joël advise somebody making these decisions today?

I ask Joël what he’s seeing today - if someone came to him and asked for advice on full suite versus best of breed, how would he advise them? Joël says there are two aspects to consider here - how do you approach the market, and how do you ensure you know your own business? He explains that his answer would differ based on the business’s spend profile. If you’re 100% indirect and you don’t do any production, then that’s a different story to a business with a heavy lean towards manufacture and parts. It’s important to have a solid understanding of your ‘as is’. Make sure to go around the different functional teams and get a clear picture of your business. Potentially consider geographies, the different teams you may have, and be sure you’re addressing that in terms of spend. You want to address the big pieces, then craft your vision on an end-state. He advises asking yourself: What are we going to do for spend analysis? For sourcing? for procure-to-pay? For SRM? What are the constraints here? From there, you want to share that vision - go back to your stakeholders and get feedback on it. All of this is agnostic of technology. You’re really asking ‘what is important?’ and ‘what do we need?’. I bring up contract management as an example. There are loads of CLM products out there, but none of them seem to offer DocuSign or AdobeSign functionality for sign-offs. If this is something you think you’ll need, this is where you need integrations. Joël agrees that these are the things you’ll need to consider. How does this kind of functionality fit into your CLM strategy?. Are you using internal or external templates? You need answers to these questions, before you can fully craft a strategy. I summarise then, that if you want advanced CLM functionality, you’re going to have to look to a best-of-breed. Ultimately this is the difference between a “jack of all trades” and something that’s trying to be a world-beating solution to a very specific problem.

Let’s talk about sourcing

I ask Joël, in terms of the state of the market today, are the sourcing modules that come integrated out of the box with the bigger suites more focused on strategic sourcing and complex tenders, or more focused around tail spend and bringing operational sourcing into a single source of truth? Does it tend to skew one way, or does it depend on the solution? Joël says it very much depends on the solution - which is why it’s essential to consider your specific needs. Is your business more on the complex side, or not? What he sees in the market today, is that everyone is picking their own verticals and categories and choosing to specialise within a niche. Knowing your profile is essential before you go out looking for solutions. Joël comes back to his central point - that it’s crucial to have a technology-agnostic end state in mind. What do you want? What do you need? This is going to impact the functionality that you’re looking for. Where do you need deep functionality, and where can we live with functionality that’s more basic and out-of-the-box? Going to market, yes you can look at the Gartners of this world, but Joël feels their scope is quite small. He’d recommend going to places like Spend Matters, or indeed ProcurementSoftware.site and searching for the keywords in functionality that matter to you. Get a sense of what the best-of-breeds are offering in your space, educate yourself on the jargon specific to your niche needs, know what’s out there, then you can compare that to the functionality offered by your full suite options. You don’t need to see every application, but you’ll get quite a sense of what’s possible quickly and can then move from there. I thank Joël for his very in-depth answer and agree that ultimately knowledge is power. It pays to know what’s out there. Joël has an additional point about applications talking to each other. That’s an important issue that we may not be alerted to as procurement professionals: What other integration methods are there for this tool with other tools? What’s the degree of integration available? And functionally, how does it integrate - for example, can you align language used across tools? A system may be seemingly well integrated in terms of the technology, but if you and your stakeholders are having to use different words for the same things, it won’t feel very integrated at all.

Supplier Relationship Management (SRM)

I move us onto talking about SRM, and how this plays out for both best of breeds and full suites. I ask Joël to what extent he would recommend a full suite, or would a company working in highly regulated industries -for example, automotive or food and beverages - need a best of breed to manage their SRM needs. Joël thinks they’ll eventually come to the realisation that they need SRM. The consideration with SRM is that this is the base of everything else - having a strong supplier relationship model is critical. If you’re going to spend a lot of money on a vertical, this one has ramifications on everything else, so he’d strongly recommend that it’s worth the cost. If you don’t give thought to these use-case issues at the beginning then you can find yourself tied up in complications down the line and creating a lot of extra manual work. I agree that it’s a “necessary evil” to spend money on a best-of-breed, here. Joël goes on to give some further examples of areas where best of breeds are the way to go here. He brings up Stephany at TealBook’s analogy that this should work like contacts in your phone. You pick up a new phone (meaning application), you go on your contacts and everything gets uploaded automatically - that’s the dream for suppliers. However, this is never really the case. Each application handles suppliers differently - leading to manual work. So this is why having that data management piece in place can provide real value. Some applications will do this better than others. And flexibility in master data is hugely important, so it can change to fit your evolving application landscape.

Managing P2P outside of ERP

I ask Joël if he’s ever implemented for a client that manages P2P outside of their ERP system that then punches that back into whatever solution they’re using to pay invoices - bypassing something like SAP or Oracle completely, and having a stand-alone tool transfer data back to financial? Joël says that he has, and that the correct spend profile to fit is when your spend is 100% indirect. If you don’t have any materials or inventory management then you can look at this kind of setup. When you have any sort of inventory management, that’s when you need to look more closely, and when this kind of strategy doesn’t work so well. It’s not to say this couldn’t work - indeed, this is what Joël finds really interesting. Each business is different. As much as consultants seem to love saying “that depends”, sometimes it really does. Joël brings up the Dunning-Kruger effect - whereby people feel like experts after doing only minimal reading on a topic, but then the more they learn, the less qualified they feel. To be a true expert in a field, it’s going to take a while. We compare our own specialties - Joël in implementation, and myself in knowing the market at a holistic level. We wouldn’t be able to do each other’s jobs, and nor should we. Pressures of budget and timeline can lead us to overestimate what we’re able to digest. We feel like we (and our teams) can become experts overnight, but we should really plan for change to take a long time. Implement something once, take six months to let your users get used to it, then come back and - without re-implementing - optimise. It takes time to bring any change to full fruition, and all too often companies will replace a suite, or move on to a new solution, before they’ve truly given their first purchase time to properly imbed. These solutions are expensive and you should take time to wring all the value out of them that you can.

Time to implementation

Speaking of time, some applications boast implementation in a day, whereas I’ve heard stories of some big suites taking years. I ask Joël about his experience when it comes to implementation and time, and if this differs between suites and best-of-breeds. He says that when it comes to similar data requirements, you’re going to be looking at similar implementation times regardless of the application you choose. He comes back to his previous point on overestimating how quickly we adapt to change, and this is often the big factor when it comes to implementation time. He’s typically seen upstream modules like sourcing and contract management take around two to four months, as a realistic timeframe. But then there’s a long process after that of optimising - making sure everyone’s using it, and managing that change across each of your locations. P2P, he’s seen take even longer - often six to nine months, because it’s so complex in terms of vendor data. Integration is always the most complex step.

• What are you integrating into?
• Is there middleware?
• Should there be?

This is always where you’re going to run into the most complex questions, and require the most expertise when it comes to end-to-end data flow.

Wrapping things up

I draw this week’s visit to the procurement pub to a close, thank Joël for his time today.

Stay in touch!

• Connect with Joël Collin-Demers on LinkedIn
• Visit Pure Procurement website
• Download our Tech Map for Enterprise
• Download our Tech Map for Mid-Market
• Download our Tech Map for SMEs
• Find your perfect procurement tech solution in our Software Finder app
• Sign up for the Procurement Software Newsletter
• Book an Intro Call and let’s talk all things Digital Procurement!
• Connect with James on LinkedIn