Understanding divisions and organizations
Mapping real world entities to technical concepts is one of the key factors for successful software products. It is therefore quite interesting to see how the Siebel design team faced the challenge of bringing the complex hierarchical relationships of large corporations into the Siebel data model.
Early in the analysis phase of a Siebel CRM implementation project, the divisional or departmental hierarchy of the customer is analyzed and documented. The typical diagram type to document the divisions of a company is an organization chart. The following is the organization chart for an example company:
The Sales, Service, and Marketing divisions are subordinate to the Headquarter division. The Sales department has subdivisions, which define the territories (North and South) that the sales force operates in.
Setting up divisions
Once the divisional hierarchy of a company is documented, it must be translated to Siebel administrative data. An administrator uses the Administration - Group screen, Internal Divisions view—shown in the following screenshot—to enter and manage the division information:
This view allows administrators to enter and maintain information about a company's divisions. The example company visible in the screenshot (Vision Corporation) is part of the Siebel sample database and has four subordinate divisions.
In order to create a new divisional hierarchy, we can follow the steps in the task list below:
- Log in to the Siebel application using an administrative user account.
- Navigate to the Administration - Group screen, Internal Divisions view.
- Create a new record for the top-level division first.
- Enter address and other information if required.
- Save the division record.
- Create a new division for each subordinate division and use the Parent Division field to select the appropriate parent division.
- Use the explorer applet to verify that the divisional hierarchy represents the organization chart.
The following screenshot shows the explorer applet in the Internal Divisions view after the entry of the data from the example organization chart:
In order to distinguish the example company from other divisions in the database, the acronym "AHA " was used.
From an administrative perspective, we must be aware of the fact that organizational changes might occur frequently. These changes can include one department becoming subordinate of another, or other departments being detached from the hierarchy in order to become separate companies. Siebel administrators must be informed of these changes in order to be able to adjust the division data in a timely manner.
In your demonstration environment, use the instructions in the above section to create a division hierarchy. You might want to use the example or create your own divisions.
Setting up organizations
When a division or an entire partner company wants to use the Siebel CRM infrastructure, this is typically accompanied by the requirement to associate data with the division or partner company in order to provide data security.
Siebel administrators can declare a division as an organization. This is done by simply checking the Organization Flag of a division. However, this change cannot be undone. Once the division is flagged as an organization and the record is saved, the flag becomes read only, as shown in the following screenshot:
We can decide which divisions within the organization chart should be flagged as organizations depending on the data security requirements defined by the project team. The result is typically a second hierarchy of organizations within the division hierarchy. Once an organization is created, Siebel data such as customer accounts, service requests, and so on can be associated with the organization. The following diagram shows how the divisions named Headquarter and Sales have been flagged as organizations. They are now part of the organization hierarchy.
By default, each new organization becomes subordinate to the "Default Organization", which the position of the Siebel Administrator (SADMIN) is assigned to. If data security policies mandate, we must set the Parent Organization field to an empty value in the Organizations view of the Administration - Group screen.
Even if a division cannot be associated to Siebel data, employees who have a position within that division are automatically associated with the nearest organization that can be located upwards in the division hierarchy.
In the above example, an employee who has a position in the AHA Sales North division will be associated with the Sales organization. The following screenshot shows the AHA Sales North division (note that the Organization Flag is unchecked) in the Internal Divisions view:
The Organization Name field displays the name of the nearest organization (AHA Sales) above the AHA Sales North division. Employees who are associated with a position in the AHA Sales North division will automatically be associated with the AHA Sales organization. They will therefore be able to see data associated with the AHA Sales organization and each record they create will be automatically associated with the AHA Sales organization.
Similar to divisions, organizations cannot be deleted. When organizational changes require it, a Siebel administrator must detach the non-existing organization or division from all parent records by emptying the parent division field and change the name to indicate the state of the organization or division. For example, the name can be prefixed with "NOT USED" to indicate that the division or organization no longer exists. Furthermore, records that are associated with an organization that no longer exists must be re-assigned to other organizations. This is typically achieved by using the Siebel Assignment Manager.
Mark at least one of the sample divisions you created earlier as an organization by setting the Organization Flag and saving the record.
Setting up and managing the position hierarchy
Employees are not associated directly with organizations. Siebel CRM uses a mechanism named positions to define both the association of an employee to an organization as well as the reporting relationship or hierarchy of the positions.
Positions represent a job entitlement for which people are recruited and subsequently paid. Employees can hold more than one position, for example to take over a colleague's job during vacation or sickness. Positions can also be held by multiple employees, which is unlikely for a CEO position but maybe more likely for sales representative or call center agent positions.
Each position can be assigned as a parent position to multiple child positions, thus enabling the administrator to create the so-called reporting hierarchy, which defines both the career level and the data access rights of an employee who is assigned to the position. The following diagram depicts a typical position hierarchy and indicates that each position must be assigned to exactly one division or organization:
Positions within a single hierarchy can be associated with divisions or organizations that might be unrelated to each other. This provides a high level of flexibility, which allows administrators to implement almost every organizational setup.
Administrators enter the position hierarchy with guidance from the documents delivered by the business analyst team in the Administration - Group screen's Positions view, which is shown in the following screenshot:
In the above example, the administrator has finished entering the positions depicted in the above diagram. The explorer applet allows administrators to verify the reporting hierarchy defi ned by the parent position field. The Division field is a mandatory field. It allows an administrator to select any division (marked as organization or not) and associate it with the position.
Use the example position hierarchy described above to implement sample positions in your demonstration environment.
Multiple positions for an employee
As indicated above, an employee can be associated with more than one position to allow, for example, the implementation of vacation replacement. When an employee holds more than one position, the Siebel application always uses the employee's primary position to determine the organization she or he belongs to during login.
In the User Preferences screen, the employee can use the Change Position view to switch from one position to another. However, in a single session, the employee can only hold one position at a time. The screenshot below shows the Change Position view:
The employee who is currently logged in holds two positions, one of which is marked as the active position. By selecting another position and clicking the Change Position button, the employee can switch to the other position, which might result in an association to a different organization.
Once the employee has switched to another position, she or he can use the same views as before but the data displayed will most likely differ because of the Siebel access control layer filtering the data for the employee's current position and organization.
Setting up user and employee accounts
As discussed above, each person who wants to use a Siebel CRM application must be registered as either a user or employee. The difference between user and employee is that employees are associated with at least one position.
User records are typically created for customers who register themselves in customer facing web applications such as Siebel eService or Siebel eSales. The workflows invoked during the user registration process ensure that user records are created and associated with the necessary responsibilities automatically.
In the following, we focus on managing employee accounts. The following task list guides an administrator through the procedure of setting up a new employee manually:
- Log in to the Siebel application using an administrative user account.
- Navigate to the Administration - User screen, Employees view.
- Create a new record and fill in the following fields (at least):
- First Name
- Last Name
- User ID (a unique user identifier for the employee)
- Responsibility (assign at least one responsibility to the employee)
- Position (assign at least one position to the employee)
- Time Zone (if the company deploys Siebel CRM across multiple time zones, associate the correct time zone with the employee)
- New Responsibility (empty this field if the employee is not responsible to create new users or employees)
- Password and Confirm Password (these fields are only writeable if directory server authentication is implemented)
- Save the record.
The following screenshot shows the form applet in the Employees view of the Administration - User screen:
The New Responsibility field defines the initial primary responsibility of any new user or employee that is created by the user or employee it is defined for. This is necessary for automated user registration where self-registering customers inherit the responsibility defined in the anonymous user account's New Responsibility field. The GUESTCST user for example, is used as the anonymous user for customer facing applications and has a "new responsibility" of "Web Registered User", which allows a customer who has registered her or himself to access more views than in anonymous mode.
Creating or verifying user accounts in the authentication system
Each employee or user must be authenticated by an external system that is either a relational database management system (RDBMS) or a directory server (LDAP or Microsoft Active Directory ).
For Siebel CRM implementations that use database authentication, a user account with the same username as defined in the User ID field must be created in the account management of the RDBMS.
If directory server authentication is implemented, the information entered in the Employees view of the Administration - Group screen is propagated to the directory server and a new directory server account will be created automatically for the employee or user.
It is among the Siebel administrator's duties to create or verify the respective accounts in the authentication system.
On your demonstration system, create a new employee account and ensure that the authentication system is updated accordingly. Test the new account by logging in to the Siebel application using the new employee's credentials.
In this article, we discussed the necessary steps to create the administrative data that allows people to log on to Siebel CRM applications as users or employees.
In Siebel terms, a user is a person who has a responsibility and who can log in to a Siebel application. An employee is a user who has a position within an organization. To enable fully functional data security, administrators must create organizations and positions before they can start creating employee accounts.
The article provided insight into the administrative views and the typical administrative tasks to manage divisions, organizations, positions, employees, and users.