Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Siebel Systems (SEBL) - strong buy? -- Ignore unavailable to you. Want to Upgrade?

To: Clam Clam who wrote (1472)	5/3/1998 4:11:00 PM
From: seth thomas	Respond to of 6974

A big consideration in the building of new products is the installed base problem. It is substantially more difficult to build a software product if you need to be upwardly compatible. With these enterprise applications, there are data, schema, customization, platform, database and other considerations. It is really complex to be upwardly compatible. The other choice - to not be upwardly compatible - alienates your customers forever. The problem is challenging enough when you have one product - when you have two products to integrate, and you are trying to be upwardly compatible for two big products - it takes awhile, and a lot of effort.

To: Clam Clam who wrote (1472)	5/4/1998 1:56:00 PM
From: Kevin Rose	Read Replies (4) \| Respond to of 6974

Hi Clam: Yup, still here. Plugging away at our Mobile product for our Q2 release. You've hit on one of the HUGE issues in the SEBL/SCOP merger; one that is bigger than the technical challenges (which are awesome). Basically, SEBL has two choices: 1) Merge the existing products 2) Dump the SCOP product and rebuild it on the SEBL architecture Tom (and common sense) will not allow for the third possibility; dump the SEBL product and build on the SCOP architecture. My opinion is that #1 is what customers are expecting, and #2 is what should be done. There is too much overlap between the products and their infrastructure to make #1 a viable long term strategy. I detailed some of my opinions on this in an earlier post, so I won't go into that subject again. #2 is the best strategy IF they leverage the SCOP product development expertise and experience. However, in order for that strategy to work, they must: A) Retain that knowledge and expertise. B) Convince people that they are not engaged in strategy #2, but in fact are doing strategy #1. C) Get it done quickly. D) Find some way to transition the current SCOP customer base (at 500+ customers) to the new product (i.e. make it seem that they in fact did #1). Risks associated with the above: A) Their stock is down and the cultures don't mesh well. If they can't get the stock back up to 30 quickly, could become an issue. High stock prices have a tendency to cover a lot of pain, which comes out as the water rises and covers those options. B) This is Tom's forte. Risk is that he is now selling this to suspicious IT/CS people instead of admiring Sales folk, but Tom is a great salesman. C) Both SEBL and SCOP have good technical people. Big job, they'll have to really dig in. D) Herein lies the crux of the biscuit (which, btw, is much more than just the apostrophe). How do you transition customers from a highly customized and self-tailored mission critical product to a completely new one? D) is where most of the work and thought is going, I'm sure. One critical sticking point: most of SCOP products are installed in critical places in the organization. These installations cannot suffer one hour of outage without much knashing of teeth and knocking of knees (not to mention lost customers and business). Thus, the upgrade to the new products must not only be complete and seamless, but nearly instantaneous. I fear that many CIS customers have built such a fragile shell around the SCOP product that they will find immense difficulties around this, akin to 'pulling the tablecloth off the table' trick (but instead of ordinary dinnerware on the table, it is more like an expensive set of china). Best way, IMHO, to solve D) is to approach it as a new vendor situation. That would mean starting with the assumption that all the old stuff is gone, and the new stuff will completely replace it. A user's favorite functionality that is lost is lost; favorite queries need to be re-created; legacy interfaces completely reworked. Lots of pain and work, but a MEASURABLE amount of pain and work. Unfortunately for SEBL/SCOP, the 'best' solution is also the one that has the most business risk. It leaves the door open for other vendors to re-enter; why not do a reevaluation of vendors if you have to start over anyway? SEBL/SCOP will have to resell all these accounts. And it isn't really like a new sales situation; these customers will want some consideration for past $$$ spent, whereas new vendors don't have this same burden. Tom will have to work this one hard to get the same $$$ in these deals as in new deals. On a different note, I believe that some of these problems are unique to the SEBL/SCOP merger. SEBL is the dominant player in this 'merger', whereas SCOP brings many more existing customers and years of tough battle experience to the table. Contrast this with a situation (like the oft-cited VNTV/PSFT rumor) of a biggie trying to get into a new market. These problems are smaller (possibly much smaller) because there is not the need for such a close coupling between ERP products and CIS/SFA products (don't burn me here, there IS a need for a strong link, just not such a tight one). Jeez, took a lot of words (I type fast) to come to the answer to your question of how long it would take to build a product with SCOP's functionality using SEBL's architecture. My answer it would be a short time to a demo (3 months); a fair amount of work (6-9 months) to produce a product that could show well and have some smaller installs; more work to get the 7+ years of depth that CIS vendors have and their customers expect (12+ months). This would allow SEBL/SCOP to compete in new opportunities. But for the existing customers, the path is tough. Hence, a lot of the SI talk of new 'opportunities' for all vendors to vulturize the existing SCOP installed base. Good luck PS I work for a competitor (CLFY) so my opinions are known to be biased/suspect.

To: Clam Clam who wrote (1472)	5/4/1998 10:49:00 PM
From: Lee L.	Respond to of 6974

Clam, I don't have a source for my opinion. My HO is based on working with SEBL for two years, and having gone through a similar product mash several years ago (albeit with comparatively primitive product architectures to SEBL/SCOP). I'll restate that I don't think that SEBL knows how they will integrate the product sets yet. I've spoken to several people at SEBL and they simply don't know. I agree with most of Kevin Rose's post on SEBL's options -- I see one of two outcomes out of three possibilities: 1. Maintain two product sets with basic integration between the two. I'm sure that SEBL is doing this now. This solution is sell-able to new customers, but has many warts -- two development tool sets, two installs, redundant interface development to legacy systems, data-synchronization fun, etc. 2. Add SCOP functionality to SEBL to have one single, architected product set. To do this, the SEBL data model must be greatly expanded to include SCOP functions, all SCOP objects must be translated or re-written in SEBL (maybe SCOP's objects can be `seamlessly' called by SEBL's, I'm not technical enough to say for sure). The end result is one data model, one user interface, one tool set, one installation, one product set. 3. Rewrite everything in SCOP -- not a possibility. I believe that SEBL will do #2 after #1. However, the SCOP-to-SEBL migration path can only be ugly. SEBL may provide some special conversion utilities, but I can only envision a complete re-implementation. Let's say that the complete SEBL/SCOPE product is released as `Siebel 99'. For existing SEBL customers, you get the `one button conversion' (another topic entirely). For existing SCOP customers however, you've got a big choice -- re-implement, or stay on current SCOP architecture. I would also bet that SEBL maintains the SCOP product for the existing user base for at least a couple of years. This would not be unlike SAP's R/2 and R/3 customer base. Both products are maintained and enhanced, although all of the emphasis is on R/3. Getting from R/2 to R/3 is a re-implementation.