article on siebel crm

Siebel's eBusiness Application and Controls

Siebel Systems Inc. is a worldwide provider of customer-focused e-business application software with more than 1,500 customers. To perform an application audit on this software, IT auditors should have a basic understanding of the Siebel eBusiness application architecture and the control considerations related to the quality aspects security, integrity, auditability and controllability. This article will focus on these two areas.

Process, application and technical architecture and related controls need to be aligned to make sure the configured software, data and support organization meet the organization's standards for integrity, security, auditability, controllability, availability, efficiency and effectiveness.1 Therefore, although not the main focus of this article, a high-level overview of customer relationship management (CRM) processes and Siebel's technical architecture will be provided as well.2

CRM Processes

In today's increasingly competitive global markets, businesses continuously must improve their operations. Having spent considerable effort and resources in previous years automating finance, manufacturing, distribution, human resources management and general office operations, many businesses now want to leverage information technology for their sales, marketing and service processes. Companies, both large and small, are looking to gain this advantage through CRM strategies that enable them to manage all customer contact points, including person-to-person contact, the telephone, e-mail and the Internet.

• Operational CRM (communication strategy level) is the automation of the customer-oriented front-end marketing, sales and service processes and their integration with back-office systems. An example of operational CRM is a customer database maintained purely for direct mailing purposes.
• Analytical CRM (marketing strategy level) is the analyses of the data created with operational CRM to better meet the needs and desires of customers. For example, relations between events and buying behaviors are analyzed, typically in a data warehouse (possibly with neural network capabilities).
• Collaborative CRM (business strategy level) is the overall communication and coordination model of a customer life cycle between the channels and contact points. In this collaborative CRM approach, business processes and a central customer database are drivers for success.

Siebel is designed to deal with all the different levels of CRM and supports CRM as a business strategy. It should be taken into account that the way CRM is implemented and effectively utilized will vary between organizations. It is dependent on many variants, including the way of doing business, buying habits of customers (e.g., convenience vs. specialty goods), industry (e.g., telecom with many consumers vs. forestry with a few business customers), company size, existing systems and organization structure.

Organization-specific aspects need to be incorporated in the process designs for marketing (e.g., campaign management, lead generation), sales (e.g., opportunity management, contact and account management and quotation management) and service (e.g., call center processes, service agreement management). These processes have to be related to the relevant business units and Siebel products. As a result of this mapping process, changes or improvements may be identified for the business units as well as gaps between the process design and the Siebel standard solution.

It is important for the IT auditor to be involved in the process design to ensure integrity, security, auditability, controllability, availability, efficiency and effectiveness requirements are defined for the core marketing, sales and service processes as well as for the management control and support activities surrounding these processes (e.g., interfaces with the backbone ERP software).

Siebel eBusiness Application Overview

Siebel eBusiness applications synchronize the data through one central repository regardless of the contact points (e.g., web, e-mail, call center, field visits and resellers). By having everyone in the organization working with the same repository (data are stored only once), a complete 360-degree view of the customer can be provided to every department or function on an as-needed basis with consistent and up-to-date information available throughout the organization.

The central customer repository can be accessed via different contact points with their related applications. Figure 2 provides an overview of the application areas covered by Siebel's eBusiness applications, including a short functional description and application components.

In addition to these function-related applications (horizontals), Siebel provides industry specific solutions (verticals) such as eFinance, eInsurance, eCommunication, eAutomotive, eEnergy and ePharma.

Underlying the different functional and industry applications are some cross-application architecture components that are required to have specific functionality available, such as security, workflow, data synchronization and replication, enterprise application integration, customization and software distribution.

As Siebel has many applications, it is important for the IT auditor (and consultants) to know which applications have been purchased. Although all business objects are delivered to the client and can be configured, license keys limit end-user access to those components that are licensed.

Siebel eBusiness Application Architecture

