Operationalizing VaaS Starts With ‘Why’
SaaS is not just changing the way software is delivered. It’s changing the way vendors and customers work together. Gone are the days of where vendors could charge perpetual licensing fees and lock customers into guaranteed annual maintenance contracts. With SaaS, Customers are essentially renting the software from the vendor, and most deployments get re-evaluated every year.
In this new paradigm, there’s only one lens for evaluating a software deployment: Value. What is the measurable value that the software is delivering to the customer? At Coupa, we call it Value as a Service (VaaS).
VaaS requires a more holistic effort where the vendor and customer jointly share the responsibility for achieving value throughout the product lifecycle. This partnership approach is still relatively new for both customers and vendors, and it can be a challenge.
Vendors must lead the way by developing a scalable, repeatable framework for operationalizing the delivery of VaaS throughout all phases of the engagement—discovery, implementation and optimization. This framework is something we were working on at Coupa even before our CEO Rob Bernshteyn first articulated the concept of VaaS.
Feature discovery vs. value discovery
Today I’ll talk about how we approach discovery—we call it value discovery. Value discovery is the ‘why’ of the deployment. Arguably this is the most important part of the framework, not only because what comes out of value discovery gets translated into the roadmap for the customer’s implementation, but because it lays the foundation for the customer-vendor partnership.
What traditionally has been done in the discovery process is to work through an RFP detailing the features and functionality the product must have, a total cost of ownership analysis (TCO), and a return on investment (ROI) analysis. This is all good and needs to be done, but that doesn't get to the point of distilling the true value that the customer is trying to get out of an investment. It lays out the what, but not the why, because the conversation is backwards.
At this point in the evolution of enterprise software, we can definitively say that deriving value from a software implementation is not correlated with features and functions. It would be rare today to find software that doesn’t offer more features and functions than any customer will ever use, yet companies still struggle to realize demonstrable value.
So, instead of starting with features, we start by partnering in an exercise to identify three to five measurable and time bounded objectives on cost savings, efficiency gains, or other metrics that will deliver value to the company’s bottom line. Only when those metrics are agreed upon do we determine what features are needed to get there. Without success metrics to inform the process, value discovery devolves into feature discovery, and the only thing you can demonstrate is that the features were implemented.
Lift, replace, chaos
My own department’s purchase of a new support ticketing system illustrates the pitfalls of a feature-oriented discovery process in a nutshell.
We bought a new system because we wanted some more advanced features, especially advanced analytic capabilities. We told the vendor what features we were looking for, but we never had a conversation with them about what it is we were trying to do.
The implementation was to be a lift and replace, transferring a process we ran in the old software to the new software. But soon after, our support agents were upset because we took a process that was working well in the old software and we tried to force fit it into the new software. That made their lives worse.
What the vendor should have done, and what we are trying to do with our customers during the sales cycle, is figure out what the value drivers are. For us in this case, those would have been measurably increasing customer satisfaction with the experience of using the tool itself, and also increasing overall customer satisfaction by increasing the efficiency of our support team and speeding up ticket resolution time.
We wanted better analytics, but not just so we could have cool reports. We needed to get better insights in order to optimize our process. Asking why, and approaching it with those three success metrics in mind, we would have taken a more holistic approach to process design, configuration and change management. The implementation would have been a lot less painful.
A new buyer
If we’re so good at doing value discovery ourselves, why did this happen? Why didn’t we lead our own value discovery process? It’s a reasonable question. The answer is that in the pre-SaaS world, it took a village to buy and deploy highly customized software on the customer’s premises. In addition to internal business stakeholders and IT, that village included consultants, system integrators and change management professionals—in other words, a lot of people who do this all the time.
The cloud and SaaS have made software more accessible by bringing the cost down, and making it easy to implement and integrate with little to no help from IT, and making it configurable, but not customizable. You sometimes still see outside project teams at big companies, but now we see a lot of smaller companies buying enterprise software, and they don't have the money to spend on having SIs redesign their processes and lead them through a change management exercise.
So, we see a lot of people leading projects who have never had to create success metrics before because they’ve never done a software transformation. You can be extremely bright, hardworking and passionate in your regular job, but this is something completely different, and for most people, something they’ll only do a handful of times in their career. Therefore, it’s up to the vendor to give them the framework to become successful.
A templated approach
When you have SaaS companies that automate a specific business process at scale--like human capital management, customer relationship management, or in the case of Coupa, spend management--they have tens of thousands of people running a standardized business process through their system. Because it’s hosted in the cloud, all that transactional data is visible to the vendor.
That means vendors can bring cross-company, cross-industry best practices and data into the value discovery process. When we go into a value discovery meeting, we have a generic set of metrics that are templated for whatever industry and solution we’re talking about. For example, if we are talking to a retailer, we probably have 10 or 15 metrics we know are meaningful to retailers, so we’re not starting from scratch.
If we’re talking about e-invoicing, we have our own benchmark data that shows that the average invoice approval time for our customers is 23.1 hours. If you’re trying to improve your invoice processing times, that’s valuable information. If you’re trying to save money by getting more spend under management, we can take your spending and apply the average savings of our clients across the board and project the amount of money you could save.
Cart full of metrics
We’re bringing a shopping cart full of metrics, but the customer is leading us on a journey to put those in the context of their business. We’re trying to get to where we agree on three to five measurable outcomes that we can partner on and achieve. It’s much more of an interactive discussion than a sales pitch, and there’s a lot more white boarding than PowerPointing.
This makes value discovery a much more valuable process. It leads to a stronger business case, and helps the project leaders have a metrics-based conversation with executive leadership. We’re committed to working with the customer until we get it figured out, because it’s not easy.
A common language
There are a million things that can happen during a software deployment. Maybe the customer hits some issue with the solution, or they have a change management crisis internally, or the people who were spearheading the process left the company. Without a focus on specific, measurable goals, there’s a much higher risk that these hiccups will cause the project to go off track and fail. That’s the worst-case scenario. The more common outcome is not being able to point to any tangible value.
The only way that you’re going to know if you’ve successfully achieved your mission is by understanding the value you’re trying to unlock in the first place. Placing value at the front of the discussion informs feature selection. It sets the stage for an implementation that is designed specifically to achieve the agreed upon metrics. Everything we talk about during implementation and production centers around these metrics. Value discovery is where we begin to speak this common language.