The Baan Gambit
SSA GT buys Baan and (pick one) a) pays way too much or b) gets a bargain.
The Problem
Last May, Invensys put Baan up for sale. According to public sources, Baan had roughly $275 million in expenses and $250 million in revenues. Its core application was aging (not even web-based across recent versions) and had no clear edge against any other ERP player. There was little new business. Despite all this, Baan attracted four serious buyers, all of whom went through a whirlwind due diligence process. (Invensys had promised to complete the sale a month after the announcement.)
The winner(!?), SSA GT, paid roughly $150 million. Evidently, all the other buyers felt the property was worth even less.
Whenever I imagine taking over a software company, I think of those science fiction novels where the protagonist happens on an abandoned spaceship, whose control panel is designed for some alien hand. There are a lot of knobs and levers and buttons, but the labels are all in Alien. What the heck does any of them do? Push the wrong one, and the darn thing will take off toward one of the Magellanic Clouds.
I've talked to several of the buyers, and, from what I can tell, there were
many different opinions about which buttons to push.
A reasonable approach would have been to cut expenses,
basically by cutting staff or moving operations to India. (Call this the i2 Model.) But there were issues. The European employees, especially the Dutch employees, were protected by strong labor organizations. There had, moreover, already been several rounds of cuts. If you wanted to cut again, whether in Europe or elsewhere, you were going to have to cut away something that had a reason for existence.
What were you going to give up on? The existing customers were happy with the company and the support; were you going to cut that? There was a new release in the final stages of development. Were you going to cut that? (Realistically, new releases require investment, because you have to ramp up sales, marketing, and support.) The easiest place to cut would be in Asia/Latin America, but these are also the
areas of greatest opportunity.
You could also simply divest many of the companies that Baan had acquired over the years, but never really integrated into the core. There was Berclain, the SCM company, CAPS Logistics, the transportation company, several different CRM packages, including Aurum, a sales force automation company and two different configurators, Antalys and Beologic. There was a partial interest in an Israeli PLM company. Shut these guys down; spin them off; sell them. But the nagging
question would remain: are you killing off your best chance for new revenue?
No matter which buttons you push, time is against you. The Baan customer base is aging.
The majority are on Version 4,
which was a viable product back in 1998. Another 20% (roughly) are on Version 3. Assuming that the median replacement time for ERP systems is 10 years from the time of first purchase, a good rough guess is that half your maintenance revenue is going away in the next five years.
So you have to do something positive, as well. If you just cut, you will convince the customer base that there is less and less reason to pay maintenance, more and more reason to replace their installation sooner with one of the many fine web-based products that are out there.
SSA Gets to Decide
At the end of the process, only SSA was left. One potential
buyer looked at the problem and, following the lead of their governor-to-be,
said, "Asta, baby." The other buyers stayed to bid, but
evidently felt that even $150 million was too much.
So Graeme Cooksley of SSA got to decide
which buttons to push. I talked to him recently, and
he was quite forthcoming about his decision-making.
Cutting was necessary, and cutting was done, in quite short order.
Roughly 800 jobs worldwide went away, including those of all but one of the senior management team. 800 is roughly 1/4 of the company, more if you recognize that 1/5 of the employees were in India.
Non-European cuts certainly happened, but Cooksley was also able to work through the necessarily painful negotiations with the Dutch works councils and make cuts there as well. There was a certain amount of transferring to India, but not as much as one might have expected.
In keeping with the SSA strategy--own as many distressed properties as possible--the SCM, logistics, and CRM applications were kept, to be
added to the SSA menu. Even the Israeli PLM company
was kept, and SSA now owns it outright.
Personnel cuts were not the only cost-cutting strategy. According
to Cooksley, Invensys had not been careful about stoppering up some cost leakages; some leases and some other supplier contracts left over
from the Baan brothers days, were reexamined. And, of course there were some opportunities for
consolidating buildings, data centers, etc.
To augment revenues, an audit
program was instituted.
Cooksley is confident that these steps in themselves will quickly return Baan to
a level of profitability that is consistent with SSA's corporate targets. Think
15-20% margin or roughly $45-50 million for Baan, and you won't be far off.
Many an onlooker thinks this is unlikely. (One person who had been involved said
he would be happy to buy Graeme a very good dinner if he can do it.) I myself am
skeptical.
But two things may allow Cooksley to get his dinner. First, large
Baan customers may decide that the risk of dealing with Baan is down to
manageable levels and step up
or at least stop delaying purchases of
neeeded new seats. (This, Cooksley says, is already happening.) Second,
the rising tide of the last two quarters may lift this
boat even as it's lifting the SAP supertanker.
Cooksley's basic assumption in all this is that cutting 1/4 of the company won't
do very much damage. One has to wonder whether that's true.
Support for this position, though, has come from a surprising source.
People who had been midlevel managers at the old Baan and
had kept their jobs were uniformly positive.
They commented frequently on the "professionalism"
that SSA brought to the company and welcomed the "rigor" and "discipline"
that were in evidence. SSA claims that they are good at acquisitions.
Certainly SSA dug very deep,
very fast and managed to spark some enthusiasm at the same time.
The New Baan Strategy
So far, then, the takeover shows some promise. But the
talk with Cooksley still left me wondering what the strategy is.
With only 3/4 the number of people, you can't do everything you
were doing before. So what's going to go?
There were two obvious things to do.
First, cut support. According to independent surveys, Baan customers have
the highest customer satisfaction among all the major ERP players.
Clearly, if you cut that back a little bit, you're still going to have
competitive support.
Second, delay the Gemini (Version 6) release.
Redirect people whose work on the project was finished. Simultaneously slow
the marketing and support investment that a new release would require.
In my view, a lot of what was in that release had no important
constituency in the installed base, so the delay would not matter too much.
SSA has in fact done both things. Core support was cut back about 10%, and some
support tasks were taken over by development. And Version 6 has been delayed.
According to a recent announcement,
SSA said the delay would be at least until summer.
As much as anything, they said, they wanted to be sure the release was stable,
so they were seeking beta customers before releasing.
Interestingly, certain things were pulled out of Version 6 and
released earlier. Most important was a web interface that could be overlaid on
Version 4 or Version 5. Beyond that, there was a product developed in India, called Leanware, that extended Baan's capabilities in high-volume, repetitive manufacturing. And finally, there was some integration software that will also be offered to the customer
base and possibly used to integrate other internal applications.
Both these moves have an improvisatory, tactical feel to them. The
moves themselves and the way in which they are presented are designed to
make you think that pretty much Baan will go on as before: the same
revenues, the same performance, but with much lower costs.
Some of this impression, of course, can be supported by
improvisations on the accounting side.
Cooksley set aside a large amount of money to cover the "costs of acquisition" and
used the money, for instance, to buy out the long-term leases. His "profitability" goes up, because the costs of rent go away, but operations haven't changed.
I suspect that these improvisations
may actually be the strategy. Essentially, Cooksley may
just be setting out some broad directions but trying to
make things work day-to-day as best he can.
In any case, here are the directions:
- Separate out all the Baan software assets and put each one individually
on to the SSA menu.
- Reduce direct sales and move to selling through channels.
- Where appropriate, put Baan knowledge and capability to work for the broader SSA
organization.
Perhaps no more can be expected at this point.
The Problem with Improvisation
I'm a big fan of muddling along, and I don't think
SSA has to tell the world everything it is doing. But I
don't think that improvisation can carry the
Baan purchase very much farther. Here's why.
SSA is a new kind of software company, one that simply renounces the idea that
an ERP application company needs to be built on a single platform. Instead of
a platform, they sell a portfolio of products, whose fit with any particular
customers' applications and needs is a matter of circumstance and history.
I agree that single platforms are vastly overrated. But, as we can see
from this Baan purchase,
portfolio companies are really hard to manage. And if you don't manage
by providing really concrete statements about what you're doing,
you put a lot of pressure on people.
Let me give you two very concrete examples. Let's say
you're going around trying to renew Baan channel relationships, part
of the broad direction that you've been given.
What is it that you want these people to sell? They shouldn't
sell the from the entire SSA menu; effective sales, installation,
and support for all these products would stretch anyone too thin.
Your big carrot is probably the chance to sell the full SSA discrete
product suite.
But that's a future and hence not much of a carrot in
today's heavy competition for channel partners.
And even that carrot has its risks. You still have to worry
about overloading the partner. And you're practically guaranteeing
channel conflict. Managing channel partners is always a jigsaw puzzle
with ill-fitting pieces. But in this situation, a certain vagueness
about future direction makes it a stretch of anyone's capabilities.
You get a similar problem in product development, as you try to put
Baan expertise to work for the entire company. It is actually the
case that some members of the strategy group from Baan
went into the product marketing group at SSA that determines
product direction for the entire company. They were
put in charge of things like "manufacturing" or "new consulting products."
Good, in keeping with the direction. But putting these very good and talented
people in these jobs will still be a big stretch.
You don't just learn process manufacturing overnight, no matter how talented you are.
I think this problem is structural for a portfolio company.
When you're
trying to juggle 15-plus code bases, hundreds of integrations, and thousands
of customers, and you're trying to make this new company
profitable where none of the other ones were,
you're going to need superior performance from a huge
number of people, because you're stretching them across so many
products.
Historically, in
the software industry, it's been the reverse; a few brilliant performers have
made the difference. When companies lose their brilliant performers,
normal, competent work from decent people has proven to be insufficient.
Baan's 2004
In 2004, SSA will have a year of honeymoon with the Baan customer base.
The takeover will be done; the customers will then learn what their new supplier is made of. Right now, I think there is a fairly big risk that the honeymoon will end on that sour note that presages divorce.
Concrete examples are always a help. Take the new web-based
interface. It isn't quite what you (and the customers) might think
it is. For you and me, a web interface is a built-from-scratch,
clientless interface that is the primary, preferred, and usually
only way of getting into the application. This new web interface is
less than that. Essentially, it does allow you to present the
screens using HTML, but the screens you get don't have as much capability
as the client screens that they are designed to replace.
When other companies tried this kind of stop-gap solution (and many have), it didn't work out very well. Customers who wanted an architectural solution weren't satisfied; those who wanted functionality stayed with what they had.
My worry is not the web interface, per se. My worry is that
the breakneck speed, the improvisation, the stopgap solution, the heavy
pressure on employees will be
the mode in which SSA deals with its customers.
Those of us who have a manufacturing background
know that when stopgaps and improvisations become part of the fabric of the operation,
the factory is inefficient, a candidate
for closing. When they become part of the
fabric of operation for a portfolio company, the customer
disengages.
I think SSA can avoid this, can build Baan back up, and can make
far better use of Baan's supply chain and logistics assets than
Baan ever did. But I think they will have to do some things differently.
To some extent, I think they'll have to bite the bullet and decide to make
Baan (or SSA Discrete) stand for something within the manufacturing
world. They need some vision for the product.
I also think they need to figure out an efficient
way of matching their portfolio of products to the their customers' needs.
Historically, software companies do a lot of demand creation; their salespeople
know what their product can do and spend time showing people how cool it would be
if they have it. But when you're selling 15 different products, that's just
not going to happen. Most salespeople will give most of the product line
short shrift and keep on selling what they know how to sell.
In all probability, SSA can only do this by keeping much better
tabs on their customer base than software companies usually
do. At many software companies, there isn't ever much up-to-date
information on what their customer is actually using. (I believe that
this was the case at Baan.) With better information about
the customer and their needs, you can make your salespeople more
efficient. But not since the days of PeopleSoft's account
reps has any software company done this successfully.
Baan Redux
Looking back at Baan's history, it has always seemed surprising
to me that it did so well. In the early days,
it seemed to me a company whose management largely failed it; in
the later days, it seemed to me a problem that no management could solve.
The problem probably began when Baan sold its product to Boeing and magically
became one of the BOPS (Baan-PeopleSoft-Oracle-SAP). Suddenly, though,
Baan was two companies, one that served small companies largely
in build-to-order industries and one that served a Boeing
that was marching toward catastrophe. The Baan brothers,
in my view, didn't know what to do with either company, and rather
than figuring out what to do, they took their cue from their big neighbor
and tried to become the Dutch SAP.
When Tom Tinsley took over the company, all that really
happened was he added a new problem on to the previous one.
With Amal Johnson, he decided to
become an assembled solution company. He and Johnson bought a lot of
best-in-breed players: Aurum, Berclain, CAPS Logistics, etc.,
without knowing much about how difficult it was to
assemble solutions or (alternatively) sell a portfolio. Once
they bought them, they let them wither.
When Invensys stepped in, it was able to provide the
cash that could keep the company alive. But Invensys couldn't
solve any of the essential problems. Perhaps there
wasn't any solution.
Almost miraculously, SSA has found a solution to the second problem.
They are putting all the components of the assembled
solution into their portfolio and finding a new set of customers
for those products. (As I said, they still have to figure out how
to sell them.)
But I wonder whether they've figured out how to solve the first one.
Baan is still serving two kinds of companies, and each part of
that customer base is under attack.
At the low end, many small manufacturing companies that were
sold Baan years ago now have a lot of people knocking at their
doors, perhaps most notably Navision. And at the high end,
the Boeings and Flextronics of the world are happy, but the full
group of large company clients is under attack from the other ERP
vendors and attrition, though slow, does occur. Protecting
yourself from both kinds of attacks is difficult and expensive.
Still, so far, so good. Baan is bought; the price is good; the
actions assertive; the market recovering. If it's a mountain
that needs to be climbed, at least the first steps have been
taken.
To see other recent Short
Takes, click here for a listing. |
