Summerland, CA
August 15, 2005

Whither QAD?

QAD has survived so far. Can this odd state of things continue?.

The View of the Pacific

QAD's headquarters in Summerland, California sits on the top of a hill overlooking the ocean. Airy, low-slung, sleek, you approach it from the back, so that only after you enter the foyer does a sumptuous view of the Pacific spread itself out in front of you.

Inside, that view defines a rather understated hierarchy. Near the windows are open spaces with cubicles. Farther back, for the most part, are the managers offices. But there is a group of offices toward the center where senior management resides and one office, in particular, that is set so far forward that you get the feeling that this grand Pacific ocean is yours and yours alone. It is one of the best views on the Pacific Coast, a place where whole social hierarchies are based on how much view you have.

The office belongs to Pam Lopker, founder and first employee of QAD, Inc.

As you read this piece, where we discuss QAD's value proposition, its prospects, its place in the application universe, and the odd fact that the company is still here in an era of consolidation, keep that office firmly in mind.

Nearing the Top

When I first came to work at QAD in the early nineties, things were more ramshackle. The 50 or so employees occupied some waste ground behind a freeway entrance whose parking lot seemed more solid than the building.

No matter, though. To be alive was very heaven in those days for a vendor of MRP (soon to be rechristened ERP) software, especially one that was open systems. Leads were coming in through every window, and development, where I worked was just racing to get the next version out (and the old version fixed) There was a need to hurry; Unilever, Johnson & Johnson, Philips, or AT&T were waiting.

In those years, it looked as if QAD was set to be the next McCormack and Dodge. Its major competitors in manufacturing, SSA, Symix, ASK, and MAPICS had serious (as it turns out, fatal) flaws. The JBOPS (JD Edwards, Baan, etc., ) who dominated the late nineties had not yet arrived. Indeed, I remember vividly a presentation by an executive Pam had hired away from some company called SAP that none of us had ever heard of. His glowing talk about this interloper fell on uncomprehending ears.

What was all the excitement about? MRP software is software that tracks all the core operations in a manufacturing plant, managing demand (sales), inventory, supply (purchasing), and manufacturing with a single set of software that runs in a single database. MFG/PRO, QAD's product, was originally built (by Pam) to run Karl's sandal factory, which he had started right out of UC Santa Barbara.

MFG/PRO was, unusually, an open-systems product, running on both DOS and Unix, but it was not an open-database product; it ran only on a database from Progress Software. Still, it was relatively more open than most of its competitors, and it was (and is) an attractive product for a manfuacturing plant. It was very straightforward (Pam had a natural sense of design), and it was built to be standard, doing exactly what standards organizations like APICS (the American Production and Inventory Control Society) said software should do.

It was a great position to be in. But it didn't last long. As it turns out, neither the product nor the company was capable of staying long in the top tier. Then and later, I heard any number of oversimple and often angry explanations of what "went wrong" at QAD. It was the marketing. It was the sales. It was Pam. It was Karl. It was Progress Software. It was all of the above.

It was all very silly. Nothing went wrong there. Yes, there were any number of really terrible decisions--about personnel (q.v.), about channel partners, about platforms, about the dot-com craze, etc. But every software company makes lots of terrible decisions; it was the great Hasso Plattner, after all, who came up with mySAP.com.

If you want to understand the QAD of today--and I do think it's worth taking the time to understand them--you have to realize that Pam and Karl set out some basic principles of operation when the company first started and never really veered away from them.

These principles governed how the product would work, how the company would go to market, and how QAD would grow. They are roughly as follows.

• Product. The product would be kept simple. If there were three ways of doing a business process, QAD would support the most common way of doing it, rather than, say, building support for all three and giving the customer the choice of what to do. Not only did this reduce TCO for all the customers who did things the normal way, it also reduced development costs and time to market, something that was not lost on Pam.
• Scaling Up.The product was built for a single factory; if it was to be scaled up (so that people could run multiple factories), the essential structure would not change. The scale-up had to be done, since the large companies that were flocking to QAD in the early nineties wanted a product that a large, complex, multi-country organization could use. But QAD wanted to do this by adding, not rewriting.
• Go to Market. In sales and marketing, the company would take a conservative tack, not spending too much, often hiring locally, and eschewing the scorched-earth marketing and sales strategies of its competitors.

It is certainly arguable that QAD was to forgo a lot of opportunity as a result of these principles. It is not merely arguable, it is certain, that they created a lot of trouble for customers. But it is also arguable that the principles kept it in business.

Shuddering Along, 1994-2004

I got to see some of the trouble first-hand. I left QAD in early 1994 and became first a QAD consultant and then an industry analyst. (For the sake of full disclosure I must say that Pam fired me. I should add, too, much as it pains me, that this was not one of those terrible personnel decisions referred to above.)

