Daily Archives: April 7, 2009

There’s Nothing More Important Than A Good “Test Drive” — Even in e-Procurement!

While my esteemed colleague might believe that you can’t “date” where e-Procurement is involved, 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.

A Handy Guide to the Eight Biggest Mistakes in (Procurement) Outsourcing

Global Services recently published a great piece on the eight worst mistakes in outsourcing and how to avoid them that should not be overlooked if you are outsourcing or considering outsourcing one or more business functions (in your supply chain). These mistakes are all too common — and they don’t need to be, especially since they can be prevented up front.

  1. Poor Governance
    A formal governance model, backed by executive sponsorship, is absolutely critical to success. Without a model, which must clearly define the objectives, a collaborative working model, SLAs, and a dispute resolution process, there’s nothing to stop the outsourcer from doing whatever they want, which includes doing nothing at all!
  2. Shortsighted Focus on Cost Savings
    This leads to unrealistic expectations for year over year savings. Done right, outsourcing will save you money, but the savings will not increase continually. If you’re 80% efficient, then you’ll get 20% savings … and that’s it. But that’s still better than what the function is costing you now. The real benefits come in the form of process efficiency, improved planning ability, higher levels of operational reliability, and the ability to divert focus to core business areas where strategic improvements can lead to significant savings.
  3. Lack of Preparation
    Starting the RFP and contract negotiation process before an outsourcing decision has been thoroughly evaluated internally is the wrong way to go about it. First you analyze the cost / benefits thoroughly, then you outline the governance and model, then you evaluate the vendors, then you start negotiations with the preferred vendors.
  4. Outsourcing High-Touch Activities
    Not all processes are ideal for outsourcing. Processes with high business value that you are effective at should be kept in house. Processes that require continual contact with stakeholders are also not good candidates for outsourcing.
  5. Failure to develop an Effective Communication Program
    Poor communication is often the top reason cited for failure of an outsourcing project. Regular information sharing is essential and needs to be addressed up front.
  6. Improper Evaluation of Outsourcing Providers
    Outsourcing is not an instant solution and proper evaluation of providers is crucial. Choosing the wrong solution provider will give you sub-optimal returns at best, and can lead to the outsourcer abandoning the engagement, leaving you high and dry.
  7. Poor Cultural Fit
    At the end of the day, an outsourcing relationship works best when the chemistry between outsourcer and service provider is right. If the evaluation and negotiation process leads you to believe that the working relationship will not be a comfortable one for your people, immediately call off negotiations and move on to the next provider.
  8. Inappropriate Metrics and SLAs
    For example, call throughput is a bad metric. It’s not how many calls a rep takes in a day, but how many issues get resolved in a day.