Anyone already live on Siebel 8? - General CRM(Archived)

We're considering upgrading to Siebel 8 and wanted to see if anyone had any feedback on system stability, and performance.

I'll let Yannick and others talk to specific customer experiences, but I will say that at the product line level we are tracking Siebel 8 metrics very closely. There are two things to remember: first, unlike Siebel 7, we did not make a large platform change; Siebel 8 was built on the 7 platform. Secondly, most of the changes we made on the platform side were additive (Task UI and ADM, for example), so there were few changes which would have caused regressions.
According to our metrics, customers are filing Service Requests at about only half the rate they did for 7.8. This ratio has held roughly constant over the last nine months since 8.0 was released, which means that customers have had the chance to really work through the system and have good experiences with it.
We will continue to monitor our quality closely going forward to ensure that we provide the highest quality releases to you.
Scott Nash
VP, Siebel Product Management 

not to drag you to our booth...:)....but i do have a few tips that you might be interested about, come on by and i fill you in (moscone south, booth 310), ask for yannick. 

We considered an upgrade an did a POC. We are currently on version We decided that we outstanding product defect was to much to facilitate a smooth upgrade. Issues like Taks Based UI defect, Global variable in script, ST engine, Performance in Tools Find Functionality. We are waiting for Siebel 8.2 - as Siebel 8.1 does not have all defect fixed yet.
Kind Regards
David Dommisse


Oracle Demand Planning or Demantra?

It seems fairly obvious that if you are starting out an implementation (or even part way through), you would cease implementing Oracle Demand Planning (ODP) and implement Demantra. I have read that all development work was ceased on ODP (even though some new features have been implemented in ODP R12). Further, I have read that there is no simple migration path from ODP to Demantra (due to the very different data structures).
My questions:
1. Do you agree with my comment about ceasing the implementation of ODP and resuming with ODP, and if not, why not?
2. Is there any known migration path between the two products that is supported by Oracle or is a completely new implementation needed?
3. What are the comparative costs of the two products?
4. What are the technology stack requirements of the two products? (particulary of Demantra).
Thanks, as always. 
We just canceled our ODP implementation and started a Demantra implementation. The analyst was finding too often the ODP plans had to be dropped and recreated whenever anything went wrong, which was happening too often to be comfortable with the technology. Also, if you are using DP only, you might be able to convince Oracle to swap your ODP licenses for Demantra DP licenses.
Here are the documentation links I have. The Installation Overview and Diagram note has a good image of the technology stack. I have 11.5.10 with Demantra 7.1.1 and 12.0.6 with Demantra 7.2 along with Windows VMs and 10.1.3 OAS servers all running on the same Thinkpad, so you do not necessarily require all of the horsepower described on the notes.
Oracle Demantra Documentation Library
EBS-Demantra Integration Installation Overview and Diagram
List Of High Priority Patches For Oracle Demantra Including EBS, Siebel and E1 Integrations
List of High Priority Patches for the Advanced Planning & Scheduling Suite
Oracle Demantra Installation for Release 7.1.1
About Oracle Demantra Supply Chain Planning for Release 7.1.1
Oracle Demantra V7.1 Demand Management Documentation Library 
I would agree with the previous person's reply.
It is not an easy exercise moving from ODP to Demantra. See below powerpoint slide from Demantra SIG at OAUG
You will need to do a completely new implementation of Demantra as there is no path to convert automatically.
There appears to be a lot more Demantra consultants than ODP consultants (perhaps as Demantra was being used more widely). Getting an ODP consultant is almost impossible and we found that fixing bugs was taking a long time.
I strongly suggest abandoning this undertaking and re-evaluating your situation. Do you really need a tool like ODP (or indeed Demantra)? Perhaps you can make do with Inventory forecasts - maybe with some customisation.
Just my 2c worth. 
with regards to point 1... demantra is a better tool; it will create better forecast numbers and will provide a much more sophisticated end user experience. however the answer to your question is not always an obvious one.
firstly lets talk about finance and schedule. ceasing an implementation that is costing a large sum of money in favour of a newer product may not be the right course of action. budget alarm bells will start ringing since the delivery schedule will now be off the chart and the costs will only go up. is the implementation required to fix legacy system and data problems? if so there will be groans from the people that need the forecast numbers when they hear that the current inaccuracy will continue because some fabled "even better numbers" will be available somewhat later than promised.
what about stability? odp has it's fair share of problems but it is still much more robust than oracle demantra and depending on factors such as company size, structure, product life-cycle, forecast horizon and methodology demantra may not even provide a better solution. an r12 implementation of odp would survive for a number of years before requiring an upgrade and by then newer and better versions of oracle demantra will be available. there are a lot of customers still using odp and oracle will continue to support them.
don't forget the bigger picture and plan for the future. planning and forecasting solutions need to be flexible - whatever solution you use you should expect that it will need to evolve and part of that evolution should be a product migration. if the planners that are expected to use the new tools and process are not yet skilled at forecasting (maybe they just manipulate numbers in excel based upon weekly meetings?) then the basic approach to skills development might be as follows: start simple, then develop a more sophisticated approach and finally create a sophisticated forecasting solution (this pathway could take years). if you don't yet know the medium or advanced strategy then how can you possibly know which tool is best suited? start simple with odp knowing that in two years when you will want to move to a more advanced forecasting approach your users will understand what they want. at that point you can decide whether to stick or twist.
as for the other questions: 2 is a no. 3 & 4: don't know (sorry)
good luck and let us know what you decide.