Sitting inside the development organization, I thought Pam's ideas about the product were pretty good. But when I had to put them into practice, I found them a bit maddening. Doing the simple, straightforward clear thing was good in principle, but it left a lot of holes, and the holes damaged the utility of the product. At one company, the units of measure didn't have enough places after the decimal point. At another, which made textiles, you had to create a new item number for each roll--a nightmare, when you have 1500 or so in stock at any one time.

And this was in manufacturing. When you got to sales, purchasing, or financials the simple approach too often turned out to be superficial. (The product had always been better in areas that Pam or Evan knew well, so core discrete manufacturing was always pretty good, and so was AR, which Pam used every day.)

I was later to learn that all the JBOPS had equally maddening holes in their products; boy can I tell you some SAP stories. But this never made me feel better about it. The plain fact was that the product fell short, and we (the customers and consultants) had to pay the cost.

One of the biggest problems was that the Simplicity Principle was having some unintended consequences. Multi-, multi-, multi- turned out to be a hard thing to put into the product, if you didn't change the structure. And, given how insistent and impatient large customers were, there wasn't much leeway for coping with the difficulties. This led to serious quality problems and then to serious delay problems in product releases, the double whammy. And this meant that the company was overstretched, the perhaps inadequate personnel (and I include myself) being asked to make too many customers happy.

In this, mind you, QAD was not much different from its competitors. PeopleSoft had its Version 5 and Version 7 problems; JD Edwards had its OneWorld problems. Oracle had 11i(and also 10.7). SAP's 3.1 didn't settle down until 3.1i.

But because QAD had chosen the road it did, it may have been damaged more by these problems. One actual experience of mine may be instructive. It occurred at two AT&T (Lucent) plants that had bought MFG/PRO. Management wanted to combine operations at the two plants and saw QAD as the lever for this. Unfortunately, what management wanted didn't make much sense, operationally, plus the lever they had chosen wasn't a good lever for what they wanted.

My job was to help the project team figure out what to do. It was pretty rough some days; other days, progress was OK. There came one day, though, when I came to work at the plant and nobody else showed up. I sat in an empty room, until the plant manager came in and told me that the powers that be had decided to go with SAP.

Five years later, I ran into the plant manager and asked him how it had worked out. "It was like going through the gates of hell," he said, "but at the end, I think it was a good thing." Had they combined the plants? No. But they had been able to install it in his plant. They had spent $600 million in the process "and by the end, not one person there had the same job he had when he started." But they did it.

So ultimately, was that good for the company? Unfortunately, by the time they had finished, contract manufacturers had become a real force in high-tech, so the original reasons for doing what they had done had largely disappeared.

So, in the cold light of retrospect, did that plant indeed do the right thing? It's hard to see. I now believe that the plants had to choose between two very, very flawed solutions, neither of which could act as the lever that management wanted.

What is very clear in that cold, grey light is that one three-letter application company did a heckuva better job masking its flaws and persuading management that it would be the right thing for them. They may not have had a better solution, but they had better account management, they sold at the right level in companies, and their product design was more persuasive, even if it wasn't better. One three-letter company was simply more effective than the other three-letter company. It wasn't even close.

Had QAD been a different company, with better account control, more ability to articulate the advantages of their way of doing things, fewer defects in the product they delivered, etc., etc., maybe it could have been. Maybe they would have been able to persuade their customers of something that was quite true: the choice of MFG/PRO would have been much less risky and much cheaper.

After I became an analyst and did a lot of software selections, I saw this play out many more times. Software selection during that period was not a rational process (even with our help). And much of the irrationality worked against QAD. Simple, straightforward and (relatively) modest in its scope just didn't sound like the company you wanted to spend jillions with. And because of any number of decisions that they had made, decisions that can be traced back to those principles, decisions to hire this kind of them to hire this kind of person and not that, to make this kind of case for the product with the analysts and not that, etc., etc., QAD was unable to fight back.

There were times when QAD found its customers, certainly. I remember one small company that was considering R/3 and MFG/PRO for a business where the fit was poor with both products. I presented the case (fairly, I hope) for both companies in terms of design approach. And they seized, eagerly, on MFG/PRO.

Mind you, marketing, selling, and delivery were not the only problems facing QAD during that period. QAD was also having to learn how to deal with GUI interfaces, thin client and web-based UIs, and competition from dot-coms, even as it was still learning how to cope with the management problems that its approach to multi- multi- multi- had created. Progress (pun intended) was painfully slow in these areas--and perhaps worse from Pam's point of view, money was squandered.

But all tunnels have an end. Damaging as the dot-com was to QAD, it also gave them time. While SAP was floundering around trying to give away its brand and business model, QAD was plodding along, if only because it couldn't see anything else to do. And when the world decided that ERP wasn't dead after all, QAD was readier than it was before.

