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.

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.

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?

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?

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 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.

Vinnie Mirchandani frequently rails against maintenance fees in his Deal Architect blog, quite correctly in my view. As apps get older, the ecosystem becomes more robust, the number of people available to make the things work increases, and the underlying technology gets better, prices should go down. That they don’t is a testimony to the chutzpah of the application vendors and the, er, timidity of the customers, nothing more.

But let’s say, Vinnie, that you know this and you’re not particularly craven, but you need these guys. What do you do? Or let’s say that you’re just buying something they’re offering, because it makes sense. What do you do? Or let’s say that you believe those silly pundits and you’ve decided to go off maintenance. What do you do?

As I said in an earlier post, you still need an application strategy. The question is really, “What should that strategy look like?”

In that earlier post, I suggested that you should favor cloud applications, because they reduce the invisible, but very real long-term infrastructure costs. You should think Google Apps and Salesforce and developing on Amazon (but not on Intuit’s QuickBase, no matter what you do).

But this isn’t in itself a strategy, it’s just a guideline. So let me add another such guideline.

Think small.

Do you remember back when Jerry Brown was governor of California and was talking about something he called, “Appropriate Technology.” Appropriate technology was small stuff, which worked, which didn’t cost too much, and which was suited to a small, local problem at hand.

Let me give you an example that I remember from the time. Our local, San Diego power company wanted to build a plant in the desert, basically to deal with peak power demand. This was a big technology solution. Perhaps emboldened by Governor Moonbeam, the appropriate technology people proposed a combination of cogeneration and peak usage pricing. Miracle of miracles, they one. Why? Well, I can assure you it wasn’t because San Diego County had gone blue. It was because everybody could see the point of not having to pay for concrete and transmission lines, when they didn’t have to.

Oh, gosh, am I talking about best-in-breed apps, heterogeneous computing environments, multiple vendors, nightmarish integration costs, etc., etc., all the things we were trying to get out from underneath when we jumped onto the big app bandwagon?

Yup, yup, yup. That’s what I’m saying. In this day and age, you’re better off figuring out small, local solutions to specific problems–and accepting the costs associated with that–than you are buying a large, global solution, that supposedly offers economies of scale, but never delivers them.

If you adopt this strategy, you think (or at least you entertain the possibility) that a small, light call center/knowledge management app that deflects 10% of the time-wasting calls and can go in tomorrow, SaaS, might do more for you than the global call-center app that is designed to automate your interaction with most of your customers, costs jillions, and will take so long to install that none of us will ever be there to see what happened–even though the large app is supplied by your primary IT supplier and will become part of your global application footprint (the one you pay all that maintenance for).

I know it’s a radical notion. But that’s the idea. Think small. Look for small improvements. Buy small apps to make the small improvements. Don’t buy more than you need; assume that light apps that do less are the way to go.

Given the cost structure in place today, you’ll not only do more, faster; you’ll save money.

Why? Well, when you cut through all the nonsense, it’s the same reason I pick up a wrench rather than call the plumber. It doesn’t require that much. The job gets done. And there’s no reason to pay any more than I have to.

The Oracle Quarter

June 23, 2009

I was following some Oracle deals, as their quarter closed last month, and what struck me most about some of these deals is that Oracle competitors are trying to out-Oracle Oracle–and failing.

Let me give you an example. One of the most common, best-known plays in the ERP salesperson’s playbook–the equivalent of post-right in football–is called elevating the deal.

When you elevate the deal, you try to take it out of the hands of the “team” that has been assembled to evaluate your product and put it in the hands of busy executives, preferably several levels up, who are in a position to override the team. When you’re put in front of these executives, you pitch business benefits, instead of functional capabilities, and fill their soft little heads with visions of flexibility and agility, competitive differentiators, and money dropping like rain to the bottom line. At this level, of course, you just assume that your software actually has the functionality that will allow you to gain those benefits, which is of course what that low-level team was taking all this time trying to assess.

Both Oracle and SAP are past masters of this particular play; when they run it, it’s Tom Brady to Randy Moss, man.

So this quarter, I heard about two situations where one ERP vendor tried to elevate the deal, at the express instructions of the coach, er, head of sales. In either case, was it Oracle? No, it was the other guy. And did it work? Not a bit. The only thing the competitor succeeded in doing was ticking off the selection team.

It’s a pretty small sample size, of course. But it made me wonder. I know that the applications themselves showing their age. Is it possible that the tactics that go along with those apps are beginning to fray, too? I have been saying for some time, now, that they’ve outlived their usefulness to the customer (if there ever was any). See my blog post, “Lawson’s New Office,” for instance. But now, I’m wondering, have the old sales tactics stopped working for the vendors, too?

I’d be curious to get comments on this; as I said, my sample size is too small. But assuming I’m right, there’s one other question to ask. Why has Oracle figured this out and other companies haven’t?

If so,

Designed for Stability

June 22, 2009

I was just talking recently to a specialty chemical company whose specialty product is used primary by an industry that is now under water. They have a lot of middle-aged systems, and they’re looking for something, anything that they can do in the systems area that can help them out.

We’re talking about a company that needs to contract by, say, 50% until their market comes back.

So what can they do? Well, nothing. But the reason they can do nothing is well worth paying attention to and pondering.

You see, the systems they have–I won’t tell you which one is preponderant, but it’s one of the $AP family, that is, SAP, Oracle, PeopleSoft, JD Edwards, etc.–are all designed for stability. They work well only when things change very little. Change a manufacturing line, get a new big customer, add a new product or two, and these systems can deal; it only takes a few man years of work.

