Process/Project SBL - Process - Siebel Implementation

Stage SPA00 - Plan and Activate
Stage SRP00 - Release Planning
Stage SRQ00 - Requirements Definition
Stage SFA00 - Functional Analysis & Design
Stage STA00 - Technical Analysis & Design
Stage SCF00 - Configuration
Stage SDM00 - Data Migration
Stage STS00 - Testing
Stage SDP00 - Deployment
Stage SUT00 - User Training
Stage SCE00 - Control and End
Process Flow
Templates for this Process
Show all Techniques


Customer Relationship Management (CRM) is a multi-faceted approach to improving one's business through the successful acquisition and retention of a select customer base. CRM encompasses more than a technical solution. Before implementing any kind of application for automating and improving customer relationship handling, an organization must understand its customer market and define a strategy for changing the way it conducts business so that it becomes customer-centered. It must also prepare its staff for the resulting cultural change in their approaches to handling customer-related issues (e.g., call center and sales representatives must learn new ways of interacting with customers). In other words, a CRM strategy and readiness initiative (i.e., CRM Assessment) must first take place if the implementation of a CRM technical solution is to be successful.

This Process presents james martin + co's recommended approach to implementing the Siebel Enterprise Application in an organization. It is a project guideline for customizing and implementing the Siebel package to address the organization's CRM requirements. The scope of the Process does not include assessing an organization's readiness for CRM. A complete CRM Assessment should already have been conducted to determine the organization's reasons for implementing CRM and what kinds of application functionality would best serve the organization in achieving its goals of improving customer relations. The strategic decision to implement CRM using Siebel as the technical solution should have been made prior to launching a project based on this Process.