The Survivor

When I visited QAD a few months ago, I found a company that was arguably in as good shape as it's ever been. QAD was profitable. It had grown. It was serving its customers better than it ever had. It paid a dividend higher than Microsoft's. And it was a completely credible competitor in its core markets.

I spent that day trying to learn everything that happened in the last 10 years to a product and company that I used to know as well as my brother (who also worked there), and while I certainly didn't find out everything, what I did find out was encouraging.

• Many of the most maddening problems (especially in manufacturing) had been fixed.
• A new, more modern version, called EB (for extended business) is now in release 2.1, with release 3 coming next year. At least some of what QAD learned during its many forays onto new platforms has now been incorporated into the core platform. Distributed order management, a key requirement for scaling up was now included. The financials are still apparently not up to enterprise level, but "a major upgrade" is expected in Version 3.
• After years "supporting" lean manufacturing, QAD has bitten the bullet and built capabilities that will make it a quite reasonable choice for a broad swath of manufacturers who want to adopt lean techniques. For almost ten years now, "lean" has been the "Just say no" of the manufacturing world, a good idea that nobody puts into practice. But who knows, maybe its time is beginning to come and who knows, maybe for once, QAD's timing is good.
• QAD is now building specialized extension products. A new sequenced order capability, for instance, provides something that has long been needed by some of QAD's Tier 1 automotive customers and could be needed by other lower-tier automotive manufacturers.

If I were a QAD consultant today, frankly, I'd be a lot happier. QAD has its best ever core product. It has dealt with many of the problems that its loyal large-enterprise customers have been working around for years. It is able to claim with some persuasiveness that it can help manufacturers move in the direction that manufacturing is going. And it is working to fix the financials.

