Establishing the need

We know what we have. And we don’t like it, hence we would like to change. But how to figure out what we need?

Get your team together and do a brainstorming. All ideas on Post-it notes, no judgment or comment. Some will duplicate, and some will be very expensive or impossible. Not your problem at the moment.

Then get them all on the board (or wall) and together split them into three categories:

Must have: If the feature is not there, you will not buy the software. No matter what.

Good to have: The team has to explain why this would make their work easier. You should see a measurable performance improvement.

Nice to have: Fancy things that we would like to have, but they will not significantly improve the day-to-day operations. Yes, it is nice to have an AI tool that will convert an email into a Purchase Request. But, does someone need to read either the email or the Purchase request?

To this, add the features your current system has. We do not want to skip something we did not put on the wall because we already have it.

Internal stakeholders

Before even starting discussions with the vendors, you have to get two main stakeholders on board: IT and finance

IT requirements

Step 1: Collect the current user data for your system:

• Number of users and their roles.
• Number of documents your current system creates.
• All procurement-related databases: approvers, item masters, location masters.

You will probably have to go through a big clean-up of this data. During the years vendors stopped doing business, some items became obsolete, and you closed a couple of clients. Things change. This clean-up will take a lot of time, so plan it into your project journey.

And then ask them to help with the technical questions:

• How will your new software communicate with other systems?
• What security protocols and rules must the system follow?
• Any other technical requirements the new software must adhere to?

IT must be with you in the room in the first couple of meetings. They are the ones signing off on the technical part of the offer.

Budget

Let us ensure we have a budget for this change. Nowadays, most of the software is subscription-based. So, there is an implementation cost and an annual subscription.

Ask for some basic budgetary numbers from the Software providers. The last thing you want is to go through a long exploration just to find out that there is no money in the budget for the purchase.

The steps of the procurement software RFI/RFP/RFQ

Step 1: Source vendors

There is so much information outside that filtering out vendors you want to invite for an RFI becomes challenging. An example is this report issued by Gartner. https://www.gartner.com/reviews/market/source-to-pay-suites

The goal here is to have at least 6–7 vendors that look like they can satisfy your requirements.

Step 2: Issue RFI

Once you reach out to the vendors, brace for a never-ending inflow of calls and meeting requests. I have met many salespersons in my life, but those guys are the worst. You will have an inbox full of invitations to speak at events or watch presentations at fancy places.

But your goal here is to get as much data about the software as possible.

• Can you choose the modules?
• Is there a limitation on the number of users?
• Does it cover all your must-haves and good-to-haves?
• Do they offer consulting services, helping you with change management?
• Will they assist in connecting their software to your other software systems?
• For how long will they support you during the go-live phase?

If a provider does not tick your minimal boxes, stop it right here. There is no compromise solution. Remember, you will have to live with this solution for at least five years. Do not settle if you are not 100% convinced.

Step 3: Refine your must-have / good-to-have / nice-to-have list

During this initial stage, you will learn about the different options available in the market. And some new functions will seem important, even if you did not think about them in the beginning.

This step could as well be called: stop and re-think.

Where do you see the company and the procurement function in five years? Will the software that you imagine be able to support the growth? Maybe there will be a strategic shift in the business, and you will need to adapt.

This is a good time to present the options to your C-level. Call it an exploration workshop. Present your findings and explain your thought process.

In one of the two cases I was involved, this step was skipped. The contract was signed. Once stakeholders started with their requirements, the management figured out that there was no way the software would ever be implemented. Firstly, a complete organizational change had to be done. So, the software implementation was scrapped.

Step 4: First demo

I will be very precise here:

“Do not let them run their fancy presentations!!!”

Period!

If you are buying a car, would you make your decision based on a fancy video, created in a controlled environment, performed by professional drivers? And taken many times, until it was perfect?

Of course not. You want to test drive it. Feel it, smell it.

Same with the software. Let them bring their demo version. or go to a company where the solution is already implemented.

In one case, I stood up and left the meeting when the sales guy tried (again) to put his presentation on the screen. Next time, he came with his full technical team. We figured out that the solution was lacking one of our must-haves.

Step 5: Initial RFP

Get the first pricing in, based on the information shared so far. Yes, it will change later. But at least you can see if it is close to the budget. Or you are wasting your time on something you can’t afford. Make sure they have provided the technical part as well. The basic information, so IT can have a look and be able to ask questions in the next step.

Step 6: Workshop—get the team involved

No matter how small the business you are, it is very unlikely that one person is doing the end-to-end procurement. So, bring in the people that do the job. They will ask more questions and challenge the vendor to go into the details of the solution.

Step 7: Shortlist

I would recommend doing the shortlisting using three criteria

• The feedback from the IT team:               
• compatibility with other systems in use,
• security challenges,
• support during implementation
• User feedback:
• practicality,
• covering all musts,
• Commercials-TCO:
• acquiring,
• subscription fee,
• upgrades,
• changes

Step 8: Get the IT sign-off

This is the technical sign-off. IT is the team that carries the most weight in the implementation. Whatever will not work later, will come to them. If they are not comfortable with the solution, do not push. If you want the particular software, try to find and resolve their challenges.

Step 9: Final negotiations

