December 13, 2006 • Hollywood, Calif. - Management.travel spoke with Travelport CEO Jeff Clarke during last month's PhoCusWright conference here, before Travelport announced plans to buy Worldspan but after
The Beat told readers to expect it. At the time, Clarke could not comment on that pending proposal, but he did address a handful of technology issues and questions about running multiple systems.
Travelport is in the midst of a $75 million cost-cutting initiative. Is it tough to convince customers that that does not mean you're taking resources away from things they think should be developed on an ongoing basis, whether technology or people?
Customers understand that. There is not a customer out there that is not looking to constantly reengineer the organization and optimize their cost structure. Given the scale of our firm, where we have over $1 billion a year in operating expenses, a $75 million cut is a relatively modest cut. To put that in context, we have in the last four years made over 20 acquisitions and are just now shifting the focus toward intense integration and execution. In doing that, there are a lot of low-hanging fruits: lots of duplication and manual processes. In turn, we're implementing new phases of the Oracle enterprise resource planning system, and over time that produces economies of scale. But the real thing that is driving the cost structure is a philosophy we have brought into the company around prioritization. We strongly believe that if a department is doing ten things, most likely those things are too diffused to be successful in all of them. So we have asked each of our departments to prioritize everything they do in a forced rank, and we have asked people to redeploy, in a Darwinian way, their activities toward the most important areas. You get your strongest managers refocused on your most important priorities, and several priorities at the bottom become less affordable. So, it's not asking people to run faster or work longer; it's a reprioritization. We had been working on over 250 enhancements to Galileo. Many of those were pet projects and had multiple-quarter deliverables. Most of them looked like good things to do on paper, but no organization can operate on 250 items at the same time. It's too many cooks in the kitchen. By reprioritizing, we believe we can do fewer, more strategic things and save money at the same time.
As far as Galileo, with it changing hands a few times, some so-called traditional travel management company managers feel they're not as familiar with the technology direction as they would like to be. Can you share more detail about how much Galileo is moving off the traditional mainframe?
First of all, we have a new chief technology officer, Bill Murphy, who joined us a couple months ago and we're excited about the thinking he's bringing. Galileo is 30 million lines of code. It parallels with some of the seismic forecasting that occurs in labs and with sophisticated financial models on Wall Street. It's as sophisticated a technology implementation as you have. It's not necessarily as portable as many people might think. As such, many of the "alternatives" have been long on position papers and on marketing, but very short on the ability to actually "disintermediate" a model that is very stable and adds extraordinary value. That said, we have been able to take certain applications off the mainframe and reduce cost. We do our faring off the mainframe. We do certain levels of search using players like ITA Software who have found innovative ways to cache certain sets of data and make it more available and richer in content. So, we're open to alternatives and don't have a "not invented here" syndrome, but we're very committed to our 30 million lines of code and the ability to deliver high-availability, robust solutions.
Is the scope of the non-mainframe faring worldwide?
It's worldwide. We have moved it to open systems and it has had meaningful reduction in cost, and when you have the ability to take things off mainframe and yet continue to commit to the mainframe, that allows you to negotiate better with your suppliers of technology; you find very pragmatic responses from technology suppliers when you have alternatives.
What's left of the dual-system setup of Galileo and Apollo?
We have two cores, the Apollo core and the Galileo core. The interfaces are modestly different. They tend to serve different geographic footprints, and they tend to have similar underlying technology. We develop today on a code base that supports both. Holding the two cores doesn't have any significant cost overages. It's not the way you would design it if you started from scratch, but since it was really designed through acquisition, over time we will continue migrations. But I think we have found a good balance in one application development enhancement structure going forward with two underlying infrastructures and one contract supporting the two.
So the advantages people would normally think about in terms of combining into a single platform are not as apparent?
It's not an issue that drives the economics of some of the other initiatives we have. Over time, there is a series of things you'll do here, but this is not something that meets the high priority levels. Over time, it does. But in the short term, the next several years, it's not going to be high in priority. It works fine, we have strong cost competitiveness and we have other things to worry about.
