While my esteemed colleague at Spend Matters might believe that you can’t “date” where e-Procurement is involved (as per “Don’t Test Drive e-Procurement, Make the Right Decision First”, I have to disagree. You see, e-Procurement, like e-Sourcing, is a multi-step process that doesn’t conclude until you seal-the-deal.
You see, despite the continually propagated misconception that e-Procurement, EIPP (Electronic Invoice Presentation and Payment), and P2P (Procure-to-Pay) are essentially the same thing, nothing could be further from truth.
By definition, the only requirements for a P2P system is that it permit e-Procurement, possibly through a (n integrated) third-party (e-Procurement) platform that permits electronic ordering, and that it permit payment approval, possibly through a(n integrated) third-party (e-Payment) platform. A P2P “solution” could be as simple as a “punch-out” to a supplier catalogue and “punch-in” to your accounts payable system, allowing accounts payable to process the returned invoice and pay it (through e-banking) as soon as you indicate the goods have been received.
Similarly, by definition, the requirements for an EIPP system are just as weak. As long as the system enables suppliers to submit electronic invoices, procurement to review them, accounts payable to process them for payment, and integrates with one or more e-Payment mechanisms, it’s an EIPP “solution”.
On the other hand, e-Procurement must enable each and every phase of the (up to) 9-step procurement process:
- Requisition:
The e-Procurement system must make it easy to create requisitions. This means that it must support up-to-date catalogs and punch-outs and should support virtual supplier networks and B2B 3.0 enterprise search capabilities that allow users to requisition what they need, when they need it, on the appropriate contract. - Authorization:
It must support and require authorizations when a volume limit or dollar amount is exceeded or when a requisition is off contract. The workflow should be customizable to the organization’s approval process. - Purchase Order:
It must support the automatic creation of purchase orders off of approved requisitions. - Receipt of Goods:
It must capture good receipts. - Invoice:
It must allow for suppliers to submit electronic invoices using EDI, XML, or web-based forms. - Reconciliation:
It must support multi-way matching between the contract, requisition, purchase order, goods receipt and invoice and insure that the organization only pays for delivered items at contract prices. - Payment:
It must support payment authorizations and integration with one or more payment systems. - Tax Reclamation:
It must capture the data necessary for finance to reclaim tax payments. - Analysis:
It must enable export of the data in standard formats for spend analysis.
And, most importantly, it must be:
- easy to use:
User adoption is the single most important factor when it comes to e-Procurement Success. - easy to administer:
If you can’t keep the platform up-to-date, it will be abandoned. - easy to change:
If workflows, processes, supplier data formats, or related supply chain systems change, it must be able to support these changes.
And this is why you need a test drive.
Brochures, demos, and sales assurances can’t tell you if it’s easy for your buyers to use. And these deomos certainly won’t uncover the limitations and hiccups of the administration process. And unless you can see the APIs and run your own integration test, you’ll never know if you’ll be able to properly integrate it with your current system(s) or not.
Furthermore, an e-Procurement test drive needn’t be rolled out to the whole organization. It can be limited to a small control group of buyers, and organizational users, who would be most impacted by its implementation. Only if it looks promising would the “test drive” need to be extended to additional users. While an e-Procurement system might touch a significant number of users, only a small percentage will be using it regularly. Think about it. How often does Paul Programmer order new machines? Sam Secretary restock the office supplies cabinet? Sally Salesman replace her cell-phone? You only need a few of these users to gauge usability and impact.
Furthermore, if integration with your current payment system is critical, you can have IT, or your third party integrator, dive into the APIs and evaluate the complexity and expected time-frame of integration while you test-drive. And if the configuration and integration requirements are significant, as my colleague suggests they will be, I suggest you say “No Thanks” and move on. With so many EDI and XML standards to choose from, and so many new on-demand and SaaS solutions supporting standards out-of-the-box, if it’s not an easy configuration, then the vendor is behind the times.
Similarly, if the education requirements for basic use require more than an hour of training, keep looking. With the advancements in usability made over the past 10 years, and the fact that everyone is familiar with standard office software, Web 2.0 applications, visual workflows, and multi-media “on-demand” training, your e-Sourcing and e-Procurement applications should almost drive themselves where standard tasks are involved.
Finally, if the primary benefits of the new process enabled by the new solution aren’t obvious, I’d ask if they were there in the first place. We’re a tech-savvy generation who want to use well-designed software solutions because we’re tired of poorly designed clunkers that impede us. If the primary benefits aren’t clear, the system isn’t yet mature.
And you’ll never know the integration complexity, education requirements, or design usability without a walk-through. While it’s easy to fashion a good looking demo (and vendors excel at this), it’s much harder to control a user “test-drive” — and this is where the truth comes out.
So, while if this were 1999 (and maybe even 2004) where e-Procurement systems were on-site, clunky, and required more training and integration than grandpa could shake his stick at, I might agree with my fellow blogger, but this is 2009 and we’re on-demand, streamlined, and self-explanatory. This says that taking a software test-drive should be easier and less committal than test-driving the new vehicle on your automotive dealer’s lot.
The simple truth of the situation is this: you can’t figure out if a software solution is right for you until you use it. So take that test-drive. As long as it’s well designed, well planned, and suitably controlled, you can’t lose.