(These financials will be a pretty important test for QAD. In most people's view, there is a huge gulf between the financials of Oracle, SAP, and PeopleSoft and those of the second tier competitors. I have seen any number of attempts over the years to "bring up" second tier financials to the top level, and they've all been pretty compromised, still so much less capable than what Oracle, for instance, does that the case for them doesn't seem compelling. One hopes that QAD will do better than this.)

Not only is QAD itself doing better, it has finally benefited from two shifts in the market. First, QAD wins as much as any application company from the move in manufacturing to China, India, and Eastern Europe. QAD has always had a presence in these countries --the only time I ever ran into somebody I knew in Eastern Europe, it was a QAD employee--but the markets have had to mature. Now that the shift of manufacturing to these countries is largely a fait accompli, QAD has become a standout choice, if only because the simplicity that had hurt it for so long is now a competitive advantage.

Second, many of its major competitors are no longer being sold with the same verve that a one-product company might bring to the table. As companies look to replace or upgrade systems--and there are still quite a few of these-- QAD is being brought into deals as the second or third entrant, where before JD Edwards or Baan might have elbowed them out. In those deals, if the customer is really looking for what QAD offers--a simple, straightforward solution that does what it is supposed to do--QAD has a good shot.

The Case Against QAD

From that office on the Pacific, then, the view of QAD is pretty good. But the view from Wall Street is very different. One never knows which is worse, indifference or outright dislike, but no matter. Wall Street hands out both.

QAD would be undervalued if it were a utility. My local utility, for instance, pays a dividend comparable to QAD's and has a higher P/E. Yet it is valued at two times revenue, whereas QAD is valued at less than one times total revenue, two times maintenance revenue.

A valuation like this can only be explained if the market believes that competition will be so ruinous in the next few years that even the maintenance revenue is highly vulnerable. "Resistance is futile," says the Borg, and it's clear that the Wall Street crowd goes to the movies.

Reality is a bit more complicated, as always, but even the facts can be construed in a pretty negative way, if you want.

It's just a fact, for instance, that QAD is not a takeover target. Pam and Karl own 52% of the company; they've spent the last 15 years building something that would last; and if they sold, Pam would have to give up her view. All kidding aside, they just don't see any reason to sell. Given that there are many buyers of application companies these days and not many quality products for sale, there would be a pretty rational case for holding out indefinitely even if they did.

Another simple fact has to do with QAD's size. Oracle, SSA, Lawson, PeopleSoft, and Infor have all made a pretty compelling case that smallish application companies have ruinously high fixed costs. Unable to grow quickly, and unwilling to join another company and thereby reduce these costs, QAD's cost structure puts it at a disadvantage.

Yet another fact is that QAD's sales and marketing has never been strong. As noted above, management has been out of step with the rest of the industry in these areas, and this has meant that they've never been able to retain talent that took a more conventional view. The case against QAD views this record as a very bad thing, for it means that there's little chance that the mediocre past performance will ever improve. I'm a little more agnostic, since I find that most application companies are inept in this area. But I see the point.

The same kind of argument can be made against the product. The plain fact is that the company has little to show for years of experiments with new platforms and new distributed operations capabilities. For the case against QAD, the fact that a "thin-client" interface is a feature of a relatively new release is shocking, never mind the fact that one QAD partner calls it little more than a screen scraper.

Pretty powerful case, right? Well, if you hadn't been following the company for 15 years, maybe. But when you remember that these criticism have changed little in all that time and that somehow or other, the company has built software that works pretty well, provides value, and sells, you get to think that maybe it's overstated. The view from the Pacific may not be the same as the view in Silicon Valley. But it isn't entirely shuttered.

QAD as a Best in Breed Company

Ultimately, therefore, I don't buy this case. The problem for QAD is not to atone for whatever sins there have been in the past. The problem is to take what's good about the product and company and fend off the Borg. If QAD didn't adopt a sales and marketing model that was used effectively by some companies, well, that shouldn't be a reason to write them off, it should be a reason for optimism, since they now have another chance. And if QAD is still trying to adapt its product to a new age, well at least they can take comfort in the fact that it will cost them far less to do so than it cost their competitors.

So in the short term, QAD is in fairly good shape. It has a simple, straightforward product that has the depth the target market wants, and it finds itself in a period where people are better able to value its virtues than they have for some time. Indeed, in my (not entirely unbiased) view, if you are a company of a certain size in QAD's target markets (certain parts of automotive, life sciences, high-tech, and CPG), you really can't do better than MFG/PRO.

But what about that long term, that thing that Pam and Karl have done so well. I've been arguing that a best in breed application company can't survive over the long term unless it learns how to deliver value, not just applications. Delivering value will set it apart from the Borg, which will always be in the business of delivering software.

Can QAD learn how to do this? Well, it's starting from a good place. A clear, simple product that goes in easily is far more likely to deliver value than a complicated product.

But a clear, simple product is by no means enough. Application software customers who are trying to get value are like turtles running a steeplechase. Once they come to a hurdle, all forward progress stops. The delivery of software is the first hurdle. After that, there are 15 more.

Is it up to a software company to help these companies over all the hurdles? Only if you want to survive and grow. In my view, the days of helping the customer over the first two or three hurdles are gone. These days, every small application company has have the discipline to stay with its cusotmers as they slog their way through the race.

What does this discipline consist of and what would adopting this discipline do for QAD?

Well, for a best-in-breed ERP company, a good first start is doing the kind of thing that PeopleSoft did with its TOE program--improving the usability and manageability of the product. It also means eliminating the software hurdles by making sure that everything the customer really needs is actually there.

A next step might be getting to understand just what all the other non-software hurdles are for those 5300 tortoises. Look at those customers, determine how they're getting value and why they're not getting value, and start helping those accounts plan.

Then evolve software, services, and IP that make QAD the natural place to turn when a new hurdle is encountered. It gets the customer over the hurdle, and it gives QAD new kinds of renewable revenue opportunities. Who knows, maybe it even keeps off the Borg.

Perhaps a minor test case for QAD is the sequencing application for Tier 1 automotive suppliers mentioned above. Even developing this software shows an appreciation of the hurdles that exist for these customers. If QAD could develop more products like that, do it cheaply, and market the products effectively, they could achieve significant new penetration of their installed base.

Where's the iPod?

The day I visited, we had a very amicable, sunlit lunch with some analysts from AMR, Pam at one point said, "Where's the iPOD in this business? One day, music players were an old, commoditized business, and the next day, there was an iPOD, which changed all the rules. I just want to know what the iPod will be for us?"

There seem to be two answers running around loose these days: On-Demand and SOA. Her point, I think, is that neither of these fit the bill. A revolutionary innovation is simple, clear, appealing, and lets you do a new thing in a new way. (No, Marc, salesforce lets you do an old thing in an old way; it's only the log-on that's new.)

If such a thing comes along in this industry, I don't think a pure technology company will find it. Face it. The age of innovation for application companies has been over for some time. When they innovate, it extends only to "safe" innovations, marginal improvements that don't change the underlying model.

My bet right now is that no one finds it. Thirty years from now, we will take sales orders with the same underlying technology we use today. It happens. Theoretical physics was a hotbed of innovation for 25 years; now, it's a bore.

If nothing magical does appear, the next 10 years in application software will be devoted to cleaning up the mess created in the previous 10 years. If that's the case, the winners will not be the ones who play by the rules that those 10 years established.They will be the ones that figure out how to make technology work better and more seamlessly for their customers.

Hard stuff. And maybe just a little boring. If someone wants to take it on, I think they deserve a good view. For the last ten years, this view has had to be a view of San Francisco Bay. But maybe the world has changed. Maybe a good view of the Pacific will do as well.

To see other recent Short Takes, click here for a listing.

A best in breed ERP company.