Siebel's eBusiness applications are based on a three-layer application architecture, namely user interface, business objects and database objects. It is important to understand what data are stored in the Siebel solution and the properties, rules and policies of those data. This will help the organization understand whether the data model supports the organization's business logic. This also allows the gaps to be assessed and determines how difficult it will be to meet requirements. The layered architecture allows rapid application development (RAD) for specific business needs. The amount of effort required is dependent on the layer where the change has to be implemented. For example, changing the location of a control (what users tend to call a field in other applications) in an applet in the user interface layer has less impact than adding a column in a table on the database objects layer.

User Interface Layer
End users work with the user interface layer. This layer consists of five components:

2. Applications—They are the components bought by a company (see examples of applications in Figure 3). An application has one or more screens.
3. Screens—They represent a certain business function, such as contacts, accounts, products and price lists. The tab bar that contains the screens usually has fewer screens than the menu bar for user friendliness reasons. A screen has multiple views.
4. Views—They contain applets (not to be confused with Java applets) with a minimum of two applets and a maximum of eight. For example, the views related to an account (screen) are opportunities, service requests, contacts, quotes and orders.
5. Applets—There are two main kinds of applets: list and form applets. List applets show a number of records as a list. Form applets reflect the content of a specific record.
6. Controls—They are comparable to what users typically call a field on a data entry screen.

[Note: In this article, italic is used to refer to the control component to prevent confusion.]

Business Objects Layer
The business objects layer represents the business logic. Business components can be thought of as a virtual database table that spans multiple real tables. It shows the data in the way the user chooses to view the data rather than how it is organized for effective data storage. The business component represents one business entity, such as service request, contact or activity. Business components can be grouped logically in business objects. Within a business object there is one leading component. For example, the contact business object consists of a set of contacts plus their related opportunities and service requests.

Each business component can belong to multiple business objects. A change to a business component affects all business objects that make use of this business component.

Business components and objects are linked with their respective applets and views on the user interface layer. In addition, fields and business components are related, respectively, to columns and tables on the data object layer. This application structure has an impact on configuring user requirements because a change to the user interface settings has a limited impact on other aspects of the implementation, whereas changes at the data object layer need to be more carefully considered because, although they may successfully address the reason for the change, they may unintentionally create problems in other areas of the application.

Database Objects Layer
The database objects layer contains the logical database design. The physical Siebel database runs on a third-party relational database management system (RDBMS). The data are stored in normalized tables. There are three kinds of tables on the data objects layer:

• Data—Stores user data
• Interface—Transfers information from/to legacy or back-end systems
• Repository—Contains object definitions of one or more Siebel applications

It is important to understand the parent-child relationships within the Siebel application as well as the relationship between the business entities (1:n; m:1; m:n). These relationships4 must be mapped with the entity relation diagram (ERD) of the existing data structure. In case relationships do not match, a trade-off has to be made between adjusting the current way of maintaining relationships and adjusting standard Siebel to meet specific business requirements. Furthermore, mapping the ERD with Siebel's business entity model may reveal that fields are not available in Siebel. In case users require fields that are not stored in the data objects layer, there are several ways to add fields in the data objects layer: use user extension tables, rename a column of an existing table, add a column to an existing table or create a new table (figure 4).

High-level Technical Architecture

Siebel's technical architecture is based on a three-tier client/server concept. There are three kinds of clients: dedicated, mobile and thin.

Dedicated clients connect directly to the database to update the data in real time. These clients typically are used for high-volume users like service and call center agents.

The mobile (remote) client updates data on the local database and synchronizes to the central database. Examples include laptop or handheld devices. This kind of client is used for remote users such as field services and field sales agents.

Finally, thin clients are used to connect via the Internet to the database. There are several variants of the thin client, for example

• Thin clients for Windows, which allows navigation through the data with a web browser (e.g., Internet Explorer or Netscape Navigator). This kind of client often is used for high-volume Internet and intranet users.
• Thin clients for Java, which allows Java applications to use the database in case there is a non-Windows operating system such as Sun Solaris (UNIX). This kind of client often is used for high-volume Internet and intranet users.
• Thin clients for HTML, which uses HTML to display the user interface. These clients are used in the Siebel.com applications and are best suited for Internet users, channel partners and infrequent internal users. Typically they are designed with the look and feel of the corporate web site.
• Thin clients for WML, which provides a wireless connection to the database via a wireless application protocol (WAP) device and a WAP server. WML and XML are used to specify content and user interface for WAP devices. The WAP server translates data from Internet protocol (HTTP) to the wireless protocol (WAP).