But change the business in some fundamental way and everything breaks. Move a line from one factory to another, and it might actually be easier to move the physical line than it would be to move the data in the old ERP system into the new one.

Chrysler faced this a while back, when Cerberus bought it; now, both GM and Chrysler are having to deal with it. I ran into the problem at an electronics company that was deciding to outsource and at a company that was trying to shift a lot of its business onto the web. Their systems wouldn’t let them change.

Well, it’s a good thing if the company that’s setting up the system is stable, has a product that doesn’t change too much, has reliable customers and a business model that will work for the next twenty years.

Know any companies like that?

It’s a bad thing, though, if your company wants to or needs to change fast. Then your systems will get in the way.

Do people ever think about this simple fact when they’re buying the systems in the first place? I’ve never seen any company that did. Do they think about it when they’re buying a company? I’ve only seen a few. When they’re figuring out whether to consolidate systems, that is, do they consider the tradeoff between the money they’ll save by consolidating systems and the money they’ll lose if they have to disentangle the newly consolidated entities? I’ve never run into anybody who did.

It makes sense, of course. Everybody thinks that things will stay more or less the same. Companies, their employees, the people who sell them systems, the people who design the systems. So that’s what they plan for, build for, and buy for.

The only problem is that much of the time, it isn’t true.

Not only the systems, my dear, but the entire mode of doing business with the vendor.

They come to the conversation talking to me about consolidation; they want to use fewer systems, servers, support personnel, etc.

I don’t think this is going to work; in fact, I think they’re going in exactly the wrong direction.

Only Thought Required

March 30, 2009

Some 10 years ago, a colleague at the small consulting firm where I worked “brought over” a sample requirements document and selection process from the large consulting firm where he had worked. They were pretty bad then, hopeless now, but the amazing thing is that they’re still being used. You can find copies (authors’ names removed) on the Internet.

You all know what they look like. You use them. If you’re just buying an application or replacing an application or maybe adding an extension, you score up the candidates based on a spreadsheet, giving due weight to the quality of service, the viability of the company, the price, and, of course, a long list of functional requirements. The company with the highest score wins.

Bunk, bunk, bunk, bunk, bunk.

First of all, the process overwhelmingly favors the large companies, like SAP and Oracle, because the companies are more “viable,” and the service organization is nominally bigger.

But it isn’t that that kills me. It’s the functionality requirements. You see–and this has been true for 20 years now–most of the functionality requirements don’t matter. The only things that matter are what you might call, “Derailers,” that is, bits of functionality without which your operations are derailed.

Let me give you a couple of examples. Years ago, Avon wanted to buy SSA and did. Avon, as you probably know, sends out a circular with a list of items and prices some 15 times a year. With every circular, the price changes. So unless you could vary the prices depending on which circular you ordered from, you had nothing. SSA couldn’t, and that’s what Avon bought. They put some astronomical amount of money into “customizing” the application, but it didn’t work. The project was derailed.

With any application purchase, those derailers are what matter. Sometimes there are 5; sometimes there are 10. But unless the app you’re buying can do all of them correctly, don’t even bother to buy them.

Unfortunately, the standard way of buying apps masks this simple fact completely. Most of the time, the requirements are long, but nowhere near detailed enough. So by the time a weary group is asking a vendor to demo what matters, they rarely get down to whether the functionality actually works the way it must. At Avon, for instance, all they asked about was “price lists;” they never asked whether the price lists could be attached to a circular.

Worse, even if you figure out that the derailer doesn’t work, the weighting methods that are always used can sometimes lead you to ignore the problem. The fact that the vendor does do 6 of 7 things or 25 of 26 things or 131 of 135 things makes you ignore the fact that IT DOESN’T DO WHAT MATTERS.

What is required instead of requirements documents? Thought. All you have to do is figure out what the derailers are. Then gauge the competitors only on that.

Try It!

March 18, 2009

Here’s a radical idea for you. Don’t buy it without trying it. I repeat. Don’t buy it without trying it.

It? What? A car or an iPod, right? No, I mean an enterprise-level application. If you can’t get a copy and set it up, don’t buy it. And I don’t mean a limited-functionality demo or a look-and-feel demo or maybe a video of the application. I mean try it and see if you like it.

I know. That’s impossible, right? Any vendor will tell you so. No human being can just get a copy of an app, install it, set up the data, and see whether it will work for them. It’s too difficult. It’s too complicated. It takes too long. It requires too much expertise. You need too much help. It would be a support nightmare. It’s completely impractical. It’s pointless.

I’ve heard all these things from the vendors. And they must be right, right?

Oh yes, I forgot all the things they don’t say. It would be too discouraging; the buyer hate the software. The buyer would screw up the implementation and then blame the vendor. The buyer would find problems and insist on their being fixed before he bought. The buyer might even compare capabilities with another vendor’s and use the comparison to drive down the price.

Or the biggest nightmare of all. The competitors get hold of the software, distort, exaggerate, and lie about what they found, and convince an all-too-gullible customer not to buy us and buy them again.

Such bad behavior. What vendor would even imagine this kind of thing?

All wrong. Every bit of it, at least from the customers’ point of view. It is possible to set up a company fairly quickly. And if you can’t, that’s a problem. If you don’t like it, that’s a problem. If something doesn’t work, that’s a problem. If it does something worse than some competitor, that’s a problem. It’s the kind of problem that you should find before you buy.

So try it. And if they won’t let you. Go somewhere else.

But oh, before you do, let me know who it was. And I’ll post the list here.