As I settle into my new role here at Spend Matters, I am struggling to prioritize where to focus my efforts first – especially because there are so many interesting areas! But since one of my main goals is to help build a deeper practitioner-focused set of research, I will start with the practitioners and what they have found most valuable in discussions with me. I am continually amazed that even the most supposedly advanced organizations struggle with making good choices regarding their procurement solution providers.
Usually, they are like Kevin Costner's golf pro character in Tin Cup, when he is found in a sorry state with various swing aid contraptions bolted onto his body. They wisely (in the short-term) select best-of-breed vendors to deliver quick-hit ROI rather than delay value delivery because of a long ERP rollout cycles. Yet, over time, they end up constructing a procurement applications 'Tower of Babel' that becomes increasingly untenable. It reminds me of Car Talk's Ray Maggliozi in an episode where he discusses the Weber-Fechner law of just-noticeable differences, and used the boiling frog analogy to explain it. With procurement technology, sometimes we have a bunch of dead frogs to deal with.
So, to unwind the problem and help the clients find a pathway forward, one of the key success factors is to help them think through what effective procurement information architecture looks like. I use the term "information architecture" rather than technology architecture, because it is not so much about low-level technical infrastructure – nor about having superficial functionality-checkbox discussions about best-of-breed vendor X versus ERP vendor Y in process area Z (sourcing, contract management, buying, paying, etc.). Rather, it is about creating an environment where different solutions approaches, application types, vendor types, and yes, named vendors can be interchanged more easily within a more coherent framework.
It's a thorny problem. For example, take scorecards/dashboards, whether for procurement or suppliers. It's highly dependent on analytics, but also involves the workflow regarding picking KPIs, setting targets, linking dynamically to master data, etc. And even analytics are a broad spectrum of techniques and tools that go way beyond data warehouse, cubes, and dice-n-slice OLAP. Or take supplier portals or internal portals. How do you define a 'portal'? And for the variation in semantics that users have on these topics, the vendors impart even more as they position themselves - see my Star Trek-metaphor ridden coverage of this on Spend Matters PRO: The Trouble With Tribbles and the Problem with Portals and The Trouble With Tribbles and the Problem with Portals (Part 2).
Unfortunately, this is not a competency that most organizations possess. This has been one of the core capabilities that I have tried to develop and impart with my clients over the years. It is also something that I will cover more deeply on Spend Matters PRO, regarding designing a world-class procurement information architecture (pardon the 'world class' term – I can't help myself). We will try to be as precise as possible regarding the terminology that we use. For example, besides 'portals', think about the terms 'suites', or 'architecture', 'composite applications' or the most ubiquitous term of them all: 'platform' (IT industry analysts have ranted on this last one for eons). Anyway, I think two of Jason's best posts dealt with aspects of this topic in terms of SOA and also in terms of the requirements of what such a next-generation procurement suite (and related organizational capabilities) looks like.
So, I will pick up where Jason left off and a lead the development of a multi-part series on procurement information architecture. But we at Spend Matters can't do it alone, and although these are very practitioner focused frameworks and insights, the procurement technology and services vendors (and other enablers such as open standards) will be part of the 'design team' (and general contractors) for such a new class of such solutions. They will clearly be part of the discussion, and we hope to bring them in and highlight the interesting ones who are the pacesetters in not just being 'cool tools', but also cool (aka effective) approaches that make the tools work better and ensure you're picking the right tools for the job over the long term.
What do you think? Is it time to transcend the feature-function wars and start looking at the bigger picture? We'd love to hear your feedback!