OEM and SLAs

Does the latest version of OEM provide any kind of support for Service Level Agreements (SLAs)? If not, is there any current Oracle product that provides such support? I know that Amberpoint supported SLAs, but I have heard that Oracle will not be continuing use of this product. What is the future plans for Oracle and SLA support? Any info would be appreciated. Thanks,
If by 'supporting SLAs' you mean reporting on component/application availability then yes.
I've gotten quite involved with the Service Level Management pack as of late and at it's simplest form you can establish hours of operation and report on up/down of components or synthetic transactions against an application. You can then present this information in customer friendly dashboards showing how you have faired over the last 24hours, 7 days, 3 months.

Running Multiple Versions of OBI on One Desktop

I'm hoping that someone can give me some ideas.
My team is responsible for supporting OBI, both from a hosting, as well as a admin/application, perspective for multiple business units across our company. Because each business group can be widely different, each application instance can be as different. OBI is relatively new in our company, but I can see a time coming (and coming soon) where we're going to run into the problem of having to support different releases of OBI. There are always going to be early adopters of new releases, as well as business groups whose requirements insist on a more conservative approach. Since we need to use desktop admin tools in order to perform migrations, open & edit RPDs, etc. we are concerned about how we are going to be able to support the varying OBI releases being used by our customers.
Does anyone have any ideas or tips on how one can run more than one desktop version of OBI on one machine?
Thanks for any ideas.
Debbie Sullivan / New Hampshire

Key things to consider upgrading RMS v9.0 to ORMS v13.0

Hi All,
My client is currently using RMS v9.0 and are thinking about migrating to ORMS v13.0. We are trying to put together a deck with things to consider for migration. Does anyone have any experience with the migration? Any sort of input will help us.
Thanks in advance,
There are drastic differences from RMS 9 to 13 in the data model.
A comprehensive data mapping exercise is needed to map v9 tables to v13.2. 
Hi Rajesh,
You are going to face a lot of challenges in that project!
I doubt you'll be able to get specific advice on what to look out for. You need to handle this like any other large software replacement / redevelopment project. Make sure you do not underplay the analysis that will be required as this is less of a 'migration' project and more of an implentation of a new system. There is no upgrade path from 9 to 13.
As mentioned above, there are wholesale differences in the data models, however I don’t think it’s worth performing an exhaustive data mapping exercise – that’s useful for data migration perhaps, but it's too low level to tell you what the differences are between the systems. You need to understand what has changed functionally and how this impacts on the business processes – this is where the greatest cost for the client will be.
Anyone still on v9 has probably had the software heavily customised and may have custom integration to non-Retek suite products. You'll have the additional challenge of very little Oracle Retail support / expertise so it may be tricky to identify what is base and what is a mod – hopefully in-house support is good?
On top of the functional / gap analysis you will need to give a decent amount of attention to the process change that will be introduced, this includes training requirements.
Ideally integration will need a complete overhaul, but to save time and money the client may expect you to 'make RMS v13 output data as per the current v9 solution' –this may be possible to a certain extent but you'll probably lose some of the new functionality and will borrow trouble for the future.
I've worked with a company that have started a very similar project countless times, only to panic at the scale of change involved and bury their head in the sand again.
Good luck and please keep us informed of your progress / challenges and so on! We can offer better advice if you have more info about the environment (Is other Retek software involved? Is this being replaced as well?)

Differences between CC&B v1.5 and CC&B v2.3.x?

Hello everyone..
Where might I find, or can someone describe the conceptual / architectural changes between the old v1.5 and current - I assume v2.3.x is current - versions?
Just after the high level differences, core technology differences, major changes to the way the product works, stores data, integrates etc..
Not the incremental "extra" features list..
Hopefully someone can point me in the right direction.
The older version of CCB has more of Cobol programming and any customization to be done is carried out more in COBOL, where as the newer version involves java programming. 
So has all of the core code that makes up 2.3 been re writen in Java?
Or is it just the new stuff in Java - any of the old stuff still in COBAL? 
What is the impact to technical and functional people?
Could a technical resource with skills to install, configure, maintain 1.5 easily transition to 2.3? some minor "update" training and away we go or?
Could a function resource with skill to understand and explain, train, document the applications functions easily transition? what would be required?
What has changed for CC&B users between the versions?
Do Oracle have any doco on the differences at all? 
Hi Paul,
This is a MAJOR upgrade and is both functional and technical, althoughly with largest focus on the technology change.
I don't have access to the documentation, but, if you are are working for an organization considering the upgrade, I recommend you work with someone from your Oracle project team and dilligently plan for this.
Lot of COBOL has changed to Java, that is one part, but also the Tuxedo layer has been eliminated, etcetera.
Functionally there is a slew of new stuff as well, the major change being the advent Config Tools, but there are lists of other changes.
Some of the changes will affect your 24 hour clock due to impact on performance.
Enjoy ;-)
You should look at Doc. Id: 1204543.1 on Metalink.
This would give you enough information of each release starting from CC&B 1.5.0 until CC&B 2.3.1 in form of Release Notes.