Don’t Throw Out the Beautiful P2P Baby with the Old Vendor Bathwater (Part 2)


In Part 1 of my two-part response to my colleague Jason Busch’s original piece, A Relationship That Should Never Have Happened: P2P (eProcurement and E-Invoicing), I argued that the demonstrated business value of integrated P2P is undeniable, and some of it is due to the fact that P2P is really part of a larger value proposition for S2P.

With that done, let’s now translate the business requirements to the technology supply market. Jason argues that “there is no single P2P market” and that since the market is so nascent, fragmented, and poorly served across various spend categories, that we should basically also keep procurement and payables separated in terms of how these groups buy technology (even though they are merging from an integrated process/performance management standpoint). In other words, Jason is “pre-lotting” the market basket of technology requirements (not a good idea as we’ve written about before) into smaller process siloed buckets.

One way to think of this is as a simple matrix of mega spend categories vs. P2P mega processes (i.e., buy and pay), as shown below. You can replace “buy” with “purchase” or “procure” if you prefer. Also, we won’t bring “source” into the equation here.

The mapping of business processes to technology/services supply markets is a one-to-many affair (i.e., there is no such thing as a simple MECE view of the market) and the smaller the market scope, the less healthy the market (except for niche “lifestyle” businesses that are able to build barriers to entry through unique IP and services). This is evidenced by numerous acquisitions and also providers expanding their scope. In P2P, Basware is a good example of e-invoicing creeping upstream to eProcurement, and conversely, Vinimaya and Wallmedian are examples of eProcurement firms moving more heavily downstream into EIPP (and Ariba obviously since supplier fees is “where the money is at”).

For example, the P2P business process is supported by multiple market segments, including a P2P standalone market that does in fact exist and also includes providers such as Verian, Bellwether, Vroozi, Inconto, SpendMap, and others (would be nice to see Concur and Rearden here). But, the process is also supported by other natural market segments (which we will feature in our upcoming provider almanac) such as Source-to-Pay, ERP, and Supplier Networks / Platforms. Also keep in mind that the general trend is towards suites, not away from them, and until a Procurement PaaS can come onto the scene with a strong ecosystem strategy, getting granular with your scope is swimming against the stream.

Finally, when you think about where to naturally “de-couple” your procurement applications, it tends to be between sourcing and P2P – not within the high-volume transaction-intensive P2P process where you need tight integration and where integration problems will kill you, especially if the data quality in your transactions are not “clean” (and that means >95% of folks out there). If you add in inventory management, such as in an MRO environment, all I can say is a big New Jersey “fuggetaboutit.” The three-way integration will kill you. Actually, with three systems, that is a minimum of six integrations, and when you get under the cover to the data model level, including master data integration, you will not be in happy land.

So, there are many choices out there, especially if you have an ERP backbone to bolt on to. But if you need P2P and don’t already have eProcurement and want an advanced e-invoicing platform that is from a vendor with no foreseeable eProcurement on its product roadmap, then you can follow Jason’s advice. So, if this about 5% of organizations out there, then Jason is at least 5% right. You can also do this if you don’t care about P2P and just need a good eProcurement-only solution (e.g., going with the re-skinning option of Simplifying IT, BuyerQuest, Cordis Solutions, etc. if you have an ERP system like SAP) or even someone like eRequestor or TrxLink. Or go with a BPO/ managed services provider to cobble all this stuff together.

Jason concludes that P2P is like the relationship between Chris Brown and Rihanna and that putting two superstars together doesn’t make sense. The funny thing is that his analogy adds the already plentiful nails in the coffin of his argument. Why? Because looking for eProcurement and e-invoicing separately is in fact looking for the superstars and hoping for a good marriage. If you think it’s worth the risk to try to hook them up and keep them together for the long-term, then have at it. And there’s nothing wrong with opening up your market basket to niche providers and their complementary solution provider partners (if they have any) – and making the decision after you really scope out the integration risk and business risk issues. But in the end, you’ll find that “the trend is your friend” and that you should indeed “skate to where the puck is going” – which is by following my advice.

So, to Jason, the ball is in your court. Game, set…

Voices (3)

  1. Gary Hare:

    Something to take into account with regard to this debate; size and global scope of the company. Speaking from experience, implementing a single platform for P and AP in a $50M, US-based manufacturing firm is a TOTALLY different reality than doing the same with a $10B multi-national corporation.

  2. Pierre:

    I would agree. But, for the 85% of firms who can’t get Finance to release their steely grip on AP (and who ‘play the separation of duties card’), you still need to at least manage it as a ‘mini-me’ end-to-end process (i.e., but be part of larger S2P process). Managing it as an end-to-end process means 1) defining it (per various buy-pay permutations) and 2) measuring it in a way that aligns P and AP to a balanced scorecard that has bi-directional KPIs (and SLAa). 1 and 2 will inevitably then lead to standardization of process, KPIs, and maybe even technology.

  3. b+t:

    I think the problem is political. AP should serve Procurement not vice versa.

Discuss this:

Your email address will not be published. Required fields are marked *