Process/Project SBL - Process - Siebel Implementation

Description

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
Configuration
Data Migration
Testing
Deployment
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.

Configuration

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.

Testing

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.

Deployment

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.