Businesses in industries previously dominated by license-based products are increasingly shifting towards as-a-service models. However, the operational systems supporting these organizations often aren’t even equipped to handle subscription billing, which is only the tip of the iceberg that is advanced billing models these days. There are multiple solution paths to take, from integrating on top of a legacy system to engaging a big bang approach. One company still in the middle of the longer automation journey they chose is technology supplier VMware. To find out how they’re progressing, we invited Rishi Gowaikar, VMware’s Director of Product Management for Enterprise Apps to speak with Igor Stenmark at the 2021 Monetize Forum. Rishi explains why they landed on SAP BRIM as their new billing engine, and how their approach has yielded early returns.
Key Issues
What kind of complexities are involved in automating quote-to-cash for a global B2B operation?
What models beyond subscription are allowing companies to expand the ways in which they offer services?
What are the benefits of opting for a longer roadmap over a big bang implementation?
Guest Profile
Rishi is the Director of Product Management for Enterprise Apps at VMware.
Prior to joining VMware, Rishi served in senior information technology management roles at companies including Agilent, Deloitte, and Hewlett-Packard, among others. Rishi holds advanced degrees in engineering and business.
Igor Stenmark
Welcome to Monetize Forum 2021. This is Igor Stenmark at MGI Research. In our next session, “Monetization at Global Scale,” you will hear a case study on how VMware has been transforming its monetization platform for global scale and capability. Our guest speaker, Rishi Gowaikar, has been leading this modernization effort. Rishi is the Director of Product Management for Enterprise Apps at VMware. Many participants in our audience today are likely very familiar with VMware as a technology supplier, but in this session, we’ll focus on how the company automated its internal quote-to-cash capability.
Prior to his work at VMware, Rishi worked in senior information technology management roles at companies including Agilent, Deloitte, and HP among others, and he holds advanced degrees in engineering and business. He joins us today from the San Francisco Bay Area. Rishi, welcome to Monetize Forum 2021. It’s a pleasure to have you here. Thank you for being here.
Rishi Gowaikar
Thank you for having me. Glad to be here.
Igor Stenmark
We look forward to hearing your perspectives and any wisdom you can share with us regarding what you guys had to go through. To begin, could you expand a bit on your area of focus at VMware?
Rishi Gowaikar
Sure. My specific roles are around IT application implementation. I own the team that leads the delivery of functionality and capabilities around some of the order-to-cash capabilities that we have, and I have teams spread out across the globe in different geographies. That’s the role I play right now.
Igor Stenmark
VMware has been working on revamping its quote-to-cash capability now for some time. Could you share with us the genesis of this effort and what your original goals were? Additionally, how far along you are in that journey? What are your macro-level objectives for the business?
Rishi Gowaikar
VMware, as most of you may be aware, is an infrastructure software company. That’s how we bill ourselves. We typically provide software that gets used in most data centers of companies and most private cloud situations. Additionally, we have software that we have started to sell pretty well in the end-user computing group; that’s software that manages devices—laptops, mobile phones, et cetera. Historically, our business has always been license-key-based because, when the company started, there was no subscription or usage component to it.
As the market has evolved (over the last 10 years specifically), a lot of our product lines started to shift towards a SaaS/subscription approach. However, the operational systems supporting our business were built the traditional way: take an order, bill it once, and we’re done. So, there were significant deficiencies in those existing operational systems to address, and as part of that, we embarked on this journey. We broadly call it the monetization journey, but it’s mainly about enhancing the billing capabilities to link them to the order management, upfront, and quoting. That’s the journey we are on.
In terms of where we are right now, we’ve gone live on our new billing platform, SAP BRIM, and we’re moving product line by product line. We’ll have an opportunity to talk more about our journey thus far in detail, but I would say we’re about 30% to 40% done. We have numerous business units that we’ve acquired through external acquisitions, and we have internal, organic growth of new product lines coming up as well. Each of these product lines was originally in the legacy platforms, and we are moving them over one by one. We have another two years of roadmap to get the rest of our subscription product lines over to the new platform.
Igor Stenmark
Yes, it sounds like an extremely intense, complex effort. Following up on that, when I look at your process and what you guys have to handle, it strikes me as having a lot of different dimensions of complexity. You have e-commerce, direct selling, subscriptions, usage, configuration issues, channel—all kinds of complexity. Would you expand on that? What have you guys dealt with so far?
Rishi Gowaikar
We initially started our journey as part of self-service e-commerce, and we’re mainly B2B (business-to-business), so we very rarely deal with consumers. Consumers can come to our website and buy software, but our customer base is predominantly B2B. We started with the e-commerce, go-to-market approach and enabled that, and then we expanded further to what we call our sales-lead processes, where sales reps are actually setting up the quote for the customer in our CPQ system. Then, that was built to flow end-to-end using the same core capabilities the e-commerce front-end was using as we couldn’t afford to have two different setups.
Additionally, of course, a lot of our traditional business has been conducted through EDI, via our channel partners and things like that. Therefore, we also had the tricky task of enabling EDI for consumption of our subscription/SaaS services. And, of course, this is a global implementation, so we had to enable all currencies that we do business in—about six to seven different currencies. All of that has to be real-time, so we didn’t want to use the traditional batch mode where orders are sent in by our channel and have to wait for a couple of hours before they get acknowledgment. Hopefully, that gives a bit of the flavor of where we are and what we’re trying to address.
Igor Stenmark
So, it involves many dimensions of complexity. The volume is probably medium, but I can imagine that there could be thousands of line items per invoice.
Rishi Gowaikar
Correct. It’s a B2B scenario, so the number of invoices is less than, say, a utility or cell phone company would have. That said, each invoice is comprised of, for example, 40 line items, and if you look at the details which comprise those 40 line items, that could be millions of usage records that we record in our data centers, rate using the new billing engine (SAP BRIM), and collapse into a readable bill. The nice part about the billing engine is that we have full, end-to-end traceability for customer service issues. For example, when a customer has a problem with a specific line item on their invoice, we can actually trace it all the way back to the exact, let’s say, 100,000 records of usage—which hour, even which second they were using which service to what degree. We can then spit out that report as a PDF and give it to the customer. Of course, there are more complications in rating, which we’ll get into in the next few minutes or so.
Igor Stenmark
You almost answered one of my next questions. I understand that subscription is now table stakes in your business and that you’re heavily into usage. What kind of adoption have you seen in your business so far, and are you experimenting with any other advanced pricing models—outcome-based models, for example?
Rishi Gowaikar
We could talk about this specific question for about 20 minutes, but I’ll keep it short. As part of this effort, we switched from a proliferated SKU approach where we had thousands and thousands of SKUs for each and every permutation of our SaaS offering. Folks will know what this is in their context, but as an example, if I wanted to sell a red car, I’d have to have a red car as one SKU and a blue car as another SKU. The process of setting up the SKUs individually was a nightmare originally, and it still is in the legacy applications because all the SKUs have to go through a lot of approvals from the different departments of finance, costings, et cetera.
We did two things here. We enabled what we call attribute-driven pricing, where the base price of the product is decided and gets adjusted based on the configuration attributes. This is much easier to manage for our pricing operations team. We also enabled something called dynamic pricing. In our business, we have use cases where, for example, our electric utility company at the data center drops or increases its rates, and we need to be able to give discounts or uplifts to the customer immediately—as soon as, let’s say, midnight tonight. To enable that, we looked at a few other software packages that did billing, but for those, we needed to amend all the live contracts so they could pick up the new pricing. That wasn’t a feasible process or practical approach for us, and one of the key capabilities we looked for in selecting SAP BRIM was the ability to have this dynamic pricing feature where we have a central price list for certain product lines and validity dates, and then all contracts refer to that and apply their specific discounts on top. Those were some of the things that we had to deal with.
Aside from that, we have the typical SaaS/subscription billing models coupled with consumption-based models. So, we have the commitment the customer purchases which you can think of like a $50 cell phone plan. If you go over the committed amounts, we look at how much more you used, and there are overage rates we use to calculate the overage billing. That was the initial billing model that we enabled when we first went live with SAP BRIM. We now have complicated billing models that arise out of hardware. We have situations where we have services sold as hardware as-a-service with a rental charge for the hardware component. Then, we have to couple that with our SAP logistics system shipping and the entitlement management system. We currently have that system in-house, but we’re looking at SAP’s EMS. We plan to manage all of our digital assets for customers on EMS.
So, it’s a broad effort right now with a variety of billing models we have to enable. Every product line brings its own flavor. We’ve tried to standardize, but we discovered that many of the product lines are driven by what their competitors in the market do. So, standardizing all these product lines on, let’s say, three billing models has been extremely tricky and problematic for us. Therefore, we’ve chosen a platform that we believe gives us the flexibility to accommodate as many billing models as get thrown at us. That’s where we are right now.
Igor Stenmark
Great. You mentioned SAP BRIM is your billing engine. What does your product technology stack look like in terms of handling all your quote-to-cash requirements?
Rishi Gowaikar
Starting from the beginning of the quote-to-cash process, the CPQ system uses mostly Salesforce. We have another system called Model N as well, but all the sales rep processes get mainly driven from Salesforce. That’s integrated to our back office which is the SAP billing system. We share pricing data between SAP and CPQ and also EDIs, so our partners get a dump of the prices—meaning EDI infrastructure is the same as it has been. So that’s what we have from a CPQ standpoint, and then the rest of financials (the billing, et cetera) happens in SAP. We use Oracle, our legacy system, for a small component in consolidating accounts receivable, but the general ledger and so forth happens in SAP. So, SAP is slowly becoming the dominant platform as we roll over more and more product lines.
Igor Stenmark
With so many different products, where do you keep the masters for pricing, product catalog, and such?
Rishi Gowaikar
We’ve made a decision to maintain the SaaS subscription pricing and rating in SAP. That is our master. Product data is mastered in a different system called Product Data Hub, which is a standalone system that feeds data. It feeds into our legacy system as well as SAP. Pricing for SaaS, though, is managed and mastered in SAP and fed out to all the consuming systems.
Igor Stenmark
What kind of resource commitment have you had to make to this entire vamping effort for quote-to-cash? It sounds like a lot.
Rishi Gowaikar
Yes. This is a massive effort within the company with a lot of commitment all the way from the top executives. Currently IT, my department, is divided mainly into what we call “keep the lights on,” keeping the current systems operational, and the auto applications team. That second team is entirely dedicated to what we call the subscription-enablement effort. There are multiple tracks in there, but the bulk of the team delivering new capabilities is dedicated to this effort right now. After pulling so many team members, we still have a roadmap of a couple of years. It’s not a big bang approach.
Igor Stenmark
Yes, you still have a ways to go. Step by step. What have the results been so far if you look at the measurable impact on the business? Have there been any surprises? How does it compare with what you guys originally expected?
Rishi Gowaikar
We determined that setting up some of the foundational operational pieces (going back again to product and pricing data for our operations teams) is easier in SAP. However, we haven’t totally rid ourselves of the shackles from the legacy system because many of the product lines have to be enabled in both the SAP application and the legacy application. The operational teams have not completely shed their older efforts, but setting them up in SAP is far quicker under the master data. Transactionally, it’s changing. SAP as the billing system is truly being relegated to the back office where all orders are coming in through interfaces. There’s no manual entering of an order into SAP. Everything is coming in through interfaces, and then we make sure there’s decent error handling. We’re seeing less and less of the traditional approach of going into SAP and keying in an order.
Another big takeaway we’re noticing in terms of product and pricing operations is that the skillset has become a little more technical than it traditionally was. Because of the rating models, charging models, attribute-driven pricing, and so on, we’ve seen our product operations teams have had to upscale themselves and even hire some IT-like skillsets for their departments so they can adapt to the changing platforms, where previously, they would just create a new product for everything. Now, a lot of thought has to go into the product design. We’ve found about 60% of the work is the product design. If we do that well, everything else—the order flow, the quote flow, and the amendment of contracts—falls into place.
Igor Stenmark
For companies that are looking to duplicate what you achieved in modernizing quote-to-cash, what did you guys learn from your experience? What can you share or recommend? What are the big lessons learned?
Rishi Gowaikar
Historically, my experience with SAP was always of the big bang projects that went live for the full company or half the company. What we’ve learned, at least for our company and our peer group, is that the appetite for massive projects isn’t there, and the requirement for agility is much higher. We need to be able to show some wins every two or three months to the execs and everyone else. To that end, I think what has served us well is this “think larger but execute smaller” approach.
We looked at what the needs were for the whole enterprise, but we’ve come back to executing on a product line by product line basis. It actually worked so well that a couple of the product lines are growing fast enough to come to us and ask, “Hey, can we raise the priority for our product line so that we can go live earlier?” So, I would say that was a good lesson we learned, and I would highly encourage others to consider this approach rather than executing the whole project as a big bang and going live in one shot.
Igor Stenmark
So, think globally, act locally.
Rishi Gowaikar
Yes. Think larger, but take smaller steps to execute.
Igor Stenmark
Absolutely. Well, we’re at the end of our time. I wanted to thank you for participating in the Monetize Forum and for sharing some points of wisdom. We hope to have you back at future Monetize events. Thank you very much, Rishi.
Rishi Gowaikar
Thank you very much for the opportunity.