Each client uses a common executable file (.exe), repository file (.srf) and configuration file (.cfg). The .exe file is the engine for Siebel's eBusiness applications. This file is the same for all applications and cannot be modified. The .srf file specifies the configured application definitions and behaviors (business rules). This file can be modified with Siebel Tools. The .cfg file defines which .srf file and database to use (e.g., gateway server, enterprise server, repository file, file system, security adaptor and database). This file is application specific and is a text file with initial settings (including security settings) for the application engine. If located on the client or user's computer, this file can be modified by the end user without further file protection.

Software Change Management
The Siebel Tool allows the set up of development projects. Projects relate to a part of the application (e.g., a business object and related information). Standard Siebel has pre-defined projects that can be adjusted by the client. Persons configuring the application can be granted access to specific projects. Typically project members work on their personal computer to develop the project. When they select business objects from the master development repository and download them to their personal computer, the business objects and related information are locked for other users.

Once functionality is configured, an .srf file for testing will be created by selecting the (latest) changes to be included in the .srf file. After user acceptance, the new .srf file can be distributed to the clients. Proper version control of the .srf files is required to prevent regression. Siebel Tools has programs that support the comparison of two different .srf files (e.g., development vs. test, test vs. production or current .srf release versus new .srf release).

Siebel Anywhere, a software distribution tool, can be used for automatic upgrading clients with the new .srf file (and .cfg file if required). Dedicated and mobile clients have the .srf and .cfg file locally, whereas thin clients use the .srf and .cfg files stored on the object management component of the server. Therefore, from a software change management point of view, dedicated and mobile client usage requires more work than thin clients, because each client needs to be provided with the latest configuration (.srf) file. For thin clients, the business logic is stored in the object management component of the server and needs only to be changed in one location because all thin clients access the data via the object management component.

Synchronization
Synchronization of remote clients' databases with the server database is triggered by the end user. If a dedicated client modifies records after a remote client downloaded the data, the data on the server database changed by the dedicated client will not be overwritten (in case of conflict, the server database prevails). The remote end user will receive an error message for the record in question. If two remote clients attempt to modify the same records offline, the remote client that synchronizes its remote database first will update the server database. The other remote client will receive an error message for the record in question when synchronizing the remote database.

E-business Application Control Considerations

IT auditors should determine which quality aspects (e.g., security, integrity, audibility, controllability, availability, efficiency and effectiveness) will be taken into account for the scope of the application audit. This article focuses on the quality aspects: security, integrity, auditability and controllability. Each is discussed in relation to Siebel's application architecture. The information on controls provides auditors with a good basic insight on the available controls within Siebel, but is not exhaustive.

Security
Security for software applications means that only authorized persons may make use of the application through authorized procedures and system authorizations that are in line with organizational responsibilities. Aspects of security are privacy, confidentiality, segregation of duties, identification, authentication and authorization.

