Use “Use Cases” to Evaluate Procurement Software

Making procurement click at most companies involves handling the req to check process as easily as possible. That’s why @ Coupa we’ve spent so much time with our initial releases trying to get the usability “right”. But beyond drag-n-drop, streamlining, and consumerizing the application, procurement flows must recognize the nuances of “what” an individual is trying to buy.

A 1-time engineer-to-order part is a lot different than a PDA. And a complex services buy is another thing entirely. So you can learn a lot in your eProcurement software evaluation by shrugging off the abstractions and going with your actual use cases to see how the software “fits” your business.

[One thing you learn, as a software vendor, is how the whole idea of verticalizing Procurement software is a fallacy. The use cases dictate software functionality, and those use cases can and do cross industry verticals in unexpected ways. Said another way, once you’ve handled Simple Fixed Price Services, you’ve handled it, regardless of whether it will be used in Public Sector or Aerospace. Now on the margins you can find exceptions where truly vertical functionality creeps in. And certainly Direct Materials Procurement should be treated as a special and important case. But at the core much of Procurement is a horizontal application category. ]

So my recommendation is to not get caught up in an exhaustive feature-function list in your next evaluation – instead stick to flows that keep the context of what you are trying to achieve. Build up your use cases on what you’ve bought in the past — and if that’s not available take your best guess. Buy a lot of complex services with SOW’s you want to track through payment? Ask your prospective vendor how their software can handle that flow.

Sticking to category use cases gives your vendor the ability to meet your requirements without being straight-jacketed. And using them can make sure you hit the targets you are signing up for with the project.

Good luck!