Rethinking P2P Evaluations, Implementations and Extensions Over Chicken Wings

exclusive-design/Adobe Stock

Eating chicken wings between flights in an airport the other day, I stumbled into a conversation with a principal from a procure-to-pay (P2P) system integration firm called RiseNow. While that may sound fishy to you, the wings were actually garlic-parmesan, and the discussion turned out to be refreshingly candid, if not a little inspiring.

To say that most middle-to-large-market companies now understand the business case for spend management is probably fair, but clearly, issues remain. I say that because the market is littered with less-than-stellar P2P implementations, as determined by spend coverage and, in many cases, user adoption.

As it turned out, my dining buddy, Matt Stewart, is RiseNow’s managing partner. He minced no words in describing his firm’s approach as “old school”:

“We go right at the end user experience, as that is where many implementations/systems fail. Whether we get involved during the original evaluation process or even after the fact to address problems stemming from the original implementation, we start identifying the KPIs and business outcomes that matter most to the client that are typically not being achieved. We then assess if the issues are user and/or system related and deliver a comprehensive solution blueprint that outlines the path to achieve the desired outcomes and establishes a basis of accountability for all parties moving forward.”

This made sense to me, so I pushed a little further. Here are my notes from the discussion:

  • The selection process must be free of internal bias.
  • The client’s most challenging use cases must be identified and targeted for resolution.
  • Proof of concept around these same use cases (i.e., completed workflows) must be built and tested.
  • Integration points must be fully validated (i.e., load and response times).
  • A solution blueprint should be produced and be able to stand on its own — an effective map for any qualified third-party implementer.
  • Fixed-price, performance-based contracts where all project players have skin in the game, including the software provider, must be negotiated and attached to a framework for accountability.

Stewart’s overarching point was that the right solution choice has less to do with “what” a system can do (as claimed by the vendor) versus “how” it does it. This simple pivot strikes at the core of how modern software is sold. Despite what is generally said, getting the required workflows and user experience right are not simple matters of “configuration.” The idea that modern software has somehow obviated the need to understand the tradeoffs that every P2P option on the market presents, regardless of how much functionality they share, is simply incorrect.

Again, the point is that the configuration flexibility of modern software, even software as core as P2P, requires a project developer’s mindset. Back when “agile software development” was all the rage, implementation success could be traced directly to the quality of the spec — not a check-the-box RFP.

“Something old” is the first line of a rhyme that details what a bride should wear at her wedding. And the descriptor “old school,” as used by Vanilla Ice, is definitely not a flattering characterization. But an “old school” when used to convey an agile developer’s mindset, especially when applied to P2P, whether at the original evaluation and implementation stage, or in support of an system extension or improvement initiative, seems classic. And that definitely is a compliment.

Share on Procurious

Discuss this:

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.