7 Things to Consider Before Implementing Procurement SaaS
- All Industries
What is SaaS?
When you decide to deploy a SaaS solution for procurement, you are choosing the provider of a service. You don’t choose any of the server, storage, or networking specifics, and you don’t choose an operating system, or even a language to develop new tools in. Rather, you get an application, such as eProcurement or Supply Chain Management. However, you can choose the specific settings in the application, the design of templates etc. For example, you would set up your own RFP forms based on your desired criteria and parameters. In addition, the implementation will involve some internal integrations with third-party systems such as ERP, and possibly with some external systems too. One size does not fit all and therefore the delivery of a SaaS solution can take some time, though it is a lot faster than developing a solution from scratch.
The services are then delivered over “the cloud” i.e. SaaS uses the internet as a medium to deliver resources, rather like the power grid delivers electricity.
The Benefits of Saas in Procurement
There are several major benefits of SaaS in procurement, including:
The key reason why procurement teams are selecting SaaS solutions is due to their low cost when compared to the on-premise counterparts (no hardware, installation or maintenance costs, less reliance on internal IT). Lower upfront costs mean quick ROI.
Procurement departments work directly with the vendor’s service team to deliver the solution. As mentioned, there is still some work to be done, such as third-party and internal integrations so that they can share the required data.
With SaaS you have an opportunity to test-drive the solution before you decide to invest in it. “Try before you buy” is a significant advantage; this helps you test various possible situations and find out if it meets your organization’s needs.
Unlike an on-premise solution, with SaaS the cost of scaling up is much lower and can be easily controlled: you can have as much additional processing power and storage capacity as required without having to worry about additional equipment.
Security was once an objection to SaaS solutions. Organizations felt more comfortable having data in-house. But today, the organizations providing platform services for SaaS providers, and the SaaS providers themselves, offer physical security and data protection that is at least as good and, in many ways, better than any on-premise installation.
Considerations for Saas implementation and deployment
That said, there are a few things you should consider when implementing and deploying SaaS for procurement to ensure that everything goes as smoothly as possible and you capture the generic benefits outlined above and the specific benefits of the procurement applications.
Involve all stakeholders
In the past, procurement would go to the CTO or CIO and request a software development project. Today, investing in technology is no longer a job for the IT department alone. This is a good thing, because digitalization presents an opportunity not merely to digitize documents and manual processes, but to transform procurement, making it many times more efficient for the business. But to capture this opportunity you must involve all stakeholders: IT, procurement and the wider business (e.g. operational departments). Involving all of the affected stakeholders early on and throughout the project will ensure a high level of user acceptance and adoption.
Agree on the project methodology
There are two basic approaches to implementing and deploying a SaaS solution: waterfall and agile. Without going into detail, waterfall is a more “linear” process whereas agile is more “iterative”. Agile is generally more suited to SaaS because it allows you to make quick wins. And if things do go wrong, you “fail fast” and can take a different course without being too heavily invested. A “Lighthouse Project” further reduces risk: you limit the initial project (e.g. geographically) and then roll it out. The scalability of SaaS makes this easy.
Nevertheless, with a purely agile approach there is a risk that objectives, costs and implementation periods will be unclear, which is why the next considerations are important.
Agree clearly defined objectives
Many projects fail before they even begin for one simple reason: failure to define project objectives clearly. Only when the stakeholders and implementation team understand and agree a clear set of project objectives can they align their efforts effectively. So, although it may seem like stating the obvious, you must set out what you expect to get out of the new solution, i.e. the specific outcomes and benefits. Without these there is a high risk of “project drift” as intentions are unclear or become fluid to the frustration of some or all stakeholders and team members. This can easily happen if stakeholders have different priorities or bring new requirements in the course of the project.
Start with best practices
Select a vendor with a proven track record of delivering successful solutions. A SaaS implementation then never starts from scratch. The vendor should implement a “Minimum Viable Product” (MVP) based on past best practices. It won’t give you everything you want, and it won’t meet all of the objectives you set out; but it will probably deliver 60-70% of what you are looking for and, most importantly, will do so very rapidly. It is not unreasonable to get an MVP up and running within 30 days.
Implement the remaining features in “sprints”
So, you have got your MVP up and running. Get all of the stakeholder representatives together and review it. Get the end-users to try it out. What do they like and not like? What is missing? Prioritize what you need next. The implementation team will work on this for the next week and report back again. In agile SaaS delivery, this is known as a “sprint”. A series of these sprints will progressively move you from MVP to final product.
The team should assess progress throughout the implementation cycle by reviewing the deliverables and priorities at the end of each sprint review. Also, at the end of the project, it’s important to evaluate the project as a whole. The implementation team and key stakeholders should host a meeting to discuss what went wrong, what went right, and why, to ensure that the next project will have a solid foundation for quality improvement. It is also a good approach to bring an external reviewer in to solicit feedback about the implementation process and user satisfaction with the final product. This way you will get an honest and productive appraisal of the team’s professionalism, project leadership, user acceptance and quality of output.
Appoint a power user
So, your system is up and running. The vendor should help with user training. But what of the future? Where should users turn if they have any queries? Who is the go-to person if things are not working properly? Who should be responsible for taking suggestions for improvements and communicating them to the vendor? Appoint a power user. You should think about this early on. It should be someone within the procurement function who is technically competent and who was involved in the project implementation.