CRM software maker Siebel
has aspirations of becoming an integration specialist, or in its vernacular, a universal application network (UAN) provider.
The company is using the systems software of others as the backbone to build its own connectors and compete against SAP
to deliver customer-facing business processes to the enterprise.
Nimish Mehta, Siebel's UAN group vice president and head of its integration practice, leads the effort. With 45 percent of companies requiring customers through separate systems and 60 percent who have limited or no integration between front- and back-end office systems according to AMR Research, it's Mehta's job to convince corporations to choose Siebel as their software vendor.
Mehta recently talked with internetnews.com about the challenges of a CRM company living in an integrated environment.
Q: How do you convince potential customers that Siebel is an integration company, as well as a CRM company?
It's really an evolving thing. First, there was sales force automation and then we added service, we added marketing, analytics and it became CRM. We've had, for some time, a very firm commitment towards integration, and that came for us out of our core expertise. Look at how Siebel goes to market; we have probably some of the most, deep verticalization -- industry-specific capability -- of any software vendor out there. We have products in 26 verticals.
At one level, you're right, Siebel equals CRM and has for years, but for Siebel the end-to-end business processes that exist in any company are natural for us, because that's how we've written our marketing requirement documents for years, so an integration product was very easy for us. We don't approach integration like many do, which is a point-to-point tactical Web services kind of situation, we look at it as "what business problem is the customer trying to solve?"
Q: How do you differentiate from the competition?
Tibco or IBM or BEA, they don't offer one view of the taxpayer, that's not a solution you'll find on their Web site. They don't offer automatic pre-pay invoice reconciliation for wireless companies, they don't offer customer lifecycle management -- what they offer is software that integrates applications together -- so it's very much a systems perspective. So what customers are saying is that if you can solve this business problem for me, I'll pay you for it.
For integration, we didn't do what, say, SAP did, or Oracle, or PeopleSoft or every other company did, which was they went ahead and built their own proprietary stack. They created an IBM competitor, a BEA competitor; we didn't do any of that, we leveraged these technologies in our solution and built our technology on top of it, so people can use what they want.
In every layered stack where someone is providing really good technology, we don't recreate it. So, we don't abuse IBM, we don't abuse BEA, we don't abuse Microsoft like some of the others; SAP does, and Oracle does, and so forth. If you want the best application server you go to IBM or BEA or Microsoft, we're not good at that and we'll never build that. What we hear from our customers is a significant level of appreciation for the fact we're not forcing them to learn yet another technology stack.
Q: So, you have to wait for other companies to innovate technology before you can add your connectors?
When we first came up with the idea for end-to-end processes, we didn't think of the problem of connecting Siebel with SAP or Oracle to something else. That's not how you start looking at a problem, if you start looking at it that way you'll end up with this low-level engineering-oriented product versus solving a problem the business executive can understand.
What that led to was, 'We'll use the technology stack that already exists,' but then we found that not all of the vendors, and we selected six -- IBM's WebSphere, BEA WebLogic Integration, Microsoft Biz Talk Server, SeeBeyond ICAN, Tibco BusinessWorks, and webMethods -- and not all of them supported the things we needed in order to offer these end-to-end processes. So we went out and looked for standards, and we asked OASIS [the Web services standards body] what language we should use. They said they were ready to author a language called BPEL, Business Process Execution Language. So we went to each of the six vendors and asked them if they would support BPEL. Some of them did, and some of them did not, and we then convinced them to support BPEL. We also asked them to support some XML standards.
As a result, all six vendors support a plethora of standards that support specific standards we use to author all our software. As a result of that, we have not waited for the innovation to happen from them, we've kind of led them down that path, and now we have 165 business processes that are in production, available on all the integration platforms.