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
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.
FOR MORE INFORMATION:
The Best Web Links on implementing CRM