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 can help lay the groundwork for an effective POC while avoiding common pitfalls, making for a smoother implementation of your spend management solution.
1Limit 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 organization to use 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 organization, assess how easily it can be customized or configured and make sure it can be deployed company-wide.
2Prepare use cases
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 and 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.
3Allocate adequate time
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 are testing not only the software but the vendor’s implementation and support services as well.
4 Define key performance indicators
Define 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.
5 Involve the right users in the evaluation process
Involve users who have enough time, knowledge and interest in your evaluation process. Make sure to incorporate their concerns and thereby facilitate the subsequent adoption by the end user community. Select POC users within each business unit that 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 in 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 and solidify requirements, enable best practices and set the stage for a successful implementation.