News


5 principles of successful Spend Management solution Proof-Of-Concept


A Spend Management solution proof of concept (POC) brings a vendor’s product in-house to ensure that it will work in your Procurement environment and function the way it was promoted.

Whether you’re looking to implement a full spend management suite or a 1-module solution, developing a POC may provide you with an opportunity to solicit internal feedback about the software’s capabilities, while reducing unnecessary risk and exposure and providing the opportunity for users to assess functional and design choices early on in the deployment cycle. It may also help the software vendor to identify potential technical and functional issues that might interfere with success.

The success factors outlined below are based on Ivalua’s extensive experience of developing a winning POC, they will not only help you lay the groundwork for an effective POC but also avoid common pitfalls of POC projects, making for a smoother implementation of your spend management solution.

  • Limit the POC scope to a manageable size. POCs are good for proving one or two concepts but they do not take the place of an implementation. In fact, they delay implementation.
    The POC provides an opportunity for your Procurement organisation to utilize the solution within your business environment, using your own data. Limiting the POC scope to a manageable size (in terms of volume of data, functionality and individuals involved) allows the project team to complete a sufficient number of operations to determine whether the software is appropriate for use by your procurement organisation, assess how easily it can be customized or configured and make sure it can be deployed company-wide.
  • Prepare use cases that reflect your desired end-state solution and your own procurement processes. Do not ask the vendor to run a POC based on their out-of-the-box scenario.
    A POC requires an effort on your part to design your own use cases based on process flows you are familiar with. Use cases should describe a particular use case scenario of the system by a user
    Use cases shall describe the process flows through your spend management solution based on its most likely use, do not spend too much time on exceptions and hypothetical situations.
  • Allocate adequate time in the POC period to allow the vendor to react to feedback and make adjustments. A POC is not simply a chance to get a hands-on feel of the system but is also a chance to see how the vendor reacts to the adjustments you will inevitably request during initial implementation. You are testing not only the software but the vendor’s implementation and support services as well.
  • Define S.M.A.R.T key performance indicators, that are agreed by both parties and enable you to gain confidence before you commit to subscription costs. Carefully crafted requirements, scope, goals and objectives will make your pilot project evaluation an easier task to accomplish.
  • Involve the right users into the evaluation process, those who have enough time, knowledge and interest. Make sure you incorporate their concerns and thereby facilitate the subsequent adoption by the end user community and set the tone for a successful implementation by selecting POC users within each Business Unit which will be using the chosen solution whether they’re from the Procurement department or not.

A Spend Management software POC is often the first step towards a successful implementation. As such, it should not be used as part of the evaluation process, but rather to develop a deeper understanding of both the product and the company, and ultimately reduce business risk. It will educate users on requirements, solidify requirement, enable best practices and set the stage for a successful implementation.