Implementing Software as a Service (SaaS) is just the same as implementing an on-premise procurement solution, right? Same software vendor, same functionality, same look and feel – just a different pricing model with someone else hosting it? Well, actually, not really. It requires a different mindset, a different approach, and, oftentimes, different people.
This article highlights the main difference in SaaS Procurement applications and explores the implications for implementing it effectively. Having worked with a number of companies over the last few years of SaaS (as well as with companies still implementing on-premise solutions), we’ve seen those that do it well and those that struggle to adjust.
Until a few years ago, business technology seemed to lag behind the consumer experience – the elusive “Amazon” experience. One of the main reasons was software vendors’ long development cycles, followed by long testing and then by long upgrade projects (once the business had sold the case for an upgrade to its management). This all equals an online business experience that is several years behind the consumer one.
Here’s where SaaS comes in. SaaS is software hosted by the software vendor in the cloud, accessed simply through a web browser without the need for local client installation or IT infrastructure to run the application or store its data. Think of it as outsourcing your business system, as well as its delivery, development, and maintenance.
Key to this is the fact that true SaaS is multi-tenant, meaning that there is only one code base or version of the system across all companies using it, with each company’s data partitioned. This means that it is quicker and easier to update and is therefore far more up-to-date and responsive to users’ requirements and demands; it’s in step with the consumer experience. Along with different pricing and a lower cost of ownership, this goes some way to explaining the rise in the number of companies using SaaS at around $10 billion in 2010 with an expectation from Gartner that this will double to over $21 billion by 2015.
SaaS is fresher, quicker to roll out, and more cost effective. But the one code base has some significant implications on how you implement it effectively. Applying the same mentality and principles as a few years ago may well result in failure (we know of two large organisations learning the hard way). So here are some key pointers that hopefully will help you succeed:
1. Recognise that SaaS is different. You must accept this first and foremost! We just about remember the ERP days when people would walk into a workshop with a roll of brown paper, a load of Post-its, and some markers and spend days or weeks drawing out how they want things to work.
SaaS means you don’t need to do this. You can configure it to your organisation’s requirements, but the processes and functionality are relatively fixed. They have been built to reflect best practices and while they may not fit your processes 100%, they probably fit 90%. And if they don’t, then it is probably worth thinking about your business processes.
This should free up significant time to focus on the things that matter in procurement projects (change management), rather than having your head buried in Visio.
The most successful organisations walk into those initial workshops and tell everyone: “This is how it’s going to work; tell me why it can’t.” OK, perhaps it’s a little softer than that. There’s still some gap analysis work to be done, but you have your solution and your future state, not a blank sheet of paper. Don’t dilute that benefit by over-engineering your processes or spending too much time on things that don’t deliver value. It is entirely possible to have a basic, working solution up for people to see within a week.
2. Pick the right resources. This is a procurement project – not an IT one. So, you don’t need IT involved in your implementation nearly as much as you used to – and IT certainly should not be managing the project. You’ll likely need IT support to confirm security, data, and integration set-up, but configuration, testing, and training should be managed by business resources, ideally from within procurement. This also helps change management, ensuring that business objectives are met and the correct messaging is communicated to increase adoption of your new system.
3. Changes can be made quickly. With update cycles as regular as once a quarter with many vendors, if something really doesn’t work for your company, you have a good chance of feeding this back and seeing it actioned far sooner than with an on-premise solution. These regular changes also add another dimension that needs to be considered. User acceptance testing and regression testing are not a one-off activity. Ensure you’ve got the right people regularly looking at new feature releases and making sure they work for your company.
4. Don’t be complacent about training and testing. Implementing SaaS tends to be an easier process than on-premise but you must remember the basics. Thorough testing is still key, particularly if you’re integrating with other systems. Likewise with training, yes, your new system might be simple to use but your staff still need to be trained to make the best use of it. Training is a great change management vehicle also, reaching the wider community with the message of why e-Procurement is important and helping adoption of the new system.
5. Think about your support model. As discussed above, while the software vendor takes away a lot of the support requirements you would usually need from internal IT, you do still need some internal support. This includes a first line support desk for general “how do I…” type questions, as well as a small team of super users who can tweak configuration settings and set up new users or suppliers, for example.
As a consultancy implementing both SaaS and on-premise, SaaS has certainly revolutionised the way we interact with our customers. It has freed us up to do more procurement work and less IT. We think there’s no reason it shouldn’t be exactly the same for our customers.
Implementing Software as a Service (SaaS) is just the same as implementing an on-premise procurement solution, right? Same software vendor, same functionality, same look and feel – just a different pricing model with someone else hosting it? Well, actually, not really. It requires a different mindset, a different approach, and, oftentimes, different people.
This article highlights the main difference in SaaS Procurement applications and explores the implications for implementing it effectively. Having worked with a number of companies over the last few years of SaaS (as well as with companies still implementing on-premise solutions), we’ve seen those that do it well and those that struggle to adjust.
Until a few years ago, business technology seemed to lag behind the consumer experience – the elusive “Amazon” experience. One of the main reasons was software vendors’ long development cycles, followed by long testing and then by long upgrade projects (once the business had sold the case for an upgrade to its management). This all equals an online business experience that is several years behind the consumer one.
Here’s where SaaS comes in. SaaS is software hosted by the software vendor in the cloud, accessed simply through a web browser without the need for local client installation or IT infrastructure to run the application or store its data. Think of it as outsourcing your business system, as well as its delivery, development, and maintenance.
Key to this is the fact that true SaaS is multi-tenant, meaning that there is only one code base or version of the system across all companies using it, with each company’s data partitioned. This means that it is quicker and easier to update and is therefore far more up-to-date and responsive to users’ requirements and demands; it’s in step with the consumer experience. Along with different pricing and a lower cost of ownership, this goes some way to explaining the rise in the number of companies using SaaS at around $10 billion in 2010 with an expectation from Gartner that this will double to over $21 billion by 2015.
SaaS is fresher, quicker to roll out, and more cost effective. But the one code base has some significant implications on how you implement it effectively. Applying the same mentality and principles as a few years ago may well result in failure (we know of two large organisations learning the hard way). So here are some key pointers that hopefully will help you succeed:
1. Recognise that SaaS is different. You must accept this first and foremost! We just about remember the ERP days when people would walk into a workshop with a roll of brown paper, a load of Post-its, and some markers and spend days or weeks drawing out how they want things to work.
SaaS means you don’t need to do this. You can configure it to your organisation’s requirements, but the processes and functionality are relatively fixed. They have been built to reflect best practices and while they may not fit your processes 100%, they probably fit 90%. And if they don’t, then it is probably worth thinking about your business processes.
This should free up significant time to focus on the things that matter in procurement projects (change management), rather than having your head buried in Visio.
The most successful organisations walk into those initial workshops and tell everyone: “This is how it’s going to work; tell me why it can’t.” OK, perhaps it’s a little softer than that. There’s still some gap analysis work to be done, but you have your solution and your future state, not a blank sheet of paper. Don’t dilute that benefit by over-engineering your processes or spending too much time on things that don’t deliver value. It is entirely possible to have a basic, working solution up for people to see within a week.
2. Pick the right resources. This is a procurement project – not an IT one. So, you don’t need IT involved in your implementation nearly as much as you used to – and IT certainly should not be managing the project. You’ll likely need IT support to confirm security, data, and integration set-up, but configuration, testing, and training should be managed by business resources, ideally from within procurement. This also helps change management, ensuring that business objectives are met and the correct messaging is communicated to increase adoption of your new system.
3. Changes can be made quickly. With update cycles as regular as once a quarter with many vendors, if something really doesn’t work for your company, you have a good chance of feeding this back and seeing it actioned far sooner than with an on-premise solution. These regular changes also add another dimension that needs to be considered. User acceptance testing and regression testing are not a one-off activity. Ensure you’ve got the right people regularly looking at new feature releases and making sure they work for your company.
4. Don’t be complacent about training and testing. Implementing SaaS tends to be an easier process than on-premise but you must remember the basics. Thorough testing is still key, particularly if you’re integrating with other systems. Likewise with training, yes, your new system might be simple to use but your staff still need to be trained to make the best use of it. Training is a great change management vehicle also, reaching the wider community with the message of why e-Procurement is important and helping adoption of the new system.
5. Think about your support model. As discussed above, while the software vendor takes away a lot of the support requirements you would usually need from internal IT, you do still need some internal support. This includes a first line support desk for general “how do I…” type questions, as well as a small team of super users who can tweak configuration settings and set up new users or suppliers, for example.
As a consultancy implementing both SaaS and on-premise, SaaS has certainly revolutionised the way we interact with our customers. It has freed us up to do more procurement work and less IT. We think there’s no reason it shouldn’t be exactly the same for our customers.