Identification and Authentication
Users must be defined on both the Siebel application and the database to gain access to Siebel data via the user interface. If security integration is activated in the .cfg file, the user does not have to explicitly logon to the database. For the communication of passwords between Siebel and the database, encryption can be activated via the .cfg file parameters (40-bit and 128-bit encryption based on Microsoft's Crypto API). Access to the database must be restricted to authorized users and programs only.

For authentication, Siebel offers the possibility to use security adaptors (activated in .cfg file), such as LDAP. In those cases, authentication is not done via the Siebel database but the LDAP. When using an LDAP, the security parameters in the .cfg file need to be reviewed for the requirement for user ID and password or activation of single sign-on (users can be authenticated via the operating system login).

Another consideration is the identification and authentication information to login to other systems. This information can, in some cases, be stored in the .cfg file. Proper .cfg file protection must be in place to ensure confidentiality.

Finally, security for .com applications is done via HTTPS if the view (user interface definition) is marked as secure. Users can logon to the Siebel web engine application via a cookie (after having selected "save my user ID and password") or via an explicit user ID and password entry. If they have logged in via a cookie it may still be useful to have users logging in to certain parts of the web site with an explicit user IDs as well (e.g., order history). This can be activated in the view (user interface layer).

Authorization
Each user ID in Siebel is used for ownership and has assigned:

• One or more responsibilities
• One or more positions

There is no relationship defined in Siebel among positions and responsibilities and each responsibility or position can be assigned to one or more user IDs.

Responsibilities provide the view selection (opportunities, quotes, price list). Persons with the same responsibilities (views) may have access to different data records based on their assigned positions (a position in Europe gives access only to European records, whereas a North American position gives access to North American information). Filtering of data records is associated with:

• Organization—Positions restrict access to records based on organizational unit ('all' view). Each position belongs to an organizational unit and each record contains one or more organizational units, hereby restricting the positions that can access the information.
• Team assignment—Positions can be assigned to a team and the teams can be assigned to certain records, such as opportunities, accounts and contacts. The whole team can access and maintain information assigned to the team ("my" views). Each team has a primary contact, which allows special access, such as merging and deleting records. It also allows the manager of the primary contact to view the team's data ("my team" view). If a team is defined across organizational structures (e.g., two members from the European organization and three from the North American organization), team members can view their team information even if their position is not assigned to both organizations in question ("all cross-organizational" view).
• Ownership—Ownership relates to records that can be accessed only by the owner and include service requests, quotes and activities. The creator will be assigned as the owner of records, which allows access to special functions such as merging and deleting records. If persons change position, they remain owner of the records unless the administrator makes a mass change.

Visibility can be configured to be different for different users depending on how they connect to the database, namely dedicated or remote clients. It can be defined per view whether or not the view will be available for local (dedicated) access only. Typically remote users do not need to replicate "all" views information, but mainly " my" views.

Integrity
Information system integrity is the extent to which data and information systems are a reflection of reality. Aspects of integrity are correctness, completeness, accuracy and timeliness.

Controls in Object Definitions
Many controls can be found in the different layers of the application architecture. Table controls can be activated on each component in the layers controls. Examples of such controls include, but are not limited to:

• Application: Add, remove or relocate Windows menu items
• Screen: Add views to an existing screen
• View: Require (or not) explicit login to gain access to the view
• Applet: Allow (or not) for deleting, inserting, merging and updating of records
• Control: Set control to read-only or allow drilldown possibilities on controls
• Business component: Allow (or not) for deleting, inserting, merging and updating of records, activate (or not) logging of changes, allow (or not) visibility of multi-value links, allow (or not) owners to delete records, or limit users (or not) to only pick from selected values in dropdown menus
• Field: Hide (or not) fields, allow (or not) multi-values in a field, set (or not) a default value for a field, set (or not) a field to read-only, set (or not) a field to required field, or determine the length and type (e.g., text, numerical, date) of a field
• Table: Type of table, such as data, interface, dictionary
• Column: Allow (or not) null-value, set (or not) column to required, determine length and type of column, set (or not) default value for column, or set (or not) specific validation rules

Some of the controls appear at several places throughout the application architecture. Therefore, there needs to be consistency between the different levels (no conflicts) to ensure reliable data processing. This can be achieved by having adequate design standards and test procedures. Another control consideration example for consistency in reliable data processing would be the views. Information can be entered in both list and form applets and therefore the control requirements in both applets in a certain view need to be aligned. However, this may not be the case as list and form applets are defined and configured separately. If the controls in the list and form applet in a view are not identical, one applet needs to be modified or the user needs to be trained on which applet to use to enter information.

The layered architecture offers the possibility to fine-tune controls on the layer where the control is most effective and most efficient from a maintenance point of view. For example, a control in a column on the data objects layer will be active for all fields in the business object components that are linked to the column. Consequently, the check will be in place for all applets in the user interface layer that makes use of the related control. On the other hand, a control in a field in the business object layer is only in effect for that field. If another field relates to the same column, field controls can be set differently for that field. Consequently, the user may have different controls dependent on the applet used and the controls (and related fields) in the applet. In short, activated controls on the data object layer are more applicable (impacting) than activated business object layer controls, and activated business object layer controls are more applicable (impacting) than user interface controls.

Controls Via Automated Tools
To organize the CRM process more effectively, Siebel offers tools to support the marketing, sales and service processes. Some of the automated tools, if implemented properly, also will strengthen the control environment, especially in the data entry area. The automated tools (with examples) are provided in figure 5.

In general, the automated tools are not part of the first wave of the CRM implementation cycle as they typically fall under the nice-to-have category. In addition to these automated tools, users can configure data entry preferences themselves. This includes confirming deletions and setting up default sales methodology for opportunity creation (to limit entry errors).

Controls for Data Quality
Siebel offers controls5 to prevent entry of identical records from a typing technical point of view—user keys—as well as tools to verify duplicate entries from a logical point of view—deduplication. Furthermore, Siebel has tools to ensure information is entered consistently and accurately—cleansing.

User keys: Siebel generates row IDs for all table entries [data object layer]. The row IDs are unique cross tables (primary keys). Although this results in technical unique records in the database, logically user keys need to be defined by the organization. This means that one or more columns must be identified as a unique set of values to prevent duplicate records. Furthermore, tables may have foreign keys that are used to refer to a row ID of a related (parent) table. Foreign key data are maintained by the Siebel application to ensure referential integrity. (Note: Data that are part of foreign keys should never be updated directly using SQL. Integrity may be lost if references are not updated properly.)

Deduplication: The deduplication tool identifies possible redundant data, such as Bill J. Smith vs. William Smythe or Internatl Bus Machines vs. IBM. This functionality can be activated for account, prospect and contact records. Like cleansing, deduplication can run real-time or batch. However, deduplication requires intervention of the user because the system will provide the user with the potential duplicates and allows the user to choose whether the information is duplicate or not.

Cleansing: The cleansing process occurs in the following ways and can be run real-time or in batch (periodically):

• Address correction (street, city, state/province and postal code are stored in a uniform format; logic verification is included for US zip codes)
• Standardization (prospects, contacts and account names are stored in a uniform and consistent format)
• Capitalization (changes name and address field information to all lowercase or uppercase)

International Control Aspects
Siebel applications are used in many global firms and deal with internationalization by the ability to display pick-list values in the user's active language, supporting multiple currencies and associating string, number and date display with the regional settings in the operating system. A few international control considerations will be described:

• Field size: The size of entry controls (and related fields and columns) and control descriptions on applets may have to vary dependent on the language. For example, "car" in English is " voiture" in French. Therefore, ensure that the loaded language shows all the information in a user-friendly way and allows all information to be entered completely in a control.
• Language: Not all industry Siebel applications can handle the same languages. Furthermore, standard applications are translated automatically during compiling .srf files (e.g., dialog boxes, buttons, error messages, reports and online help) and one .srf file can have several languages. However, modifications are not translated automatically and therefore cause extra translation efforts, especially if a modification is applicable to many countries.
• Keyboards: Due to the binary space differences of keyboards not all countries may be able to connect to the same Siebel repository.
• Repository management: Although one global database may be desired in many cases, the organization may consider splitting the database and periodically synchronizing the databases. Factors to consider include, among others: whether or not there is a desire for regional control over the database (e.g., for support reasons if the time difference is large), system performance when many users are on the system and performance of the underlying technical infrastructure is not optimal, and the extent that customers in different regions are common with other regions.

Auditability
The auditability of an information system is the extent that it is possible to gather information about the structure and operation of that information system.

The setup of the process, application and technical architecture needs to be documented from a user, process, controls and IT management point of view, including cross-references, to get insight on the structure of the system. To verify the operation of the information system, fields to be logged need to be identified. Configuration needs to be able to report on changes. The transaction logging should be activated at the business object layer. Alternatively, database logging can be activated and used. If audit logging is not set up, only the latest information can be retrieved (for example, there is no standard reporting with changes in user authorizations). An exception to this includes some industry solutions where audit logging is set up to meet industry specific regulations, for example ePharma.

With respect to the logging it should be taken into account that in release six of Siebel, all transactions are stamped with the date and time where the server is located. There is no automatic translation to the local time.

Controllability
Controllability is the level to which an information system can be adjusted, to ensure it meets the ongoing requirements. This includes aspects such as flexibility (adjusting or extending the application), maintainability and connectivity between modules and other systems.

Configuration Changes and Modifications
Changes in configuration tables can be made with Siebel Tools. For maintenance and upgrade reasons, any configuration change and modification needs to be properly documented and it is recommended to limit the changes to the standard Siebel application architecture. The configuration tables and source code will be overwritten during release upgrades. As explained in the application architecture overview, the complexity of a configuration change depends on the layers that are affected by the change. Changes in the source code (Visual Basic) and data structures are not recommended, but if they occur they have an even larger impact on the upgrade process. When making a modification, it is recommended to copy the standard Siebel object and rename it (e.g., starting with the company's name). This allows for easy analysis in upgrades.

Connectivity
The different Siebel applications can be connected relatively easily as Siebel is structured in building blocks. However, from a security, integrity and auditability point of view, the process, application and technical architecture must be re-assessed if applications are added. This is needed to ensure the new process, application and technical architecture do not introduce new or increased risks to the existing environment (see example in figure 6). This is especially important as all applications make use of the same central customer repository.

Integration with other applications, especially back-end ERP systems, will have an impact on the success of the CRM package implementation. A successful integration prevents double data entry, provides reliable and timely information (e.g., a 360-degree view of customers) and provides users with one user interface. Siebel offers a wide variety of interface possibilities. Dependent on number of records and type of interface required, (e.g., synchronize, export, export/import, display or interact) an interface type could be selected. Siebel offers:

• Synchronize Siebel data with non-Siebel data
• Display non-Siebel data in Siebel applets
• Display Siebel data in another application
• Incorporate the Siebel user interface into another application
• Incorporate non-Siebel user interface within Siebel application
• Export Siebel data

The e-business application integration (EAI) offers tools to support the above mentioned interface types. For example, Siebel offers an SAP connector to exchange orders between Siebel front office and SAP back office via intermediate documents (IDOC) and the business application programming interface (standard SAP interface—BAPI).

Conclusion

The applications controls design needs to be integrated in an overall system control approach that covers process, application and technical risks. These risks and controls need to be defined for each organization because CRM will be implemented differently in organizations dependent on their CRM strategy (operational, analytical or collaborative), way of doing business, buying habits of customers, industry, company size, organizational structure and existing systems.

The flexibility for organizations to implement Siebel eBusiness applications controls (or not) contains the most risk as organizations typically focus on the functional aspect of a CRM implementation, especially if they are under pressure to go live. As CRM software provides a single repository for a 360-degree view of the customer, the quality of that data is crucial to the success of the implementation. Although high-quality data do not necessarily mean an organization is optimizing the interaction with the client, high-quality data is a prerequisite to effectively apply CRM. Therefore, an IT auditor should be involved in Siebel implementation projects as control advisor in the design phase and implementation phase. Areas of concern for CRM applications are not different than ERP applications. Five areas of application level concerns, typically for CRM software, include (but are not limited to):

• The organization change management to implement cross-organizational streamlined CRM application settings (and standardized business processes) and harmonized data definition and usage, to gain corporate wide benefits from the CRM application
• Integration with legacy or ERP systems to make sure data can be accessed or updated in a timely, complete and correct manner
• Data conversion to ensure upon going live that initial data are clean, complete and reliable. The data cleansing process requires particular attention, as data typically come from different sources, have different formats, are incomplete or incorrect and lack data elements that are required in the new CRM package.
• Alignment of business process and application controls, to ensure the ongoing quality of the data (e.g., access controls, data entry controls, reports to detect erroneous data processing and adequate end-user training)
• Modifications made to the application, because modifications often are not adequately documented for maintenance, require additional upgrade efforts (especially if modifications are implemented in several countries with different languages) as they will be overwritten when upgrading the system, and introduce additional security, integrity and controllability risks

To make adequate application risk assessments, provide advice on efficient and effective controls and add value to the project team, IT auditors should understand the basic application architecture and control considerations of the CRM package that is being implemented.