Hopefully, you have 2–3 options that all stakeholders signed off. Now it is the right time to push the negotiations button to the max. It is software, and the maintenance costs go down with the increase in the number of users. The sales guys will go significantly down just to add a couple more users. After all, your subscription represents re-occurring revenue for the next couple of years.

Step 10: Implementation — good luck!

I am yet to see a software implementation that went on time and within budget. No matter how much buffer you add, something will go wrong. Features we forgot to ask for, critical team members on leave, issues with data transfer.

On one hand, be ready to pull the plug if you see that the implementation is going nowhere. Maybe, after all, the software can not deliver what you understood it can. Perhaps it is incompatible with other systems.

On the other hand, stay positive. It is a journey. Not straightforward, with many ups and downs, but as long as you are going towards your goal, it’s fine.

Couple of warnings

In the end, a couple of things I have seen/heard about going wrong. And it is usually around the Company culture and the team.

Expecting the moon and the stars

Some stakeholders will expect that the new software will magically make all their problems go away. If there is no change in the process, new software can make it more efficient. But if your order needs three approvals as per the company policy, the new software will not make them go away. Especially, managers expect that the more efficient software will dramatically reduce the number of staff required. While the work hours will be reduced, it is not always so straightforward.

Too many chefs spoil the soup

In large companies, several employees do a very similar job for different regions or departments. But, somehow, rarely they do it in the same way. And then every one of them tries to present their way of executing tasks as the correct one.

Secondly, there will always be team members who will try to present a rare case happening in their area of responsibility as something very important that must be covered by the software.

Try to be as objective as possible and not to be dragged into power-play games. As always, I will refer back to the Pareto Principle: You shall aim to cover 80% of the needs of all stakeholders.

Time and change management

Even today:

• Fewer than 30% of software projects are completed successfully.
• 40% of software projects miss delivery dates.
• Poor project requirements gathering at the beginning of the project contributes to 37% of project failures.

We, procurement professionals, are by nature risk-averse. Here, however, we need to be bold and persistent in our requests.

Top 20 issues while implementing procurement software

As a proper risk-averse procurement Professional, I wanted to be on the safe side. Hence, to cover frequent problems that I have not had, I have asked our AI friend ChatGPT to give me the top 20 issues. Furthermore, I have run it a couple of times, and here is what he collected:

1. Lack of clarity on business requirements: Companies often struggle to define their specific procurement needs and objectives, resulting in difficulties in finding the right software solution.
2. Inadequate stakeholder involvement: Failure to involve key stakeholders from different departments, such as procurement, finance, and IT, can lead to a lack of buy-in and adoption challenges.
3. Integration complexities: Integrating the new procurement software with existing systems, such as ERP (Enterprise Resource Planning) or financial software, can be complex and time-consuming, causing delays and disruptions.
4. Data migration challenges: Migrating data from legacy systems to the new software can be a significant challenge, especially if the data is poorly structured or inconsistent.
5. Resistance to change: Employees may resist adopting the new software due to fear of job loss, unfamiliarity with technology, or a preference for existing processes, hindering successful implementation.
6. User interface and experience issues: If the software has a complex or unintuitive user interface, it can impede user adoption and productivity, leading to frustration and inefficiencies.
7. Insufficient training and support: Inadequate training and support for end-users can hinder their ability to effectively use the new software, resulting in underutilization and reduced ROI.
8. Limited scalability and flexibility: Some procurement software may lack scalability, making it challenging to accommodate business growth or adapt to changing needs and processes.
9. Budget constraints: Implementing a new procurement software can be costly, and companies may face budgetary constraints that limit their ability to invest in the necessary resources, infrastructure, and licenses.
10. Vendor selection and reliability: Selecting the right software vendor is crucial, as companies may face challenges related to vendor reliability, post-implementation support, or the lack of responsiveness to ongoing software updates and maintenance.
11. Inadequate customization capabilities: The software may not offer sufficient customization options to align with the company’s unique procurement processes and requirements.
12. Incomplete or inaccurate data: If the procurement software relies on incomplete or inaccurate data, it can lead to faulty decision-making and inefficiencies in the procurement process.
13. Security and data privacy concerns: Companies need to ensure that the procurement software complies with data protection regulations and offers robust security measures to safeguard sensitive information.
14. Performance and system stability issues: If the software is prone to performance issues, such as slow response times or system crashes, it can disrupt procurement operations and impact productivity.
15. Limited supplier management capabilities: The software may not adequately support supplier relationship management, leading to difficulties in supplier collaboration, performance tracking, and risk management.
16. Ineffective reporting and analytics: If the procurement software lacks comprehensive reporting and analytics capabilities, it can impede data-driven decision-making and hinder performance evaluation.
17. Lack of support for procurement best practices: Companies may find that the software does not align with industry best practices, making it challenging to optimize procurement processes and achieve desired outcomes.
18. Complex configuration and setup: Difficulties in configuring and setting up the software to meet specific business requirements can result in delays and frustration during the implementation phase.
19. Incompatibility with existing workflows: If the software does not seamlessly integrate with existing workflows, it can disrupt established processes and workflows, requiring significant adjustments and retraining.
20. Inadequate vendor documentation and resources: Insufficient documentation, user guides, and resources provided by the software vendor can impede effective implementation and user adoption.