Siebel CRM Configuration Best Practices.
This article discusses recommended practices for Siebel configuration.
First and foremost, you need to evaluate whether the business process can be changed or modified as it is usually more cost efficient to change the business process rather than change the application. You should change the application when the cost of changing the business process is greater than changing the Siebel application.It is always advisable and recommended to make minimal changes to the standard Siebel application; this will reduce the possibility of unexpected errors and also the possible performance issues.
You should always try to use existing Siebel object definitions wherever possible. This will make the application easier not only to maintain but also during upgrade process. General rule of thumb is to modify existing Siebel repository objects or copy existing repository objects rather than create new objects. It is also highly recommended do not delete/inactivate existing Siebel objects as they may be referenced by other objects.
Approach: You should plan the Siebel project from the top down which is nothing but determining UI and Siebel application, then determine the changes required to business objects and business components, then determine what changes this results in the data level. You should implement the Siebel project from the bottom up (i.e. Edit the data level objects and then edit the business object level, then edit the UI layer objects).
Business Components: For business components you should take care when copying business components. Care should be taken not to define system fields on the business components. You should name all new business objects and business components with a prefix that identifies the project and the name you give an object should be descriptive and meaningful to that object. Also make sure if you do copy a business component that you specify, the name of the original business component in the Upgrade Ancestor field so that the object can be easily upgraded.
Applets: For applets you should take care when copying existing applets, only copy when you have to make major changes to the applet. It is usually best to modify existing applets. Reuse with applets is the best methodology. This saves a lot of time and maintenance. As with business components/business objects, name your applets with a meaningful descriptive name and prefix with the project name acronym.
Views: Ensure that you modify existing views just making changes to the Title and applet layout of the view. Create a new view if no other existing views present a similar applet layout that you desire. As with applet/business components/business objects you should name new views with a meaningful descriptive name prefixed by the project acronym. When you use a view within the application you need to define the view in the master reference data and associate responsibilities to this view, otherwise the view cannot be viewed.
Scripting: Use scripting only only as the last option, and only when you cannot implement the required functionality through Siebel configuration. Scripting will always cause a performance hit on the application. If possible avoid scripting on applets; it is usually better to script on business components. Try to avoid writing scripts on events that occur frequently. Re-use script as much as possible using business services. Schedule regular technical peer reviews to ensure that the scripting is efficient as possible.
You should always enter comments in the "Comments" field for any objects that are modified. You should use a project standard for comments. The following is a good project standard:
[project acronym]-[initials]-[date]-[description2]; [project acronym]-[initials]-[date]-[description1]
Now, you can see that when multiple changes are made to an object these are separated by ";". [project acronym] = The project acronym for the implementation, [initials] = developers initials, [date] = date of the change, [descriptionx] = description of the change.
Objects: Please ensure that you perform a full get on local developer databases on a regular basis. Always use local database to make changes, never make changes on the server. The following strategy can be used to determine whether to make changes locally first or whether to check out a project to make changes:
1. If you are unsure what changes need to be made and wish to try something to see if it works, then perform a get on the projects you require and lock these projects locally. Then when you are satisfied take a Siebel archive (sif) of these changes and go to step 2 and merge these changes to the project.
2. If you are completely sure of what changes need to be made, then check out the project and make the desired changes and then check-in.
Related Posts
No comments :