The Elephants and the Rabbits (Accounting at SaaS Companies)
August 19, 2009
Brian Sommer just posted a very funny piece on how SaaS CEOs can prepare for an earnings call. If anything, he understates the problem.
We have learned over the years how to respond to software company earnings calls. We look at license revenues; we look at revenues; we look at margin; and we decide whether the company is doing what it “should” do at its level of maturity.
What few people realize is that the rules governing SaaS vendors are different, so comparing SaaS vendors and perpetual license vendors is like comparing–oh, let’s try to avoid a cliche–elephants and rabbits.
This gives these guys so much opportunity to obfuscate that frankly, they don’t even need to practice.
To understand how this works, you need to understand the differences between the rules. I’ll stick with the basics. The key difference is that when a perpetual license vendor sells something on the last day of the month, they report the total amount of the contract as revenue; when a SaaS vendor sells the same software, they don’t.
With the perpetual license vendor, the idea of the accounting powers that be is that selling a software license is like selling a piece of packaged software over the counter. You sign the contract; they invoice; ka-ching. With the SaaS vendor, the idea is that they’re not selling an over-the-counter product, they’re selling a promise to deliver a service. And, since there’s always a risk that they won’t deliver, they can’t recognize revenue until they actually do that delivery.
Let’s see how this works in an example. What we’re trying to do is evaluate how sales are going. With a perpetual license vendor, at the end of the quarter, we can look at their reports and be able to tell, basically, what they sold, and how sales are going. If SAP sells a $1 million contract on June 30 (and ship and invoice), they report $1 million in license revenue, and we know that’s what the sales force did.
Now imagine that a SaaS vendor is working equally effectively. At the end of a quarter, they sign a $1 million contract that is effectively equivalent in the customer’s eyes. (Who knows, maybe SAP and Salesforce were competing and Salesforce won.) If we look at their revenues, we’ll have no idea that this is the case. Almost none of that $1 million will appear as revenue, because they are only allowed to report revenue for the days of SaaS that were actually delivered. For that $1 million contract signed on the last day of the quarter, SAP will report $1 million in license revenue, but Salesforce will only report $1,000, assuming they turned the product on that day and so delivered one day of a 1,000-day (3-year) contract.
This makes Salesforce look bad. But later on, things reverse. Imagine there’s a quarter when both SAP and Salesforce reps sell bupkes in a quarter. That quarter SAP reports $0 license revenue, but Salesforce reports the $90,000 that it earned from the 90 days of delivery on that old contract.
Two companies. Identical performance. Completely different-looking results. Now, we’re not completely trapped. We can get some idea of what’s going on, by looking at what are called the “bookings” numbers. (The booking is the amount of money invoiced during the quarter for the contracts that are signed.) Most financial analysts just use a quick and dirty rule of thumb for comparison purposes; bookings for SaaS companies are roughly equivalent to sales revenues for perpetual license companies.
if SaaS companies booked revenues the same way that perpetual license companies bill for revenues, this would be fine. But in fact, SaaS companies don’t necessarily book all the revenue from contracts like that $1 million contract that I’m using as an example. Very often, they don’t invoice for the product until it actually starts being used. So on that last day of the month, it’s reasonably likely that the bookings will be, say, $299,000 and the revenues $1,000 for that contract. But the rest of that $1 million won’t appear anywhere. It will be booked in the fullness of time, but by that time, we won’t really care.
So how do you compare the elephants and the rabbits? You don’t. To compare the two, you would have to know the value of the contracts that the SaaS companies signed And they have no responsibility whatsoever to tell you what that value is. In fact, they can say anything they want to about that imaginary $1 million contract; they can announce it, hide it, whatever. If this quarter, they want you to believe that they’re selling as much as SAP is, well, they can release figures that make it seem that way. And if this quarter, they want you to believe something else, well, OK. All perfectly legal. In our example, Salesforce and SAP are “actually” doing equally well. But there is no way of knowing this.
Oh, it gets worse. It turns out that the accounting standards that govern SaaS companies make margins worse than they “actually” are. So even if you did get data that let you compare sales accurately, the accounting standards would automatically make the SaaS company look less profitable than the on-premise company.
Awful, right? Not even close. You see, very soon, it’s going to get even worse. The accounting standards are changing. But hey, that’s material for another blog.
Delivering Sourcing Optimization
August 6, 2009
It’s a plain fact that there are certain kinds of math problems that even bright people don’t solve very well and computers solve better than we do. Some of these look surprisingly simple. If you’re a retailer, when should you mark down product and by how much? Or if you’ve got to make six deliveries, should you use one truck and make six stops, two trucks with three each, etc.
Entrepeneurs in the world of enterprise software have recognized this fact for a long, long time and have seen an opportunity there. They develop so-called optimization software, which solves an essentially mathematical problem and then provide it in various forms to the market. A few have provided only the engine itself, most of them ending up in I-Log, and many more that provide optimization solutions that address specific problems, like supply chain optimization, markdown optimization, or the subject of this post, sourcing optimization.
Now if there’s one thing that’s completely clear about optimization software, it is that the track record has been disappointing. I’m not just talking about the overpromising and underdelivering that afflicted the big-name supply chain optimization vendors. (No names, but you know who you are.) I’m talking about really wonderful products, like Joe Shamir’s ToolsGroup, which have struggled to put their tools in the hands of people who need it.
Sourcing is no exception to the general rule. In sourcing, optimization came to the fore when companies like FreeMarkets or Digital Freight wanted to set up sourcing “events,” where possibly hundreds of bidders could bid on thousands of line items, offering discounts for bundles of selected lines. What if A bids X for lines 1, 2, and 3, and B bids Y for lines 2, 3, and 4, etc.? This is one of those math problems that linear programming solutions solve better than human beings do.
A number of vendors still in the market place (you know who you are) proceeded to develop solutions for setting up and managing these events, which of course did a lot more than just figuring out which bids to accept. And to some extent, they worked; they did change the way many companies do business, and sourcing events are now fairly normal, with several large companies being big proponents.
But in my (admittedly somewhat limited) view, the optimization piece has been relatively unimportant. Certainly some companies have developed some good optimization algorithms, and they are used, but in the events I’ve seen or heard about, it’s not clear to me that the solutions they offered were actually all that optimal, and the reaction of buyers that I know to the solutions they offered have been tepid, shall we say.
I’m not surprised, as I say, because I’ve seen similar reactions from users of other optimization software.
Now I have a degree in math, and I’ve taken a course in linear programming. I know that the solutions they give you are better than what people can come up with by themselves. So are the people who don’t like these solutions just grousing? That’s certainly what most vendors think.
Well, the other day, I got a glimmer of the answer from some terrific research done by Vishal Gaur of Cornell University. (See my earlier post, “An Automated Replenishment System.”) He found in his case study that a solution produced by optimization software had a highly suboptimal operational effect because it was optimizing around the wrong things. The math was done perfectly, but the problem had been set up incorrectly.
This is always a problem in principle when you set optimization software chugging away. The software draws a box around the problem and finds the point inside the box with the best available solution. If you draw a different box (usually a larger one), the solution will be different, and will take longer to find.
In Professor Gaur’s case, the software developer had drawn the wrong box around the problem. Now what’s interesting here is that the software developer never knew that he’d done anything wrong. He delivered the software, and the IT people who were using it expressed satisfaction. And you might think, “Well, so what, even if it drew slightly the wrong box, it got roughly the right answer.” But in fact, when you change the box, you change the answer completely. So in this case, the users had to replace (manually) all the solutions the software offered (manually) with better and completely different solutions.
If you have optimization software, in other words, you have to draw the right box, or the answers that it gives you are not better than what you can provide, they are worse, often much, much worse.
Now look at how this applies to sourcing optimization. Let’s say that you set up the problem in one way. (You only allow bids from certain vendors, for instance, and you require that they offer discounts of a certain percentage.) If you draw the box differently, you will come up with quite different answers.
I was discussing this problem with Garry Mansell, president of TradeExtensions, a small sourcing optimization vendor. He argues that the only way of solving this problem is to provide a lot of services, along with the software. The experts that he provides (it just so happens, of course, that he’s in the business of providing this pairing) can keep the sourcing on track and make sure the right box is drawn.
Now I react to most honeyed words from vendors the way I react to offers of honey for my tea. (Hint: “No, thank you.”) But this struck me as roughly right. The problems that I’ve seen with implementations of myriad kinds of optimization software wouldn’t be solved, then, by fixing the software. It would be solved by helping people to make sure that they’re drawing the right box around the problem.
So who knows. Maybe Mansell is right. (Or maybe he’s just selling software. Or both.) But it seems to me to be a useful thing to keep in mind. If you’re looking at sourcing optimization software (or, more generally, any optimization software), don’t buy it and don’t use it, unless you have some serious experts, who can help you make sure that you drew the right box.
Effective Buying Strategies for Enterprise Applications
July 19, 2009
It stands to reason, doesn’t it. The more thorough and rational the buying process for enterprise applications, the better the outcome. For sure. Right?
Well, the other day, Dennis Moore, aka @dbmoore, a well-known figure in the industry, posted a query on Twitter asking for data that would show this is true. The more thorough the buying process, the more effective the implementation has to be true, doesn’t it. But no, the guy wants data. “Not anecdotes,” he said later, “but data.”
He isn’t going to get any. There are three reasons for this. First, there isn’t any reliable data of any kind on whether implementations were successful, at least none that I’ve seen in a career of nearly two decades. Second, most effort expended on pre-purchase analysis of software is misdirected, adding little to the quality or accuracy of the decision. And third, if you work backwards from failed implementations and identify the causes of the failures, it is very rare that the cause is the kind of thing that could have or should have been caught by a more thorough analysis.
The fact that there is little reliable data on whether an enterprise application product works is, of course, a scandal, but the fact remains and will continue to remain just so long as enterprise application companies want everybody to believe that the odds of success ar high and customers are embarrassed to admit failure.
I have been involved in at least two attempts by large, reputable companies to get a good analysis of what value, if any, has been gained after an enterprise app was implemented. The first interviewed only project managers and determined that the project managers found many, many soft benefits from the implementation. The second, a far larger effort, was eventually abandoned.
But let’s say that we had some rudimentary measure, like number of seats being actively used versus seats planned to be used two years after the initial projected go-live date. Would it show that thorough investigation really helps?
I don’t think so, and here’s why. The question of which software application to buy and/or whether one should buy one at all is usually a very simple question, one with a relatively clear right answer, at least to an objective observer. But it is rarely, if ever, treated as a simple question. People wrongly worry about a lot of irrelevant things; they are (usually) distracted by the salespeople, who naturally want the purchasing decision to be based on criteria most favorable to them, and because there’s a lot of risk (A LOT), people tend to create lengthy, rigorous, formal processes for getting to a decision, which do very, very little to improve the accuracy of the final decision.
Honestly, I can usually tell in an hour’s phone conversation what a company ought to do, and I often check back later — sorry Dennis, more anecdotal evidence — and I’d say I’m right at least 2/3 of the time, maybe more. And because of the way my business model works, I don’t even charge for these conversations.
What do you need to look at? Well, it’s a complex question, don’t get me wrong. But because the number of providers is limited, the capabilities are limited, and the likelihood of failure pretty high, there are usually only a few things that actually matter. And when there are only a few things, it shouldn’t take you that much time to figure them out.
Give a call, any time, if you want to test this out.
Innovation in Enterprise Applications?
July 10, 2009
Those of us who have been in the business for a while feel it’s in the doldrums: there’s not much innovation, and every year, the apps get older.
Where will innovation come from? Well, the thing about innovation is that it has to change something that we think is fundamental and immutable: it has to be on a CD-ROM, it has to be typed from a phone keypad, etc. So you can’t look for innovation in the same old stuff.
That said, here are four areas that I think are wide open, wide open, wide, wide, wide open. An enterprise application (or an enterprise application company) can get an edge if they can do one of the following things:
Reduce the cost of sales by a factor of 10.
Reduce the risk of ownership by a factor of 2.
Increase the effectiveness of the application by a factor of 5. What’s a measure of effectiveness; well, let’s say it’s the number of users who use it seamlessly and easily.
Increase the speed of the application (usually by using a special-purpose database) by a factor of 50.
At least two of these aren’t impossible, because we’ve seen them happen.
Salesforce reduced the cost of sales for SMB customers by selling an enterprise-level application that you could test for free and buy with a credit card.
Workday and Qlikview both transformed applications in their area using special-purpose databases, and Hasso wants SAP to do the same.
And at least one large company, SAP, is trying for innovation in the third. Fumbling and clumsy as their effort to improve maintenance has been, the idea is to reduce the risk of owning SAP by making maintenance practices considerably more effective.
As for reduced risk of ownership or increased effectiveness (actually, maybe you’ve seen Qlikview do this), we’re still waiting.
Ideas on who’s done this or how it can be done?
Lower the Cost of Sales!
July 3, 2009
In many previous posts, I have complained, bitterly, about the sales tactics that every enterprise application vendor uses, mostly to defend aging, poorly designed products. It’s one thing to put lipstick on the pig, I’ve essentially said, but it’s outrageous to charge admission, just to see the pig.
This is, of course, what happens in most sales situations. Companies big and small buy the software through a highly-paid salesperson, part psychologist and part snake-oil salesman, who listens to you, discusses your pain with you, and then arranges a long, long process that you and your team will go through: functionality requirements and demos and business cases and who knows what all.
Let me fill you in on a little secret. It’s mostly a waste of time. And money. Not just your time and your money. But also the software company’s. You are both driving up the cost of software, simply by accepting and perpetuating a system where rigmarole is the rule of the day.
In a time of economic growth, maybe both companies could afford it. So what if you use up a lot of IT hours compiling functionality lists and sleeping through demos. (Who could stay awake in them?) The IT guys like it well enough, and they like to be asked for input. So what if the software company wastes a lot of, er, resources flying in executives or taking the team out after all their hard work to a place where attractive women perform. (Happens, believe me.)
In a time of economic frailty and, not coincidentally, a time of doubt about the value and merits of enterprise software, no one can afford it any more. Not you, who has better things to do with your resources. Not the software companies, whose sales resources are being spread thin by companies that are insisting that the salesperson do more and more for them.
Wouldn’t it be better to use some of the resources squandered on these endless sales cycles for something else a little more worthwhile? LIke getting both parties to the right solution faster?
Don’t Buy Unless You Try
July 2, 2009
A product manager at an up-and-coming software company was talking about his experiences at Siebel, where he cut his teeth in that job.
“At Siebel, we would never, ever, ever let a customer take a look at the software. No way. Not ever.”
At his new company, by contrast, they give out free personal copies.
Now, which would you pay more for, software that you know works, because you tried it, or software that you can’t prise out of the company’s hands unless you fork over, big time?
Not sure what the answer is? Well, what if I told you that the success rate for the second kind of software was roughly 50%. So 50% of the time, forking over is just like sending money to that friendly Nigerian guy who seems to need some help.
Still not sure? Well, what if I told you that the software company made you sign a non-disclosure agreement about the software that you had just forked over for, which said, essentially, that no matter what you find after you forked over, you can’t tell anybody about it. Wouldn’t you think that maybe, just maybe, that was eau de rat that you were sniffing?
Well, if after all of those warning signals, you went ahead and bought, don’t think I’d call you a fool. You’d only be doing exactly what everybody who ever bought from Siebel did. And nobody would ever call those people fools.
Would they?
Don’t Pay Maintenance–and Use the Money For?
June 29, 2009
Top 10 things to use the money for, once you stop paying maintenance.
10. Reducing the backlog at internal support. This doesn’t take much money, of course, since you’re already saving the hours your people had been on hold waiting for the software company to answer.
9. First-Aid. You know all those open, raw spots in your current installation, the ones you hoped would be fixed by the latest version, if you could ever get it installed? Take charge and fix them, ’cause now your former supplier ain’t gonna do it. You’d be surprised what rudimentary first-aid tools can do: a few user exits, a virtual machine for low-profile Java apps that the exits talk to, a little user training, a few reports. You’ll get people back to the front in no time.
8. Raises. You know life just got easier. But that doesn’t mean that you shouldn’t use some of the money to reward your staff for all the effort they put out over the years dealing deal with your former supplier.
7. Shutting down the patch testing environment. Of course, once you do that, you have even more money, so…
6. Buy something you couldn’t afford. Go on, live a little. Here are some suggestions…
5. Invest in mobile. Every one of your executives wants cool stuff on their iPhone (or an iPhone if they don’t have it). Make yourself a star. Give it to them. They’ll go to their graves believing that IT support improved on the day you stopped paying maintenance.
4. Invest in the cloud. Face it. With the end of enterprise support, you don’t have an excuse not to do development that you can’t afford to do. So start by reducing the cost of development. With EC2 or Force.com or Rackspace, you can suddenly start doing it right, that is light and cheap.
3. Don’t invest in social networking. But do take the shackles off. Spend a little, tiny bit of money encouraging people to figure out what they ought to be doing with these new tools (if anything). And maybe use some of the tools to help everybody keep track of the efforts.
2. Return some of the money to the CFO. He or she has been walking around the halls looking for some spare change. Now you can reach in your pocket, pull something out, and feel good for the rest of the afternoon.
1. Hold a check-burning party. Write out 10 of those big checks made out to whoever it is, go out to the parking lot, and reduce them to their constituent elements. Hint: bring some beer.
Got your own suggestions about what to do with the money? Add some comments here.
Preparing for Next-Gen Apps: Clean up Your Data
June 25, 2009
A new generation of apps is coming, a generation that will make today’s middle-aged apps look as dated and primitive as the old Dun & Bradstreet software.
I remember the last time this happened; it was 1990. The big deals in enterprise applications were ASK and the aforementioned D&B and SSA. I worked at one of the next-gen apps, QAD; nobody at our company back then had even heard of SAP or PeopleSoft.
At that time, how could a company sensibly prepare for the fact that they would soon replace their systems? It was pretty simple. Don’t buy the old-fashioned guys, because the useful life is too limited. (Basically, it’s the same reason you might not want to buy a new car in the last year of the model.)
But what else can you do? Well, as I said in the previous post, buy appropriate technologies: keep any new technology small and simple and don’t worry too much about your platform (which is dying, anyway).
Here’s another thing to do. Fix your data. When you look at any modern app, one thing strikes you immediately. They just won’t work on bad data. It isn’t just garbage-in, garbage-out. It’s really more like the catalytic converters, which would turn into sludge the second exhaust from lead-based gasoline hit their poor little crystals.
But can’t you wait until you get a next-gen app, when all your data will be nice and new and clean, just like the app? Well, no. Because one of the things you’re going to want to do (and can do, because next-gen apps worry about conversion) is use your old data in the new app. And if your old data is, well, what most people’s old data looks like, you will muck up that old app.
In a way, what will happen to data when modern apps come in is what happened to the pioneer’s farmhouses after they got modern plumbing. Before, real cleanliness was something only rich people could achieve and then only at fabulous expense. After, real cleanliness was simply expected of anybody who called themselves middle-class.
So, if you believe my analogy, how do you clean up your data if you don’t have running water? Well, a whole lot of it is attitude. If you want it clean, even if you’re poor, you can do a lot about making it clean and keeping it clean. [Please comment if you have a good suggestion.] And if you don’t really care–it’s not that you’re against cleanliness, mind you, it’s just that it’s a lot of work, and you’ve got other things to worry about, and besides, it’s pretty dark over in that corner, so who would notice–well, you’re in for a surprise when attitudes and technologies change.
The Applicator 