1. Research, Demo, Benchmark
Research the market. Whether you decide to do this internally or bring in external eyes (consultancy), it’s important to know what’s out there. See something during your research that seems interesting to you? Good, request a demo.
You’re not going to know the true ability for a solution to add value until you see the solution in action. Demo environments allow you to start verbalizing your challenges and allows you to initially qualify if a solution provider has a solution to combat those challenges. You should be able to put your challenges in front of a ProcureTech provider, and they should be able to offer a solution to those challenges. Research gives you a snapshot of what is out there, but demos give you a snapshot of who is out there. Your evaluation criteria of a ProcureTech provider needs to go beyond the software/hardware, and take into account the people that are providing the tech. These are, when it’s all said and done, your possible future partners.
What did you see? Who did you speak to? What didn’t you see? Who didn’t you speak to? It’s likely that solution research & demonstrations will be delegated to various members of the team. This is why sharing information and benchmarking is important for understanding vendor capabilities, market gaps, opportunities, and commercial implications/required investments. Some elements you should benchmark solutions upon are:
- User Friendliness; UX/UI
- Potential value-added of the solution
- Overlap/Potentiality to save on the replacement of existing systems
- TCO of implementation and continued use
- Onboarding requirements from your team — what will the solution require in FTE to implement?
- Scalability — ability to integrate across applications
- Security — Servers and Data
This is, of course, an initial evaluation, but make sure that you have a high-level understanding of criteria you find important after leaving the first meetings. After benchmarking, you can likely count out a few actors, whilst others will quickly rise to the top of the pile. This is why it’s important to know what you’re looking for, and have a well-aligned team who can discuss debate, but ultimately come to an agreement.
2. Define Requirements & Communicate Them: RFx?
After benchmarking what the market has to offer, it’s time to start boiling down your team’s requirement list. This may be in preparation for a tender, or simply something you’d like to communicate to favorable vendors. One way or the other, the definition of requirements is key for realignment after the research, demonstrations and benchmarking phase. These activities could have brought your team further apart, rather than closer together. Not seeing eye-to-eye doesn’t have to be a negative thing. Strong opinions about what should be included (must-haves, should-haves, nice-to-haves) on a requirement list for a ProcureTech solution will result in a robust stakeholder perspective. While this may make the requirement list more difficult for vendors to meet with full compliance, it will help you to quickly sort out which vendors do and don’t have the functionality you and your team find to be necessary.
You gotta fight, for your right, to party! Now that you know what you want, you need to say it with your chest! Communicate your set of requirements to attractive vendors.
How you communicate your requirements is up to you. Run an RFx, or do something a little bit more ‘down-and-dirty’. This is something you may want to decide whilst creating your roadmap, so you can plan for the length of a full tender process. Again, this is why avoiding rigidity is important. Because, if you find a solution you want, and you know it’s the right fit, is a tender really worth the resources?
3. Shortlist & Test it!
Whether you decide upon running a full-blown tender, or a hybrid alternative to an RFx, you should always come out on the other side with a shortlist — AKA more than one alternative vendor. Keep things competitive with the solution providers you shortlist. I don’t need to tell you this, though. You’re a professional buyer. You know how to create negotiation power :))
Now, test it! Run a trial period, or engage the supplier to provide you and your team with a POC. While spending the resources on trying the solution yourself isn’t always necessary, seeing the solution in action, in line with your requirements, will make a future use case for you and your team all the more concrete.
It’s important to not just test the solution but put the solution to the test. It’s a rather standard procedure to ask for T&C, Technical Specifications, and possibly even subject the vendor to a security review. Again, this needs to be taken into consideration during roadmap creation as it will require resources from legal, IT & will likely take time.
4. Align & Decide
You came, you tried, you need to align.
Align within your team, and celebrate. You’re nearing the end of the decision making process. And, because you’ve taken the correct steps to get here, you’re not going to regret the solution you purchase.
Deciding upon the right vendor should be pretty simple if you’ve taken the proper steps previous to the decision-making stage, and have a robust set of evaluation material to base your selection upon. You’re a procurement professional, so I assume you have the whole Communicate, Negotiate, Terms & Agreement thing down, so I’ll spare you the details of entering/finalizing a contract agreement.
5. Implement & Adopt
You’re now in a post-contract phase. Feels good right?
It should! You’ve been thorough and have completed a purchase that will likely alter the future efficiency of your procurement organization. While this is a great accomplishment within itself, there is a good bit left in this purchase lifecycle…
Implementation & Adoption. AKA actually using what you bought. And, using it correctly. There are a lot of questions that need to be answered, and processes to be managed to ensure a successful implementation and adoption.
Let’s pluck the low-hanging fruit.
First and foremost, will you take an approach to evolution or big bang?
Whichever you choose, be realistic with the resources & FTE it will take from your team, external consultants and/or vendor implementation experts. “All key stakeholders and impacted parties need to have sufficient agreement and understanding of what successful implementation will look like and require, otherwise bottlenecks, delays, and apathy will inevitably occur” (Harrington 2018). Avoiding bottlenecks is easier said than done when implementing new solutions, especially if it requires team members to adjust their daily mode-of-operating.
Make sure that someone in the group of key stakeholders, or selection/steering committee, remains in an ownership role/project management role of the implementation. Own the solution you’ve been a part of purchasing, love it, use it, and get others excited about using it too!
It’s all too often that companies buy in new IT solutions and allow them to sit on the shelf like a can of beans. Even beans have an expiration date. If you don’t adopt the ProcureTech solutions that you buy, then your team will surely fall back on the tools that they relied upon pre-implementation.
Buying a ProcureTech solution requires your organization to spend money. But, actually using a ProcureTech solution requires time, energy, focus and most importantly — buying into change.