In order to understand and exploit the many features of the Siebel Enterprise Application and master the complexities of implementing a technical application package, all implementation project team members (including the client organization's project team members) should undergo Siebel Enterprise Applications training. This Process assumes that all project team members have a working understanding of the look, feel, and functionality of the Siebel application and are familiar with Siebel terminology. Relevant class topics include Using Siebel Enterprise Applications, Application Administration, Marketing Administration, Service Administration, Synchronization Administration, and Configuration and Customization.

The following development stages comprise this Process:
Release Planning
Requirements Definition
Functional Analysis and Design
Technical Analysis and Design
Data Migration
User Training

In addition, there are two Project Management stages that can be used as a guide to institute, monitor and conclude the project:
Plan and Activate
Control and End

The development stages are described below.

Release Planning

In this stage the project leaders confer with the organization's management to determine what kind of high-level functionality should be implemented in the Siebel application to meet the pre-defined business requirements of CRM. The requirements are used to determine which base and expansion modules of the Siebel Enterprise Application will be implemented, and the scope of the project is set. The Siebel modules and supporting third-party software are purchased. Additionally, the development. production, training, and testing environments are specified for costing purposes, and the necessary servers and workstations are ordered for the development and testing environments.

At the end of this stage, the project leaders should have a high-level understanding of the expected functionality of the system, its architectural complexities, and its interfaces to other systems and projects, capitalizing on the overlap with other projects from the "MOST" perspective of integrating Managerial, Operational, Social, and Technical project components. This understanding is formulated in terms of a proposed Siebel solution that specifies the critical application components and estimates the technical architecture required for its implementation. The corresponding Release Strategy is then defined, which details planned releases, functionality to be included, iterations, timelines, major deliverables and dependencies on other projects.

The Release Strategy should be a logical roadmap for the incremental delivery of functionality to the organization's end-users. It should take into account how the Siebel system will interface with existing databases and systems as well as how it can beneficially impact or be impacted by other projects being conducted within the enterprise. A release strategy should define an incremental delivery such that the earlier releases constitute prototypes of user interface and application functionality, while later releases successively incorporate more of the actual enterprise data and interface more with existing systems (i.e., evolve toward the fully functional, final production release).

The goal of any Release Strategy should be to deliver new or additional application functionality to the users within four to six weeks of project startup or from the time of delivery of the previous release. Part of the release planning effort should therefore be to prescribe a minimum level of functionality which can realistically be delivered in this timeframe, and the additional subsequent releases necessary to delivery full functionality, including integration with other systems and external data sources on a graduated schedule. The Release Strategy should also consider the number of geographical locations and user groups to which the Siebel application will ultimately be deployed. A final production release is typically rolled out to a specific group of users first, then rolled out to subsequent groups of users on a planned schedule.

The Release Strategy will be incorporated into the Project Management Plan (PMP). The PMP will, by necessity, change as the understanding of the particular business requirements is refined, and as part of the followup evaluation after each incremental segment is rolled out to users and feedback has been captured. It is an important communication tool that should be used both for project team guidance and for addressing user expectations.

Siebel training for the project team should normally be conducted to coincide with the start of this stage (see Plan & Activate stage).

Requirements Definition

During the Release Planning stage, a high level Release Strategy specified which Siebel application components would be implemented to meet the enterprise's CRM goals. The purpose of the Requirements Definition stage is to ascertain from the end-users what functionality they expect and would like from the Siebel application in order to use it to do their respective jobs and achieve those enterprise goals. By analyzing existing systems and business documentation and conducting interviews with managers, users and technical infrastructure teams, the Project Team develops an understanding of how the business operates and its supporting infrastructure.

The main tool here are the "Siebel Business and Reporting Requirements" which need to be solicited from different types of users. The business and reporting requirements (which are functionality requests) are analyzed for feasibility, cost, and benefit of implementation, and the requirements are prioritized into the Requirements Definition, a comprehensive checklist against which the application design and configuration can be assessed. Key information on the user base and organizational structure is factored into the requirements as well; this information is instrumental in the functional design and subsequent configuration of the application.

The Release Strategy portion of the Project Management Plan is revised according to the Requirements Definition.

Functional Analysis and Design

This stage is focused on analyzing the data and functional requirements and breaking them down into components to create a stable Functional Specification from which to conduct configuration work. The customization of existing "vanilla" Siebel data and presentation objects is designed, including identifying extensions to the standard Siebel data objects and changes to the target Siebel database tables to implement the specified functionality.

In this stage you identify the logical data objects of the business and user actions on those objects that must drive the Siebel application so that the user interface can be designed accordingly. The presentation layer objects that allow users to access the underlying data and the contingencies for access are identified. The Functional Specification produced by this stage specifies the following:

- Business Objects to be used and whether modified from "vanilla" or created new
- Business Components to be used and whether modified from "vanilla" or created new
- Transactions performed on Business Objects
- Views for accessing each Screen (a Business Object is represented by a Screen)
- Applets and Reports which constitute each view
- Drill-down links between views
- Visibility classes for each view

It is imperative to confer with representative end-users in the development of all user interface components, to ensure that the final application will be accepted by the user base. The users are the key people whose business needs must be met by the new system, so the system must provide the functionality they need and be easy and comfortable for them to learn and use. The more users are involved in the analysis and design of the system, the more they will come to accept the system once it is configured and deployed, and the fewer the "must re-do" headaches for the design and development teams in the end. User requirements drive the design of screen flows, screen layouts, and other key user interface elements of the Siebel application to implement the proposed functionality.

Technical Analysis and Design

The purpose of this stage is to identify the components and configuration requirements of the hardware/software technical architecture to support the users of the Siebel application, with attention to capacity planning for increasing user and transaction volumes. Both the technical architecture that is needed specifically to run the Siebel application and the overall technical architecture to which the Siebel application is connected must be detailed. After the specified architecture is thoroughly reviewed, the hardware/software components are procured.


During the Configuration stage, the custom Siebel Enterprise Application is configured based on the Functional (design) Specification. Although design specifications have already met with user approval, it is important to involve users in the actual configuration activities as well, to ensure their satisfaction with the look and feel of the application as it is transformed from a design specification to a tangible, functional system. Interim configurations will be prototypes of the functional application. The end product of the iterative configuration cycle is the configured application that is quality reviewed and prepared for deployment.

In the Configuration stage data and presentation layer objects are configured, the database extensions are implemented, and Siebel VB scripts are developed to perform any necessary special functionality, The release is reviewed for stability and quality before being tested by users (User Acceptance Testing is covered in another stage). After users have tested the release, change requests are evaluated and fed back into the iterative release cycle accordingly.

Once the final release has been configured, the system is reviewed for production readiness, in preparation for deployment. In addition, supporting materials are developed to train and guide Operations and support personnel and to orchestrate the deployment.

Configuration employs a rapid application development (RAD) approach to deliver multiple successive prototypes of the Siebel application, based on the written specifications received from business requirements gathered at user focus meetings conducted in the first weeks of the project and from industry renowned practices. User representatives will trial test each prototype and in turn will provide immediate feedback on suggested changes. These change requests will be prioritized by scope, importance, scheduling and budget, and evaluated by the project team and the client organization for incorporation into subsequent releases.

Data Migration

Data migration is the set of procedures for moving data from source systems into Siebel. It is done both for systems which Siebel is replacing and for systems with which Siebel will interface on an ongoing basis. This is an iterative activity that happens concurrently with Configuration.

This stage involves acquiring the external source data records and ensuring that the data is clean and format-compatible with the Siebel base table format. The automated procedures required to load information from the source systems into the Siebel database are built. The data is then extracted from the source systems, cleaned, loaded into the Interface Tables, and then loaded by EIM into the base tables. The data migration routines should be thoroughly tested. The data load activity can run via the batch processes and may be performed iteratively until all data is loaded successfully. The routines for manually entering data into Siebel should be designed and conducted where necessary as well.


The purpose of this stage is to conduct User Acceptance Testing (UAT) and System Performance Testing on the configured Siebel application.

Develop a UAT plan and test case scenarios to guide a select group of key end-users in testing the user interface and functionality of the Siebel application. It may be useful to specify what kind of data to feed into the test cases (e.g., certain ranges of values). Test case scenarios should be defined for all test conditions and include the input, the required user actions, and the expected results. User Acceptance Testing should address all user profiles (e.g., sales support, sales rep, sales manager, sales director). Different user roles should have different access rights and see different views, and these differentials should be verified through testing. The Plan should specify by business area the users who will test the application and the schedule for testing, taking scheduling constraints into account.

Develop a SystemTest plan and scripts for testing the overall performance, functionality, speed and capacity handling of the Siebel application under multiple user conditions, both connected and remote. (An automated tool may be used for this type of testing.) Test scripts should enable testers to check for:
- acceptable speed in performing transactions
- production of expected transaction results
- remote users' synchronization and initialization
- remote users' visibility
- desktop workstation performance

Install and configure the testing environment and conduct the tests according to the test plans. Note: The Testing environment may also be used for end-user training, although a separate training environment may be set up if feasible according to the project needs and specifications.


In this stage the Siebel application is rolled out to the user base. The rollout should encompass one group of users at a time, as per the Release Strategy. The production server is loaded with the control data, the interface systems are backed up, the configured application is deployed, and the support functions are set up to support the newly deployed system,

The final step in the rollout is to conduct follow-up sessions to elicit feedback from users on their reactions to the newly deployed Siebel system. Evaluate to what degree the release met user expectations and measured up to delivery promises made in the Release Strategy and document the user feedback. Review the results of the rollout and compare them with the original Release Strategy and modify the Release Strategy accordingly. Finally, obtain the formal signoff from the Executive Sponsor to proceed with the next release of the application.

User Training

It is vital to the success of the new Siebel system to train business users in its operation and to train system support personnel (such as help desk staff) in both the system operation and activities related to its installation, removal, adjustment and interaction with other systems. In addition, it may be necessary to develop new procedures, policies, job descriptions, competencies, incentives, etc. to facilitate the cultural change needed to implement and use the Siebel application. The major activities in this stage include:

- Prepare for Cultural Changes
- Create Training Schedule
- Learn Business and Application
- Develop Training Materials
- Conduct User Training
- Evaluate Learning

Keep in mind that the changes inherent in the above issues may be met with resistance. Consequently, the introduction of the Siebel application must be done in a sensitive manner. Providing incentives, encouragement, and support is key to helping people making the necessary changes in the way they do their jobs.

Process Flow


"Words are the most powerful drug used by mankind."

- Rudyard Kipling