News Stay informed about the latest enterprise technology news and product updates.

Q&A: Siebel defends value of UAN push

It's been nearly a year since Siebel Systems announced its Universal Application Network (UAN), and even Siebel admits there's still some confusion surrounding the initiative. UAN is partly a product, prebuilt software that automates 120 industry-specific business processes. It's also partly about partnerships, compatibility deals with major integration vendors like BEA Systems Inc., IBM Corp. and Microsoft Corp., as well as third-party software providers. Nimish Mehta, Siebel's group vice president for UAN, told News Editor Jon Panker that Siebel expects UAN to be a key cog in its business.

When talking to customers, how do you define UAN?
There is an industry initiative that's called the Universal Application Network. Notice it doesn't have a Siebel name in front of it. It's something that WebMethods, Tibco and other major integration vendors have signed off on -- to be UAN compliant. And then there is the Siebel software that we sell called Siebel Business Integration Software. That's the product that we sell that has the industry-wide processes built in. There are two different things here. Building on open standards and forming partnerships may help integrate CRM with other packaged applications. But how does UAN link Siebel software with custom-built legacy systems?
The custom-built approach is to use the standard integration servers [and] prebuilt industry best practices in processes. What we've done is ask, 'What are some of the common processes companies in different industries have to do?' We've prebuilt 120 of these processes as software. These processes we ship out of the box. We run those on general integration servers. Let's say you have a custom system you want to integrate into the process. You use the integration server tools to write a small piece of code. We've taken a conical view of data objects that are required for these processes, an application-independent data structure. We've created the ability to map the custom system into the conical structure. So there is custom coding involved. You have to write some code to integrate your legacy system into this architecture. Siebel calls it a myth that the integrated suite helps solve integration woes. But there seems to be a perception that suite vendors minimize integration greatly.
A customer's environment includes the challenge of integrating your accounting system to your CRM system. But that's just a fraction of the total integration challenge that customers face. You're solving the easy problem. In a practical environment, what PeopleSoft, SAP and Oracle claim is not relevant. General Motors has 5,000 applications. They have a number of different warranty systems, financing systems, dealer management systems. Just to do an address change requires them to update 92 different systems. Getting PeopleSoft isn't going to help you. Is it safe to say that, for Siebel, integration is far more important -- and that perhaps your business hinges on it -- given the perception in the market that the suite approach solves many of these integration problems.
I agree with the first part. Integration is very important fundamentally. Customer-centric processes are a lot less standardized than back-office processes. In the front office, you tend to have a far more fluid nature, you want to be customer driven. So integration is fundamentally more important and, yes, important to Siebel. If we do our jobs right, [UAN] will be half our business in a few years.

The perception that Siebel needs this more than the suite vendors certainly exists, but it's fundamentally wrong because, in a large company, the suite-versus-CRM integration argument is such a small fraction of the [overall] integration challenge. Is that code being written in house or using outside consultants? And, using your example, would GM have to write separate code for each of its 5,000 applications?
It can be done in house. Or you can Siebel professional services or an outside consultant. GM would have to write code for many of them. But remember, GM may have many dealer management systems, and they're all transforming to the same conical representation. So a lot of the code is reusable. Twenty-six out of Siebel's 3,500 customers are using UAN. Is that a success?
Yes. I think the typical the sales cycle on something like this is typically six or nine months. I think we will see a significant ramp-up of customers as you go forward. Let's talk about the competition for a minute. What does UAN do that SAP's xApps and PeopleSoft's AppConnect don't?
XApps compared, to what we're doing, is fundamentally different; xApps is simply another set of applications on top of the SAP data model. What they've done is said customers have a certain amount of data that they put into the SAP data model, and we're going to build a bunch of new screens on top of this existing data model to do, say, mergers and acquisitions activity. It doesn't fundamentally solve the problem of integration.

AppConnect is closer to what we do, but they don't have the process library. PeopleSoft basically has a proprietary integration server. The idea is, if you want to integrate with PeopleSoft, you have to write that integration on the integration server. If you have Tibco, or one of the other vendors, you can use it for the custom stuff you're writing. [AppConnect] is OK. It's sort of a more passive approach, in my view.


Article: Siebel's future, so much depends on the UAN

The Best Web Links on implementing CRM

Dig Deeper on Customer data integration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.